Lessons learned from Hacking Team attacker - Part 2

Earlier I posted about HackingTeam's attacker post mortem describing the hack.  I'll keep part two short and sweet since it's a busy day for me on a forensics case.

The attacker notes in his post mortem that much of the data he stole was made possible due to data in backups.  He was able to easily access the backups on the network attached storage (NAS) devices because the iSCSI targets did not require authentication.

Nmap scan report for ht-synology.hackingteam.local (192.168.200.66)
...
3260/tcp open  iscsi?
| iscsi-info:
|   Target: iqn.2000-01.com.synology:ht-synology.name
|     Address: 192.168.200.66:3260,0
|_    Authentication: No authentication required
Nmap scan report for synology-backup.hackingteam.local (192.168.200.72)
...
3260/tcp open  iscsi?
| iscsi-info:
|   Target: iqn.2000-01.com.synology:synology-backup.name
|     Address: 10.0.1.72:3260,0
|     Address: 192.168.200.72:3260,0
|_    Authentication: No authentication required

There are two takeaways here:

1. Always require authentication on your iSCSI targets.  
2. Continuous network monitoring would have discovered the data exfiltration with ease.

Takeaways in detail:
NAS vendors like Synology and QNAP make it too easy to screw up iSCSI authentication with their easy to use administrative interfaces.  This never used to happen in the old days when real systems admins used to have to get involved with the creation of every iSCSI target.  This is a good point to consider - scan your networks for iSCSI (default on TCP port 3260).  During penetration tests at Rendition Infosec, we regularly find open iSCSI ports.  Unfortunately, many have weak or no authentication.

Continuous network monitoring is something we frequently talk about in security, but rarely actually do.  When Rendition Infosec does incident response, we almost always use network monitoring to aid in uncovering the badness that lurks beneath.  One of the things we're looking for are communications to odd devices.  Whether the attacker uses a port forward or a kernel module to connect to the iSCSI device and begin siphoning data, this will stand out like a sore thumb in net flow and connection logs - but only if you are looking.  Recall that the attacker pivoted through an undisclosed embedded device - this is probably not the sort of thing you expect to have an iSCSI connection, especially not if it's transmitting lots of data.

Closing thoughts
Don't pass up this rare opportunity to get a first hand account from the attacker on how the crime was committed.  Examine the post mortem and determine whether your organization would hold up under a similar attack.

Lessons learned from Hacking Team attacker - Part 1

The hacker responsible for taking down HackingTeam has published a post mortem on how the hack was performed.  It's relatively straightforward and there are some lessons that can be learned from it.

Why is this significant?
There's nothing earth shattering in the post - it's pretty much what you would expect.  But we rarely get a first hand account of how an attack was conducted and forensic evidence is almost never complete.  Organizations should examine this walkthrough and consider how their organizations would stand up in the face of a similar attack.

Entry point
The attacker notes that because Hacking Team had very little publicly exposed infrastructure, he had three choices for a remote exploit:

look for a 0day in Joomla, look for a 0day in postfix, or look for a 0day in one of the embedded devices. A 0day in an embedded device seemed like the easiest option, and after two weeks of work reverse engineering, I got a remote root exploit.

Security researchers know how poorly most software/firmware for embedded devices is built, so it's no surprise that this was the route the attacker chose.

When working with customers at Rendition Infosec, we regularly find that too much faith is placed in vendors to obtain quality third party security assessments.  All too often, the hardware and software these vendors are peddling to unsuspecting victims is plagued with obvious security vulnerabilities.  In some cases, no third party assessments have been performed at all prior to selling to the customer.  Of course, this fact is almost never disclosed - in fact, I've never seen a sales brochure proudly proclaim "shop with us, we've never had a third party security assessment of our software."

Sometimes vendors will tell you that they have performed internal security assessments. While these are better than nothing, they are hardly unbiased.  Again, in my experience with Rendition Infosec, well over a third of claimed "internal security assessments" are found to have been performed by the same development team that created the software in the first place.  Ever tried to proofread your own term paper?  How well did that work?  Yeah, that's what I thought.  It's even more ridiculous to think that developers can audit their own code for security flaws.

Pivot
Now that access was gained, the attacker wants to pivot through the device.  but most tools aren't available in embedded systems.  The attacker notes that he built a custom firmware image with a number of extra tools for pivoting and exfiltrating data.

