Assessing the impact of Supermicro BMC vulnerability with PowerShell

So there has been quite a bit of news around a vulnerability in some of Supermicro's Baseboard Management Controllers (BMC) which allows an attack to remotely retrieve the admin credentials for the BMC system remotely (and in plain text). You can find the original write up by CARI.Net, as well as SANS and Arstechnica.

Most recommendations that have been provided about assessing if you have vulnerable systems have involved netcat (nc), which has to be one of the best tools in a sysadmins utility belt, however, speaking from experience, it has the drawback that some anti-virus products don't like it, which results in security people complaining. There is another way, and that is to use PowerShell.

It is pretty simple to use the Invoke-WebRequest CMDLet, specifying a the URI you want to test. The URL in this case will be HTTP://<your server>:49152/PSBlock. If we can't connect, or receive a 404 file not found, then we are probably ok, if we receive content back, then we need to take a closer look!

So what does our PowerShell expression look like?

If you get content returned, then you really do need to investigate further. Hopefully this is a good example of also how to use Invoke-WebRequest.

Start-CHARGENAmpAttack – Looking at CHARGEN protocol denial of service attacks

I am going to start by saying that this post is pretty much all Patrick Gray's (http://risky.biz, @riskybusiness). Patrick recently did a short interview with Marc Eisenbarth as part of the AusCert coverage for the Risky Business podcast, where they were discussing amplification attacks like those seen using DNS and NTP, but also looking at the future where things like SNMP or even the CHARGEN protocol might come into play. Now I happened to be listening on a train that was slowly going nowhere, and thought to myself, how hard would it be to write a CHARGEN DDOS tool that makes use of these amplification techniques? Could I manage to write one?

So last week, whilst managing work, on call, and a dead PSU in my main machine at home, I started looking at how easy it would be.  All in all, it took about 3 days from inception to actually having a primitive tool which could be used. I can’t take all of the credit for this however, I had help from Google and some rather good pieces of code from www.winsocketdotnetworkprogramming.com (that is one long domain name). All I did was add some easy to use PowerShell code using jobs to provide parallelism.

So before we get too far along. Let’s talk about CHARGEN.

What is CHARGEN?

CHARGEN, or the Character Generator Protocol, is a network service defined in RFC864, from way back in 1983 (which makes it older than me). It was designed for testing, debugging and measuring networks and applications. The idea is simple, connect to the port and get a “random” amount of “random” characters back. You can connect on TCP or UDP on port 19, with none/some data, and it will send the “random” data back to you.

The specification contains a significant number of security issues which as you will see shortly, will lead to its misuse. This isn’t a protocol which is in wide use today, but oddly enough, you will find it in some of the most peculiar places (home routers, printers, etc) and this is why we, as IT and security professionals, need to be aware of its capabilities.

To enable CHARGEN services in Windows, simply install the “Simple TCP/IP Services”. In Linux, enable via INETD.

How do we abuse CHARGEN?

The most typical abuse for a protocol like CHARGEN is by its involvement to amplify DDOS via the spoofing of source IP addresses in UDP packets. The scenario is pretty much the same whether the protocol to be abused is DNS, NTP, SNMP or CHARGEN. The attacker sends a UDP packet to the server running the protocol, however the source IP address has been specified incorrectly, in other words, spoofed, to look like a different address. In this case, the attacker will specify an IP address of a server or service they which to DDOS. When the server receives this UDP packet, it will send the response back to the source address. This response will be sent to the victim machine, the one whose IP address was fraudulently specified in the original packet.

How does this amplify our attack? Well, the attack is sending an extremely small packet to the server running CHARGEN, which will then send back a packet containing the “random” data. This response can be anywhere from a few bytes to several kilobytes in size. Thus, the attacks very small message has been amplified to something much larger.

Let’s take a look at a quick CHARGEN message exchange. In the capture below, our client has sent a message to the CHARGEN server, which has responded back to it straight away. The client send a packet with a length of 58 bytes, and the server responded with a packet with a length of 1441 bytes. This is roughly a 28 fold increase in size. It should also be noted that the source MAC for the incoming packet matches the destination MAC of the outgoing packet. This means that at the hardware later, the same machine sent and received this packet.

Packet papture of a legitimate CHARGEN session

But how do we do this in practice?

We need to be familiar with network and socket programming to be able to create UDP packets with invalid/spoofed source addresses, it isn’t something we can simply do with the Microsoft .Net Framework’s building UDPClient class. The built in UDPClient class automatically specifies our IP address as the source IP in the packet, and we don’t want that. We need to work with the lower network socket classes to have our way.

Now, I wanted to try and do all of this in PowerShell, but right now I just don’t have the knowledge, and my .Net and C# skills are pretty limited as well. Thankfully as I was trying to learn .Net socket coding, I came across the site, www.winsocketdotnetworkprogramming.com, and whilst the site resembles something from the 1990’s, there is some really good stuff there. In particular interest to me/us for this code is Chapter 8, and within that chapter, sections 23 and 25.

