Thursday, October 27, 2011

ROP Chain for Windows 8

Today I want to share a really good blog post about Windows 8 ROP mitigation. As described here Windows 8 implements a simple protection mechanism which aims to check the %ESP. The testing stack happens by comparing %ESP register before calling new functions (switching frames). If ESP is in between StackBase (FS:[8]) and StackTop (FS:[4]), the stack address is assumed as valid and functions will continue to be executed. Otherwise, the stack is assumed as invalid and the program will be terminated. Following a fragment of the implemented code by Alex Ionescu:


As it might be simple to figure out, the attacker having the full control over the stack could firstly save %ESP (by using a gadgets for example) and secondly he could restore it directly on the stack before calling functions. Bikis describes a ROP chain able to exploit this theory in order to break Windows 8 countermeasure. They reused the Firefox vulnerability described here and its payload described here to build the Windows 8 ROP chain.  The described ROP chain is developed by following these steps:

  • Using msvcr71.dll – v7.10.3052.4 module
  • Integrated with: JRE (Java) 1.6
  • Loading with browser
  • Able to work on Windows XP/Vista/Win7/Win8/2003/2008
  • ASLR-free
  • Using kernel32.VirtualProtect function
  • Base: 0x7c340000.
  • Size 0×56000.
I've been testing their demo code too. Of course, I had to use their ROP chain instead of the old one when the change of the stack address was required for my ROP exploit code. In my test case the chain started with %EBX pointing to a valid stack area (i.e. between FS:[4] and FS:[8]), so it was pretty similar to the original one.

I think Bikis made a great job in developing this new ROP chain proving the inefficiency of Windows 8 countermeasure, it is for sure a "security byte" to remember.  Again another great example of "the eternal battle between attack and defense".

Tuesday, October 25, 2011

Amazon and Eucalyptus hacked.

Today I'd like to point out a paper entitled "All Your Clouds are Belong to us - Security Analysis of Cloud Management Interfaces"by Juraj Somorovsky et Al. 

In this paper, they provide a security analysis pertaining to the control interfaces of a large Public Cloud (Amazon) and a widely used Private Cloud software (Eucalyptus). Their research results are alarming: in regards to the Amazon EC2 and S3 services, the control interfaces could be compromised via the novel signature wrapping and advanced XSS techniques. Similarly, the Eucalyptus control interfaces were vulnerable to classical signature wrapping attacks, and had nearly no protection against XSS.

The following picture shows a classic XML Signature Wrapping Attack 

As shown in the figure, the original SOAP body element is moved to a newly added bogus wrapper element in the SOAP security header. Note that the moved body is still referenced by the signature using its identifierattribute Id="body". The signature is still cryptographically valid, as the body element in question has not been modified (but simply relocated). Subsequently, in order to make the SOAP message XML schema compliant, the attacker changes the identifier of the cogently placed SOAP body (in this example he uses Id="attack"). The filling of the empty SOAP body with bogus content can now begin, as any of the operations defined by the attacker can be effectively executed due to the successful signature verification.


The paper follows by describing the practical attacks on Amazon EC2 and on Eucalyptus specifying attack vectors and consequence of the designed attacks. Finally, the paper describes some countermeasures for the described attacks. The most important lesson learned from their analysis is that managing and maintaining the security of a cloud control system and interface is one of the most critical challenges for cloud system providers worldwide.

My personal opinion is that of course they did a pretty nice job with the vulnerability analysis even if they clearly did not use a specific "bug hunting" methodology. It would be quite interesting, at least to me, mapping what they found and the way they discovered it to the current penetration testing methodologies to see what kind of correlation is there. Such a great work without any contribution to the current methodologies might be "end to itself", like a single attacker that has experimented a vulnerability to a big system and finally found it. 

Thursday, October 20, 2011

Malware 2011

