Information Security News
A certain model of Low Power FM radio transmitter with known vulnerabilities has been targeted in a new wave of radio-station hacks this week. Armed with an exploit that was known all the way back in April 2016, hackers have commandeered terrestrial radio stations—and in apparent unity, the hackers all decided to broadcast the YG and Nipsey Hussle song "Fuck Donald Trump."
News of the song's unexpected playback on radio stations began emerging shortly after Trump's inauguration on January 20, and the hack has continued to affect LPFM stations—a type of smaller-radius radio station that began to roll out after the FCC approved the designation in 2000. Over a dozen stations experienced confirmed hacks in recent weeks, with more unconfirmed reports trickling in across the nation. Thus far, the stations' commonality isn't the states of operation or music formats; it's the transmitter.
Specifically, hackers have targeted products in the Barix Exstreamer line, which can decode many audio file formats and send them along for LPFM transmission. If that sounds familiar, that's because Ars Technica reported on this kind of hack last year. As Barix told its products' owners in 2016, Exstreamer devices openly connected to the Internet are incredibly vulnerable to having their remote login passwords discovered and systems compromised. The company recommends using full, 24-character passwords and placing any live Internet connections behind firewalls or VPNs.
OAKLAND, Calif.—In September, KrebsOnSecurity—arguably the Internet's most intrepid source of security news—was on the receiving end of some of the biggest distributed denial-of-service attacks ever recorded. The site soon went dark after Akamai said it would no longer provide the site with free protection, and no other DDoS mitigation services came forward to volunteer their services. A Google-operated service called Project Shield ultimately brought KrebsOnSecurity back online and has been protecting the site ever since.
At the Enigma security conference on Wednesday, a Google security engineer described some of the behind-the-scenes events that occurred shortly after Krebs asked the service for help, and in the months since, they said yes. While there was never significant hesitancy to bring him in, the engineers did what engineers always do—weighed the risks against the benefits.
"What happens if this botnet actually takes down google.com and we lose all of our revenue?" Google Security Reliability Engineer Damian Menscher recalls people asking. "But we considered [that] if the botnet can take us down, we're probably already at risk anyway. There's nothing stopping them from attacking us at any time. So we really had nothing to lose here."
The tweet originally announcing this issue stated that Windows 2012 and 2016 is vulnerable. I tested it with a fully patched Windows 10, and got an immediate blue screen of death (see below for screenshot).
A Proof of Concept (PoC) Exploit causing a blue screen of death on recent Windows version was released on Github earlier today. The exploit implements an SMBv3 server, and clients connecting to it will be affected. An attacker would have to trick the client to connect to this server. It isnt clear if this is exploitable beyond a denial of service. To be vulnerable, a client needs to support SMBv3, which was introduced in Windows 8 for clients and Windows 2012 on servers.
Right now, I do not see a Microsoft statement regarding this exploit and the vulnerability triggered by it. Of course, it is best practice to block port 445 inbound AND outbound on your firewall, limiting the impact somewhat.
A traffic capture I collected between two virtual machines (Windows 10 victim) can be found here: https://isc.sans.edu/diaryimages/smbexploit.pcap. The exploit can be seen in packet 27 and 28. The long string of Cs does trigger the buffer overflow.
After the (normal) Tree Connect Request message, the server responds with a crafted Tree Connect Response message. The message itself is actually kind of ok, but the length of the message is excessive (1580 Bytes) and includes a long trailer.
The tree connect response message consists of:
This is where the message should end. But apparently, since the total message size according to the NetBIOS header is larger, Windows keeps on decoding in the crafted header (all Cs in the exploit) which then triggers the buffer overflow.
Based on this understanding of the exploit (please let me know if I didnt get it right or missed something), I wrote a simple snort signature that looks for Tree Connect messages that exceed 1000 bytes in size. Use this at your own risk. It is in works for me state:
alert tcp $EXTERNAL_NET 445 - $HOME_NET any msg: SMB Excessive Large Tree Connect Response byte_test: 3, content: |fe 53 4d 42 40 00| content: |03 00|)
The exploit can be found here:https://github.com/lgandx
Blue Screen of death after successful exploit:
-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.