Archive for the ‘Uncategorized’ Category

Even “security consulting” firms get hacked

Tuesday, September 26th, 2017

I have to confess – I love irony.

… Sounds nice, but the reality is more like this …

Sounds like their Office 365 admin account got hacked … because they used neither the built-in 2FA on Azure nor a privileged access management system. Like our friends at Equifax, Deloitte delayed public disclosure as long as possible and is actively down-playing the scope of the (very serious, it seems) compromise.

Would you take security advice from a firm that got hacked in this way and failed to disclose to their customers?

Equifax breach

Friday, September 8th, 2017

The Equifax breach reported this week sets a new bar for exploited PII!

Apparently SSN, name, DoB and in some cases CC data for 143 million Americans was compromised. Given that probably 1/4 of the population has no credit cards (children, the elderly, illegal immigrants, etc.), this means that PII for over half of US card-holders was compromised in a single hack. That’s huge!

What can we learn from this?

First, what not to do? Other firms should learn from Equifax’ mistakes:

  1. Equifax let this happen, presumably by under-investing in IT security. Did they have a privileged access management system? Effective access deactivation processes? Pen testing against apps? Sound firewalls? 2FA? I don’t know, but I bet some of those questions will come back with a “no.”
  2. Equifax discovered the breach on July 29 but disclosed Sep 7. That’s a 40 day delay – disgraceful and probably illegal in some states.
  3. While the Yahoo breach was larger, this one included SSNs and some D/Ls, so the data stolen from Equifax is much more suitable for identity theft. This is bad folks.
  4. There may have been insider trading – three executives sold some stock after the breach was discovered but before it was public. If they knew about the breach, they are risking jail time.
  5. Equifax setup a web site for consumers to check if their information was included in the hack. But apparently you have to waive your right to join a class action lawsuit against Equifax to use it. That’s “sneaky” – except that lots of people caught on, so now it’s just more bad press.

Bottom line: Equifax could well go out of business as a consequence of this event and how badly it was handled. I’d lay at least 50/50 odds that this event kills them within the next few years, as litigation works its way through the courts.

Next, what to do?

  1. Watch your mail for letters from banks or other firms, to see if someone has taken out a loan in your name. Consumers beware, your info is probably compromised!
  2. Stop using name, SSN or DoB as credentials. If someone calls your IT help desk and you need to authenticate them, this data should be assumed to be public and not suitable for authentication.
  3. Lock down your IT systems. You don’t want to be the next victim.

UPDATES:

  1. just saw this:
    Equifax Faces Multibillion-Dollar Lawsuit Over Hack. That didn’t take long!
  2. Krebs lambastes Equifax, noting among other things that the web site to check if you’re affected by the breach appears to be bogus – it just returns a random string, and issues a predictable PIN. He also gives good advice (news to me, as I’m not an American), that you can visit his earlier post to learn how to lock down your credit profile, which should offer some protection against incompetent credit rating agencies combined with identity thieves, at no cost.
  3. It just won’t stop. They were caught with their pants down in Argentina too! admin/admin logins

But what about usability?

Wednesday, May 17th, 2017

Thin and beautiful devices are commonplace nowadays, but it feels like nobody cares about usability any more.

What got me thinking about this is the age of my laptop. It’s an older Lenovo and has an awesome keyboard. We’re talking full keys, long travel, pre-chiclet design. My laptop is ugly as sin, but really easy to use when I travel. Sooner or later I’m going to have to replace this thing, and it seems that all laptops nowadays have chiclet keyboards. Ugh. I find it difficult to type at any appreciable speed on chiclet keyboards.

The newer keyboards look nicer, but they are harder to use. Smaller keys and shorter vertical travel.

This is a part of a larger trend.

Another example is very thin phones — with too small batteries and consequently less-than-desired battery life. I’d really rather my phone was 1mm thicker, a few tens of grams heavier, but had twice the battery life. I think most consumers might agree with me on that one.

Want another example? How about SIM cards. Oh how I hate the shrinkage of SIM cards! I travel often and instead of paying high roaming fees, I like to pick up a local SIM card when I arrive at foreign airports. That works great, but the SIM cards themselves have become so small that they are hard for someone with adult-size fingers to manipulate. Was it really necessary to shave off an extra few square millimeters? All SIM cards are electronically identical — the shrinkage is just in the plastic surrounding the chip. The original SIM card design was quite small, and new “micro” and “nano” SIMs are awful.

