Hack Our Train

This year, in an effort to raise awareness about IoT security, we launched the Hack Our Train challenge. For over three weeks, a model train tirelessly chugged on its tracks inside our IoT village at Co.Station Brussels and then once more for two days at BruCON 2017. We provided it with an emergency brake system powered by IoT technologies and challenged people to hack it and stop the train! With every successful hack, the train stopped, creating a service disruption. A live-stream allowed hackers to monitor the effects of their attacks.

The Hack Our Train challenge was actually composed of two parts: a local one, situated close to the IoT village and then its online counterpart. The local challenge did not require any specific technical skills. It invited people to try and break the pin of the controller that activates the emergency brake mechanism. Check out this video of people having fun with the controller:

But, the online part is where things became really interesting! Over the course of the challenge, only a handful of people succeeded in figuring it out and remotely stopped the train… In this post, we’ll provide a walk-through of the challenge and focus on some of the vulnerabilities featured in it and, more importantly, on ways to fix them.

Hunt for the firmware

On the challenge website, we provided aspiring hackers with the following scenario: Bob, one of the IoT village’s railroad technicians, recently had to update the¬†emergency brake panels. Unfortunately Bob left his USB flash drive laying around and Eve found it and made its content available online!

The first step is to analyze the USB’s contents. It is a zip archive containing two files: firmware.enc, which conveniently hints to the encrypted firmware and a binary file called firmware_updater. The firmware updater is used to decrypt the firmware and then upload it to the control panel via a serial connection.

If we execute it on a Linux machine, the firmware_updater asks us for a pin before decrypting the firmware. People who braved the challenge came up with all sorts of clever ways of cracking the firmware_updater binary and forcing it to decrypt the firmware.

For now, we will resist the temptation of breaking out our dissassemblers and debuggers and we will just look at the strings inside the updater. There are some really interesting parts:

strings1

strings2

If we think this out (of course, dissassembling would make this much easier), the firmware seems to be encrypted using AES. To perform the decryption ourselves, we would need the key and the initialization vector (IV). Luckily, these are hard-coded into the firmware (see image above).

So, we just need to turn those into their hexadecimal counterparts and we are set:

bash openssl enc -aes-128-cbc -d -in firmware.enc -out firmware
-iv 766563353667647639396e6e73647161 -K 686f746b3138313965663132676a7671

Vulnerability: use of hardcoded cryptographic keys.

Fix: if possible, avoid using schemes that require hardcoded keys. If using a hardcoded key is unavoidable, there are techniques that can be employed to make the key harder to recover. Ideally, decryption should be performed directly on the embedded device, which avoids the need to expose the key in the firmware updater.

One last word on the update procedure we just cracked: now that we have the keys, no one can stop us from modifying the decrypted firmware to add or remove some functionalities, encrypting it again and uploading it to the device. The emergency controller would have no means of knowing if the firmware has been tampered with.

Vulnerability: firmware not digitally signed.

Fix: Digitally sign the firmware so that the embedded device can verify its authenticity.

Inside the firmware

Phew, we have the firmware, now comes the hard part: we have to reverse engineer it and find a way of remotely trigger the emergency brake mechanism.

Using the file command on the firmware reveals it is in fact a Java archive. This is really good news: using a Java decompiler, we can easily recover the source code.

Vulnerability: code is easy to reverse engineer. Attackers have easy access to the internal workings of the application, which makes it easier for them to find exploits.

Fix: use a code obfuscation tool – there are many available online, both free and commercial. Once you have used the tool on your code, test your application to make sure that it is still functioning correctly. Remember that obfuscation is not a silver bullet but it can drastically increase the effort required for an attacker to break the system.

Before looking at the code, let’s try running the firmware. We are greeted with a status page containing a button to initiate an emergency brake, but we need a pin.

screen1screen2

A quick look inside the source code reveals that it is simply “1234”. We have managed to unlock the button. Spoiler: it doesn’t work!

Vulnerability: use of hardcoded passwords.
In our scenario, the password was of no immediate use. Still, this would be harmful if we ever had access to a real emergency brake controller.

Fix: if the password must be stored inside the application, it should at least be stored using a strong one-way hash function. Before hashing, the password should be combined with a unique, cryptographically strong salt value.

