We’re happy to announce that Daniel is now a SolarWinds Certified Professional. Daniel has been designing and deploying a SolarWinds monitoring solution for a client for the last nine months, and this certification validates his experience and knowledge on the Orion monitoring platform. We’re looking forward to expanding our efforts to help folks deploy SolarWinds and leverage it to monitor and report on their enterprise networks! If you have questions about how to deploy SolarWinds or better leverage your existing installation, reach out today and send Daniel an email.
Spent a few hours tonight and converted hagan-consulting.com to use HTTPS for all traffic. I have to thank Hynek Schlawack for his very useful blog post explaining how to configure optimal SSL settings. If you’re interested in seeing how your site (or this one) ranks on SSL, check out Qualys’ very useful SSL Labs Server Test. Unfortunately, the version of Apache I’m using doesn’t support elliptical curve cryptography, so Internet Explorer users will not have perfect forward secrecy. But all other major browsers should be getting the latest encryption settings, including perfect forward secrecy.
If you’re interested in the steps used, here’s an outline…
- A 2048-bit SSL certificate was generated and certified with Comodo’s PositiveSSL service (via my registrar, Namecheap.com).
- Apache 2.2 was configured with the SSL settings from Hynek’s blog post.
- Apache 2.2 was configured to serve a HSTS header per the Wikipedia article.
- The site was tested with the SSL Labs Server Test to verify the configuration.
If you’re new to SSL and HTTPS and would like some background on why transitioning to HTTPS is important, the EFF has a nice explanation. And of course, you’re always welcome to comment below!
Everyone has more or less agreed that the 2006 NIST standard for random number generators includes an algorithm that was likely back-doored by the NSA. The upside was that the algorithm was not particularly attractive, and it was likely that most people chose one of the other alternative algorithms. Plus, even before the NSA revelations, researchers in 2007 started pointing out why there were some flaws and this algorithm should probably be avoided.
Fast forward to today, and RSA (a major security company) has announced that the suspect algorithm is the default choice in their security products, and recommends that their customers take special steps to change that default now.
There’s two ways I think we can take this…
1) RSA is not as smart as we thought, especially since they claim the choice to make this a default was originally made “on the basis of providing the best security for our customers”.
2) RSA made this the default algorithm due to pressure from the NSA as part of the NSA’s admitted program to influence commercial crypto products.
If it’s #1, this is a sad day, because RSA is a giant in the security field.
If it’s #2, you have to take this announcement from RSA as an implicit admission that they compromised their customers’ security as a favor to the US Gov’t. This is not without irony, as many of their customers are OTHER parts of the US Gov’t, who depend on RSA products to keep us safe from foreign adversaries.
Operational Security (OpSec) is the discipline of denying an adversary information that would be advantageous in their plans against you. Maintaining anonymity is a very effective technique for OpSec, but it’s also one of the hardest to achieve. The longer an anonymous operator is active, the more peripheral information will be exposed. When that peripheral information finally exceeds the threshold necessary for an adversary to correlate it, the protection of anonymity fails.
Domestic Law Enforcement Agencies (LEAs) are even more powerful an adversary than the vaunted “nation state actor” we normally talk about in IT security. This is fundamentally because of two primary advantages that LEAs have that even a foreign government can’t (easily) exploit.
- They have lawful access to a HUGE amount of peripheral information. Things like cell phone and ISP records are much easier for a LEA to access than almost any other adversary.
- They have lawful leverage against people’s physical and financial well being. This makes it orders of magnitude easier to turn any accomplices against you.
Throwing down the gauntlet against a LEA (or a collection of LEAs) is probably the single most-likely-to-fail action any individual can take. And yet, this is exactly what the LulzSec crew did last year. It’s instructive to examine the eventual OpSec failures once LEAs devoted attention to them.
It only takes one weak link…
The de-facto head of LulzSec was a hacker named Sabu. Sabu religiously used a service called Tor to anonymize his IP address while online. Unfortunately for him, he logged into IRC one time without using Tor. That’s all it took for the FBI to locate and eventually arrest him.
That’s only the start of the story though, because while LulzSec claimed to be a leaderless collective, the FBI was treating them as a criminal conspiracy. When dealing with a conspiracy, the best way to wrap everyone up is to turn a member of the conspiracy into a source and then use his (or her) cooperation to capture everyone involved.
And that’s exactly what the FBI did with Sabu.
Once the FBI (using advantage #1) had tracked down Sabu “in real life”, they used advantage #2 to turn him as a source. It turned out Sabu was the legal guardian of two young kids, and the FBI eventually succeeded in using the threat of separating him from the kids via a stint in federal prison to turn him into a source. Once he was in the bag, they instrumented everything about his online activities and set him in pursuit of unmasking the other members of LulzSec.
Sabu isn’t the end of the OpSec story, he was just the beginning
Taking down the “head” of the gang would be the culmination of the plot if this were a Hollywood movie, but the real world doesn’t work that way. This is where the real lessons in OpSec start to surface. We now shift our focus from Sabu to one of his accomplices – “sup_g”. Sup_g felt comfortable with Sabu and made the mistake of having “loose lips” in IRC chats. During the period that Sabu was turned as a double-agent, he got sup_g to expose personal details such as:
- He acknowledged alternate aliases in IRC, allowing the FBI to tie each of his various online personas into a single target profile.
- He mentioned prior run ins with the police and even prior prison time.
- He mentioned his association with the “Freegan” movement.
Again, the FBI used their legal access to huge amounts of information to sweep through old records of arrests, prison time, and prior (unrelated) surveillance notes. Once they had all that information, they correlated it down to a suspect – Jeremy Hammond in Chicago. All these innocuous conversations with Sabu ended up exposing Hammond, and once the FBI had a suspect, the full LEA machine went into effect.
Inexplicably, Hammond was using a wireless network in his apartment. (When you’re doing something illegal, you probably shouldn’t be literally broadcasting it throughout the neighborhood.) The FBI eventually started watching his wireless activity and internet connection 24×7, as well as having him under physical surveillance. Their detailed tracking of Hammond’s physical activities were combined with Sabu’s reports on when sup_g was online in IRC. Once the correlation was well established, the FBI went to a judge and got a warrant. Game over for Jeremy.
OpSec is a full time job
Most people probably assume that hackers are caught “in the act” so to speak – tracked down by forensics from evidence they leave behind in the hack. But as both these stories illustrate, the ultimate failures of OpSec that cost both these men their freedom came during their “off hours” chat, not during the “operational” phase of a hack.
OpSec is 24×7 – and the more powerful your adversary, the harder it is to remain Anonymous.
You know an idea is here to stay when even the criminals get behind it… In this case, the idea is crowd sourcing and user-driven development models. Brian Krebs recently reported on a new development in the malware world – the developers of a new ZeuS variant called Citadel are offering a CRM and social network for their customers to provide feedback and report bugs.
What I find constantly intriguing about these types of developments is not that malware authors are trending towards the same best practices used by other development verticals, but that they can field such sophisticated customer relationship systems without compromising themselves to authorities. But having criminals continue the trend of cooperative development while defenders and authorities are all too often stuck in a mode of default secrecy, refusing to share what compromises and counter measures are working, does not bode well for our industry in the long term.
Thanks to a submission to VirusTotal, it looks like F-Secure has identified the first step in the RSA hack back in March. It was a basic phishing email, with a zero-day Flash exploit payload. It wasn’t sent to a privileged user, either. But compromising a regular user account eventually allowed the attacker to leverage enough control to steal the RSA SecurID token information they were after. This is an interesting combination of simplistic delivery vector (note how simple the email is) with an advanced attack package. And of course, this was the first step in a sophisticated attack that eventually resulted in attacks on several defense contractors. The lesson to be learned here – security really is about the weakest link. Everyone in your organization needs to be trained and computer savvy enough to avoid being taken in with one of these phishing emails.
Tech folks think business folks are assholes who don’t understand the technical details and should get out of the way.
Business folks think tech folks are assholes who don’t understand the financial details and should just do what they’re told.
In a way, they’re both right…
Solution: Cross the cultural divide and learn something about the other side of the house. I know it’s helped me immensely to gain a bit of understanding about how the business side works. That understanding leads to empathy and that empathy leads to collaboration and solutions to problems that each side can’t solve on it’s own.
I recently had a perfect example of the value logging fall right into my lap. While testing out ArcSight Logger (a very cool product for a very reasonable price), I noticed some unusual firewall traffic. My NAS was making connections outbound to a IP address in Taiwan – something that in the security world can get your attention real quick! Fortunately, some quick Googling and a packet capture later, I had documented what was going on and was able to share the info on the product’s user forum.
Without a decent log analysis tool, the raw bulk of data just makes things impractical. Within a few days of installing Logger, I had over 300k events from my firewall alone. But the power of a good tool was that it allowed me to filter down to things I didn’t expect and easily identify anomalies that needed investigation.
If you aren’t using a good log tool, I encourage you to check out ArcSight Logger and Splunk. I haven’t played with Splunk yet, but the interface looks very similar and I’m looking forward to seeing how it matches up. If you’ve used Splunk, feel free to let me know what you think!
It’s been four years since the last release, but the popular Windows SSH suite PuTTY has just released a new version! Make sure to update all your installations.
For those of you using VMware vSphere, be aware that the new vSphere 5 licensing model is looking like it will cost significantly more for most, if not all, users. Here’s the official vSphere licensing explanation and a recent forum post talking about the cost increases. For those planning vSphere 5 deployments, make sure your budget planning includes the new numbers!