Without getting into the specifics of the tools and techniques the attacker used, a takeaway here is that monitoring embedded devices is critically important for good network security hygiene.  Many monitoring strategies have good coverage for core Windows and Linux endpoints, but completely ignores things like routers, switches, multi function devices, and other appliances with network connections.  But these appliances are unfortunately usually the weakest link in our network infrastructure.

Organizations wishing to avoid repeating Hacking Team's mistakes should take inventory of their embedded devices and baseline normal network traffic to the devices.  Only when you know what normal looks like can you discover deviations from the baseline.  These deviations may be misconfigurations or they may be attackers using your network devices to pivot mercilessly through the network.

Stay tuned
Same bat time, same bat channel. Tune back in and we'll talk about a few more lessons learned from the Hacking Team breach walkthrough.

Congressman gets mad about SS7 flaws

If you've never heard of SS7, check out one of the many articles or presentations out there about SS7 flaws.  This one is particularly interesting.  The flaws, which according to this article are essentially an open secret in US intelligence agencies can be used to intercept voice calls.

When hackers demonstrated the ability to intercept calls by knowing only a congressman's phone number, he was not impressed.  Or perhaps he was too impressed.  But in any case he was definitely not amused, saying:

"The people who knew about this flaw should be fired," he said. "You cannot have 300 and some million Americans, and really the global citizenry, be at risk of having their phone conversations intercepted with a known flaw simply because some intelligence agencies might get some data. That is not acceptable."

While those are some pretty strong words, I think it speaks to elected officials' opinion of the vulnerability equities process.  We have been lead to believe that the equities process evaluates the risk to the US population agains the possibility of gaining intelligence.  If the article is correct and the NSA and others knew of the vulnerability, I personally can't imagine how it went through the equities process and was ruled to be safe to leave unpatched.

Further, I think this drives another nail in the coffin of the NOBUS argument.  Independent researchers have found a market in discovering vulnerabilities - and not just in Windows.  If it involves technology, researchers (white and black hat) are looking for security holes.  It's high time that US intelligence agencies admit that they are no longer the only game in town and start thinking about protecting the interests of all US citizens.

Who is running Cyber Command?

Ever wonder about senior military leaders trying to make decisions about cyber operations?  Based on some of what we hear about in the press, I sure do.  And I think the picture below sums up the problem better than anything else can.

The commander of US Cyber Command graduated college in 1981 (Naval ROTC).  He was commissioned into the Navy and went to whatever schools the Navy uses to train its officers.  But what were Navy Officers learning about cyber operations that year?  I'm pretty sure that most Navy officer schools then didn't even use computers.  I say that because 1981 is the same year that Cosby was advertising this TI computer with a whopping 16KB of RAM.

Let that sink in for a minute - 16KB of RAM is only 25% of the capacity of the venerable (and oft mocked) Commodore 64.  But that was the top of the line when our current US Cyber Command commander (what a mouthful) graduated college and was commissioned.  Now, I'm honestly less worried about Adm. Rogers since he has been working in intelligence with an active interest in cyber for years.  But many transitioning from regular military intelligence to cyber lack the same experience that Rogers has.  

Even worse, senior combatant commanders are asked to comprehend cyber at some level.  Unfortunately, this is an attack surface that didn't exist when many of them were commissioned.  Try as they might, cyber will always be something that is newer and foreign to them than it is to their younger counterparts.

Has this happened before?

Definitely.  Military officers have had to adapt to new combat paradigms before.  The advent of long range, accurate artillery.  The advent of the tank over cavalry.  The advent of combat aircraft.  Most recently, we've seen ground commanders adapting to the reality that they have drones at their disposal for surveillance without committing troops to perform recon.  Just as concerning, lesser advanced and equipped adversaries have drones that equalize this advantage and give them time to react to preemptive attacks.

In every case, commanders have had to make changes - and cyber will be no different.  What is different is the speed at which they will be forced to make these changes.  Drones took time to catch on just like tanks and artillery before them.  They were also relatively expensive capabilities for forces to acquire.  Not true with cyber.  Today's military commanders must learn how cyber impacts traditional kinetic warfare at a rapid pace or be overtaken by it.

Closing thoughts

My point in talking about this isn't to say that old military officers can't make effective decisions about cyber operations.  But I do think that they are at a significant disadvantage when compared to those younger officers who grew up with the technology and are trained in cyber as a warfare discipline from the ground up.

I'll write some later points on the problems of cyber warfare attribution, escalation of cyber operations into kinetic operations, and suggestions for training combatant commanders in what they actually need to know to integrate cyber (mostly defense) into their current operations.

