Apple and Seagate Hacked

Over the years, Apple has dismissed some of their best technical talent. Today, it came back to bite them: the legendary electronic maker had to admit that they got hacked big-time, joining Seagate in this predicament. It made news all over the airwaves.

Zulfikar Ramzan, the CTO of RSA Security, the cyber security behemoth that’s going to merge into the Dell family, took to the airwaves in response to the news. On CNBC The Closing Bell 3/7/16, he spoke eloquently but rather vaguely about the specifics of the Apple and Seagate hacks. Apparently, he was more interested in making a great RSA sales pitch than in giving a cyber security analysis of what went wrong at the two companies. He clearly wasn’t so much into giving the audience actionable intel but into presenting RSA in the best light possible so as to capture leads. Ironically, RSA is plagued by some of the same security vulnerabilities that got Apple and Seagate a prime spot in today’s newscycle.

Let’s take a look at Apple and see what the company may have done to deserve it.

Apple.com uses https encryption but fails to enforce it. Data served from

http://images.apple.com

and

http://metrics.apple.com

are transferred without any encryption whatsoever. Apple didn’t drop merely a few balls, they dropped them all: no security headers means no protection of the user of a compliant web browser.

That bears repeating: none of the cyber security headers, Strict-Transport-Security, Content-Security-Policy, Public-Key-Pins, X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options, were actually used. Being the biggest stock-market traded IT company somehow got to their heads. Given the blatant ignorance, the cyber security incident was not a matter of if, but only a matter of when.

Furthermore, Apple is–as of this writing–vulnerable to the DROWN attack due to the use of the SSL v2 protocol.

This hack, much like earlier disasters (including the Apple iCloud hack) have been long in the making.

Over the years, Apple has fired some of its best technical talent, including, most notably, as Avadis Tevenian, the inventor of the OS X kernel, and Don Brady, who was in charge of HFS+ and ZFS at Apple for over 20 years and is now a Filesystem & Kernel Software Engineer at Intel.

In their place, Apple hired away, in marketing, for example Angela Ahrendts, Senior Vice President, Apple Retail, an amazing marketing talent from Burberry. Great move! She is brilliant, very talented and was the driving force behind the turnaround at Burberry. Sadly, she and other top-notch sales experts, came at the expense of software engineers. Given the billions of Dollars Apple puts aside every quarter, was that really necessary?

Apple is not alone, though. Seagate wasn’t far behind in terms of its cyber security blunders, and it shows in the results. As long as Apple insists on continuing this marketing-only strategy, more security breaches are bound to happen.

Seagate’s web servers run on the museum-grade Apache 2.2, a web server that was cool in the late 90’s. Today, using any Apache server version is kind of an insult and not so much a sign a great intelligence. Furthermore, the Diffie-Hellman-Key deployed by Seagate is just a mere 1024 bit long. Your iPhone or Android phone might hack this easily (though we haven’t tried).

Having said that, a 1024 bit DH key is just completely inappropriate and more of an invitation to getting hacked than a serious deterrent. Given that, according to Bruce Schneier, massive precomputation on clouds such as AWS and Azure is now commonplace and it greatly simplifies breaking Diffie-Hellman keys. A weak DH key might have been at the core of the Seagate and Apple hack.

Another weakness in Seagate’s configuration is the lack of perfect forward secrecy.

It almost goes without saying that TLS RSA encryption with an RC4 cipher in 128 bit is a big no-no! Instead of 128 bit, Seagate should be using 256 bit. In cyber security, it’s always better to be safe than sorry.

As far as the cyber security headers are involved, Seagate did a very poor job and dropped a couple of balls, too. For instance, Seagate omitted the headers Content-Security-Policy, X-Frame-Options, X-XSS-Protection,and X-Content-Type-Options. Especially the Cross Site Request Forgery (XSS) header (a.k.a. X-XSS-Protection) might have helped to prevent the attack.

In a nutshell, Seagate did a very sloppy job. Unfortunately, sloppy cyber security seems to be the new normal and that’s why these cyber attacks keep coming (See also: The Next Frontier: Hacks, Data Leaks, and How HTTP/2 Fits the Picture of Cyber Sovereignty).

Stay tuned for more at CloudInsidr and subscribe to our newsletter!