In order to understand what is going on, we can simply look at the debug messages conveniently left behind in the console. Seems like the protocol used is MQTT and for some reason, we receive an authentication failure error when we try to perform an emergency brake.

Vulnerability: leftover debug messages containing useful information.

Fix: scan your code for forgotten prints (system.outs in our case) and remove them before release, or disable them at runtime.

Look below the hood

Before going further, let’s take a step back and have a closer look at the architecture of our system. This step was of course not needed to solve the challenge but we thought it complements nicely to this walk-through!

As we just discovered by looking at the source code, communication is based on the MQTT protocol, often found among IoT applications. MQTT works on top of TCP/IP and defines two kinds of entities: Subscribers and Publishers. Publishers send messages on communication channels called Topics. Subscribers can register and read messages on specific Topics. These messages are relayed with the help of a server (also called a Broker).

circuit

This is a look below the hood of the mountain (this was our beta setup, our final circuit was much cleaner!). Two elements steal the show: an Arduino and a Raspberry Pi. The Arduino is the muscle: it controls the transistor that stops the train. The Pi is the brains: when it receives an emergency brake message, it orders the Arduino to stop the train.

Both the emergency brake controller (where the firmware runs – it is not shown in the picture) and the Raspberry Pi (shown in the picture) are connected to the internet. They communicate with the MQTT Broker to exchange MQTT messages. The Pi publishes messages concerning the train’s speed but it is also subscribed to a topic waiting for emergency brake messages. The controller displays the train’s current speed and, when the emergency brake is activated, it publishes an emergency brake message that the Broker relays to the Pi.

Of course, not anyone can send an emergency brake message to the server. In our infrastructure, authentication is based on JWT tokens. These are issued by the server relaying the MQTT messages and they are signed using the server’s private key. When¬† clients try to authenticate using one of those tokens, the server can verify their authenticity using its public key.

To clear all this up, we have created an overview of the MQTT communications going on in the images below:

speed

brake

Tokens, tokens everywhere…

Back the authentication problem. Digging into the source code confirms that authentication is JWT token based. Maybe there is something wrong with the token? Another file inside the JAR that immediately draws our attention is notes.txt. A quick look reveals some notes of a developer that was worried about his JWT token expiring. We can easily verify the creation date of the token here. Seems like out token is really old and as we don’t have the authentication server’s private key, we cannot create a new one.

Vulnerability: old and unused left behind files containing sensitive information.

Fix: before publishing your product, make sure to remove every non-essential ressource.

Knowing how the authentication works, it is time to turn to our favorite search engine for more intelligence. Let’s try jwt token vulnerability. The top result states “Critical vulnerabilities in JSON Web Token libraries“: perfect!

The author does a great job of explaining the vulnerability and how it can be exploited, so we leave you in his hands. For the purposes of this post, the idea is that if we create a forged token using the authentication server’s public key as a HMAC secret key, we can fool the server into verifying it using HMAC instead of RSA, which results in the server accepting our token.

Attack!

Having identified the vulnerability, it is time to perform our attack. For that, we need the server’s public certificate, which is kindly included in the JAR as well. As mentioned in the notes file, it has been converted to a format compatible with Java but the server is more likely using it in PEM format.

Luckily, converting it back is easy:

keytool -importkeystore -srckeystore hot.ks -destkeystore temp.p12
-srcstoretype jks -deststoretype pkcs12

openssl pkcs12 -in temp.p12 -out public.pem

Next, we have to create our malicious token. You can do this in the language of your choice. We used the jwt-simple node.js module.

With the malicious token crafted, we can finally perform the attack. The easiest way is to reuse the code included in the testMQTT.java file, conveniently forgotten inside the JAR. We just have to replace the token found in the code, compile the code and execute it from the terminal.

The select few who made it this far in the challenge saw the train stop on the live-stream and received the flag!

Vulnerability: using components with known vulnerabilities.

Fix: apply upgrades to components as they become available. For critical components (for example, those used for authentication), monitor security news outlets (databases, mailing lists etc.) and act upon new information to keep your project up to date.

Lessons learned

Our challenge involved a toy train but the IoT vulnerabilities demonstrated inside are the real deal. We added each one of them to the IoT challenge because we have come across them in the real world.

On a final note, we would like to congratulate those who were able to hack our train and we sincerely hope that all of you enjoyed this challenge!

