4

I'm assessing the security of a webportal for a client and I found a vulnerability. The code is basically doing this:

$var = unserialize($_REQUEST['something']);

I have complete control over variable. But there are no classes in the server's code, it doesn't have much controllable __destruct, __wakeup etc. objects.

Can I still do something with this? Like maybe setting a $_SESSION variable? Is it possible? Any RCE or BoF or something?

Anders
  • 64,406
  • 24
  • 178
  • 215
GMX Rider
  • 345
  • 2
  • 4
  • 9
  • Best bet is in the future use of `$var`. How does it get used later on? After all, you have full control over it: not just the contents of the variable but even the type. That might give you some exploit options via loose type checking. Here are some examples: https://www.owasp.org/images/6/6b/PHPMagicTricks-TypeJuggling.pdf If the followup code is even remotely interesting, there may be some options even without classes around. – Conor Mancone Jan 15 '18 at 20:39
  • Can you post some example snippets out of how `$var` is used? – Conor Mancone Jan 15 '18 at 20:39
  • @ConorMancone The deserialized object will be placed in SQL query parameters. No SQLi, I checked, but I was wondering if we can do something with unserialize itself? Maybe with SplObjectStorage ? (code belongs to client, sorry, don't want to get in trouble – GMX Rider Jan 15 '18 at 20:55
  • What PHP version? – Conor Mancone Jan 15 '18 at 20:58
  • 5.X, thats all I know, couldn't figure it out, but I know its not up-to-date much and I know its Ubuntu server, thats all. – GMX Rider Jan 15 '18 at 21:02

1 Answers1

2

It depends on your version of PHP. Using unserialize to find weaknesses in the application is dependent upon the application having vulnerable classes. If they don't have any classes, then the application is not vulnerable.

However, you may be in luck! I don't actually use the PHP serialization myself because in the past it has been very buggy, with severe security vulnerabilities from PHP itself. I'm not personally familiar with the exact details, and it does depend on the PHP version (which obviously you don't know), but there is a high enough risk that for someone performing security auditing, the answer is legitimately "NEVER pass user data into unserialize". For the wrong versions of PHP, the result can be a serious disaster.

You have to really know what you are doing to take advantage of said vulnerabilities, but what you end up with is a remote code execution vulnerability in the PHP interpreter itself, which gives the attacker a much bigger prize. Here is a very detailed run-down of the vulnerability in PHP 7. This obviously isn't directly applicable to you, but it shows that the vulnerability is real and it doesn't depend on the user having defined classes:

https://blog.checkpoint.com/wp-content/uploads/2016/08/Exploiting-PHP-7-unserialize-Report-160829.pdf

Also some very basic information:

https://www.cisecurity.org/advisory/vulnerabilities-in-php-unserialize-function-could-allow-remote-code-execution/

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • Thanks for the info, but without special classes in server we can't really alter/change values or make the code call some functions etc. Correct? – GMX Rider Jan 15 '18 at 21:26
  • @GMXRider Correct: application-level unserialize vulnerabilities rely upon their being additional classes defined in the application which you can use to your advantage. If the application has no classes, then unserialize cannot be used to attack the application. To reiterate though, the user may very well be able to use this to exploit weaknesses in PHP itself, in which case a very skilled attacker can use this to gain a complete remote-code execution vulnerability. In other words: a complete win. – Conor Mancone Jan 15 '18 at 21:31
  • Got it, but those exploits also mostly needs a) either knowing exact version of PHP b) having server to re-serialize your object and return it back to you... Correct? – GMX Rider Jan 15 '18 at 21:35
  • The exact details depend upon the actual exploit, so there isn't a hard-and-fast rule. Knowing the PHP version is not technically a requirement: you can simply attempt to exploit the different vulnerabilities until you find one that works. I don't know if you need to be able to see the serialized PHP again in all cases. Keep in mind though that you are finding a large variety of vulnerabilities here. You may very well find another vulnerability down the line that would help you execute this particular one. – Conor Mancone Jan 15 '18 at 21:42
  • That being said, you always have to keep in mind the value of what you are protecting. If the application just contains the TV preferences of 5 year olds, no one is going to care enough to try something like this. If however it stores everyone's bitcoin keys, then the guy who found the remote-read vulnerability will find this one and spend weeks figuring out how to crack it, if that is what it takes. – Conor Mancone Jan 15 '18 at 21:44
  • Agree with you point, thank you. Will continue digging. Just for fun of it I want to get full access, although I already found lots of vulnerabilities, I love the sight of a remote shell :-) – GMX Rider Jan 15 '18 at 21:51