BSides Edinburgh 2017 Crypto Contest Write Up

Recently, at the inaugural BSides Edinburgh, Ben Turner and I made the trek up to Edinburgh to see our colleague Neil Lines present his talk “The Hunt for The Red DA”. I can’t say that I am a massive fan of such early starts (we jumped on the first flight out of Birmingham), but thankfully the organisers made the trip absolutely worth it. The talks that I saw were well presented and had good technical content while the venue was absolutely amazing. I even learnt some stuff about the world of IoT that I wished I didn’t know; cheers Ken.

The conference was very well supported by the sponsors, particularly with the solid training on offer. We even recognised the faces of some of the competition from the CTF at DerbyCon. We’re really looking forward to doing battle again later in the year…

The crypto contest

SecureWorks kindly created a challenge for the BSides Edinburgh 2017 audience; they named it the Crypto Contest. Personally, I think one of the core skills as a good penetration tester is being able to quickly deal with data that are you are unfamiliar with and to have a good set of tools that can parse & process in a flexible way. The contest was a good way to practice some of those skills and demonstrate to my colleagues why pure C# in the world’s best programming tool – LINQPad is better than Powershell 😉 Plus, there were some very cool prizes on hand; our eyes quickly zoned in on the Hak5 Bash Bunny.

Challenge number 1 – Square

Navigating to https://www.secureworks.com/~/media/Files/US/Blogs/bsides%20edi%2017/square.ashx, we got the following wall of text

Now credit for this goes to Ben; after trying some advanced military grade cryptographic techniques such as ROT13, he craned his neck and quickly spotted that this was in fact just rotated text. Yep, I was massively over thinking it too! All we had to do was quickly put together some code that would rotate the text 90 degrees around the origin. Firing up LINQPad, the following solution was created (which of course has been tidied up and comments added).

The following out is produced and the flag is ours:

Sure, we could have put the monitor on its side, but where’s the fun in that?

Challenge 2 – Royale

Opening the page https://www.secureworks.com/~/media/Files/US/Blogs/bsides%20edi%2017/royale.ashx?la=en, you got the following, which was immediately recognisable as Morse code. The instructions stated you need to “Please decode the following message, adding appropriate spacing as needed so the flag is readable.”

Funnily enough, I had never worked with Morse code before, but the first thing I noticed was that thankfully Secureworks had put in spaces between prosigns, which made the code a little easier. The first step was to obtain a Morse code library, one that would translate the symbols to letters. This was pretty easy to find with Google and allowed me to build up a CSV file which looked something like this:

Once again, using LINQPad, the following code split up all the symbols, translate each one and then coverted it all into a string.

This gave us the following result, which is written in the NATO phonetic alphabet.

So, a slight tweak to the code, changing the last line to:

…and the next flag was ours:

Challenge 3 – Royale.txt

For challenge 3, https://www.secureworks.com/~/media/Files/US/Blogs/bsides%20edi%2017/dreams.ashx?la=en, we received the instructions “Decipher the message from this transmission” and then the following:

The first calculation was the size; the 5 lines contained 1200 bits (150 bytes). Assuming bytes was our first mistake; this had us trying to convert to different text forms and every kind of data type that we could think of, without any luck. Being bits, we then tried creating images types, e.g. bitmap and even QR codes (which in fairness didn’t really align to the size). The path then led to 6 bit characters because, well, 1200 divides by that very nicely. In honesty, we should have looked more into that first, but we didn’t as there was a talk we wanted to see (honest :)).

So, we were back inside the vendor area when the following tweet arrived.

Feel it out… hang on… Braille uses 6 bit characters, right? Bingo! Straight to https://en.wikipedia.org/wiki/Six-bit_character_code#Example_of_six-bit_Braille_codes to look at the Braille glyphs:

The 2×3 column structure lined up very nicely with the text in the transmission. Cool, so time to bash some code out. By this stage, you can probably guess what tool was opened up 🙂

The first step was to once again create a dictionary file that would translate the glyphs to ASCII. For this, we borrowed the text from the wiki page and built a csv file translating the positions into a letter. It looked like this:

Next was to write some code that translated those positions into characters. We bashed out the following quickly (it’s not perfect but did the job):

We get the following output; there were a couple of manual corrections that we needed to make to get the flag, but it looked like the Bash Bunny might be ours.

Yeah, it was!

Conclusion

While not a Crypto contest in the strictest sense of the word, it was still a lot of fun and we got some practice with data formats that we don’t normally come across. As I said at the start, this is an important skill. A big thank you to SecureWorks for putting the time in to create this contest – we really enjoyed it and we hope you all enjoyed our write up!

– Rob, Ben & Neil

