blog trackingRealtime Web Statistics Beast Archives | Gregory D. Evans | Worlds No. 1 Security Consultant | Gregory D. Evans | Worlds No. 1 Security Consultant

Posts Tagged ‘Beast’

Michael Noel Prescott BEAST 666 SEX SLAVE SATANIST

canada will not tolerate THIS SHIT ___________________________ Read More….

View full post on Select From Our Menu

90% SSL sites vulnerable to the BEAST SSL attack

90% of the Internet’s top 200,000 HTTPS-enabled websites are vulnerable to known types of SSL (Secure Sockets Layer) attack, according to a report released Thursday by the Trustworthy Internet Movement (TIM), a nonprofit organization dedicated …

View full post on National Cyber Security » Computer Hacking

Microsoft fixes Duqu hole, but not BEAST problem

Microsoft pulls patch to protect IE users from flaw in SSL protocol after running into compatibility issue.

View full post on bank security hacker — Yahoo! News Search Results

View full post on National Cyber Security

Beauty and the BEAST, (Mon, Oct 3rd)

(This is a bit longer diary – if you are just interested in conclusion and recommendations, skip below to the “Is SSL broken?” section. I recommend that you read the whole diary – and let us know if you have any comments).

Unless you’ve been hiding on a deserted island, you heard about the latest attack on SSL, named BEAST. We wrote several diaries (first, second, third) on this topic. I got interested into the attack a lot and finally had some time to go through all the details.

So, first of all – big props to Duong and Rizzo for implementing this in practice. While the idea itself is really cool (a bit more about it below), the implementation is what really impressed me, and all the effort they invested into the research here.

Some basics about the attack

As has been already written on million places, the BEAST attack attacks SSL 3.0 and TLS 1.0, in particular their implementation  of the Cipher-block chaining (CBC) block encryption algorithms.

This is probably the most widely used mode for block encryption algorithms today, so it is obvious that any attack on this (and SSL/TLS overall) can have huge impact.

In a nutshell, BEAST very cleverly uses predictable IV (initialization vector) values in order to set up particular input vales for SSL. By very carefully modifying these input values, the attacker can exploit BEAST to guess what value 1 byte in an encrypted block had. Block encryption algorithms fragment input messages into blocks, usually 8 or 16 bytes long.

The IV is initially a random number and then every next block uses the previous cipher text as the IV. The IV is XORed with the input plain text – this produces input for the encryption algorithm. So normally, in a block encryption algorithm, encrypted block C4 = encryption ( C3 XOR P4), where C is an encrypted block and P is a plain text block.

According to this, the last blocks (CN) IV will be CN-1: CN = encryption (CN-1 XOR PN). Doung and Rizzo cleverly used this so they leave the channel open and add the next block (N+1) whose content will be of one of the previous blocks. Imagine that we supply P4 (with only 1 byte modified), XORed with CN and it’s original C3:

CN+1 = encryption ( CN XOR ( CN XOR C3 XOR P4 ))

This results in:

CN+1 = encryption ( C3 XOR P4)

For which we know the result as it is C4! Now, if we can influence P4 to give us the opportunity of guessing one byte (by supplying, for example, 7 known bytes) we can try to guess what the last byte was: if CN+1 is equal C4, we guessed the byte, otherwise we didn’t.

This is just a brief overview – for more information read the leaked paper – it is written very well.

Guessing HTTP values

As you’ve seen above, the attacker can now guess byte by byte. With HTTP creating this boundary is actually simple since we know what each HTTP request will look like:


If we want to guess the first character of Header, we can make the previous line 23 bytes long (if blocks are 8 bytes each):


Notice how only H will make it into the 3rd block. The attacker now knows the content of the first two blocks and can try to guess the first character by using the attack described above.

Attack prerequisites and implementation

As if the attack itself was not impressive enough, Doung and Rizzo managed to actually do all this in the browser. Let us revisit what they have to do for this attack:

  1. They need to pull a MITM attack on the victim. This is needed for two things: first, they need to monitor the network traffic in order to guess bytes. Second, they need to somehow influence the browser to make it issue requests such as the one shown above that will let them do the guessing. For the demo they used a Java applet, but there are other ways of exploiting this (more below).
  2. Once they injected the Java applet into the victim’s browser, they wait for the victim to log in to the target site. Now the Java applet will open an SSL connection to the target site and send a specially crafted request as above (i.e. GET /AAAAAAA …). The SSL connection must stay opened so they can feed new blocks in real time, as they monitor network traffic. This will allow them to guess content of bytes encrypted by the browser. So, their Oracle in this case is the browser itself – the web server that they are attacking is irrelevant, it is the victim’s browser that let’s them guess encrypted content.