Stalking a reporter – behind the scenes!

Introduction
Around mid-October we got a call from a reporter working on an article covering online privacy and social media. Rather than writing about others, the reporter wanted to have his own story. So, he asked NVISO to research him on-line, and find out as much as possible about him! Of-course, after agreeing on some “ground rules” with the journalist, we were 100% up for it!

The ground rules that were put in place:

  • We would focus on mining only publicly available information, not make him a target of an attack.
  • We were not allowed to use social engineering tricks on him or his friends and family to get additional information.
  • In other words: we could use any information already available online, without actively asking for more.

The article that was recently published by the journalist can be found online (Dutch only, sorry!):¬†http://www.nieuwsblad.be/cnt/dmf20171107_03174488. For anyone interested in the “behind the scenes” on how we approached this – keep on reading!

Let’s hunt!

The team that stalks together…

We assembled a small group of volunteers and got to the task. We created a repository to collectively track our findings, as all bits of information would help the other researchers to move further on their own search, or validate information pieces gathered from different sources. The starting point was obvious: We had the journalists’ name, the email address he used to propose the experiment and a phone number on his signature. Plenty of information to start from!

The first step was to find his Facebook profile. We quickly found out that the reporter does not use the combination name + last name as the profile name, making it more difficult to track down the profile (assuming that he actually has a Facebook profile ūüėä). But as it often happens, some friends had mentioned his full name on publicly tagged Facebook pictures. We knew his face now! After that, identifying his own profile was possible by looking at metadata in the pictures, including the tagged friends. From there on we started building our file. The privacy settings for the profile were (unfortunately for us) quite restrictive‚Ķ luckily for us that was not the case for all his friends!

Screen Shot 2017-11-14 at 14.57.36

Facebook showing profile picture after you’ve entered a wrong password

We found his personal email account by guessing and trying to login with the email account to Facebook. Facebook shows you your profile picture when you say that you forgot your password. That is how we could link his personal email with Facebook. We correctly guessed that he also used this email for other social media and apps, and used the same method to see of he had an account. From there onwards, figuring which other services he was using was easy. From there we could gather additional interests, routines, professional activities, social relations…

Of course, this kind of research leads to many false positives. In our case, someone with the same name happens to live close by to our reporter, and some of our data actually referred to that person. That is where crossing data from different sources comes in handy. It allows to discard some of the bits that don’t really match the puzzle.

During our investigations, we also discovered details on the ex-girlfriend of the journalist – her online activity proved to be an excellent source of information! Prolific Instagrammer, her account gave us a lot of info about travels they did together, pictures, friends… Why do we know she was his ex? They are not friends on Facebook anymore! We got no juicy stuff about the breakup, though.

With the parents name (which we found in a cached document on Google), we could find their house, pets, and social media accounts with additional clues… We could assemble a fairly decent family tree. We were also able to find his home address.

With these results we got back to our reporter. He was quite surprised by the things we found out without directly approaching him or his friends! He found particularly scary what we found out about his family and his ex-girlfriend.  He was surprised, though, not seeing his birthdate on our data list.

One step further … go phishing
After our initial investigations, we mutually agreed to take it one step further. 

So what did we do ? We created a fake Facebook profile to trick him or his friends into sharing additional information, contacting his parent or just some good, old phishing to get his credentials and access his email account. We opted for the last option.

We crafted an email based on his interests (which we already identified during the first part of the research). We sent him a link that sounded very relevant for him, so he would definitely try to check it it. And it worked, even though he knew he was going to be targeted by us in this time window. He clicked, and he was directed to a google authentication page. Google? Well, actually NVISO-owned, Google-looking. That is how we got his password.

Once we gain access to his account, we stopped the game. We called him and showed him we were in by sending a mail via his own private inbox to his work email. The challenge was completed. We left nicely, whiteout reading his emails.

Untitled

Emailing from within the inbox of the reporter to the reporter (yes, this is a dummy screenshot!)

In a meeting afterwards, we explained him how he was phished. Up till then he had no clue how he had given us his credential! But we have to confess: still, we didn’t get his birthdate.