A quick analysis of the latest Shadow Brokers dump

Just in time for Easter, the Shadow Brokers released the latest installment of an NSA data dump, which contained an almost overwhelming amount of content – including, amongst other things, a number of Windows exploits. We thought we’d run some quick analysis on various elements of said content.

Before we get started

We’re going to largely avoid the obvious elements of the dump because there’s already been a lot of very helpful analysis of those elements. However, before we get to that, here’s what you need to know:

  • Patch!  The majority of the high impact Microsoft vulnerabilities have recently been addressed in the MS17-010 patch.
  • Disable SMBv1.
  • Remove all Windows XP and 2003 machines from your network.  These contain vulnerabilities that will not be patched.

The following table (raw data available at https://pastebin.com/5gkb6HLJ and courtesy of @etlow) contains some of the more pertinent information.

Shadow Brokers Exploit Table

Shadow Brokers Exploit Table

We can also recommend the following script by Luke Jennings, which is designed to sweep a network to find Windows systems compromised with the dumps DOUBLEPULSAR implant: https://github.com/countercept/doublepulsar-detection-script

With that out of the way…

Metadata, or a lack of

Throughout the Equation Group leak via the Shadow Brokers, there are a number of different languages being used. One interesting element is how it appears that there was originally a preference for Perl, that was then replaced with Python – we think that this mirrors how the offensive security industry has evolved, too.

As the age of the dump is pinned at some point in 2013, we would have expected to see a little bit of PowerShell; this was really starting to come into favor around that time. Now, this post isn’t about dropping a new l33t PowerShell technique gained from the dump, but rather looking at what the capability was at the point in time. Staying with the timing of the dump for a minute, we are reminded of the following series of Tweets from Edward Snowden back in August last year, when the ShadowBrokers [6] first dropped.

We know we run the risk of taking these out of context, and it is entirely possible that his mind has been changed since, however we find the following piece of information interesting. According to the time line from the Guardian [5], the first release of the material he took was on the 5th June 2013. It’s probable that other dumps have since has contradicted this and the view of when the hacker/s were kicked off has been able to be narrowed, but we am unaware of this (so please if you know different answers on a postcard).

Examining of the tools makedmgd.exe, part of a toolkit DAMAGEDGOODS that is used within in a PowerShell delivery framework ZIPO we see the following. One of the first things that we noticed is that yeah hmmm the build date is baked into the exe. Also some different implants not within the dump are there “distantuncle” and “finkdiffernt”; some of the coders definitely have a certain sense of humor.

Using Sysinternals excellent sigcheck.exe [7] we could view the publisher, version and build date in order to correlate. Yes, it is one of the many ways to list a binarys metadata, but some of its other superb features are that, as the name implies, it will verify the signature if the binary has been signed using Authenticode and it is also able to send the binary straight to VirusTotal and look at all files within a directory tree recursively. Running sigcheck, unsurprisingly we get the following information or, some would say, a lack of.

Any trace of publisher or company which, to be fair, will be set in Visual Studio (or your toolchain of choice have either been stripped or not set). The Link date is there, which correlates to the build date, which is also five weeks after Snowden’s material was first dropped. It is entirely possible to mess with and edit these dates, of course, before releasing the dump. We do find it strange to go the level of stripping all other information but hard coding a build date, particularly in a tool that will be released to a workstation. The directory structure that this is in implies it may have been copied in rather than part of a release, as it was new and may not have been sanitised properly (although there is a real danger of reading too much into it).

First steps into PowerShell

As stated above, we would have expected to see a reasonable amount of PowerShell considering the year, but actually there is very little. The only real example that we have found is a tool called ZiPo which can be found within the dump at /Resources/Ops/Tools/ZiPo. It contains the following tools

  • decryptor_downloader.base
  • makedmgd.exe
  • ZIPO.py
  • ps_base.txt
  • powershellify.py

In order to run this tool we call ZIPO.py, which first asks you to select a “project” directory then presents a menu asking if we want to:

  1. Upload / Create Execute an Egg
  2. Upload/ Create PowerShell script
  3. Create Compressed script to be run manually

Now Egg is a term that is used quite heavily throughout the dump and we’re not entirely sure what it means at this point in time. Pretty sure it is an Equation Group term.

Choosing PowerShell script we are then asking for the location of it, what the IP address and port of the “redirector” which we assume is a proxy and then the local IP address and proxy. This is so that the script can spin up a HTTPd listener to serve up the files that have been created.

In order to test, we created a very simple PowerShell script containing:

It has generated a public/private key pair, created an index.html & index.htm, provided us with a script to run on the target and also started up a HTTPd so that we could download the payloads on the target. That’s not too bad for a couple of commands.

Looking at the command to run its pretty standard PowerShell from the time, in fact we find it really interesting there is absolutely no attempt at obfuscating anything here. They are encrypting the payload and building a chain to download/decrypt etc, but no effort is made at hiding what the command is doing or where it is obtaining the script from (of course we would be very interested to see what they are doing now).

So what is contained within the two index files? Well, index.html is base64 PowerShell script, which is why it was executed as an encodedCommand; decoding you get the output below. It encrypts a known “questionable” password value using RSA, another WebClient is created which has the encrypted value set as a cookie. The index.html is then downloaded and decrypted using the key, which is a SHA1 hash of the “questionable value”. The payload is then executed and on the server the two files are then deleted. This is a lot of effort to hide the final payload and once again absolutely no effort to obfuscate any of the script.

This is how it looks when it is run:

DAMAGEDGOODS

The next thing that we did was to just create a meterpreter payload; nothing special and wasn’t going to get to connect back, but we felt that AV should still be able to pick it up.

Running Zipo again, we selected the third option. It asks you for a payload DLL and also the ordinal [8] that you want to fire. This is where DAMAGEDGOODS comes into play; makedmged.exe is the exe that appears to do some kind of shellcode encoding. In this case it takes the encoded binary with a script called ps_base.txt, then compresses/base64 encodes and then builds a decompression payload around it.

The script that is output at the end of this using the name you supplied is the decode/decompression/execute mentioned above and is shown below.

Decoding it you get the following, which is quite interesting; it’s a PowerShell script that allocates memory, writes the shellcode into it, creates a thread and then executes the shellcode, all in memory. The shellcode in this case is going to be the meterpreter DLL that we originally used. Running it multiple times over the same DLL you get a different version. There appears to be some kind of prologue in the shellcode that doesn’t change, but it is pretty short, running the script multiple times and then diffing with Scooter Software’s excellent Beyond Compare you find that the only section that has changed is the shellcode except for:

This series of bytes which appears to be some kind of prologue probably a decoder for the rest of the shellcode. What does it do, how does it work? Well that, we’re afraid, is for part 2 as we’ve spent too much time away from the family already this easter ;o)

 