As you can see from 2), the crucial requirement is that the SSL connection is open (so they are able to append the data and use the last block as the IV). This proved to be very difficult to do (and is one of the things in Doung’s and Rizzo’s research that impressed me the most).

There are many ways that can be used in a browser to open a new connection. The easiest way is to use JavaScript’s XmlHttpRequest (XHR). There are some limitations here though. First, Internet Explorer does not support XmlHttpRequest level 2 (which is needed in order to send cookies) and instead has an XDomainRequest object. XDomainRequest will never send cookies so, in theory, Internet Explorer users are more protected than Mozilla Firefox or Chrome users (is this a first or what!?!).

Firefox and Chrome support XHR level 2. It is worth pointing out here that the attacker is not able to read the request through active scripting due to the fact that the server will not set the correct Access-Control-Allow-Origin header, but the attacker does not care about that since he just wants to be able to use the browser as an Oracle for guessing encrypted stuff.

The biggest problem with this is, it appears, that XHR cannot be used to create streaming requests, which are needed to perform the guessing. Many other possible exploitation vectors, such as plain IFRAMEs, Websockets or Silverlight have similar issues that prevented Doung and Rizzo from using them – keep in mind that this does not mean these are “safe” against BEAST, just that current attempts to use them failed.

Is SSL broken?

Simple question, simple answer – NO. As you can see above, there are many prerequisites that the attacker needs to do in order to conduct the BEAST attack.

While the attack is inherent to block encryption algorithms, it requires the attacker to be able to append these specially crafted input blocks into an active session. In other words, it is very difficult, or impossible to exploit BEAST on other protocols that use SSL, such as POP3s, IMAPs and similar. Doung and Rizzo did it with browsers because there are many scripting (extending) possibilities with browsers and the HTTP protocol.

Couple of things I would suggest doing:
–    Be careful about switching to TLS 1.1 or TLS 1.2 because you might break things for many clients. While this definitely fixes the vulnerability, be very careful.

–    Move to RC4 over CBC. RC4 has also its own issues but just the fact that Google prefers RC4 says something too – you can use the nice sslscan utility to see what ciphers are supported by a server, here are the results for
# sslscan –no-failed
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | ‘_
          __ __ __ (_| (_| | | | |
          |___/___/_|___/_____,_|_| |_|

                  Version 1.8.2
        Copyright Ian Ventura-Whiting 2009

Testing SSL server on port 443

  Supported Server Cipher(s):
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):
    SSLv3  128 bits  RC4-SHA
    TLSv1  128 bits  RC4-SHA

–    Do not accept any unsigned Java applets and allow them to run. You should always do this, not only in this case. Same goes for any other active technology.

–    When accessing sensitive sites, close all browser windows (not tabs, all windows) and open a fresh new one and use it only to access the sensitive site. After you’re done, close it again and reopen it for further surfing. This should make exploitation a bit difficult, but keep in mind that as of Java 6 Update 10 an attacker can potentially trick a victim into dragging applets out of browser windows so they continue running after the browser is closed (I’m not sure if this can be used to help BEAST).

–    If you are a sensitive server owner – keep an eye on errors on your server. The BEAST attack needs to issue quite a bit of requests (generally each byte has a 1/256 chance of being guessed, so in average 128 blocks need to be appended to a single request). One request is needed for a byte so if you see a lot of 404 requests with similar patterns (/AAAAA) that should raise some flags. Of course, you should always monitor and correlate your logs, not only now :)

At the end, I must again admit I like the attack a lot — the idea is really cool, amazing how they came up with everything. That being said, as you can see above, there are a lot of prerequisites for successful exploitation so I don’t think that the resulting risk is very high at the moment.


Article source:

View full post on National Cyber Security

Security Solutions for Beast attack against SSL/TLS Vulnerability

Article source:

View full post on National Cyber Security » Computer Hacking

Gregory Evans | LinkedIn

Interview With Gregory Evans

Gregory Evans Security Expert

Gregory Evans on Cyber Crime

My Twitter

  • RT @GregoryDEvans: UK’s Top Police Warn That Modding Games May Turn Kids into Hackers #security #hacker #HTCS
    about 1 hour ago
  • RT @GregoryDEvans: Oops. Apple has seriously weakened iOS 10 backups against password hackers
    about 3 hours ago
  • RT @GregoryDEvans: #galaxylife #samsung4life UK police arrest man in Pippa Middleton royal photo ‘hack’
    about 4 hours ago
  • RT @GregoryDEvans: UK police arrest man in Pippa Middleton royal photo ‘hack’
    about 5 hours ago
  • RT @GregoryDEvans: Flexible Seating for Secondary
    about 6 hours ago By Gregory D. Evans

Hacker For Hire By Gregory Evans

Gregory D. Evans On Facebook

Parent Securty By Gregory D. Evans

National Cyber Security By Gregory D. Evans

Dating Scams By Gregory Evans