Conclusion
Most people aren’t too surprised anymore about the wealth of information available on each of us online. What is interesting, though, is how often we believe we are fine, just because we have our privacy settings nicely set and reviewed for all our accounts (as was the case with the journalists’ Facebook profile for example). That old account you forgot you had, the friends that tagged you, the university bulletin, a legal document or a nice note in memoriam of a loved one can give most valuable information to anyone who is interested.

Entering the active reconnaissance part, phishing once again proved a very reliable method to get additional details from a target – in our case, it even gave us full access to the journalists’ mailbox.

We are all on-line. Most of our life is these days, and that is not necessarily a bad thing. But it is important to remember that, despite all privacy and security rules we want to enforce, humans are still the weakest link. Understanding how we share information online and the impact it has on us and others is key in an increasingly digitalised world – we are happy to have contributed to the article & hope to have raised some awareness with the readers!

 

KRACKing WPA2

A new vulnerability in the WPA2 protocol was discovered by¬†Mathy¬†Vanhoef¬†(researcher at KU Leuven) and published yesterday. The vulnerability – dubbed¬† “KRACK” – enables an attacker to intercept WPA2 encrypted network traffic between a client device (e.g. mobile or laptop) and a router. Depending on the network configuration¬†it is even possible¬†for an attacker to alter or inject data.¬†Since the vulnerability lies in the WPA2 protocol, most platforms are susceptible to the attack. However, the impact is even higher on Android 6.0+ and Linux devices due to their specific implementation of WPA2.

The original publication can be found at https://www.krackattacks.com, with full details, a demonstration of the attack, and recommendations.

How does it work?

The KRACK vulnerability can be exploited by using Key Reinstallation AttaCKs. When a device wants to connect to a wireless access point, the WPA2 protocol will use a 4-way handshake. Part of this handshake consists of an acknowledgment that is sent from the client device to the wireless access point to ensure the client has successfully received the signed key. However, until the wireless access point has received the acknowledgment, it will continuously retransmit the signed key. If the attacker is able to block the acknowledgement from being sent to the wireless access point, the attacker is able to record and replay the signed key, which ensures the reinstallation of an already used key on the client’s device. As soon as the key is installed, it will be used to encrypt the network traffic between the client and the wireless access point. Since the attacker knows the keystream, he is able to decrypt the network traffic.

Since this attack exploits a vulnerability in the four-way handshake, all WPA versions are vulnerable.

Are all devices vulnerable?

Since this vulnerability is found in the WPA2 protocol, all platforms, such as Windows, Linux, MacOs, iOs, OpenBSD and Android can be targeted. Linux and Android 6.0+ devices are especially vulnerable, because the WiFi client will clear the encryption key from memory after installation. If the Android device is told to reinstall they key, the cleared out key will be installed, which is actually an all-zero key. This makes it trivial for an attacker to intercept and inject or alter data sent by these devices.

Does this mean that we need to stop using WPA2?

Although an attacker is able to intercept traffic and in some cases traffic can be altered or injected, this attack can only be performed when the attacker is in close proximity of the client’s device and wireless access point.

If the attacker has successfully exploited this vulnerability, traffic over TLS, such as HTTPS or VPN traffic, will not be accessible to the attacker.

What should we do? 

When this vulnerability was discovered, it was first disclosed to various vendors. Many vendors (e.g. Microsoft, Cisco) have already released patches for this issue. Install the available patches on all your devices or contact your vendors to see if a patch is available. A list with all patches per vendor can be found on https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519.

Furthermore, it is strongly advised to only use encrypted connections, such as HTTPS or a VPN connection, when sensitive content is transmitted over WiFi networks.

Additionally, watch out for rogue access point in your surroundings, office buildings.

More information? 

NVISO‚ÄĮanalysts¬†are still working on additional research and will update this blogpost with any results.

Should¬†you¬†require¬†additional¬†support,¬†please¬†don’t¬†hesitate¬†to¬†contact¬†our¬†24/7 hotline on +32 (0) 588 43 80¬†or csirt@nviso.be.

If you are interested in receiving our advisories via our mailing list, you can subscribe by sending us an e-mail at csirt@nviso.be.

YARA DDE rules: DDE Command Execution observed in-the-wild

The MS Office DDE YARA rules that we published yesterday detected several malicious documents samples since 10/10/2017.

Remark: the malicious samples we mention were detected with our DDEAUTO rule (Office_DDEAUTO_field); as we feared, the second rule (Office_DDE_field) is generating some false positives and we will update it.