Hi Folks,
during the past days I have been in Puerto Rico presenting at Malware 2011. Well, Puerto Rico is an amazing place and the conference was a "cozy" and "worm" place to share knowledge about Malware. A small and "family conference" this is my definition of Malware 2011, and  for this particular reason it has been a very great one ! I had the pleasure to meet a lot of interesting people from Academia as well as from main Vendors. I totally suggest to attend to next Malware, 2012 because it is a great place where you might meet Academia and Professionals. Over many interesting papers today I suggest the winner of Malware 2011 -best paper award-  from Michalis Polychronakis and Angelos D. Keromitys titled: ROP Payload Detection Using Speculative Code Execution.


Overview of the scanning process. If the 4-byte value at the current position does not correspond to a mapped executable memory page, the sliding window advances one byte (a). When a valid address is found, EIP and esp are initialized appropriately and a new execution begins (b).



Their presented a way to detect ROP Payload Detection by executing the code. Their technique speculatively drives the execution of code that already exists in the address space of a targeted process, and identifies the execution of valid ROP code at runtime. They made experiments which demonstrated their theory.  Good Job guys !

Thursday, October 13, 2011

Bypassing Windows 7 ASLR

Hi Folks,
few days ago Stefan Le Berre from NES security labs wrote an interesting document about Windows 7 ASLR.  Most of my readers know that exploiting a randomized user space is quite difficult, and  I am sure they appreciated NES effort. In ASLR attackers are forced to use heap spraying and other padding techniques that make difficult the whole exploiting process. Keeping trace of the randomized address by rebooting the system many times is always a good solution for understanding how randomization works, but this time Microsoft made things in the right way making impossible a statistic attack over ASLR.

A first study to attempt to analyze the user space randomization came in September from Oleksiuk Dmytro who discovered that a static memory zone is always mapped at 0xFFDF0000 within RWX rights. This is pretty different from a statistic analysis on ASLR. Oleksiuk made a simple "show diff" of the memory contents over multiple system reboots. After a month or so, NES laboratories discovered that more areas are always statically allocated. The following picture shows (in green) the static allocated piece of memory.


Now, why this is such an important finding ? Well, if there are some static allocated memory spaces, it means you know what is in there ! And why is so important knowing what is in there ? Well you should know something about Return Oriented Programming  :D :D (if you don't please read some of my posts on ROP: here, here, here, here, here, here, here ). If you are familiar with it you know that by "ropping" you might find useful gadgets to build your own exploit! The "paper" (more then a paper it looks like a presentation slides) follows by saying they had issues on finding useful gadgets (they had some issues to use RET2LIBC attack). I wonder how they looked for ROP and how many misalignment bytes they used. Probably if they used more then one byte of misalignment they might find more useful gadgets ...  Anyway, they exploited the address space layout randomization by using the RWX rights over the memory static allocated addresses and by controlling one register.


By setting the desired instruction on a register (lets say %EAX) and %EBP to the next address they where able to control the stack. When the processor executes the instruction it will overwrite the next instruction by arbitrary values. If "POP %EAX" is the first value to set (see picture above) and last byte is "RETN" it is possible to force a new execution of the gadget over time. Making a loop.  For every loop it is possible to execute new data (for setting arguments or for setting up the stack)  and after loops it's possible to execute the shellcode.


NES laboratory made up a PoC. The above picture (taken from the original "paper") shows that what they did succeed in bypassing Windows 7 ASLR. Actually they didn't proved that the machine in which the PoC run was a Windows 7 machine ;), but we trust them ;). Again, I still did not test it, so I am not saying that it really works, I am only reporting on my personal blog an interesting piece of security history that I consider important to keep in mind. I suggest the reading as soon as they will come out with a full paper on the great work they did ! Good job Stefan !

Wednesday, October 12, 2011

Your Browser Matters

A very interesting project founded by Microsoft measures your browser security. It is called  your browser matters and analyzes IExplorer, Firefox and Chrome basing on 4 macro categories of attacks: 

  1. Dangerous Downloads
  2. Phishing Websites
  3. Attacks on Browsers
  4. Attacks on Websites
My old Firefox got reasonably quite low score (1.5 out of 4):




And if you want you can see what's the average of the browsers score.  It really surprised me:


Well, well, well a project founded by Microsoft which says that Internet Explorer is way long more safe (4 out of 4) then Google Chrome (2.5 out of 4) and Mozilla Firefox (2 out of 4)? Sound interesting, doesn't it ?  Anyway, I really would like to investigate how these tests have been chosen, for example why these tests and not others ? What about the "attack on your browser" section ? What attacks have been implemented ?How do they test them ? I actually have many more questions for them. BUT, beside my questions I do agree that it's a nice place where users can get a first security check. I bookmarked it, let's see if they will release some source code in the future ;) .

PS: Many Thanks to Wouter Rogiest for the typo in the title and in the body ;)



