MS15-034 Update
I just wanted to let everyone know that over the past few days I updated my MS15-034 code to support HTTPS connections. The work involved was much easier than I expected, so I felt that it was worth including.
Working with HTTPS is pretty simple. I have followed the usual convention and defined the –UseSSL parameter, it should be noted you will need to specify a port with the –Port parameter as well. Typically –Port 443 –UseSSL will perform what you need.
Let’s take a look at a few quick examples.
1) Testing a Windows 2012 server with HTTPS and determining if it is vulnerable:
2) Invoking the DOS, this time there is a custom port number in use:
One thing to note, the certificate will be validated, so make sure it is trusted/valid etc.
I am still seeing and hearing of this attack occurring, with a significant number of systems still remaining unpatched. I still haven’t seen any code examples supporting Remote Code Execution (RCE), but I am sure someone has figured that one out and is keeping it very secret.
You can find the updated code at the GitHub repository MS15034, or download the code as a zip file.
Kieran Jacobsen
Exploiting MS15-034 with PowerShell
Updates have been made available to this code to support SSL. See the update here.
On Thursday morning, I woke up to an extremely busy Twitter stream; the topic which that was on everyone’s’ lips was Microsoft Security Bulletin MS15-034.
MS15-034 is a critical security bulletin impacting HTTP.SYS, which forms a core component of IIS and a number of other Windows roles and features. The vulnerability described in the bulletin is a Remote Code Execution (RCE) however at the time of the publication of this post, only a Denial of Service (DOS) of the system has been achieved. There are a number of claimed RCE pieces of code on sale, yet none have been verified.
Over the days since the original release of the bulletin and its associated fixes, things have moved quite quickly. Simple detection (more) and exploitation code had been developed, as well as more complex pieces and even a Metasploit module. Now it is fine for those of us who have Linux systems, or even maybe those who have Windows ports of perl, python, curl or wget installed to use a number of these scripts/examples that are out there, however I feel it is important that this be presented in a way that is accessible and understandable by the average Windows administrator.
Chris Campbell (@obscuresec), put together some PowerShell code that would allow administrators to determine if a system was vulnerable. Unfortunately, there were some issues with this code that means it isn’t as effective as it could be. Firstly, Chris’ code doesn’t report if any other HTTP errors are generated, for example, if you specify an invalid page, the code wouldn’t alert you to the HTTP 404 that would be returned. The next issue is that a non-vulnerable system returns a HTTP 400 after the patch, something the code doesn’t pick up on. Finally, the range header values specify do not match what has been specified in other pieces of code. I felt we needed not only PowerShell code to test if a server was vulnerable, but that it would be interesting to see if we could also exploit a vulnerable server.
Now it should be noted, that you simply can't use the .Net WebRequest class to specify the appropriate “Range” header values, you need to use the TCPClient class and run at a lower level. This is more of a separate discussion I will leave for a later post.
Over the course of past few days, I developed PowerShell code, heavily inspired by the Metasplout module, to allow for the testing and exploitation of MS15-034. This code is contained in the module, MS15034.psm1 up on the Posh Security GitHub. There are two functions which will be of interest; Test-MS15034, which allows for the testing of servers, and Invoke-MS15034DOS which is capable of performing a denial of service against a specified target.
Testing
The CMDLet Test-MS15034 requires the specification of a computer name or IP address, and optionally a port number, and then 3 different parameter sets:
- Specifying the -Windows2008 parameter
- Specifying the -Windows2012 parameter
- Specifying a custom HTTP path with the -ServerPath parameter
The first two are simply to simply the testing against lab environments, as they will connect to the URL of the format http://<Computer>/welcome.png and http://<Computer>/IIS-85.png respectively. The third option is to specify your own HTTP path, which is something you are more likely to do in a real world scenario. You can specify any file or structure using -ServerPath, examples could be:
- /index.html
- /CompanyLogo.png
- /images/logo.jpg
Let’s look at some examples (these may not display correctly via RSS)!
1) Testing a Windows 2008 server and determining that it is vulnerable:
2) Testing a Windows 2012 server and determining that it is vulnerable:
3) Testing a Windows 2012 server and determining that it is not vulnerable :
4) Testing a server using a custom server path and determining that it is vulnerable:
5) Testing a server and specifying the wrong operating system (or the default files do not exist):
6) Testing a server using a custom server path, which doesn't exist:
This CMDLet will connect to the URL determined by the parameters, specifying the header Range: bytes=0-18446744073709551615. If the response from the server is a HTTP 416, then it is vulnerable, if the response is HTTP 400, then the server is not vulnerable. Other errors will be displayed and managed accordingly.
Exploitation
Now let’s take an attack to the next level and take the server down! The CMDLet Invoke-MS15034DOS will do the trick for us. This CMDLet works much like the Metasploit module. The CMDLet accepts the same parameters as Test-MS15034, however it will begin by testing if the server is vulnerable, and if so, will then perform a denial of service. The denial of service will be performed by specifying the header Range: bytes=0-18446744073709551615.
In the examples that follow, I am simply using the default out-of-the-box images as the addresses, much like in the previous tests.
1) Invoking a denial of service against a Windows 2012 (R2) server:
2) Invoking a denial of service against a Windows 2008 (R2) server:
3) What happens if you try to invoke a denial of service against a patched server:
Next is a video of Invoke-MS15034DOS against an unpatched Windows 2012 R2 server. Note how quickly the server is taken down. I think it makes a nice alternative to Restart-Computer.
It should be noted that my code will only support HTTP and not HTTPS. I could develop support for HTTPS, but I suspect that in most environments, testing if a server is vulnerable via HTTP will be sufficient.
You can download my module from my GitHub repository MS15034, a zip file can be found here.
I really hope people will find this code useful. I will be putting together some follow up posts on this topic, including some observations around the issue and how I developed the code.
Kieran Jacobsen
Hacking with a rubber duck
On the weekend I had the pleasure to present at CrikeyCon 2015. I want to thank everyone involved including the organizers; the other speakers; our wonderful MC, Patrick Gray from Risky Business; and of course the attendees!
This year I chose something a bit different to present on, the Hak5 Rubber Ducky. I started with two (and one failed,) demonstrations in the morning before setting up in the events area to show off some more advanced demonstrations.
As promised, I am posting up my content for everyone to make use of it.
Firstly, the PowerPoint slides can be downloaded here, or viewed on SlideShare here (and below).
I have setup a separate page on this side, Rubber Ducky, where you can find the scripts/payloads and a description with each.
There are a number of links which I found to be extremely useful.
If you have any questions, comments, or feedback please feel free to leave a comment, contact me via this site or send a message to me on Twitter.
Kieran
Presenting at CrikeyCon 2015
I wanted to quickly let everyone know that I will be presenting at CrikeyCon again this year. Once again I am excited to be presenting, as well as nervous.
This year I will be doing something a little different from my usual presentations. This year I will be talking about the Hak5 USB Rubber Ducky. This is something I have wanted to show off and get more people interested in for a number of years, and am extremely excited by this opportunity.
My presentation this year will be shorter than usual, with only 15 minutes to perform a quick overview and some warm up demonstrations. I will then move to the events area along side my good friend Ash, and the always exciting Robert Winkel, where I will be showing off some more advanced demonstrations.
There is an amazing list of speakers again this year, and once again Patrick Gray will be the MC.
Last year, tickets sold out quickly, if you want to attend, then visit the Eventbrite page today to secure yours.
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:
- Get list of CHARGEN systems
- Import list into PowerShell
- Run a separate PowerShell Job for each server, which:
- Runs RawSocketUDP.exe
- Sleeps
- 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.
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).
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.