The first¬†sample¬†uses PowerShell to download an executable¬†and run it.¬†With zipdump.py and our YARA rules we can extract the command, and with sed command “s/<[^>]*>//g” we can remove the XML tags to reveal the command:

The second sample is using PowerShell with a second stage DLL (we were not able to recover the DLL):

As could be expected, we also observed many samples that are not truly malicious, but just the samples of persons experimenting with DDE code execution starting 10/10/2017. This could also be the case for the “DLL sample”.

Finally, we observed a malicious campaign spoofing emails from the U.S. Securities and Exchange Commission (SEC)’s¬†EDGAR filing system with .docx attachments abusing DDE code execution.

This campaign used compromised government servers to serve a PowerShell second stage script:

Leveraging compromised government servers increases the success of such campaigns, because of the implied trust associated with government servers.

Talos published an extensive analysis for this campaign. We observed the same samples, and also a sample (email attachment) from the same campaign that uses pastebin to host the second stage:

Should you have to analyze the next stages, know that they are PowerShell scripts that have been compressed and BASE64 encoded. Here is one method to extract these scripts:

New IOCs:

  • bf38288956449bb120bae525b6632f0294d25593da8938bbe79849d6defed5cb
  • 316f0552684bd09310fc8a004991c9b7ac200fb2a9a0d34e59b8bbd30b6dc8ea

Detecting DDE in MS Office documents

Dynamic Data Exchange is an old Microsoft technology that can be (ab)used to execute code from within MS Office documents. Etienne Stalmans and Saif El-Sherei from Sensepost published a blog post in which they describe how to weaponize MS Office documents.

We wrote 2 YARA rules to detect this in Office Open XML files (like .docx):

Update 1: our YARA rules detected several malicious documents in-the-wild.

Update 2: we added rules for OLE files (like .doc) and updated our OOXML rules based on your feedback.

// YARA rules Office DDE
// NVISO 2017/10/10 - 2017/10/12
// https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/
 
rule Office_DDEAUTO_field {
  strings:
    $a = /<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee][Aa][Uu][Tt][Oo]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/
  condition:
    $a
}
 
rule Office_DDE_field {
  strings:
    $a = /<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/
  condition:
    $a
}

rule Office_OLE_DDEAUTO {
  strings:
    $a = /\x13\s*DDEAUTO\b[^\x14]+/ nocase
  condition:
    uint32be(0) == 0xD0CF11E0 and $a
}

rule Office_OLE_DDE {
  strings:
    $a = /\x13\s*DDE\b[^\x14]+/ nocase
  condition:
    uint32be(0) == 0xD0CF11E0 and $a
}

These rules can be used in combination with a tool like zipdump.py to scan XML files inside the ZIP container with the YARA engine:

The detection is based on regular expressions designed to detect fields containing the word DDEAUTO or DDE. By dumping the detected YARA strings with option –yarastringsraw, one can view the actual command:

Here is an example of the DDE rule firing:

You can also look for MS Office files containing DDE using this YARA rule in combination with ClamAV as described in this blog post.

YARA rules for CCleaner 5.33

First reported by Talos and Morphisec, the compromise of CCleaner version 5.33 is still making news.

At NVISO Labs, we created YARA detection rules as soon as the news broke, and distributed these rules to our clients subscribed to our NVISO Security Advisories. In a later blog post, we will explain in detail how to create such YARA rules, so that you can do the same for your organization.

Here are the YARA rules we created:

// YARA rules compromised CCleaner
// NVISO 2017/09/18
// http://blog.talosintelligence.com/2017/09/avast-distributes-malware.html

import "hash"

rule ccleaner_compromised_installer {
	condition:
		filesize == 9791816 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"
}

rule ccleaner_compromised_application {
	condition:
		filesize == 7781592 and hash.sha256(0, filesize) == "36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9" or
		filesize == 7680216 and hash.sha256(0, filesize) == "6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9"
}

rule ccleaner_compromised_pdb {
	strings:
		$a = "s:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\Release\\CCleaner.pdb" 
		$b = "s:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\ReleaseTV\\CCleaner.pdb" 
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and ($a or $b)
}

You can scan the C: drive of a computer with YARA like this:

