02 December 2015

Adding BurpSuite CA To The Java Keystore

Just a quick tech note for my own reference in the future.
While testing a Java based thick client, I discovered the developers had left an option to set a proxy right inside the app (handy!). That meant I could throw all the app traffic through BurpSuite, and manipulate it as I wished.

The problem I ran into was that Java didn't trust the Burp CA. To get around that, I needed to add the CA to the default Java keystore. That turned out to be simple enough, the main thing to know was where the Java keystore is stored:    $JAVA_HOME/jre/lib/security/cacerts
and what the password is:    changeit

Once I had those, importing was painless:

$ keytool -import -trustcacerts -file ~/burp.cer -alias BURPSUITE -keystore $JAVA_HOME/jre/lib/security/cacerts

Enter keystore password: changeit

Owner: CN=PortSwigger CA, OU=PortSwigger CA, O=PortSwigger, L=PortSwigger, ST=PortSwigger, C=PortSwigger 
Issuer: CN=PortSwigger CA, OU=PortSwigger CA, O=PortSwigger, L=PortSwigger, ST=PortSwigger, C=PortSwigger 
Serial number: 563a4f3e 
Valid from: Wed Nov 04 13:32:30 EST 2015 until: Tue Oct 30 14:32:30 EDT 2035 
Certificate fingerprints: 
        MD5:  AF:5E:1C:E9:D5:18:4B:EC:7D:E3:6C:C7:91:BE:11:F0 
        SHA1: D5:5E:D4:2B:BC:4D:D0:0F:A2:04:97:AC:B8:1E:EB:DA:95:94:60:DB 
        SHA256: 73:F6:FF:6B:63:9C:E6:80:86:A3:63:C6:C5:08:77:F1:69:DA:71:34:4A:E5:7E:1B:33:5A:4B:F4:FD:1F:E1:6
B 
        Signature algorithm name: SHA256withRSA 
        Version: 3 

Extensions: 

#1: ObjectId: 2.5.29.19 Criticality=true 
BasicConstraints:[ 
 CA:true 
 PathLen:0 
] 

#2: ObjectId: 2.5.29.14 Criticality=false 
SubjectKeyIdentifier [ 
KeyIdentifier [ 
0000: 20 1C 1C 67 C2 21 B5 73   21 88 E2 77 6C 1D 2E 80   ..g.!.s!..wl... 
0010: 97 8E B2 D7                                        .... 
] 
] 

Trust this certificate? [no]:  yes 
Certificate was added to keystore

16 April 2015

hacker != criminal

So, whatever your thoughts on Fox news, I can confirm that this is accurately reported. I know Chris through a couple of conferences we help staff, and if you questioned my getting worried about the recent executive orders around 'hacking', the experience he had as a result of his research will perhaps change your mind.

It's becoming increasingly risky to be a security professional, and I suspect it's destined to get worse. Events like this destroy the efforts that many people - private sector and intelligence community alike - put into building relationships with white hat hackers to help protect all of us.

Instead, this may make some wonder whether it's better to just go dark.

09 March 2015

ISTS 12

This past weekend I participated in attacking 12 teams of college students.
The occasion was my fifth year as a member of a red team1, part of the  Internet Security Talent Search put on by RIT's SPARSA. If you've never heard of ISTS, it's a computer security competition, with some differences that set it apart from similar contests (like CCDC):

1) the whole thing is designed, implemented, and run by RIT students. SPARSA members aren't wizened (and often jaded) IT security folks from either Red or Blue teams trying to prove how awesome they are, they're students in a security program trying to figure out how to have fun and expand their learning outside the classroom. As a result, they have some fantastically original (and at times, downright hilarious) challenge concepts. 

2) ISTS is laid out a bit differently than other competitions. Usually the blue teams defend, red teams attack, and everyone knows their role. ISTS turns that on its head, and permits the blue teams to attack each other.

The latter point makes for a very interesting challenge - not only are these kids tasked with hardening the networks they are given and keeping their services running, but they have to figure out how to do that while simultaneously taking out their competitors infrastructure.

And this is where the red team comes in. Not only do the blue teams have to do all of the above, but they have to deal with a cadre of security professionals attacking ALL of them indiscriminately.

This year we had an amazing team:
With talent like that onboard, I almost felt sorry for the blue teams... almost.

Each year, the SPARSA folk up their game, and this year was no exception. They had things ready to go just about on time (closest to it that I've seen yet!), but more exciting for us on the red team was the sheer number of back doors they embedded into the blue team networks. Some of my favorites were:

  1. Trojaned hidden menus in Asterisk (dial the right extension, get a netcat listener on the server)
  2. An extension to the SMTP and POP servers that included a RUN command (HELO pwnd)
  3. If you sent an HTTP DELETE verb to the web server, it dropped the host firewall, added a user to the system, and enabled SSH
  4. Finally (not a backdoor, but awesome) - a plethora of Nick Cage movie sequel ideas presented by "Pwny Pictures".
Not to be outdone, the red team brought a lot of their own tricks to the party:

  1. DLL injection - delivered by adding a red team controlled share to the PATH variable on Windows hosts
  2. Several cryptolockers to hijack systems, which were then ransomed back to blue teams in exchange for services (like bringing us beverages) or bartered for footholds on other blue team equipment
  3. Nyan cat bootloader 
Within the first 5 minutes, we had established a foothold on at least 2 machines on each team. By the start of day 2, we still had beacons on at least 1 machine from each team calling back to our CnC host. As we wrapped things up, mubix had collected over 100 shells in the last 4 hours alone. It got to the point that we just stopped trying on the red team, because everything was so thoroughly compromised. Instead, we went out to the blue teams and began showing them how to secure up their systems (and in some cases, retake them from other teams that had hijacked them).


My thanks to SPARSA for hosting a fantastic event, I can't wait to see what's in store for next year!


  

Footnotes

  1. If you aren't familiar with the different teams involved in this type of event, TaoSecurity has a fantastic write-up on their blog.