Cenzic 232 Patent
Paid Advertising
web application security lab

Man in the Middle

There has been a lot going on in the man in the middle space over the last few months. Frankly - I’m impressed. It’s something I haven’t talked much about publicly, but rather something I like to talk about to people at conferences. In fact, some of the innovations in the space is stuff I’ve been trying to get guys like Robert Graham and Dave Maynor to write into ferret for years now. That said, there has finally been some major leaps forward in actual technology to empower really nasty MITM attacks.

One thing I’ve been annoyed with is that although MITM is technically possible, and indeed has even been demonstrated in lab environments a lot, it’s really not all that common, unless you’re talking about passive listening. There’s not a lot of programs that use MITM to actually modify traffic. Modifying it is where you get a lot more bang for your buck. There’s a good paper over at Watchfire about why active man in the middle attacks can give you a lot more. In fact, some of what’s in this paper was actually demonstrate by Rich Mogull at DefCon last year. No one was probably paying any mind to the analyst but that guy is ahead of his time, let me tell you! He was creating iframes to things like the gmail contact list and addresses from yahoo. Cool stuff - and that was just an evil twin.

Also there are a few newish tools that are really important in this space. I think both need to evolve a bit, but they’re both open source, written in python, easy to modify and do 90% of the heavy lifting. So in my mind, active MITM attacks are finally really viable for the average attacker. The first tool is SSL strip written by Moxy. It does a great job of showing how you can just down-convert into an HTTP mode, and most of the time users won’t notice - especially on pages that just post to HTTPS (a huge pet peeve of mine).

The second tool is Middler written by Jay Beale. Jay took the concept to the next level and actually built in most of the DNS spoofing/ARP spoofing part of the attack that you need, so you don’t have to run separate programs to get the attack working. Both programs deserve a lot of praise for getting this attack to be more widely understood and realistic and beyond the passive sniffing that we are all accustomed to with tools like ferret and dsniff. Sure, the concept of a MITM attack is nowhere near new, but now it’s finally accessible to the average attacker - which means it’s something we should really start thinking about, beyond saying HTTPS is a solution to our problems - clearly it is not (and for a lot more reasons than Moxy went into too).

