3

I have tried PoC from Google (https://github.com/fjserna/CVE-2015-7547) to test my host PC (first execute the server side PoC then execute client side PoC). It was vulnerable.

Now I want to check my router, but I'm not sure how to test it. Iif I modify /etc/resolv.conf to nameserver [my router's ip], then just execute client side PoC, it shows:

CVE-2015-7547-client: getaddrinfo: Name or service not known

Does it mean my router is not vulnerable?

Anders
  • 64,406
  • 24
  • 178
  • 215
Lee Youngho
  • 31
  • 1
  • Possible duplicate of [GHOST bug: is there a simple way to test if my system is secure?](http://security.stackexchange.com/questions/80210/ghost-bug-is-there-a-simple-way-to-test-if-my-system-is-secure) – Ohnana Mar 02 '16 at 16:24

2 Answers2

1

Testing if the router is vulnerably requires the ability to run (and usually also compile) some proof of concept code at the router and watching the output. How this can be done is described in GHOST bug: is there a simple way to test if my system is secure?.

But since there is usually no way to do this at most home routers (at least not for most users) you will probably not be able to test the router yourself. Instead you need to check with the vendor for more information like a statement that the router is not vulnerable or an updated firmware.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
-1

You can test for yourself using CloudFlare's updated PoC code, available as linked gists throughout the below post.

https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/

This does require somewhat of an understanding of valgrind output, but you can also use any other fault monitor, debugger, or other technique to watch your registers -- especially eip/rip

atdre
  • 18,885
  • 6
  • 58
  • 107
  • How does this help in finding out if the router itself is vulnerable? Given that one usually has no shell on the router one cannot execute the PoC there. – Steffen Ullrich Mar 02 '16 at 17:15
  • If it stops working... – atdre Mar 02 '16 at 21:17
  • 1
    I think you are suggesting to use the router as resolver from the client and then run the PoC. But the DNS server at the router will usually simply forward packets from outside and not use the vulnerable getaddrinfo at all. getaddrinfo might instead be used in other places inside the router, like to get updates. This means you will not know if the router is vulnerable just by using it as a resolver. – Steffen Ullrich Mar 03 '16 at 05:05
  • Ok. Update the router then and if it doesn't work, it's vulnerable – atdre Mar 03 '16 at 05:32
  • What you are effectively suggesting is to find out where getaddrinfo is used inside the router and then try to trigger these parts from outside the router. Which is kind of impossible unless you have the source code (or reverse engineer it) for the the exact firmware version your router is running. This would be out of reach for most users to do. – Steffen Ullrich Mar 03 '16 at 06:10
  • No, I'm suggesting you try out each of the PoCs directed towards the DNS for the router, and then go into the router's control panel and perform a ping against an Internet hostname, or an update of the router's firmware. It's ok that you think one way and I think another way. You'll eventually understand what I'm talking about, but first you have to open your mind to the possibility that I'm right. – atdre Mar 03 '16 at 17:54
  • So how will you then watch "...valgrind output, but you can also use any other fault monitor, debugger, or other technique to watch your registers -- especially eip/rip" ? I doubt that you will get these information inside the routers control panel and checking for this stuff at the client only checks if the client is vulnerable. And even just knowing that the ping did not crash will not help because you don't know if the ping used getaddrinfo at all but maybe some other part of the firmware does. – Steffen Ullrich Mar 03 '16 at 18:14
  • Are we trying to check if it's vulnerable or how vulnerable it is? Perhaps one cannot get console access to run valgrind, but perhaps there are other ways instead of extracting firmware, such as attaching kgdb. In my comments, I was assuming that valgrind wouldn't be an option, but detection of the vulnerability is still possible. If ping works with a known-good DNS server responses and then doesn't work with the PoC DNS responses, then you can be 95 percent or more sure that it's not just a false positive – atdre Mar 03 '16 at 21:40
  • I agree that you can see that a device is vulnerable by watching the ping fail (if there is a way to ping in the GUI at all). But you cannot be sure that the device is not vulnerable if the ping succeeds because you don't know if the ping uses getaddrinfo at all. To get the knowledge which components might use getaddrinfo (and thus which can be used for testing) you would need to have a look at the installed firmware. – Steffen Ullrich Mar 04 '16 at 04:52
  • You don't need access to the firmware, any router access will suffice, such as access to its web UI. By telling the router to ping or update its firmware (or any condition that will force it to perform a name lookup) the command should fail under one of the conditional PoCs from the CloudFlare post. It should succeed under normal conditions such as when none, or some, of the PoCs are active. What I'm explaining here is blind fuzz testing 101. You don't understand because you are not an exploit developer. Please consider reading a book such as Fuzzing: Brute-Force Vulnerability Discovery – atdre Mar 06 '16 at 18:58
  • How you can be sure that the ping from the web interface uses `getaddrinfo` and thus is the right tool for testing? I'm pretty sure that it is not part of proper exploit development to test only a single component which might not even use the vulnerable function and then declare the device as safe if this component did not fail. – Steffen Ullrich Mar 06 '16 at 19:45
  • Please consider client-side Blind ROP aka blind return-oriented programming. You fail to think out-of-the box! If you look at CVE-2015-7547 you'll see that any binary linked to a vulnerable glibc including (and possibly especially) ping, curl, wget, etc (i.e., network tools that act as a client) will access getaddrinfo() !!! – atdre Mar 06 '16 at 20:02
  • The web interface will likely show the Segmentation Fault as well! You really do not understand how any of these technologies work, do you? – atdre Mar 06 '16 at 20:06
  • As you asked for thinking out of the box: nothing says that the interface has to use the ping command. It might use the Perl implementation Net::Ping which uses inet_aton to get the IP from the hostname which uses gethostbyname which is not affected this time (but was in CVE-2015-0235). This does not mean that some other component of the router does not use glibc getaddrinfo, it only says that the ping feature does not. Again: if the ping interface crashes it is a sign that the router is vulnerable. If the ping interface does not crash there might still be a problem with another component. – Steffen Ullrich Mar 06 '16 at 20:44
  • It looks like I don't need to think that much out of the box. According to [the analysis](https://www.qualys.com/2015/01/27/cve-2015-0235/GHOST-CVE-2015-0235.txt) done in context of the GHOST vulnerability the standalone ping command uses `gethostbyname` and not `getaddrinfo`. And even if ping6 might use `getaddrinfo` it probably does not use it with `AF_UNSPEC` because ping6 cares only about IPv6. Thus the chances are high that some system is vulnerable even if ping or ping6 are not vulnerable. – Steffen Ullrich Mar 06 '16 at 21:26