This kinda looks familiar….

Now the great irony in a dump like this is finding code that appears to have come from GitHub but doesn’t appear to have the same licence or any at all for that matter [1]. This script is built from file called ps_base.txt. This is primarily used to dynamically build a type that will eventually hold a function pointer to a native function. This is then used to store the fp’s for native functions Win32 functions such as VirtualAlloc[2], GetProcessAddress[3] & GetModuleHandle[4] that can be used to perform some actions such as allocating memory and looking up the addresses of exports within DLL’s. Further are shown in this screen shot:

Now the method to create the delegate’s used in the above code is:

Programmers (ourselves included) can be utter sticklers for formatting, so it is conspicuous that there is such a big difference in formatting between the code in ps_base.txt vs decryptor_downloader.base. It’s almost as if ps_base.txt has come from somewhere else.

Well funnily enough it bears more than just a striking resemblance to some code from Powersploit[1]; screenshots from GitHub are below. Surprisingly not too much effort has been made to change the method names.

And also…

The commit date for this code is…

And as stated above we have a built date of July 2013; does this mean we will find StackOverflow answer code within the dump at some point?

But anyway back to makedmg.exe running it we get this list of other implants that are not in this dump; obviously still a lot out there.

DOUBLEPULSAR

From analysis we did on some implant configuration files, Darkpulsar appears to create a service called ‘dapu’ It also seems that when it upgrades itself it drops the new file using the following path: ‘c:\windows\system32\sipauth32.tsp’.

We also had a look at tdip.sys driver.

(sha256: A5EC4D102D802ADA7C5083AF53FD9D3C9B5AA83BE9DE58DBB4FAC7876FAF6D29)

We found same magic DWORDs as those mentioned by Kaspersky Labs in the following link: https://securelist.com/blog/incidents/75812/the-equation-giveaway/ which contains information from a previous ‘ShadowBrokers’ dump.

The following code snippet is taken from tdip.sys:

This driver was most probably used to capture network traffic and it also accepts IOCTLs from userland. There is probably a relation between this driver and “TrafficCapture_Target.dll” module that we found inside the recent ShadowBrokers dump, which we noticed that it is able to communicate with a kernel driver via IOCTLs.

Conclusion

Keeping in mind that this is a subset of the techniques that the Equation Group had in 2013, we still find it pretty interesting that just like the rest of the world they were starting to wake up to the potential of offensive PowerShell. The lack of any obfuscation i.e attempt to hide any of the decryption/download code was another surprise too considering how much “effort” has gone into encrypting the payload over the network at that point. The source of some of the code is intriguing, too.