I’ve got more examples! Ports on laptops are one: Many new laptops either omit ports (Ethernet, VGA, etc.) or require dongles. Looks great, very thin, but quite a nuisance to use. Laptop power adapters are another. Why are there a hundred different kinds of plugs? All laptops consume 20V and about 5A – so why do we need so many shapes and sizes of power plugs?

Maybe this is an opportunity for some manufacturers to carve out a niche, selling to users who care about usability:

  • Build slightly thicker devices, with more ports and bigger batteries.
  • Support “big” SIM cards in phones.
  • Standardize on something like USB-C PD for power, even in laptops.
  • Advertise that these devices are built to be used, not just looked at.

Patch management in an IoT world

Tuesday, May 16th, 2017

The recent WannaCry ransomware spreading around the world has been both tragic and predictable. Tragic because it knocked out organizations doing important work, like the NHS in the UK. Predictable because there is a growing gap between security practices in the information technology (“IT”) and operational technology (“OT”) arenas.

In IT, we’ve learned long ago that software is inherently buggy and a reasonable defense against that is to patch — automatically and as quickly as possible once a patch is released. This reduces the window of opportunity for attackers.

We can talk about other causes – the NSA weaponizing zero-day exploits or hackers stealing and remarketing that stuff – both are problems – but I don’t imagine either of these things is going to end any time soon.

We can point to Microsoft for introducing the bug in the first place, but to be fair their coding practices have been pretty good over the years and their response to security problems has been exemplary.

What remains is us, the end customers patching known problems.

Our IT shops generally do a pretty good job, though this bit of ransomware certainly caught out a few who may have not had the skills, mandate or funding to do it right.

What we aren’t talking about is systems that are not managed by any IT organization. Operational systems control the doors and heating and cooling systems in our offices. They run devices ranging from security scanners at airports to camera surveillance at the mall. These are “operational technology” — same basic technology as IT, but used to interface with and manage physical systems.

The trouble with OT is that it gets installed by people without IT skills. Heating/ventilation/air conditioning (HVAC) vendors install PCs that keep us warm or cool. Physical security vendors install camera and door control systems. The list goes on. These are often people without IT skills. Worse, the systems they deploy are installed and forgotten. They keep running, without anyone thinking much about them, for decades.

Here’s a cool example: an old Commodore Amiga system running HVAC in a school for 30 years:

http://www.popularmechanics.com/technology/infrastructure/a16010/30-year-old-computer-runs-school-heat/

Historically, these systems have not been connected to any network. Their security basically relied on physical isolation, both from other computers and — behind locked doors — from unauthorized people. It didn’t matter if the code was buggy and exploitable, because only one or two authorized people could physically interact with them.

The world is changing, however. Your HVAC or security vendor wants to be able to assist you without a site visit. You want to be able to monitor who just walked into the building without leaving your desk. These systems are getting connected to (at least) private networks and in some cases to the public Internet.

That’s a problem, because these systems run old code, without anyone looking after security, such as firewalls, OS patches, intrusion detection, anti-malware, etc.

This is the brave new world of “Internet of Things” where old, unpatched devices perform critical functions and also get IP addresses.

We should worry. It doesn’t matter how good a job we do building IoT systems today, how confident can we be that what we build today will still be secure in 10 years? 20? 30?

WikiLeaks Vault7

Wednesday, March 8th, 2017

WikiLeaks dropped a trove of information about hacking tools from the CIA this week. It’s available via BitTorrent, in an encrypted archive, whose password is SplinterItIntoAThousandPiecesAndScatterItIntoTheWinds. That’s amusing, I suppose.

So what’s in the archive and what does it mean?

First, the archive appears to be a dump of an Intranet portal at the CIA, where staff share information about hacking tools. It’s missing a bunch of stuff – images and documents – so the download appears to have been incomplete. Moreover, this is information about the tools, rather than the tools themselves, though those were apparently leaked
earlier in a separate incident.

There are tools here to hack every common operating system – Windows, MacOSX, Linux, Android and iOS. There are also tools for various other platforms, including some Samsung TVs.

