CTF036 2019, the Secured By Design CTF

2019-04-05 09:10:00

The photograph on the left was provided by Secured By Design.

I love CTFs and though I can't take part in a lot of them, I make it a point to always play in Secured By Design's CTF036. Four years in a row now and the events just keep getting better! 

I was invited to give a small talk again, this time covering the basics of PKI: public key infrastructure. In short, PKI is one of the ways to solve the challenge of "trust" in an environment: how can you trust that someone or something really is whom they claim to be? We were very much cramped for time, so I had to try and smush everything into half an hour! While the talk went smoothly, I'm not entirely happy: there was just too much info in too little time. And I didn't even cover it all! 

My slide deck for "When Alice met Bob..." is over here. 

The CTF itself was, as always, a blast! Roughly a hundred participants, attacking six copies of the same target environment: three servers and two desktop systems, part of a fake school's infrastructure. Our goal was to grab as many student IDs as possible. 

The usual suspects were there yet again: weak passwords on mailboxes, SMB shares without proper ACLs, simulated end-users and a rudimentary daemon which you could try a buffer overflow on.

I spent most of my time on attacking one of the end users: a professor. The school's website featured an open forum, with sections dedicated to each of the classes taught. One professor warned his students that their final presentations were due any day now and that they should be submitted "through the usual share". This refers to the aforementioned, open SMB share which had a subfolder "Presentations". 

I recalled that SETookit and Metasploit offered options to create Word/Powerpoint/Office payloads, but had forgotten how to. I'm rusty, it's been a while since I've done this :) After a bit of research, I turned to exploit/windows/fileformat/office_OLE*. When configuring the exploit I simply chose to target all possible options, which generated roughly twenty files with shellcode. In real life this would obviously not work, because who would fall for that?! Twenty files without content, clicking through all of them? Nope :) But in this case the script set up on the workstation (to simulate the professor) was greedy and simply went through all of them. 

Using this method I got a nice and shell_reverse_tcp to my port 443. Looking to escalate my privileges on the workstation I tried to get a Meterpreter payload to run in the same way, but failed. I guess the payload was too tricky for the target. 

I explained this particular attack vector to two teams (ex-colleagues to my right, the team in #1 slot to my left), which was a fun exercise. I love explaining stuff like this to people who're just getting their feet wet (my ex-colleagues). The #1 team quickly latched onto the idea and offered an improvement to the attack: use the reverse shell to download a Meterpreter payload .EXE file. Duh! I should've thought of that! 

Anyway: a wonderful day with fun hacking and meeting cool people! Heartily recommended :)

kilala.nl tags: ctf, hack,

View or add comments (curr. 1)

PKI: using a private versus a public ca

2019-04-05 06:17:00

This morning an interesting question passed through the SANS Advisory Board mailing list:

"Looking for anyone that has done a cost benefit analysis, or just general consideration, of using a Public CA vs. a Private CA for a PKI deployment. Some vendors are becoming very competitive in this space and the arguments are all one-sided. So aside from cost, I’m looking for potential pitfalls using a public CA might create down the road."

My reply:

My previous assignment started out with building a PKI from scratch. I’d never done this before, so the customer took a gamble on me. I’m very grateful that they did, I learned a huge amount of cool stuff and the final setup turned out pretty nicely! I’ll try and tackle this in four categories.

UPSIDES OF PRIVATE PKI

• You can run isolated from the world, you are fully self-reliant.
• Certificates are “free”, you can makes thousands of certificates without paying someone a penny.
• Very direct and short lines of communications, everything stays inside your company.

UPSIDES OF PUBLIC PKI

• Managed services, you don’t have to worry about almost anything.

DOWNSIDES OF PRIVATE PKI

• TCO, “One does not simply fire up a CA!”
• Designing, building and managing a PKI is specialized work, your team will need training.
• Designing, building and managing a PKI is more than just technology! You have to define processes and policies.
• It’s very easy to make mistakes with long-term effects (ref. Mark Cooper’s "Top 10/20 PKI mistakes" presentation).

DOWNSIDES OF PUBLIC PKI

• Costs, you pay per certificate.
• Privacy, “certificate transparency” tells the whole world about the certificates issued to you. 
• Privacy, OCSP certificate validation sends traffic to the external OCSP validation hosts, giving information about your internal data flows. 

If your infrastructure needs to be cut off from the outside world, you will HAVE to run your own, private PKI. 

I’ve recently presented on the basics of PKI and on building your own PKI, be it for fun, for testing or production use. The most important take-away was: “If you’re going to do it, do it right!”. You do NOT simply fire up a Linux box with OpenSSL, or a single instance Windows Server box with ADCS and that’s that. If you’re going to do it right, you will define policy documents, processes and work instructions that are to be strictly followed, you’ll consider HA and DR and you’ll include HSMs (Hardware Security Modules). The latter are awesomely cool tech to work with, but they can get pricy depending on your wants and needs. 

Remember: PKI might be cool tech, but the point of it all is TRUST. And if trust is damaged, your whole infrastructure can go tits-up. 

kilala.nl tags: pki, work, sysadmin,

View or add comments (curr. 0)