But back to the initial thoughts, we probably can be sure that this code was from 2013. Is it possible that Ed’s assertion the “hacker squatting lost access in June” may be flawed and they had access until at least the first couple of weeks in July. Assuming SB and no one else has tampered with the metadata within DAMAGEDGOODS, then yes.

[1] https://github.com/PowerShellMafia/PowerSploit/blob/a233…

[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa366890(v=vs.85).aspx

[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx

[4] https://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx

[5] https://www.theguardian.com/world/2013/jun/23/edward-snowden-nsa-files-timeline

[6] https://twitter.com/snowden/status/765515087062982656?lang=en

[7] https://technet.microsoft.com/en-gb/sysinternals/bb897441.aspx

[8] https://msdn.microsoft.com/en-us/library/e7tsx612.aspx

[9] https://www.scootersoftware.com/

Carbon Black – Security Advisories: CVE-2016-9570, CVE-2016-9568 and CVE-2016-9569

Nettitude have discovered three vulnerabilities in Carbon Black; CVE-2016-9570, CVE-2016-9568 and CVE-2016-9569. Two of these have been patched at the time of writing.

CVE-2016-9570

  • Module: cb.exe (SRC-149)
  • Version: 5.1.1.60603
  • Bug Type: Read-Out-Of-Bounds
  • Impact: DoS
  • Prerequisites: Hijack NetMon Pipe
  • Severity: Medium
  • Status: Remediated

Note: The following technical details are taken from the x86 build of the Carbon Black Sensor module. Variable sizes might change in x64 build.

Overview

The Carbon Black sensor receives data through the “\\.\pipe\netmon” named pipe and selects the appropriate handler based on a number that goes from 0 to 9.
If we send number ‘4’ as a command type then the DWORD store at offset (Buffer_Base + 0x7B) it will be interpreted as size for memory allocation. If we indicate 0x41414141 as size, the final size requested will be (size + 0x50). The driver has already checked if supplied size value is zero or a negative number, thus 0x80000000 and greater, so there are no integer overflows in this case.

If the allocation succeeds, the driver will copy (size – 1) bytes to that buffer without validating the size of the buffer that keeps the input data, which will cause the Carbon Black Sensor to crash through an invalid pointer dereference. A memory access violation on read in this case.

Recommendation

Perform additional validation checks over the input that is processed through the named pipe.

CVE-2016-9568

  • Module: cbstream.sys (SRC-148)
  • Version: 5.1.1.60603
  • Bug Type: Design Security Issue
  • Impact: Perform unauthorized actions
  • Prerequisites: Hijack NetMon Pipe
  • Severity: Medium
  • Status: Unfixed

Overview

This issue has not yet been fixed by Carbon Black, so Nettitude have opted to release only the limited details above for now.

CVE-2016-9569

  • Module: cbstream.sys (SRC-147)
  • Version: 5.1.1.60603
  • IOCTL: 0x62430028
  • Bug Type: Read-Out-Of-Bounds
  • Impact: DoS
  • Prerequisites: Admin Privileges
  • Severity: Low
  • Status: Remediated

Note: The following technical details are taken from the x86 build of the driver module. Variable sizes might change in x64 build.

Overview

When supplying the aforementioned IOCTL code, the driver will interpret the second DWORD (4 bytes) as a counter and the third DWORD as a value to search for in an allocated buffer.
The issue is that if the supplied counter is too big, then while parsing a memory allocation trying to find a match for the supplied value (3rd DWORD) it will eventually reach an address that doesn’t belong to an allocated memory page (read-out-of-bounds) resulting into an invalid pointer dereference which will lead to system crash, aka BSoD.

Disassembly

Disassembly

Disassembly

WinDBG – Crash Sample

ECX: counter limit provided through user input via IOCTL

eax=88128000 ebx=00000001 ecx=41414141 edx=00000008 esi=0064c33c edi=8078f6fc

eip=a06dc366 esp=8078f4e0 ebp=8078f4e4 iopl=0         nv up ei ng nz na po cy

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010283

cbstream+0x3366:

a06dc366 8b10   mov     edx,dword ptr [eax]  ds:0023:88128000=???????? <- Invalid pointer dereference

Recommendation

Validate that ‘counter’ parameter doesn’t exceed a specific value. If that value is not ‘known’ then perform boundary checks against the buffer by validating the address to read from before that happens.

Effectively analysing sysmon logs

We previously covered setting up and using sysmon (System Monitor), which is part of the Sysinternals suite from Microsoft. In this article, we’ll walk through analysing the logs using Microsoft’s LogParser utility. Read more