I'm flooded with requests for a POC and many doubt that these vulnerabilities are exploitable. And since this vulnerability is rather technically interesting I believe many could learn from it.
The POC uses the session manipulation vulnerability in combination with the remote code execution in preg_replace as detailed in my last blogpost. It will only confirm if the instance is exploitable or not and you need to have valid credentials to the database. Use responsibly.
Download here
Edit:As 0x6a616d6573 reminded me of, blogger removes "%00" if not carefully encoded. The code posted where messed up due to this. (The downloadable file where still fine)
Now it's fixed. I also added the "//" as suggested.
Subscribe to:
Post Comments (Atom)
It doesn't Work It show me
ReplyDelete[i] Running...
[*] Contacting server to authenticate.
[i] Cookie:pma_mcrypt_iv=6usxi8fDjxY%3D; phpMyAdmin=83f941377c2ad368cb065ae3511c114b6ce908d7; pmaUser-1=K6%2BMQV0L8oo%3D; pmaPass-1=C7ohzD7vwAc%3D
[i] Token:e498413730bbb8c51ce127b807160bf8
[*] Contacting server to poison some _SESSION variables.
[*] Contacting server to execute command.
[!] Authentication error. Wrong password maby.
[*] Exiting...
I use PMA V 3.4.3 PHP 5.3.5 On OSX
@Anonymous
ReplyDeleteI'll debug tomorrow. It would be helpfull if you edited the code and changed $debug to true and emailed me the output to h@xxor.se
@Mango: I appreciate the PoC, and I did learn something. I learned I should have spent more time trying to exploit this bug. lol :] Nice work!
ReplyDeleteAlso, to get the PoC working reliably, I simply added a uri encoded null byte at the end of the regex string, and a comment delimiter at the end of the injected PHP code (The null is not needed there BTW):
'&_SESSION[src_uncommon_tables][0]=||/e'.
Becomes
'&_SESSION[src_uncommon_tables][0]=||/e'.
And
'\`.eval($_POST["comm"]);'."\x00" :
Becomes
'\`.eval($_POST["comm"]);//'."\x00" :
Apparently blogger eats url encoded nulls for breakfast, but I think you know what I mean from the description.
ReplyDeleteJust tested with version 3.3.9.2 (Unsuccessful) and Tried 0x6a616d6573's ['\`.eval($_POST["comm"]);//'."\x00" :]
ReplyDeleteResult of execution:
[i] Running...
[*] Contacting server to authenticate.
[!] Fail. request returned 401. The host is not vulnerable or there is a problem with the supplied url.
[*] Exiting...
-------------
Being that -u is set to https
@Anon: Try echo'ing out the $result variable to see if that can give you some insight into how the 401 error is happening. Also, the null at the end of the php code isn't necessary. I don't know if that's the problem, but give it a go, and let us know how it works?
ReplyDelete@Mango: Have you looked into the possibility of authentication bypass since $_SESSION variables can apparently be overwritten? I realize the authentication within phpMyAdmin happens on two different layers, (Application, and SQL) but bypassing phpMyAdmin application specific authentication should suffice for a preauth remote code execution condition. What do you think?
@0x6a616d6573
ReplyDeleteAs I remember, the authentication can be bypassed without modifying the session. But I came to the conclusion that the code inevitably comes to some place where it needs a valid connection to the database before it hits any funny pieces of code.
But please, if you can find something, tell me. =D
Last Anon.
ReplyDeleteDebug = 1
http://www.pastie.org/private/66hsny5mrc8xw27dgsuitw
@Anonymous
ReplyDeleteYour server uses basic authentication. Use an url like this:
https://user:pass@db.xxxxxxxxxx.com:443/phpmyadmin
I don't know if these credentials are the same as your db credentials.
Can u show me LFI Bug PoC
ReplyDeletegreat work man!
ReplyDeleteit took me a while to fully understand all this, but now it's clear!:)
Congrats for the hard work!
Download link does not work anymore :-(
ReplyDelete