in analysis

A Remote Code Execute Vulnerability in the modem of the ISP

Today, I want to share with you how I successfully exploit the modem of an ISP in Vietnam. I found the multiple vulnerabilities in the GPON firmware, all of them belong to the web portal of the modem. That means it can only be exploited from a client which joined in LAN or it can be triggered by a CSRF in LAN. Anyway, I don’t wanna magnify this stuff.

Now, only one of those vulnerabilities is interesting for me, so I just talk about it. The other may be introduced in the next post. I hope you enjoy it.

0x00 Vulnerability Summary

I use a modem which belong to one of the most popular ISP in Vietnam for testing the vulnerability. Here is the summary of the device:

  • The device: GPON Home Gateway
  • OS: linux 2.6+
  • Exploit mitigation: No DEP, ASLR, Stack Canary

At the time, it’s not be fixed by yet. So I  will not share with you about my version.

0x01 The buffer overflow & further

I want to show you a buffer overflow in the hidden portal_Form. This form was created to check the connection of WAN on the modem. The below peseudo-code presents the buffer overflow in portal_Form:

The portal gets value of actiontype in the body request and copies to the buffer by using strcpy function without checking length of actiontype. But the address of buffer is 0x356e4 which belongs to the .DATA section, so we can’t do the stack overflow to control $pc register (pc means program counter, contains the address of the next instruction going to be executed). Therefore, we keep analyzing the portal code.

If actiontype performs a “ping” or “traceroute”, and the state of WAN is equal to 1 then the checking will perform in the diag_check function and the result will be get back to the client. Otherwise, we will get the result “WAN NOT UP” or the invalid request. Here is the pseudo-code of diag_check function:

In the diag_check function, a diagnose “ping” or “traceroute” will be executed by system(). Yep, you may be say “We might get the command injection at here”.

Oh yes, we saw a lot of addresses of .DATA section (0x3577C, 0x3579C, 0x357AC) which is the parameter of ping or traceroute. We know that it’s 0x98 bytes from 0x356e4 to 0x3577c, and it’s so easy to bypass strstr function. We can completely trigger a diagnose “ping” and overwrite the value of 0x3577c by the body request, like this:

That’s easy, huh? I tried to send the above body with some commands, but I got “WAN NOT UP”. No crashes, nothing gonna. Something may be wrong!

Oops, I forgot the wan_state variable! The address of wan_state is 0x35768. When we overwrite the value of 0x3577c, we also overwrite the value of wan_state which need to be equal 1 (Of course, I mean 0x00000001).

Thus, we got trouble with the NULL-byte. Thanks God! We are on .DATA section what that means that it’s a static segment (guys, do you know about “global variable”?). It does not change unless you change it.

 

0x02. Exploit the ISP Modem

This section, I will talk about how we can exploit the buffer overflow on the previous. We need the memory layout like this:

need to set the value of 0x35768 to 0x00000001 & the address 0x3577c will contain our desire command. I said that “It does not change unless you change it”, it means our buffer will not change unless we keep sending the next request.  It’s trick to setup the memory layout that we want. Ok, let’s go on.

I sent 4 the requests:

The 1st request:

body:actiontype=“ping”+“A”*(0x84-4)+”\x69” * 0x14 + “some_command_here

Yes, it’s 0x69 (You know that I mean character ‘i’ in ASCII, :3). Now wan_state = 0x69696969 (“iiii”).

The 2nd request:

body: actiontype = “ping” +“A”*(0x84-4) +”\x69\x69\x69\x00”

So on, wan_state is 0x696969(“iiii”).

The 3rd request:

body: actiontype = “ping” +“A”*(0x84-4) +”\x69\x69\x00”

       Now we have wan_state = 0x6969 (“ii”).

The 4th request:

body: actiontype = “ping” +“A”*(0x84-4) +”\x01\x00”

Finally, we set wan_state to 0x00000001. After sending the 4th request, the command had been already executed in the modem. It’s over!

Thanks for reading, that’s what I want to share with you. If you feel free to share anything with us, please contact via contact@vsec.com.vn.

Best Regards,

A member of VReT

Credits

  1. My old brother: KienManowar
  2. The VReT Team on the Vietnamese Security Network.

Write a Comment

Comment