P.S. This photo has to be the most 80's thing ever between the really old computer and Cosby still being popular.

CMS vulnerabilities and the Panama Papers compromise

If you've followed the Panama Papers leaks, you know that the leaks were a big deal.  They caused the Prime Minister of Iceland to step down.  Calls for officials in other countries to step down have been echoed as well.  This is a certifiable "big deal."

But it could have been prevented with good patching of the CMS.  It appears that the law firm Mossack Fonseca's Wordpress installation was significantly out of date.  The firm was also running a known vulnerable Wordpress plugin called Revolution Slider.

Mossack Fonseca's Drupal "secure client portal" was running a version known to be vulnerable in 2014.  Not patching this critical vulnerability on an Internet facing server for more than a year is beyond negligent.  Calling that same server the "secure client portal" is criminal.

It will be interesting to see whether these vulnerabilities directly contributed to the Panama Papers leaks.  At Rendition Infosec, we see a large number of compromises from unpatched CMS applications.  Some attackers just want to use the platform to send spam or exploit site visitors, while others upload a web shell and pivot into the internal network.  A CMS system can be a great way to deploy your web site, but they require constant patching and maintenance.  Once a vulnerability is announced, you're racing the attackers to get the patch out there for your Internet facing website.

Securing healthcare? You need an MDM strategy, even for BYOD

Note, that while the title on this blog specifically mentions healthcare, this is applicable to all verticals.  While the referenced reports draw their data from healthcare, the problem of confidential data on mobile devices, whether enterprise owned or  BYOD, is universal.

A new report out from Skycure shows that doctors use their mobile devices to share information about patients - a LOT.  And when mobile devices can and frequently do go missing - that patient data goes missing with them.  If you are securing healthcare today, you need an MDM solution.

In 2015, 70% of doctors reported using mobile devices to manage patient data, many of which are BYOD.  The number of doctors managing patient data with mobile devices is rising every year, and will quickly near 100%.  The problem is getting worse, not better.

Two different recent reports, Skycure and Ponemon, found that a disturbing number of mobile devices are infected with malware.  The Ponemon study found that 3.2% of devices investigated had malware infections.  The Skycure study found that 4.2% of devices had malware.  Based on my experience investigating incidents with Rendition Infosec, I think those numbers are underreported.  But in either case, that's a huge number of malware infested phones processing PHI.

Perhaps the most staggering statistic is that 14% of doctors who store patient data on their devices don't even use a password.  Forget about trying to enforce strict security or complex passcodes when 14% of those who store patient data on their phones.

Everyone in security knows that no amount of policy can fix stupid.  You need technical controls to get compliance (and monitor compliance) from users.  Users should not be permitted to store company sensitive data on mobile devices unless encryption and passcodes are used.  Even then, phones should be monitored for malware infections.  Remote wipe should be enabled because users will lose devices.

Many clients we've worked with at Rendition Infosec initially discount the need for MDM based on a low reported occurrence of lost mobile devices.  But for one client who had months of wifi logs, we were able to identify a large number of users who had replaced phones over the previous 90 days.  The client talked with the users, many of whom confirmed that they were replacing lost devices.  Almost none of them had reported the previous losses to IT.

Bottom line, you need BYOD if for nothing else than auditing and accountability (and the all important remote wipe).  If you have questions about deploying an MDM or need help managing one, contact Rendition Infosec and we'll be happy to get you sorted and on your way.

Badlock - a bad thing for our industry

TL;DR - if you're thinking of naming a vuln, think again
The day is here and while Badlock is a vulnerability, it's not the horror it was hyped up to be.

Is it RCE?
No

Is it Denial of Service (DoS) against Windows?
No

Will it make you a latte?
No

What was the CVSS score?
7.1

Whoa - 7.1?! That sounds pretty low...
Indeed, you are correct.  There are numerous bugs that have been released over the last 60 dyas with higher CVSS scores, none of which have their own website, name, or logo.  In fact, Rendition Infosec is much more concerned that clients apply the out of band Adobe Flash patch.  The flash bug is being actively exploited in the wild right now providing attackers with unauthenticated remote code execution. Badlock has no publicly available exploit and does not offer attackers RCE in any case.   FYSA, the Flash bug has a much higher CVSS score than Badlock's 7.1.

Why doesn't the new Flash vulnerability have a name like Badflash?
Probably because Adobe wishes we'd forget their software is horrifically vulnerable. Seriously, they stand to gain nothing by publicizing it, while the folks who discovered and publicized Badlock will live in infamy (for all the wrong reasons).