Another simple Backdoor Shell

Hi folks, this morning I am going to share a little and simple "backdoor shell" written in Perl.
This is nothing exceptional, really, but I think it is a perfect didactic script for everyone is approaching to the backdoor world (I am thinking now at students ... ;). So here it is:


Well, the most interesting part of the script is the way the standards output/input and error are redirected to the opened socket. This is the right way to redirecting strings (command results) directly through the connected socket. Beside that everything is pretty simple and straight. 

Sunday, October 9, 2011

Communication between multiple ARDUINO

Hi folks,
Today I want to show how it could be quite easy making two, or more, ARDUINO talking together. The used protocol is called I2C-bus protocol. I2C is a Master to Slave protocol in which the Master asks data to the Slave or it directly sends data to it. The Slave could only replay to the only Master without making any query. I2C protocol runs over analog pins, meaning that you will have much more digital pins free for your sensors.  Obviously if you need more analog pins (for example if you have analog sensors) I2C is not the right protocol for you. I often need more  digital pins then analog ones, so it perfectly works for me.

In the above example three ARDUINO (one Master and 2 slaves) are used to show how I2C-bus protocol works, but you might hang up to 128 ARDUINO. The only links you need to wire are SCL (System Clock), SDA (System Data) and GND (Common Ground). Optionally you might want to include a wire for a common VCC. In our example, made by a student of mine Samuele Solari the 3 ARDUINO are connected through pins A4 (SCL) and A5 (SDA) GND and VCC (5v).

Lets analyze a simple sketch which reads strings from Serial input (USB) and sends them to I2C-bus. The Master sketch looks like the following code:


The only needed library is Wire.h, already included into Arduino IDE. The setup procedure sets up the Wire library (Wire.begin) and starts up the Serial (9600 baudR). The loop procedure reads integers from serial input, prepares the Wire transmission to Slave1 (Slave1 is the first ARDUINO Slave given address) and sends byte (see the casting) to the first Slave. Thus it ends the wired transmission.

On the Slave side the sketch does the opposite task: it reads from I2c-bus and it sends out characters to USB serial output.



Again the only needed library is Wire.h. The setup procedure sets up the wire library giving its own address (const int Slave1 = 1; ), it sets up the serial communication (USB) and finally it sets up a event handler. Wire.h works with handlers rather then using the structured loop, this makes a so called "interrupted communication", in other words ARDUINO does not verifies the presence of bytes on the analog pin A5 by running the loop procedure, but it becomes "interrupted" as soon as a byte is available on analog pin A5. The sketch handler is called "receiveEvent", it loops over the number of available bytes and it sends to the serial (USB) the just received bytes.

Hope this will be useful, it has been really useful for me !

Friday, October 7, 2011

AmericanExpress and the hidden page.

This morning the Americanexpress company closed the door to the so lovely /us/admin/ page. If some  of you are not aware about the hidden debugging pages, to make it quick, AmericanExpress company collected cookies sessions to investigate their website news from users' prospective. A fancy but hidden debugging webpage were used to set the cookies to the tester's browser.  Here an example I took some days ago.




