Last Updated: 2017-02-18 03:23:19 UTC
by Brad Duncan (Version: 1)
Nothing really exciting this week, so let's review malicious spam (malspam) we received at our ISC handers email distro. The message is in Portuguese, and it claims to be from Detran. Detran is an abbreviation for Departamento Estadual de Trânsito, an institution responsible for supervision of ground vehicles in Brazil. The malspam concerns a ticket for running a red light, but the message is ultimately a vehicle for transporting AutoIt-based malware.
I received a zip file from a link in the email, and it easily infected a Windows computer on Friday 2017-02-17. Let's take a closer look at this infection.
Original message text in Portuguese:
Subject: Detran "Prezado(a) Condutor(a) Informe Detran (Notificacao *2 via Multa Transito*) - ***** (58825)
Infração de Trânsito, Notificação da Autuação.
A multa por avançar o farol vermelho, está descrita no artigo 208 do Código de Trânsito Brasileiro.
Ja pode Baixar o Aplicativo do Sistema de Notificação Eletrônica (SNE DETRAN), que permite receber as notificações a qualquer momento e lugar, oferecendo ainda desconto de 40% no valor da multa para pagamento até a data de vencimento da mesma.
Detran 2017 - Todos os direitos reservados - Aspectos Legais e Responsabilidades.
Subject: Detran "Dear Conductor Report Detran (Notification * 2 via Fine Traffic *) - ***** (58825)
Traffic Infringement, Notification of the Assessment.
The fine for advancing the red light is described in article 208 of the Brazilian Traffic Code.
You can download the application of the Electronic Notification System (SNE DETRAN), which allows you to receive notifications at any time and place, also offering a 40% discount on the fine for payment until the expiration date of the same.
Detran 2017 - All rights reserved - Legal Aspects and Responsibilities.
Clicking on the link presented a zip archive. I tried several times and saw at least seven different file names for the zip archive. They all contained the a .js file inside with the same file hash, regardless of the actual file name.
I emailed firstname.lastname@example.org to notify them of the URLs I found. The following HTTPS URLs over TCP port 443 provided the initial zip archive:
- www.dropbox.com - GET /s/m9vu2mwquasfhr3/%5BAvancar-Sinal%5D.zip?dl=1
- www.dropbox.com - GET /s/7dwinqclpdxt6q8/Infracao%5BMulta%5D.zip?dl=1
- www.dropbox.com - GET /s/b9u8rdqigk5ycnr/INFR-SG%5BMulta%5D.zip?dl=1
- www.dropbox.com - GET /s/lpbxa75s9vutq6r/FDWS%5BInfracao%5D.zip?dl=1
- www.dropbox.com - GET /s/d3k0u4ircpyt861/Informe%7BMulta-Recebida%7D.zip?dl=1
- www.dropbox.com - GET /s/7ann3m0bno2pe6x/FLSFW%5BMulta%5D.zip?dl=1
- www.dropbox.com - GET /s/e8yqpvl8wb0jpgt/RD793614%5BNotificacao-Multa%5D.zip?dl=1
Because the Dropbox URLs were sent encrypted over HTTPS, I didn't see any alerts when downloading the zip archive. After opening the zip archive and double-clicking the enclosed .js file, my Windows computer became infected.
The follow-up malware was sent as an 7.9 MB ASCII text file that represented hexadecimal characters for an executable binary.
The 7.9 MB of ASCII text was saved to the Windows host as C:\Users[username]\AppData\Local\TaJKgtThuk\KmNgRErtY6.zip. That fake .zip file was still ASCII text. It was then converted to a 3.97 MB binary. The binary was as an .exe saved to the local host, and it was made resident through a Windows registry update.
The ASCII text (that fake zip file) was deleted during the infection process. However, I grabbed a copy before it deleted itself, so I could double-check. I took that 7.9 MB of ASCII text, copied it into a hex editor, and saved the result as an .exe file. It had the same file hash as the .exe from the infected Windows host.
I only saw one alert on the traffic. It was an ETPRO rule for Autoit.LOX checkin. The alert is an older rule that originally appeared back in August 2014 .
Indicators of Compromise (IOCs)
The following are malicious URLs associated with this infection:
- 18.104.22.168 port 80 - mktserviceseguro.com - GET /Multa/
- 22.214.171.124 port 80 - mktserviceseguro.com - GET /Multa/Multa.php?ass=[long string of characters]
- 126.96.36.199 port 80 - etevaldomotos.com.br - GET /manhazinha/cedo/osso.dat
- 188.8.131.52 port 80 - etevaldomotos.com.br - GET /manhazinha/cedo/osso.zip
- 184.108.40.206 port 80 - vallfer.com.br - GET /maisvc/notify.php
The extracted .js file:
- SHA256 hash: ed8d7c4201c4e2a670e3418242cc02f9509e02e2e580f1b77a9ccb6e0455dc80
- File name: Infracao[Multa].js (and various other file names)
- File description: .js file extracted from zip archives associated with this malspam
The followup .exe malware:
- SHA256 hash: da9172f1e1d81c2a9300a5028bc419ea8d43518bcdb61b022180646aa2539c68
- File location: C:\Users\[username]\AppData\Local\TaJKgtThuk\KmNgRErtY6.exe
- File description: Follow-up malware downloaded by .js file
This malspam wasn't well-targeted. But our ISC handler email distro occasionally receives this type of malspam, so I like to share when I can. As usual, my lab environment is designed to be vulnerable to such malware. By the time you read this, some of the infrastructure for this campaign may already be blocked or taken down.
I don't think many people will become infected by this malspam, but it's always interesting to see what the criminals are putting out there.
From what I understand, AutoIt is a scripting language that's not inherently malicious. However, it provides a convenient environment that criminals can use to quickly develop malware. A VirusTotal search for comments tagged #autoit reveals several recent examples of AutoIt-based malware. A Google search for "autoit malware" returns several articles on the subject.
Pcap and malware for this diary can be found here.
brad [at] malware-traffic-analysis.net
Last Updated: 2017-02-18 01:47:42 UTC
by Rob VandenBrink (Version: 1)
Have you ever been asked for the config of a router or switch you (or someone else) put in so long ago you didn’t remember that device was there? So long ago that the layer of dust inside that switch is probably why the fan stopped spinning and melted it?
Yup, me too. So when it comes time to rebuild it, you go to that customer’s CATTOOLS directory (or configuration manager, or whatever backup tool that they have), and find out that:
- They retired that VM and didn’t tell you
- They let the license lapse
- They forgot about that device when they set up their backups
- They “upgraded” the backup tool, but then never started the service?
- They installed something else that broke the backup service
Yes, “stuff” happens, and backups sometimes don’t, for lots of reasons. This got me to thinking that what I really want (this week) is a PowerShell backup utility for an arbitrary list of network gear at any given client. This beats my previous method of snarfing up cattools directories (when I remember) or backing things up manually whenever I change them (and when I remember) - you see the recurring problem in that method?
Why PowerShell? There’s so many other approaches with Python, Expect, Ansible and so on (all of which can do way more than just backups) – why build something new in PowerShell? Mostly because I can run that on any customer Windows machine and expect it to work, without installing anything the client might have a problem with. Plus I really wanted to play with Carlos Perez’s Posh-SSH code ( https://github.com/darkoperator/Posh-SSH )
So, first, what to back up? What most of my clients run is some subset of:
- Cisco IOS
- Cisco Nexus
- Cisco ASA
- HP Procurve
- HP Comware
- Palo Alto Networks Firewall
Seems like a reasonable starter list? OK, now how to back them up? Again, with the theme of “don’t install anything, don’t change the host you’re running on, and (to quote Ed Skoudis), to 'live off the land' " – this is all in SSH, and all in PowerShell. Essentially for each device: login, do a “show running-config” (or equivalent for that platform), capture the output and save it to ASCII. The credentials never get saved, but you can likely scrape them out of memory if you wanted to make a point.
The input file looks like this (a fictional companyname.in is shown):
The code reads the file as a CSV, so populates a “devices” variable with properties of: devices.name, devices.IP (which can also be a CN or FQDN, it just needs to resolve), and devices.devtype
The 7 device types are covered in the example.in file above. Note that the Palo Alto is in there twice, devicetype 6 for “set” commands - the commands to rebuild the box, devicetype 7 for XML output - which you would use for a full backup, or if you wanted to manipulate that file in another app (stay tuned for that).
Running the Code:
If you run the script with no arguments, you of course get help text:
Running it “for real”, it uses get-credential to collect the userid/password for the devices in the input file. I could save these out, but I’d really rather not leave credentials like this laying around in a file.
The script then motors through the list, device by device. It takes a few minutes, and I could likely make it faster, but I’d rather it be reliable (and done) than a never ending project that never quite works – I really did write this to collect those backups!
Error checking? Umm, not so much, or better stated "not yet". If you specify a device that doesn’t exist, or if the credentials don’t match, it’ll error out on that device and just go on to the next one in the list. That’d be a good thing for me to get around to fixing (sometime soon maybe)..
The code itself is on my github -> https://github.com/robvandenbrink/rtrbk
Where do I go from here? Give the code a spin,and you tell me! If you’ve got devices you’d like to see added, or other features you’d like to see, please use our comment form to let me know!
Last Updated: 2017-02-18 01:47:26 UTC
by Johannes Ullrich (Version: 1)
In November, Heise, a german technology news publisher, broke a story that AVM cable modems included not only the manufacturer's certificate authority certificate as part of the firmware but also the corresponding private key . The news didn't get a lot of attention back then. AVM is the maker of "Fritz!Box" routers and modems which are almost exclusively sold to german speaking countries only. When I read the news initially, I also considered it only a risk to cable modem's in the area AVM operates. But it turns out, that the leak may have larger repercussions, as pointed out in a note published by CableLabs, the organization in charge of the DOCSIS cable modem standard. A reader forwarded us this note:
"All operators globally may be exposed to a security issue related to the EuroDOCSIS PKI and need to take action. AVM cable modems were shipped with the device private key and the AVM CA private key in the firmware which is now publicly exposed. As a result illegitimate cable modems can be created which could cause network problems such as theft of service. Major CMTS vendors ship their product with both the DOCSIS and EuroDOCSIS Root CA installed as a trust anchor in their CMTSs. As a result, CableLabs recommends all operators blacklist (untrust) the compromised AVM CA in their CMTSs, regardless of whether or not they have AVM equipment deployed in their network or they actively use the EuroDOCSIS Root CA." 
So what does this all mean? DOCSIS is the standard cable modem operators adopted to allow manufacturers to create interoperable equipment. EuroDOCSIS is the European version of this standard. I will refer to both standards as "DOCSIS" going forward.
DOCSIS requires that each cable modem contains a unique certificate to authenticate the cable modem to the provider. The certificate is signed by the manufacturers CA, which in turn is signed using the DOCSIS CA. Cable modem operators trust cable modems that can present a properly signed certificate.
Due to AVM's mistake, the private key for AVM's is now public, and anybody could create new certificates that will be trusted by cable modem ISPs that trust the EuroDOCSIS CA. This could, for example, allow someone to spoof a cable modem owned by a different provider, or create a cable modem with rogue firmware that will not obey configurations sent by the ISP.
Heise in a follow-up story stated that the key was already used in the wild to sign fake certificates . The fake certificates were apparently used well before Heise broke the story.
As an end user, there is nothing you can do. As outlined by the note from CableLabs, ISPs will have to distrust the AVM CA. This could potentially cut service for users who use modems that provide certificates derived from the AVM CA. But most cable modem ISPs will not allow any modem to connect to their network, but only a subset of DOCSIS certified modems that are compatible with the particular head-end equipment used by the ISP. So the impact is likely small. AVM does not distribute cable-modems outside Europe as far as I know, but I may be wrong.
 https://www.heise.de/security/meldung/AVM-entweicht-geheimer-FritzBox-Schluessel-3463752.html (German Only)
 https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=de49a18c-a9e8-4bb3-8f35-e949fc538831 (Login Required)
 https://www.heise.de/security/meldung/Entfleuchter-FritzBox-Schluessel-zum-Ausstellen-falscher-Zertifikate-missbraucht-3465065.html (German Only)
Last Updated: 2017-02-18 01:47:16 UTC
by Johannes Ullrich (Version: 1)
OpenSSL released an update for OpenSSL 1.1.0. The latest version is now OpenSSL 1.1.0e. OpenSSL 1.0.2 is not affected.
The vulnerability, CVE 2017-3733 can lead to a crash in either clients or servers. In order to trigger the vulnerability, an attacker would first negotiate an SSL connection without the "Encrypt-Then-Mac" extension. Later, the attacker would use the extension during a renegotiation handshake. The vulnerability is rated as "High" by OpenSSL, below the maximum level of "Critical".
I recommend you wait for your respective vendor/Linux distribution to provide an updated OpenSSL library, which should be available shortly if it isn't already available. Not too many systems are using OpenSSL 1.1.0. Many current Linux distribution use the non-vulnerable 1.0.2 branch. So no need to panic.
If you have more information or corrections regarding our diary, please share.