[Goodies]

So, I know it's been a while since I've don an ASM tutorial like this, but I may need to get back into it for my work, so would anyone be interested in more of this? Exploit development is important and ASM is a key feature in it.

[Goodies]

No? No one is interested in writing basic shellcode? K.

[ＡｎｏｎＲｏｂｏｔ]

I have some knowledge of ASM but this has motivated me to learn more so I can actually interpret this.
Thank you op you did a great job writing this.

---

actually what does a TCP Bind Shell i tried to research it but nothing came up.

[Goodies]

actually what does a TCP Bind Shell i tried to research it but nothing came up.

It will duplicate the stdin, stdout, and stderr standard file descriptors to the socket and execute /bin/sh allowing you to execute commands remotely and see the output. However, a BIND shell will bind to a address:port to which you have to manually connect. A REVERSE shell will connect back to you :)

[SIM-1866423]

Did u upload new tutorials ?, ı want see all of them pm me :)

[cybercoder]

HQ post. Thanks for posting mate. Learned some new things.

[SIM-1866423]

I'm starting now .. I hope I can create my own too hehe.

[Goodies]

Thanks for the post! I know this is old, but it's by no means depreciated and I hope people can still get use out of this.

Keep in mind that this is by no means advanced and meant to be only a slight introduction to bind shells. This connection will certainly show up in Netstat and so on, so don't think you're hidden,

[SIM-1866423]

Thanks for the post! I know this is old, but it's by no means depreciated and I hope people can still get use out of this.

Keep in mind that this is by no means advanced and meant to be only a slight introduction to bind shells. This connection will certainly show up in Netstat and so on, so don't think you're hidden,

You can fuck down 1-2 min in all server who care hide ? 😏

[Goodies]

You can fuck down 1-2 min in all server who care hide ? 😏

Probably the police.
Not that memory corruption is all that common now.

[xorl]

Probably the police.
Not that memory corruption is all that common now.

2015-06-23 - CVE-2015-3113 - Flash - "Heap-based buffer overflow in Adobe Flash Player before 13.0.0.296 and 14.x through 18.x before 18.0.0.194 on Windows and OS X and before 11.2.202.468 on Linux allows remote attackers to execute arbitrary code via unspecified vectors, as exploited in the wild in June 2015."

2015-05-14 - CVE-2015-2717 - Firefox - "Integer overflow in libstagefright in Mozilla Firefox before 38.0 allows remote attackers to execute arbitrary code or cause a denial of service (heap-based buffer overflow and out-of-bounds read) via an MP4 video file containing invalid metadata."

2015-01-27 - CVE-2015-1360 - Chrome - "Skia, as used in Google Chrome before 40.0.2214.91, allows remote attackers to cause a denial of service (buffer over-read) or possibly have unspecified other impact via crafted data that is improperly handled during text drawing, related to gpu/GrBitmapTextContext.cpp and gpu/GrDistanceFieldTextContext.cpp, a different vulnerability than CVE-2015-1205."

2015-06-09 - CVE-2015-1766 - Internet Explorer - "Microsoft Internet Explorer 6 through 11 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Internet Explorer Memory Corruption Vulnerability," a different vulnerability than CVE-2015-1735, CVE-2015-1740, CVE-2015-1744, and CVE-2015-1745."

2015-05-13 - CVE-2015-3076 - Adobe Reader - "Adobe Reader and Acrobat 10.x before 10.1.14 and 11.x before 11.0.11 on Windows and OS X allow attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2014-9161, CVE-2015-3046, CVE-2015-3049, CVE-2015-3050, CVE-2015-3051, CVE-2015-3052, CVE-2015-3056, CVE-2015-3057, and CVE-2015-3070."

2015-06-09 - CVE-2015-1760 - MS Office - "Microsoft Office Compatibility Pack SP3, Office 2010 SP2, Office 2013 SP1, and Office 2013 RT SP1 allow remote attackers to execute arbitrary code via a crafted Office document, aka "Microsoft Office Memory Corruption Vulnerability.""

2015-06-07 - CVE-2015-4002 - Linux Kernel - "drivers/staging/ozwpan/ozusbsvc1.c in the OZWPAN driver in the Linux kernel through 4.0.5 does not ensure that certain length values are sufficiently large, which allows remote attackers to cause a denial of service (system crash or large loop) or possibly execute arbitrary code via a crafted packet, related to the (1) oz_usb_rx and (2) oz_usb_handle_ep_data functions."

ok :)

[Goodies]

Dumb (Click to View)
2015-06-23 - CVE-2015-3113 - Flash - "Heap-based buffer overflow in Adobe Flash Player before 13.0.0.296 and 14.x through 18.x before 18.0.0.194 on Windows and OS X and before 11.2.202.468 on Linux allows remote attackers to execute arbitrary code via unspecified vectors, as exploited in the wild in June 2015."

2015-05-14 - CVE-2015-2717 - Firefox - "Integer overflow in libstagefright in Mozilla Firefox before 38.0 allows remote attackers to execute arbitrary code or cause a denial of service (heap-based buffer overflow and out-of-bounds read) via an MP4 video file containing invalid metadata."