There has been a bunch of wild and wooly press coverage about this leak, but no, the CIA does not appear to have tools to compromise encryption in popular messaging system. It’s simply the case that if you can compromise either end of the conversation, then encryption between the two ends of the conversation is irrelevant. They can’t magically turn your TV into a spy device (without first breaking into your house) and they can’t (yet?) cause your car to suddenly crash. All of these things are plausible, and even discussed in the leaked documents, but not described as current capabilities.

Many of the tools discussed in the leak require physical access. i.e., if you are some “bad guy” that the CIA is interested in, and they can touch your phone or PC or TV, then they can install malware on that device to help them spy on you. Clearly, that doesn’t matter much to most people.

Some of the tools work over the network, and obviously that’s more serious, especially if they get into the hands of criminals or other adversaries that the average business or consumer might be more worried about than the CIA.

Also of note is that some of the tools leverage security vulnerabilities in popular products that the vendors and security researchers were not previously aware of. For the US government to discover such bugs and not work with vendors to close them leaves the public at risk and represents quite dubious ethics.

So is it time to panic? Hardly. We already knew that every large and complex piece of software has bugs (they are written by human beings after all) and that some of those bugs can be used to compromise security. We also already knew that all advanced government spy agencies work to compromise device security to either collect information about their adversaries or to disrupt their operations. That the CIA is doing this is only vaguely surprising, in the sense that it really should be the job of their sister agency, the NSA.

Everyone should already be aware that a smart phone is a perfect surveillance device, incorporating network connectivity, a GPS receiver, plus microphones and cameras. It’s obvious that spy agencies would work to hack into these things to monitor people, and would at least sometimes succeed.

So what’s interesting here?

Well, someone at the CIA obviously dislikes their employer enough to leak this information. That’s a serious crime.

The US government does not disclose all zero-day exploits it finds to vendors. That’s morally compromised.

WikiLeaks is more interested in the (fairly mundane) behaviour of the US government than that of various dictatorships, such as Iran and Russia. That makes WikiLeaks and Julian Asange look quite bad, actually. They are pretty much a puppet of the Russian state at this point.

The involvement of both WikiLeaks and Russian intelligence services in the recent US presidential election should be alarming to everyone in the West. There is no reason to believe this kind of interference will stop there — it’ll continue into the future and in other Western countries. This data dump is really just a side show compared to Russian cyber
warfare efforts.

Sometimes, security boils down to pretty simple controls

Monday, August 22nd, 2016

There’s an interesting read this morning about what attack vectors are actually used to compromise corporate networks:

darkreading.com

What’s notable is that most of the commonly used, successful methods used to compromise an organization’s security are related to credential management.

When you read about security, it’s usually about software vulnerabilities, zero-day exploits (i.e., those that have not yet been discovered by others or remediated by the software vendor), perimeter defense and patch management.

That’s sexy stuff – it’s technologically advanced, requires highly skilled people to find problems and develop exploits, etc.

The reality is much more mundane, however:

  • Weak user and admin passwords.
  • Users that unwittingly download and run malware.
  • Use of old, insecure password and name resolution protocols.
  • Plaintext passwords stored on disk and in memory.
  • Wide-open networks, which allow an attacker with a small beachhead to attack additional systems with ease.

The solutions to these problems are fairly simple too:

  • Shut down network services that use old, weak protocols.
  • Patch or upgrade software address plaintext passwords in-memory or on-disk.
  • Limit user access to only what they need, only when they need it.
  • Segment the network with internal firewalls, to limit the impact of a successful breach.
  • Get users to choose strong passwords.
  • Automate controls over admin passwords.
  • User education and awareness, especially around malware and “social engineering” attacks.

Perhaps not as sexy as zero-day exploits, but more effective.

Hitachi ID Systems can help with some of these security strategies:

Whose machine or app is it anyways?

Friday, June 10th, 2016

If you deploy a modern OS, such as Windows 10, you may be surprised to learn that it’s calling home. A lot.

For example, here is a screen shot from my Windows 10 PC of the diagnostic settings, relating to what information the PC shares with Microsoft:

feedback-options-windows-10

Notice that there are 3 options, none of which is “stop doing that.”

I have no reason to believe this is unique to Microsoft. Apple MacOSX does it., Android and iOS on phones and tablets certainly monitor you and even some Linux distributions have telemetry features, though generally off by default / offered as a paid service.

