3 ms·

Wait, so how do you escalate this to RCE?

by meshko 13y ago

meowface 13y ago
Don't think either party has disclosed that. >and due to a valid scenario he theorized involving an administrative feature we are scheduled to deprecate soon, we decided to re-classify the issue as a potential RCE bug. I imagine it might be some feature that could maybe be triggered internally through a file:// or http://localhost/ http://localhost/ URL, and in doing so gain access to an interface that can issue shell commands. That's pure speculation though, and I'm probably way off.
- reginaldo 13y ago
  You're actually pretty close.
adrenalinup 13y ago
I had the same question. After researching a bit, I found that you have multiple wrappers that you can use. One of them is file:// another is php://. I wonder if the php:// one is available in HipHop. http://www.php.net/manual/en/wrappers.php.php http://www.php.net/manual/en/wrappers.php.php
silasb 13y ago
If he can do remote network calls couldn't he download a file, like netcat?
- shabble 13y ago
  My initial understanding is that the XXE flaw allows the attacker to read local files, or make network requests via the remote host (essentially, proxying them), but still only delivered to his client, rather than actually modifying or creating files on the remote host itself. remote read access is much more limited than remote write access, but even write access will be limited by file permissions, and doesn't necessarily translate to code execution. injecting some code into some of the web-app source that gets triggered by an additional request would probably be hte easiest way, but you might also look for system binaries that get called by cron or similar. Sounds like he didn't use any of these, and it was actually some sort of local web-accessible (but externally firewalled) admin interface that a suitable request could exploit, and I'm very curious how that part of it would work (especially how you'd know/find out about it as an outsider)
zobzu 13y ago
once you've fs access, it's rarely extremely hard, unless the systems are very well protected from within (such as with RBAC and what-not). They never protect the systems from within that well because generally it's more effort than it's worth (well, of course, the day a company becomes bankrupt because of an RCE, they'd wish they spent the time - as usual with security). Of course, it doesn't mean it's always possible. It's just likely. Random scenario, since /etc/passwd is available, it tells me the php config sucks. you could just write a php shell and run it on the web interface. Or have the code within requests and read the log file (again, its all about config. if php let you read the file and doesn't only execute for .php files, bang. or if you can write a .php, bang again.) The point really is that I rarely see people caring about protecting anything or following best practices once someone found a bug that affects the system (such as fs access).

Wait, so how do you escalate this to RCE?

by meshko 13y ago

Wait, so how do you escalate this to RCE?

Don't think either party has disclosed that. >and due to a valid scenario he theorized involving an administrative feature we are scheduled to deprecate soon, we decided to re-classify the issue as a potential RCE bug. I imagine it might be some feature that could maybe be triggered internally through a file:// or http://localhost/ http://localhost/ URL, and in doing so gain access to an interface that can issue shell commands. That's pure speculation though, and I'm probably way off.

reginaldo 13y ago
You're actually pretty close.

adrenalinup 13y ago

I had the same question. After researching a bit, I found that you have multiple wrappers that you can use. One of them is file:// another is php://. I wonder if the php:// one is available in HipHop. http://www.php.net/manual/en/wrappers.php.php http://www.php.net/manual/en/wrappers.php.php

silasb 13y ago

If he can do remote network calls couldn't he download a file, like netcat?

shabble 13y ago
My initial understanding is that the XXE flaw allows the attacker to read local files, or make network requests via the remote host (essentially, proxying them), but still only delivered to his client, rather than actually modifying or creating files on the remote host itself. remote read access is much more limited than remote write access, but even write access will be limited by file permissions, and doesn't necessarily translate to code execution. injecting some code into some of the web-app source that gets triggered by an additional request would probably be hte easiest way, but you might also look for system binaries that get called by cron or similar. Sounds like he didn't use any of these, and it was actually some sort of local web-accessible (but externally firewalled) admin interface that a suitable request could exploit, and I'm very curious how that part of it would work (especially how you'd know/find out about it as an outsider)

zobzu 13y ago

once you've fs access, it's rarely extremely hard, unless the systems are very well protected from within (such as with RBAC and what-not). They never protect the systems from within that well because generally it's more effort than it's worth (well, of course, the day a company becomes bankrupt because of an RCE, they'd wish they spent the time - as usual with security). Of course, it doesn't mean it's always possible. It's just likely. Random scenario, since /etc/passwd is available, it tells me the php config sucks. you could just write a php shell and run it on the web interface. Or have the code within requests and read the log file (again, its all about config. if php let you read the file and doesn't only execute for .php files, bang. or if you can write a .php, bang again.) The point really is that I rarely see people caring about protecting anything or following best practices once someone found a bug that affects the system (such as fs access).