Wednesday, July 27, 2011

ROP: some useful addresses

Return Oriented Programming is Turing complete which basically means you have every function you need to make your own program. This is true, but often very hard to realize. For such a reason attackers use to call specific functions to bypass DEP (NX bit) and then as soon as they can upload their own payload (for example a shellcode or meterpreter). Some of the most used function are addressed following.


VirtualAlloc() . On XP SP3 located in 0x7C809AF1 (kernel32.dll).
This function allocates new memory. One of the parameters to this function specifies the execution/access level of the newly allocated memory, so the goal is to set that value to EXECUTE_READWRITE. This function does not copy your payload into a new executable memory area, in order to copy yout payload you need to use memcpy() (ntdll.dll) – 0x7C901DB3 on XP SP3

HeapCreate() . On XP SP3, HeapCreate is located at 0x7C812C56 (kernel32.dll).
This function creates a private heap that can be used in our exploit. Space will be reserved in the virtual address space of the process. Then if you come from a stack based overflow you need to pivoting your memory (ESP and EBP lifting technique)


SetProcessDEPPolicy(). On XP SP3 is 0x7C8622A4 (kernel32.dll)
Works for : Windows XP SP3, Vista SP1 and Windows 2008. Bernardo Damele wrote a great blog post about exploiting through this function: here. This function sets on or off the DEP policy.


NtSetInformationProcess(). Works for : Windows XP, Vista SP0, Windows 2003. On XP SP3, NtSetInformationProcess() is located at 0x7C90DC9E (ntdll.dll). It sets executable a process.

VirtualProtect(). On XP SP3, VirtualProtect() is located at 0x7C801AD4 (kernel32.dll). More on Memory Protection here. This function changes the access protection of memory in the calling process.

WriteProcessMemory() On XP SP3, WriteProcessMemory() is located at 0x7C802213 (kernel32.dll). This function allows the attacker to copy his shellcode to another (executable) location so you can jump to it and execute it. During the copy, it makes sure the destination location is marked as writeable. How to use this function to bypass DEP protection is here.


This blog post wants to be an accessible spot in the Net where to find out those addresses within references on how to use them, it does not pretend to explain how to use them, for more explanation take a look to the this post . 

Sunday, July 24, 2011

ROP notes

I've been talking and giving refs about Return Oriented Programming as one of the main techniques to build exploits in the current "net era" (here). Today I want only share some general principles that often people tend to confuse (writing me tons of FB messages :P ). Probably next days I'll post something more on Gadgets exploiting.





Some general principles to keep in mind while thinking/using/writing about ROP.
  1. ROP exploiting techniques doesn't bypass ASLR protection but contrary are really useful for bypassing DEP (NX bit).
  2. The ROP gadgets are little piece of code spread in executable memory found by misalign code segment.
  3. Since DEP (NX bit) does not allow you to execute code from stack, hijacking EIP to your gadgets means to execute Gadget's code.
  4. There are many ways to use gadgets theoretically you might use gadgets to directly build on your memory a malware. ROP is Turing complete, but this takes so many time... Usually attackers use gadgets to disable DEP (NX bit) (like for example calling VirtualProtect() ) or to move the payload (typically a shellcode) into executable memory (like HEAP ).
  5. Every gadget must be driven from stack. So they need to return with a RETN.
  6. In order to move from Gadget to Gadget you have to use your ESP as your EIP. This is possible by using RETN. Here you have to remember that RETN = POP IP, which move ESP a word below (higher memory address space).
  7. By chaining two or more gadgets you are building a gadget's chain which will dynamically (by meaning of directly into the memory) overwrite the right parameters the stack.
  8. You always need to overflow something (lets say a stack). You always need to point to your starting gadget's chain, and you always need to put your favorite shallcode on memory.
  9. You might think to have two different chains of gadgets: (a) a preparatory chain which sets right values for the "execution functions" (for example VirtualProtect() ) and (b) gadgets that will effectively do what you want to do (again VirtualProtect example "(b)" ).
  10. Speaking about addresses, you always need to overwrite the first time EIP by overflowing, and you need to find the way to point to your ESP. You might do that by addressing directly to ESP (no ASLR) or using different techniques to JMP ESP (ASLR) like for example SEH or brute force (using NOPs).
  11. After the second chain of gadgets has been reached, the return address of the second gadget's chain (VirtualProtect()) must be the starting address of your shellcode.
I hope to have given you (all of you interested on ROP) some quick answers to better understand how ROP works. In the practice you will find much more issues like "padding gadgets" (each gadget with more then one POP) little-endian convention, NULL bytes issues, chaining issues, addresses issues and so forth... As soon as I find much time I will post a simple example of ROP, hoping to further clarify Gadget's exploiting process .

Friday, July 22, 2011

Debugging via Code Injection with Python

This morning I want to share this is awesome post: MindshaRE. Debugging code by injecting Python is a great and cheap idea . dvlabs in its post walks through an alternate way (python code injection) to perform the debugging process that can be abstracted to solve a bunch of different problems. Additionally, it offers didactic example code.


They use ctypes library which allows to load DLLs, to call DLL functions and to create/read/execute pieces of memory.... Have a good reading !

Wednesday, July 20, 2011

A great Password Study.

I am assuming that everybody knows LulzSec releases. Starting from this data Troy Hunt made a great work analyzing all the disclosed passwords. Some of the most interesting findings are the following ones:



As usual click on image to make it bigger.