Which begs the question — whose device is it? I bought the hardware, I either purchased the OS with the hardware or installed it separately, I *own* the system. What business does it have snooping on me and sending information to a third party?

I know there are legitimate reasons for this – aggregate health diagnostics, heat maps about apps that misbehave, surveillance to find malware, etc. That’s fine, but surely the default should be “off” and sending anything from my PC to some vendor’s servers should require my permission. That’s not the current state of affairs.

Which brings us to compilers. It’s been known for decades that you can insert malware and Trojan horses into compilers and create hard-to-detect compromise of systems.

It seems that Microsoft has recently, perhaps inadvertently, done something close to that. A recent release of Visual Studio inserts code into even the smallest, do-nothing programs to send telemetry home to Microsoft. (infoq.com). When caught, Microsoft confessed to doing this, claiming (probably rightly) that it was intended to be an innocuous performance tuning tool: (reddit.com).

This instance will be backed out, but Windows 10 remains a “call home” machine, as do smart phones and Mac’s.

I wonder what it will take to reverse this awful trend?

Hardware appliances have no place in production

Friday, May 27th, 2016

One of our customers runs the RSA/Aveksa product to automate access certification. Interestingly, this product was delivered on a physical appliance.

Some time this week, the hardware in the appliance (which is just a white label PC, I’m sure) died. This means that this company’s access governance system went offline. Since it’s hardware, and presumably because the company didn’t want to pay double to have a hot standby, they now have to wait until next week for replacement hardware. At that time, who knows how much effort will be required to re-enable the service?

All this is in a major US metro area — easily reached by the vendor. Imagine what would happen if this happened to an organization in a more remote part of the world, where import controls and duties can add days or weeks to delivery, and where local integrators are few and far between? What is a 1-3 week outage in the US could be a 1-2 month outage elsewhere.

Of course, this all could have been mitigated by buying redundant appliances. A costly waste of physical infrastructure, but doable.

In this day and age, why do people still ship physical appliances? As evidenced above, they are expensive and unreliable. They are also incompatible with the trend from the 2000’s to virtualize and the trend from the 2010’s to move applications to the cloud. They are energy and space inefficient. They may have unpleasant interactions with national border control officials, who have a fetish for taxing or blocking technology in general and cryptographic technology in particular.

What’s the upside of a physical appliance? If your system requires exotic hardware (ASICs) to perform well, then OK, I get it. That may apply to super high performance firewalls or anti-malware scans at wire speed, but not to most applications. Or perhaps your application is horribly complex to install, and you can shave days or weeks off of deployment time by pre-installing at the factory. I would argue that if the latter is true, you have a crappy application, and should fix it rather than hacking your way around the problem with an appliance. And if you must pre-package, then for god’s sake use a virtual appliance, not physical hardware!

In the context of an IAM system, the implementation effort has more to do with business process definition, policy setup and target system integrations. Installing the app itself shouldn’t take more than an hour — see above: if it does, then your app is the problem, go fix it.

The bottom line is this: The 1990s called, and they want their physical appliances back!

Anti-virus software creates a entry way for … malware

Tuesday, May 17th, 2016

If you think that running anti-virus software is good for security, think again.

There have been multiple exploits lately of vulnerabilities in badly written, badly architected A/V software, such that an attacker can exploit the A/V bug to compromise your system.

Here’s the latest whopper: ZDnet.com.

I think a well patched OS may well be safer than one encumbered by these badly built “security” products. Wow.

Passwords may be insecure, but so is everything else

Thursday, April 28th, 2016

Interesting bit of news today. Apparently Microsoft’s Office 365 had – for some lengthy but undisclosed period of time – a vulnerability exposing every single account to public access. This means that if your organization offloaded Exchange to O365, all your e-mails and documents were wide open for some long period of time (months? years?).

The details are here.

The short version is that there was a bug in how SAML assertions, allowing O365 to offload user identification, authentication and authorization to another system, such as on-premise ADFS for example, were processed. An attacker could consequently impersonate anyone with a bogus SAML assertion.

Wow. Just wow.

This is no different than if they had dumped plaintext passwords for all of their users.

So to everyone claiming that if we could only get rid of passwords, the world would be safe again – here’s the counter example. It doesn’t matter how you authenticate users, security bugs trump everything.

Safe computing everyone!