테슬러 사이트 웹변조에 대한 분석

What you’re about to read is a rough break-down of the Tesla Motors Twitter and teslamotors.com website defacement, and also the possibility of the compromise of one of the “AkamaiGHost” web caching/mirror servers Tesla Motors appeared to be utilizing for redundancy or load-balancing at the time of the hack, a detail no one really mentioned during or post-occurrence…So I thought I’d share my findings.

It is also my personal opinion that during the dissemination of information about the hack (via twitter), that dis-information was purposefully propagated in an effort to misdirect attention away from the initial compromise.

“In wartime, truth is so precious that she should always be attended by a bodyguard of lies.” – Winston S. Churchill

Mid-day, On Saturday April 25^th 2015, information about a Tesla Motors twitter account take-over started flowing unto the fragile webs, followed by the take-over of the official Elon Musk twitter account:

Both accounts obviously indicating they were freshly compromised by a “RIPPRGANG”, which will later be found to be LizardSquad.

Upon seeing this, I head over to http://www.teslamotors.com to find that it, had also been hacked:

It read, “Hacked by Autismsquad!”
Naturally, I checked out the HTML source, which, at the time, was viewed from a machine in the US… (more on geo-location later and how it was critical to the findings later on in this analysis).

Here’s the source code of the content that would eventually make its way around the internet (just a quick “view-source” from my browser):

 

A copy of the complete source can also be found here: http://hastebin.com/raw/egipewexib

As time passed, literally minutes into the hack, several theories began to emerge:

• The Twitter accounts weren’t configured to use two-factor auth, and were brute-forced, and accessed due to weak passwords and/or password re-use across multiple twitter accounts, although this wouldn’t have explained the website defacement, unless those same exact credentials were being used for the Network Solutions control panel.

• The domain registrar login information for teslamotors.com, registered with Network Solutions, was social engineered, and from there, DNS modifications were made. Specifically, the MX records, A and NS records were also changed to point to an IP address controlled by the attackers. From there, they would issue a password reset and would receive all mail for that domain (including the new credentials/temporary link, whatever it is with twitter.) With a change in A and NS records, the attackers would have complete control as to what IP address the domain would ultimately end up resolving to, which would host the hacked page. (This theory ends up being the one everyone runs with)

• Another theory would include social engineering AT&T to get all phone calls to a legit number forwarded to another number that the attackers controlled, which could then have been used to change the domain details at Network Solutions using that particular verification method. This is actually the method put forth by a Tesla Motors Press Release, but not one which I particularly subscribe to.

At the end of the day, the steps, in order, would had to have been something like:

1. Social Engineer your way through Network Solutions’ Customer service to get access to the domain details, DNS settings, etc.
2. Modify the MX record to point to a mail server you control. Also modify the A and NS records, and point the TLD and www subdomain to an IP hosting the “Autismsquad” page.
3. Receive all mail for the teslamotors.com domain.
4. Request a password reset for the twitter accounts.

Further Down the Lizard Hole

It was time to get some specifics, technically.

From a machine far-away on the other side of the planet (Japan), I run an nslookup on the teslamotors.comdomain which showed that it was resolving to a 69.192.182.25 IP:

This is an Akamai IP address, running their “AkamaiGHost” HTTP accelerator/Mirror service.

This didn’t make sense at first, because it’s not often you come across a defaced page, being hosted on one of these unless it was a truly compromised box. Not typical of a DNS-Hijack, and there had been early confirmation (on twitter) of a digital ocean box that had been hosting the defaced content. So the fact that this was Akamai didn’t make much sense right away.

My initial thought was that DNS propagation hadn’t made it to Japan yet. I had to react quickly to get an idea of the content that was sitting on the 69.192.182.25 (e7797.x.akamaiedge.net):

$wget http://www.teslamotors.com/index.html

In any other situation, what I would have gotten would be the defaced index.html file that would match the hacked HTML source earlier in this analysis, in the “Autismsquad” defacement, but this wasn’t the case.

What I actually ended up getting was an un-modified teslamotors.com index page. Which I identified by the Title tag, and the build information comment at the bottom of the source:

This, to me, indicated that the original teslamotors.com site was still accessible from my machine in Japan, which sort of confirmed the “DNS hasn’t propagated to Japan” theory so far…Ok…

Get a little more info. A quick version scan of TCP/80 revealed an http-robots.txt file with some disallows defined:

I grab the INSTALL.pgsql.txt and INSTALL.sqlite.txt files.

The files referenced in the robots disallow are remnants indicative of a Drupal installation and are publicly accessible.

The INSTALL.pgsql.txt file with a default Drupal install, usually explains how to create some tables and database users for your installation, but not in this case…

This is where it gets interesting…

$wget http://www.teslamotors.com/INSTALL.pgsql.txt

We’ve downloaded the INSTALL.pgsql.txt file.

INSTALL.pgsql.txt (2,638 bytes)
MD5: 731ede73118b9c24f788752f76becd4c

Just to be clear, an ORIGINAL, unmodified Drupal 7 INSTALL.pgsql.txt file that I later downloaded had an MD5 of 3f682f768267764ca2c4a2d0e88660e6 and a file size of 1,874 bytes.

To my surprise, the contents of the INSTALL.pgsql.txt were not the standard Drupal database config instructions, but rather, defacement code which pointed to “LizardSquad”, rather than “Autismsquad” that we saw in the “live” defacement page:

The only difference between the actually hosted defacement page source code, and the source code hidden in the INSTALL.pgsql.txt file, was the attribution, which noted LizardSquad, and some other minor details, like the dimensions of the embedded YouTube video.

I think it’s safe to say, that the Akamai box, is physically hosting a version of the HTML source code of the defacement, but hiding within the INSTALL.pgsql.txt and INSTALL.sqlite.txt files, which I have the original downloaded files posted here, and here, respectively.

It’s at this point that I realize that somewhere along the way, the hack started as “LizardSquad”, and ended up evolving into an “Autismsquad” hack. The interesting piece here being that these modified Drupal INSTALL* files were physically being hosted on a machine controlled and owned by Akamai/Tesla, as we can confirm via the SSL certs’ “commonName” identifier on the 69.192.182.25 (Akamai) mirror machine:

These facts, indicate that this Tesla/Akamai machine had been accessed (at some point), and theINSTALL.pgsql.txt and INSTALL.mysql.txt files were modified, and their contents replaced with “Lizardsquad” tagged defacement HTML source code, which would later be modified, and used in the Autismsquad DNS Hijack.

Questions still remain however… how was the akamai box compromised? Was it accessed as part of the Network Solutions Social Engineering phase? Was it compromised via a Drupal 7 exploit? 0day? Were the credentials to an Akamai LUNA control panel compromised via the the aforementioned SE methods? What are your thoughts? Did I step into some weird LizardSquad wormhole? I’m tired. And going to bed. Good Night, Good Morning, whatever it may be.