Most of our clients that make use of our vulnerability management service, HackRack, manage a large and usually interactive web application environment, that makes use of SSL. HackRack would then often report on findings such as weak cyphers in use (critical if the client has to adhere to PCI DSS), mismatching cert names and domain names, and then expired certs.
Now, this is easy to check and re-check when you have a couple of single hosts and openssl foo. But, a couple of hundred sites and things get interesting and time consuming.
To enable our own guys and other security minded folk, we build a Java based SSL certificate miner that will show you the "Issue By" and "Issued To" information plus whether the cert is strong and have or will expire soon.
Its nice and clean, and does the job in reasonable time. Future checks will include SSL version checking - again something that is required by the PCI DSS to be up to date and reported. Monitor our blog for future releases.
Oh yes - please download from here.
Enjoy, and as always, please let us know where we have goofed or mistyped comments.
** Shameless training plug **
SensePost will be training and presenting again at BlackHat Vegas. Free stuff for those who attend!
Ever since Ron Gula's RiskyBusiness talk #142 about their Nessus philosophy, I decided to come out of the closet and share with our readers the work we do in the vulnerability management field. [Ed: If you don't listen to Risky Business then, as we say in South Africa, eish.] Ron explained that with Nessus they aim to give users a tool that can be used for monitoring and auditing - not enforcing. The "sed quis custodiet ipsos custodes" mantra comes to mind. For 9 years now we have been building two vulnerability management solutions named HackRack (for hosted, external scanning) and BroadView (for internal scanning) and it was especially HackRack that has claimed the limelight. The runt of the litter has always been BroadView, but alas (luckily?), no more.
We decided a while ago to invest our new ideas and technology in BroadView, and when that matured and stabilized, use the new BroadView as a base for new HackRack and HackRack PCI services.
And that process is nicely on track.
I mean, just look at this interface. The Blizzards page will allow BV users to get up to date stats about their environment but also allow them to quickly grasp the actual state of affairs on their network. Blizzards are visual sql queries that display averaged or calculated results of vulnerability scans as well as collected attributes. In the example below, one can quickly appreciate the impact of adding a batch of new machines to a scan, and the resulting impact on the New Issue count blizzard.
We don't see BV as just another vulnerability scanner. Its a data collector of note. It does not just scan,it also collects. From every networked device that is probed, attributes are collected that range from regular basic info such as IP addresses and operating system values, to machines without SMS agents and WebDAV directories on HTTP services.
In the weeks and months to come we will share with you the trial and tribulations to eventually bring to light BroadView v4, Final Release. We will share with you our frustration and jubilations in successfully executing intensity scans on virtualised hardware, how to mine for installed software on OS X and appreciating the amazing reduction in bandwidth utilisation by switching from SOAP to Thrift.
Well, I am off to go watch one our guys participate in a televised panel discussion - and at the same time figuring out if there are any advantages in being able to interface BroadView with our Saeco coffee machine ...
The United States committee on Homeland Security's Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology recently held a hearing to determine if "the Payment Card Industry Data Standards Reduce Cybercrime?"
Risky Business played snippets of the hearing under the apt title: "Washington spanks PCI DSS" - Like most episodes of RB, its well worth the listen..
One of the "merchants" giving testimony made his point quite succinctly. The credit card companies require us to keep card details, and shift the burden of fraudulent transactions to the merchant. There are much better ways to handle transactions, but the current method is a cheap way for the CC vendors to shift the burden and the risk to the merchants who historically had no alternative.
Online theft of credit card details reached ridiculous proportions, and so the payment card industry had to react, but they reacted by shifting the burden (and the risk) to the merchants. Now im all for people securing their apps and networks, but when you listen to merchants complaining it becomes pretty clear that the credit card industry is threatening punishment for behavior with one hand that it is actually incentivising with its other.
Now merchants (who are no saints) were willing to grudgingly go along with this cost, but when cases like heartland pop up (guys who PCI certified ok while they were busy bleeding card info to evil hax0rs) - the merchants start baying for blood.
The InfoSec Companies: Many infosec companies saw PCI as a chance to sell more services. They rallied to the PCI flag because anything that sells more services is a good thing. This would kinda be ok (mildly excusable) if they were using PCI to sell existing services (that were created to make customers secure) but the problem got worse when PCI compliance became the goal in and of itself. Now you have a bunch of people eager to sell something to a semi captive market. The situation is built for check boxes that obey the law but miss its essence..
But this isnt new? Its not.. But listening to the merchants testifying you get the sense that they have had enough. The payment card industry has tried to fix the problem the (relatively) cheap way, by shifting the pain to the merchants but its quite clear that this approach is not going to work... it becomes clear that to fix the stolen CC problem, we are going to have to (finally) change the transaction model..
The infosec market isnt going away, but i suspect that the credit-card model we currently use, will. Now this should not scare the infosec companies who have been pointing out that compliance does not equal security, or those companies that have built a reputation working on companies and applications that care about security. For those who have built a business model on checking boxes and handing out compliance stamps, my prediction is that the writing is on the wall..
Its like building a company on the Y2k hype.. Sure you might make a whack load of money for a while, and sure there actually are problems that need solving, but sooner or later the dates going to tick over from 1999 and if all you had was the hype, then im hoping for your sake that you took the lease (not buy) option on your company assets..
*caveat-1 - SensePost holds both PCI QSA and PCI ASV certifications (because we need to make sure we understand the space). *caveat-2 - Predictions in general should be left to prophets, this posting should be taken less as prognostication, and more as prose to warn against building a business model on shaky foundations..
We've been busying ourselves with the PCI DSS in one way or another for more than a year now here at SensePost. Its been a frustrating exercise of mixed messages, politics, tokenism, mixed in with a healthy dose of mixed feelings about what the standard offers and whether that's good for anyone at all. Now, finally, we're accredited to do this that and the other under the standard so we feel its time to start speaking our minds on the subject.
First stop: Las Vegas.
We've agreed with Black Hat to present a course called 'Hacking By Numbers - PCI Edition' at this year's show. As you know the PCI DSS is having a huge impact on the security industry. One effect its had is to make annual penetration tests mandatory in some segments and thereby spawn a whole new class of off-the-shelf penetration testers. As SensePost now has both the ASV and QSA accreditations our idea was to offer a pentesting course for people performing tests for the purpose of PCI certification. The approach would be present a *technical* course for beginner penetration testers that focuses on the approach and priorities required by the PCI standard. We want to add some theory about the standard itself and where/how penetration testing fits in.
Beyond just teaching what a 'compliant' penetration test is, this course will focus on teaching real-world Internet attacks focused on really compromising cardholder information. We've even given the course a byline: "Hacking By Numbers PCI Edition - Hack like you mean it".