2018-07-31 21:29:00
A bit over three months ago, I took part in CompTIA's beta version of the PenTest+ exam. It was a fun and learning experience and despite having some experience, I didn't expect to pass.
Turns out, I did! I passed with an 821 out of 900 score :D
Now, I hope that some of the feedback I provided has been useful. That's the point of those beta exams, isn't it?
kilala.nl tags: work, sysadmin,
View or add comments (curr. 1)
2018-07-17 22:08:00
I guess I've found a new hobby: taking beta-versions of cybersec certification exams. :)
Three months ago I took the CompTIA Pentest+ beta and not half an hour ago I finished the CertNexus CFR-310 beta. Like before, I learned about the beta-track through /r/netsecstudents where it was advertised with a discount code bringing the $250 exam down to $40 and ultimately $20. Regardless of whether the certification has any real-world value, that's a nice amount to spend on some fun!
To sum up my experience:
Now... Is the CFR-310 certification "worth it"? As I've remarked on Peerlyst earlier this week: it depends.
If you have a specific job requirement to pass this cert, then yes it's obviously worth it. Then again, most likely your employer or company will spring for the exam and it won't be any skin off your back. And if you're a forward thinking contractor looking to get assignments with the DoD, then it could certainly be useful to sit the exam as it's on the DoD 8570 list for two CSSP positions.
If, like me, you're relatively free to spend your training budget and you're looking for something fun to spend a few weeks on, then I'd suggest you move on to CompTIA's offerings. CertNexus / Logical Operations are not names I'd heard before and CompTIA is a household-name in IT; has been for years.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 1)
2018-06-28 22:30:00
I've been a very happy user of Synology systems for quite a few years now. The past few weeks I've ran into quite some performance issues though, so I decided to get to the bottom of it.
Symptoms:
I have undertaken a few steps that seem to have gotten me in the right direction...
In order to disable Universal Search:
Make the following changes:
ctl_stop="yes"
ctl_uninstall="yes"
You can now restart Package Center in the GUI, browse to Universal Search / SynoFinder and stop the service. You could even uninstall it if you like.
In order to disable the Indexer daemon:
The second step is needed to also stop and disable the synomkthumb and synomkflvd services, which rely upon the synoindexd.
One reboot later and things have quieted down. I'll keep an eye on things the next few days.
kilala.nl tags: sysadmin,
View or add comments (curr. 5)
2018-06-24 20:41:00
It's gonna be a busy week!
Most importantly, I'll be taking CQure's "DAMTA" training: Defense Against Modern Targeted Attacks. Basically, an introduction to threat hunting and improved Blue Teaming. Sounds like it's going to be a blast and I'm looking forward to it a lot :)
Unfortunately this also means I'll be gone from the office at $CLIENT for three days; that bits, 'cause I'm in the midst of a lot of PKi and security-related activities. To make sure I don't fall behind too much I'm running most of my experiments in the evenings and weekend.
For example, I've spent a few hours this weekend on setting up a Microsoft ADCS NDES server, which integrates with my Active Directory setup and the base ADCS. My Windows domain works swimmingly, but now it's time to integrate Linux. Now I'm looking at tools like SSCEP and CertMonger to get the show on the road. To make things even cooler, I'll also integrate both my Kali and my CentOS servers with AD.
Busy, busy, busy :)
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
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)
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.