The funny story abut this page (that is actually described here for the first time) which makes me laugh is not really about the vulnerability that it is affected (really ? they hit an administration page without protection and they made it vulnerable too ??), but for the ingenuity of programmers that are still trusting to the net. Automatic scanners and Autonomic exploitation engines are always directed to such targets (for example: banks, credit card companies and so on..): why people are still thinking that hiding pages/codes/algorithms/etc. is a good solution against attacks  ?



Monday, October 3, 2011

ICEGov 2011 and Internet Voting.

It was a great conference: Tallinn is a very nice city and the organization has been just  perfect. Nice food, worm and cosy rooms, nice sessions and detailed conference information. So what is my post about ? My post is about Internet voting. A special session about internet voting during the last days opened my doubts on the ingenuity of people. Ingenuity often comes from disinformation. Disinformations about hacking, disinformation about security holes and disinformation about what the attacks can do in real life. I am not going to bore you writing about successful past attacks, but I am really interested on what Internet voting is for. 

Internet voting enables people to vote for their favorite candidate directly from home, or from coffee shops or wherever they prefer. The first main issue about "voting by home" is that voters can technically be able to prove what they voted for. This issues triggers the so called "covert channel attacks" where candidates can buy votes by asking proves of them. It's pretty obvious that letting the voting period be one week long does not prevent this kind of attack. Indeed the attacker might force voters to vote in the last day, he might install Malware on the voters computer to control what they voted for or he might gather people in the same room during the last voting "night" and force them to vote for a specific candidate. This scenario is pretty common, just lets try to think about organizations, political movements, religious groups etc. Kiosk election, theoretically, doesn't let you in the position of proving what you voted for. Cameras, cell phones, copy markers and whatever,  are not allowed in the kiosk room. States that enforce this laws put security checks before the poling stations, for example Iran, Iraq, some Africa states are well enforcing this law.


 

Another interesting issue that people that are using Internet voting don't care about is the trust of people platforms. When I asked: "  How do you deal with Malware  on voters computer ? ", Estonian's Internet Voting chief answered me: " We need to trust people !". This is false. Except few rare cases, people wont to install Malware on their own machines. Malware get installed for many different reasons but not because people want to install them on their computer. So it is not about trusting voters, is about trusting Internet, is about trusting the entire world, even enemies that might hire hackers to compromise your elections. A well studied malware can easily change the vote directly on the voter's machine without the voters know it; it can easily try to compromise the election server and it can easily monitor what you voted for. Even more complicated is when a voter uses an Internet caffe. In this scenario the Internet Voting system must trust a "mercenary" machine. Where with the word "mercenary" I mean a machine that has been used by many different people, potentially used by attackers too. In a well implemented kiosk systems (where voters are checked before getting close to the system) this scenario is not possible since the kiosk operative system is controlled and enforced.



Another huge problem about voting from home, even if by using smart-cards or identification tokens is about "family voting". In other words smart-cards, if used in the way many Internet voting systems are doing, can be borrowed to friends, family members and group leaders. A smart card if used "at home" does not identify the voter, it identifies the cardholder (the same problem we had with credit card bearer). The result is that the cardholder can vote for the real voter. In a kiosk system this cannot happen since pol workers identify the real voter and control that his card is with his name on it.




At this point people can think about paper mail systems. They do allows these insecurity levels too. But again, it is not an excuse to say: "they do bad I can do bad as well". What's the point here ? We are talking about democracy, and as we all know, who leads the democracy of a country can have a huge impact to the real life of citizens.

I am not saying that Internet voting is totally wrong and that we should never use it. I do believe that Internet voting is the future, it increases participation, it easy to manage, it is economic and cheaper then a paper system, it is fast and potentially with low errors rate. My point here  is that right now we don't have enough tools to ensure democracy,  if using Internet voting systems. Internet voting is good, even nowadays, but for "secondary" elections not for "primary ones". "Secondary" elections can be a great test cases for Internet voting systems but letting the presidential election to the hands of Internet voting system could be very dangerous.