Section 23 (Creating Protocols Header Definition Class (C#)) covers off developing a basic wrapper around the low level .Net framework socket components, allowing for a simpler way of creating and sending things like UDP packets. These protocol header definitions are expanded upon in Section 25 (C# Raw UDP Socket Program Example). At the end of Section 25, you will have an application called RawSocketUDP.exe, which is perfect for UDP packet spoofing and amplification attacks. The executable takes in a source and destination IP and port, an IP on the local machine to bind to, a payload size and the number of packets to send. Normally, the bind address (the IP address on our system we want to use to send the packet) and the source address would be the same, because we want the response to come back to us, but if we want to be naughty, we simply say another address is the source.

Our first CHARGEN attack!

The demo environment consists of 4 machines:

Two servers with CHARGEN - 192.168.1 and 192.168.2

One attacker – 192.168.1.10

One victim – 192.168.1.20

So how do we go about an attack using source IP address spoofing and the amplification abilities of CHARGEN?

Well, here is an example CHARGEN attack:

RawSocketUDP.exe -as 192.168.1.20 -ad 192.168.1.1 -ps 3389 -pd 19 -b 192.168.1.10 -n 1

A break down is:

Source (-as) is 192.168.1.20 – this is the system we are trying to take down, our victim

Destination (-da) is 192.168.1.1 – this is our server running CHARGEN which will be exploited

Source Port (-ds) is 3389 – The CHARGEN service response will be directed at this port (UDP)

Destination Port (-pd) is 19 – This is the port number for CHARGEN on the server we are exploiting

Bind Address (-b) is 192.168.1.10 – This is our IP address, we need to specify which network interface we are send the packet out on.

Number of times to send (-n) is 1 – Send one UDP Packet

So what happens when we run this command? Well let’s look at a packet captures. Note: yes, the times are slightly off in the captures, the test lab didn’t/doesn’t have super accurate clocks. Onwards to captures.

First on the machine we are launching the attack from:

Packet capture from attacker's PC

See how we send out a packet, but get no response. Also note that the source isn't our IP address of 192.168.1.10.

Now on the server running CHARGEN:

Packet capture from CHARGEN Server

See how we receive one CHARGEN request packet, and send one out but notice that the source MAC address for the incoming packet differed from the destination MAC addresse for the response! This is the clear sign that the source IP address has been spoofed in thus packet.

And finally, the victim:

Packet capture from victim

See how we receive a packet when we weren't expecting one.

How do we scale this attack out?

Now how do we weaponize this on a large scale?

Well, what about PowerShell!!!

So how would we go about this one? Well this is/was my thinking:

1. Get list of CHARGEN systems
2. Import list into PowerShell
3. Run a separate PowerShell Job for each server, which:
   1. Runs RawSocketUDP.exe
   2. Sleeps
   3. Repeat

Sounds pretty easy to do. What we need is a PowerShell CMDLet that can simplify the process, accepting say, a victim’s IP address, some CHARGEN servers, etc. and then run RawSocketUDP.exe in parallel against each of the specified servers. We would need some logic to keep running the executable over and over again, perhaps having a small sleep between each time we send a batch of UDP packets to the CHARGEN server.

Let’s take a look at what I came up with:

This is a rather simple CMDLet, accepting as parameters specifying the IP address of the victim, the IP address on out machine sending the initial CHARGEN packets, one or more Servers running CHARGEN (with values taken from the pipeline) and finally the folder where the RawSocketUDP.exe is located. Optionally we can specify the port on the victim side, the number of messages we will send in each period and the period we will sleep between runs. For these optional parameters, the defaults are UDP3389 (RDP), 10 messages and 10 seconds.

The Process {} code block is rather simple, for each CHARGEN server IP address specified earlier, we will create a new job. The job has a rather simple ScriptBlock {}, which will start by changing the location we are currently at to be the previously specified location of the RawSocketUDP.exe. After that, there is a simple while ($true) loop which will run indefinitely and does two things; run the RawSocketUDP.exe with the appropriate parameters, and then sleep for the specified period of time.

That’s all of the code, rather simple and easy.

Let’s perform a larger attack

This time, we are going to perform a much larger attack than our first. This time we will make use of two servers running the CHARGEN protocol, 192.168.1.1 and 192.168.1.2 to direct attack traffic to our victim on 192.168.1.20.

After importing the function previously mentioned. Our attack comes down to this oneline:

So what is this command? Quite simply we are passing an array of CHARGEN server IP addresses to our Start-CHARGENAmpAttack function, specifying the victim IP, our IP and of course, the location of the RawSocketUDP.exe.

What will happen next? Well, every 10 seconds we will send 10 UDP packets to the CHARGEN server, which will respond, but direct the response to the victim IP. This will keep happening until we stop the jobs with the following commands:

Of course, we might want to up the number of packets we send, and reduce the sleep period. We probably want to target more CHARGEN servers as well.

And a quick look at the packet capture on the victim…yes there are lots of unwanted packets flowing in!

Packet capture from victim with multiple CHARGEN servers attacking

How effective is it?

It is hard to really say how effective this attack is. In my simple lab, the two CHARGEN servers did generate a significant amount of traffic, however determining if this could be effective isn’t something I have the gear to do. What I can say is this, in my simple lab, left alone for two hours, the two CHARGEN servers did manage to crash the machine which was the victim. As we have seen this amplification attacks, especially DNS and NTP be quite effective against large targets, then CHARGEN could also be leveraged, providing you can find enough servers running the protocol.

So where to from here?

This is the hard part really. No one should have CHARGEN exposed, but it is always worth checking your environment to be sure, and not just the perimeter, this attack could be deliciously fun within a corporate network. Printers and print servers and the like often have CHARGEN running, and would make good little zombies for attacking some other part of the corporate infrastructure, and without some decent monitoring in your environment, this could be a pain to lock down.

I hope you enjoyed this blog post. It was longer than usual, but I really do hope there was something in there for people to enjoy. If you do try out CHARGEN amplification attacks with what you have seen here, please let me know, I would love to hear from you.

Links for PowerShell Shenanigans

I thought it might be easier for those wanting the links from my resent presentation if I provided a list of them here, so you didn't have to go through the presentation to find them.

My code on GitHub: http://j.mp/1i33Zrk

QuarksPWDump: http://j.mp/1kF30e9

PowerSploit: http://j.mp/1gJORtF

PowerWorm Analysis: http://j.mp/RzgsHb

PowerBleed: http://j.mp/1jfyILK

Microsoft PowerShell/Security Series:

http://j.mp/OOyftt

http://j.mp/1eDYvA4

http://j.mp/1kF3z7T

http://j.mp/NhSC0X

http://j.mp/NhSEpy

Practical Persistence in PowerShell: http://j.mp/1mU6fQq

Bruteforcing WinRM with PowerShell: http://j.mp/1nBlwX2

I hope you all enjoy!

Brisbane Infrastructure Group Presentation

On Tuesday I presented to the Brisbane Infrastructure Group a similar presentation to the one at CrikeyCon. This presentation contains updated information, some defence measures and just better information overall.

You can download the slide deck here, and the SlideShare can be found here (and embedded below).

I am working on a recorded version, which should be up in the coming weeks.

I have been tied up with some projects at work, as well as some personal development and personal projects at home. One of two I *hope* to be writing about really soon.

PowerWorm Analysis and Weaponized PowerWorm

So Matt Graber posted a few weeks ago three items of significant importance for PowerShell security folks.

The first, is he has performed an extremely detailed analysis of PowerWorm, the PowerShell malware that TendMicro found about a month ago and I wrote about as well. Matt has gone one better though, and rewritten the code, make it safe, and cleaned up the abstraction and obfuscation and put all of the code up on GitHub.

I recommend everyone, both those who are interested in PowerShell and those who are interested in malware to take a look.

Matt talks about why the PowerShell execution policy doesn’t help, the code uses the –endcodedcommand parameter when calling powershell.exe. I didn’t know about this till recently, and I was shocked at its effectiveness. If you haven’t looked into this one, I so thoroughly recommend you do, it is amazing.

There is plenty of other interesting things though, considering how this malware users PowerShell and WMI to persist. As I mentioned earlier, the use of the Net.WebClient explained why Polipo was needed as well as Tor.

I also was highly interested in the use of freegeoip.com, I have already started writing some code to make use of this site. I recommend you take a look.

Please go and look at the Matt’s post, and at his GitHub code.

But wait, there is much more! PowerWorm has picked up the functionality of CryptoLocker!!!!

Matt also tweeted a link to this post at Bleeping Computer, which describes a new variant of PowerWorm, dubbed PoshCoder or PoshKoder. This variant is encrypting files and folders in a manner similar to CryptoLocker, and then demanding the victim pays a fee of a couple of bitcoin.

The posts on Bleeping Computer do reference more volatile code, so I do warn you that it isn’t safe to play with unlike Matt’s deactivated code, so be careful. If you want to play, look at Matt’s code.

One interesting thing, is amongst these posts, it appears the malware writer makes an appearance. Whilst I and those on the forum could be wrong, there are some cryptic comments by one of the posters who makes even me wonder.

What is interesting, is that what Matt, TendMicro, myself and most others thought was harmless, has been successfully weaponized, and done so entirely in PowerShell. This malware, PoshCoder, is just as dangerous as CryptoLocker, but nowhere near as detectable. Right now, the low infection rates have prevented this from becoming a massive problem.

Last thing, paying the ransom doesn’t seem to be effective. There is a glitch somewhere and decryption isn’t working correctly. So bad news for anyone infected, you probably can’t get your files back.

Good news, some people have reported that Microsoft Security Essentials is detecting the malware.