2015-01-27 - CVE-2015-1360 - Chrome - "Skia, as used in Google Chrome before 40.0.2214.91, allows remote attackers to cause a denial of service (buffer over-read) or possibly have unspecified other impact via crafted data that is improperly handled during text drawing, related to gpu/GrBitmapTextContext.cpp and gpu/GrDistanceFieldTextContext.cpp, a different vulnerability than CVE-2015-1205."

2015-06-09 - CVE-2015-1766 - Internet Explorer - "Microsoft Internet Explorer 6 through 11 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Internet Explorer Memory Corruption Vulnerability," a different vulnerability than CVE-2015-1735, CVE-2015-1740, CVE-2015-1744, and CVE-2015-1745."

2015-05-13 - CVE-2015-3076 - Adobe Reader - "Adobe Reader and Acrobat 10.x before 10.1.14 and 11.x before 11.0.11 on Windows and OS X allow attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2014-9161, CVE-2015-3046, CVE-2015-3049, CVE-2015-3050, CVE-2015-3051, CVE-2015-3052, CVE-2015-3056, CVE-2015-3057, and CVE-2015-3070."

2015-06-09 - CVE-2015-1760 - MS Office - "Microsoft Office Compatibility Pack SP3, Office 2010 SP2, Office 2013 SP1, and Office 2013 RT SP1 allow remote attackers to execute arbitrary code via a crafted Office document, aka "Microsoft Office Memory Corruption Vulnerability.""

2015-06-07 - CVE-2015-4002 - Linux Kernel - "drivers/staging/ozwpan/ozusbsvc1.c in the OZWPAN driver in the Linux kernel through 4.0.5 does not ensure that certain length values are sufficiently large, which allows remote attackers to cause a denial of service (system crash or large loop) or possibly execute arbitrary code via a crafted packet, related to the (1) oz_usb_rx and (2) oz_usb_handle_ep_data functions."

ok :)

It might do you well to actually read the words that I wrote, not the words you think I wrote, and respond to the claim that I'm making. Look at the relative percentage of memory corruption leading to RCE 5-10 years ago and then look at the advancements in BOF/memory protection in the newer operating systems. Exploiting older versions of flash is not what I'm talking about and you should know that.

Just because the exploits come out in 2015 doesn't mean that they are new exploits if they are aimed toward outdated versions.

And even the ones that are up to date, I specifically said that they are not as common anymore. That doesn't mean you will never find another mem corruption vulnerability.

[xorl]

It might do you well to actually read the words that I wrote, not the words you think I wrote, and respond to the claim that I'm making. Look at the relative percentage of memory corruption leading to RCE 5-10 years ago and then look at the advancements in BOF/memory protection in the newer operating systems. Exploiting older versions of flash is not what I'm talking about and you should know that.

Just because the exploits come out in 2015 doesn't mean that they are new exploits if they are aimed toward outdated versions.

And even the ones that are up to date, I specifically said that they are not as common anymore. That doesn't mean you will never find another mem corruption vulnerability.

It might do you well to actually read the words that I wrote, not the words you think I wrote, and respond to the claim that I'm making.

ok

Look at the relative percentage of memory corruption leading to RCE 5-10 years ago

you said "Not that memory corruption is all that common now." not "not that memory corruption is as common now as it used to be"
also, just because it doesn't lead to RCE doesn't mean it's not a memory corruption or that it's not exploitable

then look at the advancements in BOF/memory protection in the newer operating systems.

i fail to see how exploit mitigations (which does just that, MITIGATE, not stop exploitation) has anything to do with whether memory corruption is still common or not
that's like saying a WAF will remove web vulnerabilities, there are always ways to bypass it

Exploiting older versions of flash is not what I'm talking about and you should know that. Just because the exploits come out in 2015 doesn't mean that they are new exploits if they are aimed toward outdated versions.

the current version for flash player is 18.0.0.194, that exploits Adobe Flash Player before 13.0.0.296 and 14.x through 18.x before 18.0.0.194 on Windows. I wouldn't really say that's outdated especially since we all know people do not update their shit

[Goodies]

You're obviously a decently smart person, but let's just take a look at this.

ok

Great.

you said "Not that memory corruption is all that common now." not "not that memory corruption is as common now as it used to be"
also, just because it doesn't lead to RCE doesn't mean it's not a memory corruption or that it's not exploitable

The key word in that sentence is "now." Although I would readily admit that my sentence is a colloquialism, and as such I wouldn't write it in such an unclear fashion to anyone in a more intellectual context, it is nonetheless implicative, at least colloquially, of the fact that it was different in the past. For example, the phrase "I don't drink now." would generally be interpreted as "I used to drink, but I don't drink now." Otherwise, the word 'now' would be entirely extraneous and lead to nothing but confusion.

Secondly, not that this is by any means unanswerable, but I am curious as to what you (personally) would be able to do with a memory corruption vulnerability that does not become code execution.