yara64.exe -r ccleaner.yara C:\

And there are also many other scanning tools that include the YARA engine, like ClamAV.

Hunting

The first 2 rules we created are hash based, but the third rule (ccleaner_compromised_pdb) is based on a particular string found in CCleaner’s 32-bit executables. This string is the full path of the Program Database (PDB) file, a debug file created by default by Visual Studio and referenced in compiled executables.

With this rule, we were able to identify 235 files on VirusTotal. Most of these are actually container files (like ZIP files): CCleaner is a popular application, and is distributed through various channels other than Piriform’s website. We saw examples of portable application packages distributing this compromised version of CCleaner (like LiberKey) and also RAR files with pirated versions of CCleaner.

23 files were actual executables, and were all compromised versions of the 32-bit executable of CCleaner version 5.33, except one. Most of these files did not have a (valid) signature: they were modified versions, e.g. cracked and infected with other malware.

Only one executable detected by our ccleaner_compromised_pdb rule was not infected: an executable with SHA256 hash c48b9db429e5f0284481b4611bb5b69fb6d5f9ce0d23dcc4e4bf63d97b883fb2. It turns out to be a 32-bit executable of CCleaner version 5.33, digitally signed on 14/09/2017, e.g. after Talos informed Avast/Piriform. The build number was increased with one (6163 instead of 6162). This executable was signed with the same certificate that was used for the compromised version 5.33 (thumbprint f4bda9efa31ef4a8fa3b6bb0be13862d7b8ed9b0), and also for follow-up version 5.34. Yesterday (20/9/2017), Piriform finally released a new version (5.35) signed with a new digital certificate obtained yesterday.

At this moment, we are uncertain about the origins and purpose of this particular executable (c48b9db429e5f0284481b4611bb5b69fb6d5f9ce0d23dcc4e4bf63d97b883fb2).

Are you infected?

Our rules allow you to detect compromised CCleaner executables in your environment, but this does not imply that the machines identified by these rules were infected.

Our analysis shows that the compromised CCleaner installer (version 5.33) will install 32-bit and 64-bit versions of the CCleaner executables on a Windows 64-bit machine, and only the 32-bit version on a Windows 32-bit machine.

The shortcuts (like Start and Desktop shortcuts) deployed during the install on Windows 64-bit machines will point to the 64-bit executable, hence normal usage on a Windows 64-bit machine will execute 64-bit CCleaner.

Only the 32-bit executable of CCleaner is compromised.

It is therefore perfectly possible that compromised 32-bit executables of CCleaner are detected on Windows 64-bit machines with the YARA rules we provided, but that this compromised version was never executed.

If the compromised 32-bit executable runs successfully, it will create the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Piriform\Agomo

Two values will be found for this key: MUID and TCID

Conclusion

We recommend that you check for the presence of this registry key, should our YARA rules detect compromised CCleaner installations on your machines.

Compromised machines should be reinstalled after a DFIR investigation.

Active exploitation of Struts vulnerability S2-052 CVE-2017-9805

Yesterday night (06 September 2017 UTC) we observed active exploitation of Struts vulnerability S2-052 CVE-2017-9805 (announced a day earlier).

Here is the request we observed:

The POST request to /struts2-rest-showcase/orders/3 allowed us initially to detect this attempt.

The packet capture shows that this is a full exploit attempt for reconnaissance purposes: the payload is a /bin/sh command to execute a silent wget command to a compromised Russian website (it includes the name of the scanned site as query). The downloaded content is discarded.

The XML data used in this exploit attempt is slightly different from the Metasploit module for CVE-2017-9805: XML element ibuffer is represented as <ibuffer/> in this exploit attempt, while it is represented as <ibuffer></ibuffer> in the proposed Metasploit module. Both forms are functionally equivalent.

We did find an older version of this script that is used in this attack here. This shows how fast attackers attempt to abuse newly discovered vulnerabilities using (potentially unverified) exploits.

The source of this request is the same compromised Russian website, it is the first time we observe exploit attempts for CVE-2017-9805. We saw no other requests from this source since this attempt.

We would recommend everyone to keep an eye out for this type of behavior in their web server logs. As always, we won’t hesitate to share any additional observations we make. Should you observe suspicious behavior and would like to receive additional support, please don’t hesitate to get in touch with our experts!