What the f*%k is Badlock then?
That depends on whether we are talking about Windows or Samba.  On Windows, it's an SMB replay vulnerability.  Microsoft has been warning about this for years.  We recommend to all of our clients that they implement (and enforce) SMB signing where possible.

If you are running Samba, then Badlock is a collection of vulnerabilities that are a Denial of Service (DoS).  It's not an RCE there either, though you could take a Samba server offline and cause it stop responding to requests.  In some embedded systems that use Samba this could make the device completely unresponsive.

Wait, are you telling me a non-RCE bug has it's own f%$king website?!
Um, yes.  And this is bad for our industry.  My students all know about the Jake's Mom Test (TM).  My mom is really smart in her own right, but she's a technotard.  If she's heard of a technology vulnerability, it's been really hyped.  Bugs that get fancy websites and lots of press catch her attention and I get a call.  I got a call on this one, probably because it's a slow news week.

Original attribution for hilarious meme @YanceySlide

The problem is that my mom also has a limited attention span when it comes to technology.  Try as she might, she can't be bothered by countless websites and media notifications if they are all bull sh*t.  It's the "chicken little" effect.  We as an industry can only claim the sky is falling so many times before people stop listening.

On bug naming
Bug naming isn't evil in and of itself.  Heartbleed deserved a name.  So did ShellShock.  I'm dubious of almost everything since.  VENOM was a publicity stunt.  Ghost was hardly exploitable anywhere.   The problem is that we have to choose the bugs we name very carefully.  When we fail to do so, the media gets numb to us howling about vulnerabilities that materialize to nothing.

On vulnerability disclosure
In my first post on Badlock, I accused Metzmacher of violating the generally accepted responsible disclosure guidelines. I even went so far as to accuse him of creating a new class of disclosure called 'douche disclosure.'  I tried to get this listed in Wikipedia (it was removed) and Urban Dictionary (they are surprisingly selective in approving new terms).  I'll need some help in making that term stick, but it could be a go.

Are you sorry you blogged about it?  
Not one bit.  I have a lot of clients, many of whom have have very real network security challenges.  If Badlock was all horror, three weeks is a long time to prepare and get the house in order before it burns to the ground.  Every recommendation I made would dramatically increase network security overall, Badlock or no Badlock.

Also, the early pre-disclosure prompted me to post instructions for checking TCP 139/445 egress filtering.  Many who read the blog have taken advantage of that and today understand they have a problem they didn't know about before.  That was a win for everyone and I'm happy Rendition Infosec could be a part of it.

Closing thoughts

In general, Metzmacher and Badlock illustrate that douche disclosure and indiscriminate vulnerability naming are bad for our industry.  Most of the non-infosec public are more like my mom (the technotard) than us.  We in infosec have a limited number of times we can cry wolf.  VENOM, Ghost, and now Badlock have all hurt us in this regard.  

I hate to say it, but I'm almost looking for another Heartbleed to restore some credibility with the media to our industry...

Badlock: it's here, now what?

Badlock: it's here (mostly) hype.  It's April 12th.  We've known for almost three weeks this was the day... Time for badlock.  Since the initial disclosure, many in the security industry have written about Badlock.  I have two blog posts about it here and here.  I try not to contribute to the hype and was careful to speculate that it might be just that.  

So was it all hype?
Meh.  There definitely was a bug, but it honestly isn't that bad.  And it isn't catastrophic.  Microsoft only rates it as Important rather than Critical.  It was pretty underwhelming to be honest.  It's not RCE, so we won't see a Badlock worm.  An attacker would have to already be in the network to abuse it and even then, it looks like it's only MITM.

What should I do (besides patch)?
1.  Disable SMBv1.  It's a relic and doesn't need to be a thing anymore.  If you still have it in your network and need it, determine what architectural changes are needed.

2.  Enable SMB signing and enforce it for all machines where it makes sense.  Microsoft has been recommending this to prevent SMB relay attacks for years.  You can read all about it here.

3. Enable port security on your network switches - this makes ARP spoofing nearly impossible.  Helpdesk hates it, but it does improve your security in a measurable way.

4. MITM is easier on wireless in the corporate environment than it is on the wired network.  Make sure the attacker can't get on your wireless network in the first place to ensure maximum security.  WPA2 Enterprise goes a long way here.

5. Go read my earlier post and do this stuff.  It will help your network security dramatically.