20 Responses to “Man in the Middle”

  1. peeved Says:

    On 15/1/2009 you wrote a great article called Crime and Punishment. I found myself agreeing with you, thinking it was about time someone started to take the fight up to the people who chose computer crime as a way of life.
    Very disappointed to see you promoting it here. All these people that claim to be researching in the name of good are just providing tools for the brainless idiots out there.
    Browning, Colt, Glock, Armalite provide us with protection by mass production of firearms. I’m sure they have very good reasons for doing it. Bottom line is these tools end up in the hands of the wrong people with devastating effects.
    Just like the development of firearms, the development hacking tools should be frowned upon and outlawed and the people responsible for providing these tools should be jailed or flogged or something.

  2. RSnake Says:

    @peeved - I think your taking my post out of context. I’m not saying bad guys should use it. I’m saying it finally shows that what were were theorizing about all these years is actually practical. More importantly it shows why we should stop promoting technologies (like SSL) that are really built on a house of cards. It’s time to start looking for alternatives before it really becomes a mainstream problem. I think their tools are an exercise in awareness.

    However, one thing I need to make clear, I don’t think developing tools is the problem, nor do I think research is the problem. I think the use of the tools and the research is the problem. If we don’t iterate on our knowledge publicly the only people who will know how to attack (and therefore defend) will be the people who shouldn’t have the knowledge.

  3. Jim Manico Says:

    “stop promoting technologies (like SSL) that are really built on a house of cards” is an irresponsible alarmist statement. With today’s technology, we need to encourage properly configured SSL in all risk-adverse web applications. SSL 3/TLS 1 + strong cipher suites on both ends. I put this posting in the “sensationalist” category as do many others.

    SSL is NOT appropriate for Authentication, in my opinion. But SSL for transport security? Right on- we get Confidentiality and Integrity. We will NOT scrap SSL today because it does not solve all problems.

  4. RSnake Says:

    @Jim Manico - I don’t think it’s irresponsible or alarmist, I think you are reading this out of context. I’m not telling my grandma to stop using it. And I’m not telling my bank to turn it off. I’m saying the vast majority of implementations have serious flaws, they’re not easy to fix, the infrastructure itself has massive issues, and it doesn’t solve the primary issue it was constructed to solve. This was a commentary meant to talk to the browser/infrastructure community - not you or a mom and pa website.

  5. Jim Manico Says:

    “More importantly it shows why we should stop promoting technologies (like SSL) that are really built on a house of cards.”

    Ok, will you give me, at least, that is a little “over the top?”

    We need to promote the proper use of SSL; not just flat out call it a house of cards!!

  6. Jim Manico Says:

    And by the way…

    The proper use of SSL is always a moving target, as the recent blackhat preso demonstrated. =)

  7. rvdh Says:

    Always beware of the female in the middle. ;)

  8. RSnake Says:

    @Jim - no, not over the top. Just because you think it’s a good idea doesn’t mean it’s not incredibly flawed. There’s a lot more wrong with browser implementations of SSL than his speech goes into. In fact, Moxy even said so in his speech. Frankly, SSL is only useful if an attacker has no clue about the problems and/or if the person who is being MITM’d actually knows that they are doing. The second condition is very unlikely, so you are essentially putting all your hopes on the fact that attackers wont get better educated about the issue. If either of those conditions fail, a MITM attack can easily get around HTTPS in the browser. So if that makes browser implementations of SSL/TLS not a house of cards - the primary purpose of which has been almost completely defeated - sure, my statements are over the top. If you still believe that HTTPS makes your average person safe in the face of a determined adversary/man in the middle, I have a bridge to sell you.

  9. Saph Says:

    By all regards, if tools are not produced and distributed to show when security measures are no longer sufficient, there is very little force to influence their further development. It is the malicious individuals that act as a catalyst for the market of security tools, ranging from algorithms for cryptography, implementations of them, authentication and ultimately, how business gets done. Let’s consider what aircrack-ng has done with regards to implementation of WPA/WPA2 or dsniff for SHA2 (soon to be SHA3), if these tools aren’t out and publicized, then that doesn’t mean they’re any less available. Besides, I personally find browsing my logs and seeing an attempted login from Chile, using some default account info rather exciting.

  10. Jim Manico Says:

    So Robert, are you saying that we should stop teaching developers to use properly configured SSL for transport security? I’m eager to hear a better alternative from you. Oh, and by the way, how come you are using SSL on the login portion of your site, if it’s just a house of cards?

    Oh I know, cause it’s the best we have today and it’s foolish not to use it.

  11. dt Says:

    What if also the client (and not only the server) will be authenticated using a certificate? I suppose this should improve security because client’s key is signed by CA and keys are not random generated each time a SSL connection is started.

  12. RSnake Says:

    @Saph - agreed, completely.

    @Jim - I think you mis-read my comment. I said I was _NOT_ telling my bank to discontinue use of SSL/TLS. It is better than nothing, and in cases where it is a passive MITM only it does provide value, but it still isn’t good security. But, honestly, you completely have me stumped regarding your claim that we use SSL on this site. We have never once used SSL on ha.ckers.org. We may use it sometime in the future for testing purposes only, but it’s never happened thus far. The port isn’t even open….? Honestly, no, I wouldn’t use SSL to connect to ha.ckers.org from a hostile network - and it’s not foolish if you have alternatives (which I do since I own the client and the server, in the case of ha.ckers.org).

    @dt - your right, and that works in the case of corporate VPNs, but the extreme usability concerns make it non-viable for large scale consumer issues.

  13. Jim Manico Says:

    “I said I was _NOT_ telling my bank to discontinue use of SSL/TLS. It is better than nothing”

    That is the only point I was trying to make. And I agree there are better options, in some situations, like only allowing admin functionality access over a VPN, etc.

    So SSL/TLS has serious problems, I agree. Would it be fair to teach web builders about the benefits of SSL/TLS and encourage them to use it, so long as we explain the fragility and limits of the technology?

  14. RSnake Says:

    @Jim - I don’t think there’s much point in telling web developers what the limitations of SSL/TLS are, since they can’t do anything about it. So yes, it’s fair to encourage them to do something rather than nothing, but that’s like encouraging people to use WEP instead of no crypto at all - just because it’s better than nothing doesn’t mean it’s not incredibly flawed.

    It’s up to the browser manufacturers to figure out better tech, if and when they decide it’s a problem they actually want to solve. So far I haven’t heard anyone even admit it’s a problem worth dealing with. Even most hackers aren’t educated enough about the problem to understand why it’s a problem, so I will expect it to be a very, very long time before we see any meaningful changes. UI window dressing like EV certs notwithstanding.

  15. Tom T. Says:

    Uhh, is there any chance that you yourself could design something better, since you’re aware of the flaws? Might or might not be able to make any money (patent and license?), but eternal glory — imagine RSA being replaced everywhere by RSH (RSnakeHansen, of course). Savior of the Internet, Nobel Prize in Internet Security, the gratitude of everyone who knows enough to be grateful, and your own well-earned pride. *SERIOUSLY* — this is not a facetious post. If you’re not enough into crypto, I’m sure the cryptogeeks would take care of that part, if you would just work out the implementation.

    Love to see it. Cheers!

  16. Smarmy Says:

    Guy’s name is Moxie, not Moxy

  17. chad Says:

    is it just me or was MITM viable for the average hacker with ettercap?

  18. Cagekicker Says:

    I know I’m jumpin’ on the bandwidth wagon a little bit late here, (seems to be a routine now between here and sla.ckers) but the only way to improve security is to have it tested and broken, it’s the one’s that take notice of the “chinks in the armor” and work towards bettering it that forces ALL realms of security (physical, network, web app, etc) to remain vigilant and look for and suggest improvements.

    You think developing tools to demonstrate a failing security technology is a bad thing? Guess what? They’d get developed anyways- and it wouldn’t be a white/gray hat that puts it to use- to break SSL (which even configured correctly will eventually be outdated as the attacks become more complex).

    Vulnerability R&D sheds light on the things that the common person wouldn’t be able to understand and helps deter a false sense of security. Being an ex-correctional officer, I can tell you everyone feels safe and secure up until something happens and a convicted criminal escapes–but it’s those inmates that test the system that’ll eventually find a way out, not the ones that stay within the confines of the jail/prison…and then all hell breaks lose and the finger-pointing begins that the officer “should have seen it coming”. Kinda the same way some will take their knowledge and tools to use it for bad, but then the InfoSec people should have seen that comin’ to..but they couldn’t because of people that thing that simply having properly configured SSL is secure enough…blah blah blah.

    To use your own example: “Browning, Colt, Glock, Armalite provide us with protection by mass production of firearms. I’m sure they have very good reasons for doing it….” Yes, but at the same time, those tools also come into the hands of people that only intend on using them for the greater good—but without those tools being made, chances are the bad guys would find another method of attack, and then it’d be open season on defenseless people.

  19. Cagekicker Says:

    Excuse the typos and bad grammar, I’m running on 2 hours of sleep and my “tank is empty”…

  20. Kurt Seifried Says:

    Ooooooold news (sort of, the new tools are definitely better!). Remember when dsniff came out?

    December 17, 2000 - Today [Yesterday if this is posted on the 18th] dsniff 2.3 was released, why is this important you ask? dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH. SSL and SSH are used to protect a large amount of network traffic, from financial transactions with online banks and stock trading sites to network administrator access to secured hosts holding extremely sensitive data. Both SSH and SSL use “public key encryption”, wherein their vulnerabilities lay. They also rely heavily on the user to make the right decisions when faced with an attack, and most users are not educated enough to know what exactly they are dealing with and usually make the wrong decision (how many times have we told users not to open up executables emailed to them?).

    http://www.seifried.org/security/cryptography/20011108-end-of-ssl-ssh.html