DNS-Rebinding Part # 2
Coming into this and learning of DNS Rebinding I had decided I wanted to make my own attack platform,
After doing research it was apparent that this could be quite deadly getting a victim’s LAN IP is trivial, and port scanning from a browser is even more trivial via websockets.
Funny enough I feel that when I was more active in the information security industry / scene that XSS/CSRF were not taken seriously enough and I feel a lot of developers still do not take them seriously when it seems they can lead to full-scale network compromise and it’s been proven time and time again that if enough payloads were distributed for common networks you’d be able to achieve MITM attacks on routers, reverse-shells on insecure systems and more.
Some software and users seem to rely on the idea that if it’s running on the same system they’re accessing it on that authorization shouldn’t be needed (If they access from 127.0.0.1) with attacks like this however we overcome the fact that things are running on the in-side of the network so chaining things together such as CSRF and code exec issues in systems leads to actual network compromise.
I had actually identified a few pieces of software that currently allow this kind of exploitation and was going to include them in my platform as example payloads but it seems at this point I’ll probably be writing a few payloads for BeEF after I report the issues to the vendors.
The fun part about some of these systems is that even when minor CSRF protection is in place (mostly tokens) it can be bypassed with attacks like the DNS Rebind meaning vendors need to start being more responsible with what they allow devices to do and the code they write despite the fact it’s running localhost only or on a LAN environment only.
You commonly see on forums for some smaller open-source software that ‘this should never be trusted on the WAN’ meaning they’re aware there’s issues on their systems and instead of fixing it ignore the fact and say that these systems shouldn’t be available over WAN interfaces.
One system which falls in this category is SabNZBD which tons of people run and in an ‘penetration test’ scenario there was a point where the post processing system was abused I won’t go into detail how yet, but essentially it allowed us to deploy a back-doored version of both CouchPotato and SabNZBD allowing us to browse files, take screenshots and etc (all embedded within the existing python).
That being said I’ll be following up this article with the CSRF->Code Exec vulnerabilities I’ve identified in a popular NAS software it’s POST auth that the issue occurs, but in previous versions a buddy of mine also identified a overflow which allowed for both auth bypassing (it overwrote the “isauthed” byte) and gaining code execution via ROP and calling libc system, that has since been patched but there’s still a DoS vulnerability in the actual server code which I’ll also be covering.
I’d highly suggest checking out the BeEF project if you haven’t in awhile: http://beefproject.com/
They’re doing some amazing things with it now and I’m glad to see I’m not the only one with the mindset of abusing the browser’s capabilities to attack devices/platforms/software found on the network which could allow for deeper access from nothing more then a bit of JS.