Shameless plug
As always, if you need help securing your network against this or any other threat, contact us at Rendition Infosec and we'll be happy to help you.  We're also happy to help you separate the hype from the horror.

Getting ready for Badlock

There's no shortage of speculation on what the Badlock vulnerability will hold in store for organizations when the patch is released this Tuesday.  The vulnerability's discoverer posted on Twitter that the vulnerability will give administrator to anyone on the network (though the tweet was subsequently deleted).

What does this mean?  Does the vulnerability require authentication or can an anonymous user exploit it?  This answer alone will help drive how dangerous the vulnerability is.  Also, does remote code execution occur or is this simply a privilege escalation vulnerability?  Privilege escalation would be bad, but remote core execution would mean that with anonymous access, Badlock could be wormable.  Bad stuff for sure.

What will Badlock impact?
Badlock will impact both Windows and Samba both of which use the SMB protocol.

How long will it to develop an exploit after the patch is released?
This is unknown, but the developers imply that an exploit will be developed 'soon' after details are made public.  You should assume the worst and spend some time on Monday getting ready (if you haven't already).

What can I do today?
Rendition Infosec has created a five step checklist for getting ready for Badlock before it hits next Tuesday.  We are referring to this as our "quick win" action items.

1.  Verify that SMB cannot leave your network.  If the exploit is wormable you don't want to be part of the problem.  SMB leaving the network is problematic for other reasons even if a Badlock worm doesn't emerge.  On any Linux or OSX host, check to see if you can reach TCP ports 139 and 445 on smbcheck.rsec.us.  If you get a banner, your network allows SMB outbound (no news is good news).  Talk to your firewall admin and get this fixed at your border firewall.

Not sure if your border firewall allows TCP 139/445 outbound? Rendition Infosec has set up a server so you can check.  Try these commands from any Linux server in your environment (or download a copy of netcat for Windows if you are so inclined):

nc smbcheck.rsec.us 139
nc smbcheck.rsec.us 445

If you get no output, you're good to go.  If you see what I have displayed below, you've got problems:

jake$ nc smbcheck.rsec.us 139
DANGER! Your network allows TCP port 139 outbound.  You should block this!

jake$ nc smbcheck.rsec.us 445
DANGER! Your network allows TCP port 445 outbound.  You should block this!

2.  Scan your network for devices listening on SMB.  Make sure you get authorization before doing this, but now is an excellent time to review your network inventories.  Know which devices you need to patch.

3.  Some of your network devices you never even think about will almost certainly be running SMB servers.  These devices need to be patched, but patches for these will not be available next Tuesday and likely will take months to distribute.  For those devices that you can disable SMB servers without breaking business functionality, do so.

For those devices that require SMB to be running, they probably only require access from a limited numbers of devices.  Restrict these device communications using IP access control lists at your routers and layer 3 switches to limit exposure.

Finally, note that some devices may never receive updates.  Samba 4.1 and below are out of patch maintenance, even for security fixes such as this.

4.  Consider partitioning your network by using layer 3 ACLs to block TCP port 139 and 445 inbound to your client network segments.  Private VLANs can be used to restrict client to client connections.   Windows firewalls can be enabled to prevent the use of TCP 139 and 445 on client segments as well.

Many administrators hate to restrict their activities because of firewall use, but in this case it might be worth the pain.  Firewall configurations can be updated via group policy, so manual intervention won't be required to remove these rules.

5. Identify points where network segments can be isolated in order to contain an outbreak.  Determine who has the appropriate device permissions to isolate a portion of the network.  Ensure that the appropriate personnel are available to act.  Also determine in advance who has the authority to isolate portions of the network.  You don't want to have a plan and then suffer from decision paralysis.

Isolating the network will almost certainly have adverse effects on business operations (how could it not), but these might be worth it to contain an outbreak of a worm.  Discuss with business leaders under what conditions you would isolate network segments so the actions can be taken with minimal discussion while under fire.  An alternative to isolating the network segment completely is to just block SMB from entering or leaving an infected segment.  While this would stop a Badlock based worm from spreading, it is far from foolproof.  Malware already present on these machines could continue to present a risk in your network as a whole.

Some of this might seem unnecessary, but if Badlock turns out to be wormable, then an ounce of prevention on Monday will be worth a pound of cure on Tuesday and beyond.  As always, if you need additional help or assistance in securing your network, contact Rendition Infosec (or email inquiry at renditioninfosec dot com) for help.