Paid Advertising
web application security lab

RFC1918 Blues

Well, it’s been quite a week or so for me. 7 days of travel, to Las Vegas for SANS and Stockholm for the penetration testing summit. Man, I’m tired! But I promised tons of people I’d actually write out what I was talking about during my speeches, since it’s tough to cover everything in such a short presentation, with all the other things I was talking about, and now that I’m finally recovered from my jet lag, I had a chance to sit down and write it all out. For those of you who have no idea what I’m talking about, don’t worry, you’re not behind the times. You can read the whole RFC1918 issue here. I tried to make it into a blog post, but it kept getting longer and longer, so I just turned it into a whitepaper instead because it’s easier.

Without re-explaining the paper, it turns out that in certain browser, and with certain VPN and the current architecture of most RFC1918 networks, there is a high tendency for bad things to inadvertently happen, like IP collisions. That’s annoying in the networking world (and a well known problem) but it’s dangerous in the security world (and far less understood). Anyway, I talked it over with HD Moore and Toby and some of the other guys at SANS and it turns out they had actually seen similar things happen in the past, so it’s been validated in the wild (again, inadvertently though).

8 Responses to “RFC1918 Blues”

  1. arshan Says:

    neat stuff. ip collisions are very annoying to the traveling consultant, but it’s nice to see the security aspect so thoroughly investigated here. =) i have some observations, but it’s 3am and i’m just reading this now, so forgive me if they’re not bulletproof.

    aren’t these attacks slightly, well, redundant/overkill, since an evil admin could push evil routes that would filter all your traffic through their malicious and controlled IP space? there’s no motivation to stop at the intranet space IMHO - i don’t see how many realistic attackers would think paypal is less valuable than intranet apps.

    although the evil admin could still steal internal info if he wanted:
    step #1: user connects to work VPN or LAN, which uses addresses in 192.168.1.* land.
    step #2: user connects to evil VPN, evil admin pushes down routes that tell user “route all your traffic to 192.168.1.* through″ (which is the evil router that, although it can’t reach internal sites, it can be used to collect internal credentials of all kinds like is shown in #4, including cookies, FTP/DB credentials, etc.) internal sites wouldn’t work, but who cares?

    even if the victim’s original LAN/VPN prevents exact “collisions” through some OS hook you could still bypass that by specifically putting out a separate route for each IP address so the “longest prefix” rule would match for your evil route for every IP - after all, you mentioned there’s only a few thousand of them. if they check their routing tables it will be very obvious, but if they check their routing tables, then it may be over already.

    also, has the feasibility of altering routes in the middle of a VPN session been tested? i assumed (maybe incorrectly) that when the VPN client authenticated, it got pushed down some routes and they persisted until the end of the session. the server could terminate the session prematurely, sure. that would jolt the user, which would not be that important, but would make getting timely information (like cookies/stolen data) back to the evil admin harder unless they re-establish in, well, a timely manner. but what can an attacker realistically do with those cookies anyway?

    but anyway, how can the evil admin use those stolen credentials if they are firewalled out? forcing a collision in the other direction and having him act as your confused deputy?

    it always seemed to me that accepting routes from someone indicates complete trust, and i think everything here validates that. i don’t think you’d disagree - i’d stick with some browser exploit after some enticing the corporate employee with pictures of anna faris.

  2. RSnake Says:

    You’re correct, you don’t need to stop at the Intranet. I didn’t really want to cover the other aspects of what could be MITM’d, but yes, they absolutely could be, if you pushed all routes to everything on the public Internet. PayPal is actually a bad example though, because you’d have to have an SSL cert for them to make that work. But yes, non HTTPS websites would be MITM-able.

    Cookies are really only important if they contain some useful data, otherwise, I wouldn’t bother with them. But perhaps they contain usernames and passwords that are used elsewhere, or can give you information about the webserver itself.

    VPNs to me never meant that you trusted the person on the other end to do anything other than what you set up the VPN for (but that was just me - until doing this research). More importantly it was supposed to stop bad guys from doing bad things in the middle. I never really thought about the other side being able to do bad things until I got knee deep into this research.

    I think there’s a lot more to be done here, but overall I think the practicality of the VPN exploit is low compared to the the cache poisoning+MITM attack version. Everyone I’ve talked to agrees.

  3. arshan Says:

    >PayPal is actually a bad example though, because you’d have to
    >have an SSL cert for them to make that work. But yes, non HTTPS
    >websites would be MITM-able.

    true in theory, not true in practice as is shown by moxie’s sslstrip =)

  4. arshan Says:

    p.s. welcome slashdot, you are becoming regulars

  5. RSnake Says:

    Yeah, although sslstrip would only be useful for phishing in that example. It wouldn’t be good for long term cache poisoning. But yes, you’re right. Sslstrip would fool almost everyone.

  6. noscript not stupid, js not safe Says:

    OT, but youll be inerested. your name and site came up at noscript forum. thread was about this site tells people there stupid to disable js and js is totally safe. if you use noscript you are stupid. so you use noscript right snake? so he is calling you stupid. maybe you can find some way to show him how wrong he is.

    his page
    his words in page source

    Seriously: If you believe that javascript is a threat, then you are not well informed about browser security”

    noscript thread

    pls teach this fool

    sorry for OT but didnt know how to get it to you

  7. noscript not stupid, js not safe Says:

    edit: forgot to take out the angle brakcets from his source comments so they didn’t show

    pls add this from his source

    “Filter - Blocks most stupid users from accessing the site”

  8. hampton fillingame Says:

    How can I find an expert to help secure my system.

    I have real-time spyware…. PPP forwarding to VPN going on and can’t seem to stop it.