i fail to see how exploit mitigations (which does just that, MITIGATE, not stop exploitation) has anything to do with whether memory corruption is still common or not
that's like saying a WAF will remove web vulnerabilities, there are always ways to bypass it

You cannot be serious. The very definition of the word "mitigate," namely "make less severe, serious, or painful," implies that fewer people would be able to continue it. Only those that are more persistent and, at least somewhat, skilled would be able to create exploits for them. Never did I say that it removes the possibility entirely, although in some cases it can.

What is your infatuation with equivocating an existential claim like "some vulnerabilities will be less common" with a Universal claim like "ALL vulnerabilities will be stopped"? It's absurd and you're creating straw men to attack.

For example:

• One would find that a system with no mitigations would be full of corruption exploits
  
• A system with ASLR would be vulnerable to comparatively fewer since knowing the entry point of the application is often important. However, obviously certain circumventions of this like utilizing non-ASLR libraries for finding gadgets like returning to a register, etc...
  
• OSes with DEP/NX enabled would mitigate even more attacks as they would disallow execution on the stack. Of course using ROP gadgets to, say, allocate virtual memory with RWX permissions and use RtlMoveMemory to move your payload in would be one way around this. However, this is by no means a banal course of action and does require time.
  
• Programs compiled with the /GS switch, for example, may be more difficult still since they can detect when you overwrite frame/stack pointers, but overwriting SEH records to use your own code as an exception handler can bypass this.
  
• SEHOP, however, marked the end of reliable remote memory corruption for me. By itself, it isn't anything special, but I have yet to find a reliable way to keep it from returning to the kernel exception handler without knowing the entry point of other modules.
  

Take, for example, an exploit whose nature relied on the fact that the attacker knew the hard-coded entry point of the application which uses no non-ASLR libraries. Once ASLR is enabled, it becomes virtually impossible, or at least highly improbable, to continue this attack. One might create a large NOP sled and overwrite only part of the EIP, thus returning to a semi-known range of memory, but this isn't exactly reliable. But now that all of the libraries' entry points are obscured and you have no reliable way of determining the locations of ROP gadgets or anything of the sort, the exploit becomes much harder.

Yes, it's only a mitigation, but it is intended to prevent people from having reliable exploits, which I believe that it does in many cases.

the current version for flash player is 18.0.0.194, that exploits Adobe Flash Player before 13.0.0.296 and 14.x through 18.x before 18.0.0.194 on Windows. I wouldn't really say that's outdated especially since we all know people do not update their shit

First and foremost, I'm a network engineer. My entire job pertains to looking at attacks and connectivity within a network and between devices. All of the things I've written here could easily be outdated or simply incorrect, and I have no disillusions about my own skill. Anything host-based is merely an interest of mine.

Secondly, I already addressed this. Never did I say that they would be non-existent, but rather that they would be comparatively less common, which they unarguably are. That point by itself renders your entire counter-argument moot. I am well-aware of the fact that people do not update their programs, and if your goal is to attack these low-priority targets in insecure environments, then by all means, learn BOF. However, if you are interested at all in higher priority targets, you can't simply use BOF.

Why don't you set up an isolated server on Windows 2012R2 that you can access remotely. Then you can enable all the common security features (ASLR, DEP and SEHOP are on by default in 2012 R2), and enable EMET, sandbox your server applications, set up a host-based intrusion detection system, and then run a completely vulnerable FTP server or something and you tell me when you think you have an exploit. These are the types of secure environments that I'm talking about. Not Joe's porn-filled laptop using an outdated flash version.

You're better off trying to find vulnerabilities in frameworks: django, CF, MyBB, RabbitMQ, Celery, and so on...

Would you not agree?

[ras4sc]

"I am well-aware of the fact that people do not update their programs, and if your goal is to attack these low-priority targets in insecure environments, then by all means, learn BOF. "

This is a very absurd thing to say. Do you not see the results from pwn2own every year? Just this year there was one lone man who could get code execution on any box, completely bypassing all protections, for IE, Firefox, Safari, and Chrome. I can promise you this guy did not stop learning, just because "they're becoming uncommon". With your attitude you won't reach a stage like this.

Yes, alone, the protections are useless and when chained together it can be a pain in the ass to bypass, but it's still possible many times. Have a look at this case:

vreugdenhilresearch . nl/ms11-002-pwn2own-heap-overflow/
ROP gadgets and pointer leaks are not all there is to bypassing protections, dude. These protections are here to help reduce the risk of the overflow, but the overflow has already happened. More protections may come, but, many times, they come with new ways to bypass. When some of these protections were first introduced, this left most people at a stand still. But eventually, with persistence, people found a way.

As long as someone answers no to the question, "Do you write perfect code?", it will always be worth learning about BOF's. Idiot programmers are still out there. And that includes us, too. It's not easy to write secure code.

What worries me the most is that you say people should not be learning buffer overflows. BOF's are not only useful for exploiting, but they serve as a good model for security concepts. They also are a stepping stone onto more advanced things such as kernel bugs.

Yes, BOF's may have decreased in numbers over the past years, but that's with every vulnerability. In fact, why bother with things such as SQL injection in that case? They are getting harder to find.