So, lets focus on some results:
  1. 14% of the disclosed passwords are derived from the username.
  2. 8% of the disclosed passwords are derived from place names.
  3. 25% of the disclosed passwords even if are not places neither names are derived from dictionaries.
  4. 14% of the disclosed passwords are just numbers (variable length .. but composed only by numbers).
  5. 2.7% of the disclosed passwords are made from two words linked together.
  6. 2.6% of the disclosed passwords are derived from email addresses.
  7. 1.3% of the disclosed passwords are derived from short phrases.
  8. 0.7% of the disclosed passwords are derived from keyboard patterns (what is it ? A keyboard pattern is for example: "asdf" or "1234" ).
  9. 0.4% of the disclosed passwords are derived from the url or the site where they have been used.
  10. 31% of the disclosed passwords have no patterns at all.
Alright, what can we learn from that ? The answer is pretty easy ... A common brute forcer (and I am not talking about FPGA brute forcer or Advanced GPU brute forcer) equipped with a common CPU running a simple tool like John The Ripper or whatever he prefers might be able to break the 69% of the passwords in less than a day !! In fact passwords derived from usernames, passwords derived from keyboard patterns and passwords derived from email addresses are the first passwords to be tested from brute forcers like John (if used in hi-bird mode). Everything else derived from dictionary takes just some more hours. The Troy's works underlines how security is poorly implemented from common users and the need of having a much security educated governance. I hope to be able to transfer this message over my next conferences besides the technicalities of my papers that are useful and important but not essential like this message.

"It's not really important having the most innovative intrusion detection system if the network users adopt weak passwords."

If you are interested on more detailed results check out the original post here.

Should I Change My Password ?


This is an interesting project which aims to monitor all the compromised email dbs. If Anonymous or Lulzsec compromised a DB where your email accounts where stored, through it you might find out if your email address is still safe or not.

Tuesday, July 19, 2011

NIST Appendix J.

Hi Folks,
this morning I want to point out the new draft of Appendix J : "Privacy Control Catalog" written by NIST scientist.
Appendix J, Privacy Control Catalog, is a new addition to NIST’s family of standards and guidelines that will be incorporated into the 2011 update to Special Publication 800-53, Revision 4, projected for release in December 2011. Due to the importance and special nature of the material in this Appendix, it is being publicly vetted separately from the other changes to the publication which will be released later this year. The objectives of the Privacy Appendix are fourfold:
  • Provide a structured set of privacy controls, based on international standards and best practices, that help organizations enforce requirements deriving from federal privacy legislation, policies, regulations, directives, standards, and guidance;
  • Establish a linkage and relationship between privacy and security controls for purposes of enforcing respective privacy and security requirements which may overlap in concept and in implementation within federal information systems, programs, and organizations;
  • Demonstrate the applicability of the NIST Risk Management Framework in the selection, implementation, assessment, and monitoring of privacy controls deployed in federal information systems, programs, and organizations; and
  • Promote closer cooperation between privacy and security officials within the federal government to help achieve the objectives of senior leaders/executives in enforcing the requirements in federal privacy legislation, policies, regulations, directives, standards, and guidance.
The entire document can be found here.

Monday, July 18, 2011

A Simple Connect Back Shell

Hi folks,
today I want to share a little perl script that has been very useful in my past security experiences. It's a simple "Connect Back Shell". Nowadays computer are behind NAT and/or firewall which makes hard connecting to an exploited machine. For this reason the "connect back shell" is a simple script which binds a system shell (/bin/ssh) directly to a socket and then connects the socket to the attacker address.


(Click the image to make it bigger )

There are many ways to do the same thing, some of them are better then the current script but this way is the most simple and fast one. Obviously you need to inject this script on the attacked machine thus trigger it. With this script you need to assume perl environment installed on the target machine, correct rights etc... Metasploit PAYLOAD generator (tag -t exe) is another good way to make it as described here.

Hope this script could be useful to you guys ... at least to learn perl scripting ...

International Conference of Theory and Practice of Electronic Governance (ICEGOV 2011)


Hi Folks,
Marco Prandini and I are going to present a paper Titled: "Security considerations about the adoption of Web 2.0 technologies in sensitive eGovernment processes " in Tallin (Estonia) next October. If someone will be attending ICEGOV too, please shot me an email, we will have a "security" beer together ;).

Monday, July 11, 2011

Facebook Forensic

Hi Folks,
today I want to share this interesting paper on Facebook Forensics. Actually most of the paper it's a simple way to find out if in the analyzed machine there is at least a FB account. So it's nothing really exceptional at all, just memory and Hard Drive forensic, but it offers a great list of the used toolset and a nice presentation style with a lot of screen captures and examples.



While the first part could be obvious for most of you, the second part talks about Virtual Machine forensics. Again, it's not a specific paper on such a topic. Much more "deep" papers could be easily found on IEEExplorer or ACM or even in Google scholar (here, here, here, here, here and here) but it is a well written part, perfect for whom is seeking an easy and understandable example made from scratch. Have a nice reading !

Tuesday, July 5, 2011

ARP Dosser

Hi Folks,
since in these days seems to be fashion performing DOS attacks (I am obviously referring to the Anonymous Italy section, that seems to have just discovered LOIC) I am to publish a nice ARP dosser written in Perl.



(Click to make it bigger)

It is a quick and simple ARP dosser, you might start from here for building your own LAN multi protocol dosser

Friday, July 1, 2011

Top 25 Most Dangerous Software Errors (2011)

Hi folks, unfortunately this is a pretty busy time and I find any chance to update often my blog, anyway I think this is a pretty important reading, especially if you are a developer ...


Have a nice reading.