Showing posts with label email. Show all posts
Showing posts with label email. Show all posts

Sunday, July 31, 2016

Reporters never open infected Wikileaks attachments

Since I've published my findings on malware in the GI Files Wikileaks file dumps and my subsequent attempts to encourage Wikileaks to label such malicious content, I've repeatedly been told by a variety of "Security Experts®" that no one will open infected attachments from email file dumps.

I plan on writing a post on how assumptions about user behavior are frequently inaccurate, and how assumptions based on the behavior of Wikileaks researchers analyzing email dumps based on the typical behavior of normal email users is particularly prone to failure, but for now I'll just leave this here:

Friday, July 29, 2016

Fox News asked for my take on the DNC email dump

I was interviewed yesterday by Fox News science correspondent James Rogers. I was asked for my input on the distribution by Wikileaks of emails leaked from a Democratic National Committee email server earlier this month. The entire article, which includes quotes from a variety of infosec professionals, is now available here.

If anyone is interested I might post my complete conversation with Rogers, where I talk in more detail about how the unlabeled distribution of email attachments from compromised email servers poses unique dangers to journalists, activists and researchers whose job involves reviewing each of those attachments.

This article represents the most attention paid by US media to the significant dangers posed to Wikileaks users by the insecure review methodology in place prior to distribution of these files. Although major newspapers in Europe and the UK published my findings on malware within the GI Files, no major news outlets in the United States published those findings.

Thursday, January 14, 2016

Bash script to email new S3 bucket files as compressed attachments (UDPATED)

I've written a simple bash script that checks for new files in an AWS S3 bucket and emails any that it finds as a compress (tar.gz) attachment - you can find it at my Github account under the name "S3-Filer-Mailer". I built it as a supplement for a contact form that relies on S3 as a back-end, rather than a php mailer or database. Using S3 for contact forms is attractive because it is so unattractive to spammers. There is no way to corrupt this sort of setup for spamming or to get hands on a database through the form, because it isn't connected to one.

Why not use Amazon's Simple Notification Service (SNS)? For one, AWS charges more for SNS than it does for S3 queries and downloads. For another, if this sort of functionality is available through SNS it is not clearly documented.

Getting back to the topic of security, the script establishes two network connections - one a connection to S3 to retrieve the files, the other sending the email. The S3 connection is encrypted using TLS; I'm going to add an extra pipe in here to gpg2 as time permits to encrypt the attachments themselves to close the loop - or you can do it yourself by adding a line with gpg -e -r Name foo.txt, where Name is the name you used while generating the public key you wish to use to encrypt the file. Adding encryption support as a command line operator is easy, but I want to add it as part of more general sanity-checking input.

The script was built and tested on RHEL, but it should work in any Linux that supports bash. This is pre-pre-alpha version, so no complaining. The obvious and immediate functionality problem ATM is that the script assumes that only files that contain a string with today's date in their filename were created today (plus the string has to be in format YYYYMMDD). When my copious spare time allows I will get to adding an option to filter results via regex; for now users can do this fairly simply by piping an additional grep command between grep ${TODAY} and > ${FILE} on line 16 of

The script includes two files, an executable file ( and a configuration file (S3-Filer-Mailer.conf). To get things working, move both files to a computer running Linux and modify the S3-Filer-Mailer.conf file settings; that is where you will specify your email address and your S3 bucket. You can also limit the script to a subdirectory of your bucket in the conf file. The script is recursive, so if you specify the root directory of your bucket it will check every subdirectory. For the time being, that is the only way to specify multiple subdirectories; similarly disabling recursiveness requires modifying the executable.

Also, dependencies. There are some. Only one of them should take more than 5 seconds to install, the AWS Command Line Interface. You will need Python for that if you don't already have it. On the bright side, if you want to do cool stuff with AWS and you are using linux you should be happy to drag more crap to a CLI, right? The only other dependency is mailx.

UPDATE: I've moved this from a gist to a full-fledged Github repo, and I've made a few updates that make this script significantly less lame.

The earliest version of this required sharutils to uuencode attachments, but that is no longer necessary. Relying entirely on mailx encoding also resolved an ongoing issue in which Mozilla Thunderbird did not properly recognize attachments.

Variables that need to be changed in order for the script to function have been placed into a separate .CONF file.

Wednesday, January 13, 2016

Email server using amavisd-new fails with (!)DENIED ACCESS from IP, policy bank ''

I have used ClamAV and Spamassassin for many years. I've had a less experience with Amavis (now amavisd-new), but I've decided to give it a try with a new mail server deployment I've been working on. As a reference for my install, I relied on the documentation provided by Amavis for integration with Postfix as well as a somewhat-outdated but still-relevant walkthrough published by CentOS. Prior to integration with amavisd, Postfix worked fine. Similarly, I had no issues with Spamassassin on its own.

But once I finished my install of amavisd-new, things quickly went wrong. Attempting to send messages to accounts hosted on my email server resulted in the following chaing of errors in my maillog:

Jan 13 18:17:34 hostname amavis[31578]: Net::Server: 2016/01/13-18:17:34 CONNECT TCP Peer: "[]:40209" Local: "[]:10024"
Jan 13 18:17:34 hostname amavis[31578]: loaded base policy bank
Jan 13 18:17:34 hostname amavis[31578]: lookup_ip_acl (inet_acl) arr.obj: key="", no match
Jan 13 18:17:34 hostname amavis[31578]: (!)DENIED ACCESS from IP, policy bank ''

Just as background, the system this article refers to is an AWS EC2 virtual machine, running CentOS 7 with Postfix v2.10.1, Dovecot v2.2.10 and Roundcube version 1.1.3; the trouble I experienced should be relevant to integrating amavis with other MTAs and operating systems, though - so if you encounter the same issue I did its worth giving this a try, particularly as I did not find this method in any of the many forum posts on this topic. For the purposes of this article, also assume that the firewall just works and is not filtering any relevant traffic (you should have already checked your firewall settings anyway).

For readers not familiar with EC2, by default linux machines are assigned two network interfaces - a loopback interface named lo which is assigned, and a second interface eth0 which is assigned a private IP address from Amazon's pool. Ordinarily, Amazon takes care of the routing that turns that private IP to the public IP used to communicate with the world. During the installation, my email server was setup to listen on, so that it can easily accept local connections from or connections from the world through eth0, which let's say is All of this is very basic stuff; there's no load balancing going on here and services arent divided among multiple servers.

I also setup amavis services to use the default TCP ports: 10024 for the amavisd-new client and 10025 for the smtp server that amavis-new uses to reroute emails once its done with them. Test connections using telnet to both ports worked fine immediately following installation:

# telnet localhost 10024
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 [::1] ESMTP amavisd-new service ready
EHLO localhost
221 2.0.0 [::1] amavisd-new closing transmission channel
Connection closed by foreign host.

# telnet localhost 10025
Trying ::1...
telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.
220 mailserver.domain.ext ESMTP Postfix
EHLO localhost
250-SIZE 30720000
250 DSN
221 2.0.0 Bye
Connection closed by foreign host.

Note how connections fail when attempting to establish a connection through the socket through 10025 - this is also the result of using a default amavisd configuration. Connecting to postfix itself through the socket presents no issues:

# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.domain.ext ESMTP Postfix

Anyway, talking through the socket isn't necessary to get things working, so I will save that for the next amavisd article.

So when I started looking around for a solution to this in the forums, there was a lot of hemming and hawing about settings that were completely irrelevant to the problem, and occasionally some mention of settings thought could have conceivably had something to do with my problem, but didn't in my case. Of the latter type that I encountered, I was fairly convinced that this had something to do with the @mynetworks setting in the primary amavisd-new configuration file amavisd.conf (this setting is for the most part the same as the mynetworks setting in Postfix's file, except it uses Perl syntax, like adding @ before lists). By default, @mynetworks looks like this:

@mynetworks = qw( [::1] [FE80::]/10 [FEC0::]/10

But that's a little bit wider than I needed. I tried a whole bunch of different combinations of things. I added the subnet from each one of my network interfaces and even my public IP just for the hell of it, but that did little to change things besides occasionally breaking my ability to connect to the amavis client or server entirely. Ultimately, I settled on this:

@mynetworks = qw( [::1] );

But that didn't fix anything. What isn't mentioned in any of the troubleshooting articles or install walkthroughs I saw was how to actually modify amavisd-new's ACL. After all, the error message I encountered very frankly says that inbound emails are failing as a result of the involved connection's failure to be found in amavisd's ACL:

Jan 13 18:17:34 hostname amavis[31578]: Net::Server: 2016/01/13-18:17:34 CONNECT TCP Peer: "[]:40209" Local: "[]:10024"
Jan 13 18:17:34 hostname amavis[31578]: loaded base policy bank
Jan 13 18:17:34 hostname amavis[31578]: lookup_ip_acl (inet_acl) arr.obj: key="", no match
Jan 13 18:17:34 hostname amavis[31578]: (!)DENIED ACCESS from IP, policy bank ''

So what this means is that Postfix is receiving an email from eth0, which is assigned IP Postfix than establishes a connection with amavisd from to the localhost entry. Some enterprising dunce decided that its possible to cheat the need to change the ACL by changing the interface that amavisd listens to. This can be accomplished by assigned a value like the following to amavisd.conf:

$inet_socket_bind =;

This does not work; at least it didn't on my system. It might work with some additional work, but additional work is stupid. Modifying the ACL is smart. You can modify the ACL by adding a line resembling the following one to amavisd.conf:

@inet_acl = qw( [::1] );

Note how with this ACL I only add IP addresses (or sockets) that I want to exempt. Amavisd defaults to exempting everybody; this isn't a blacklist. Also, you don't want @inet_acl to be identical to your @mynetworks setting. In my case, I do not include either or its entire subnet in @mynetworks because @mynetworks represents subnets that we always treat as local delivery. Remember - NATing is handled by AWS on my server, so even though my eth0 has a "local" IP address, it does not mean that emails handled by that IP will be local. Quite the opposite, in fact.

So that's it, after opening up the ACL amavisd routes email correctly (although I still have some more testing to do in order to confirm that Spam Assassin is actually functioning correctly).

Hope this helps - good luck!

Tuesday, July 28, 2015

Hotmail is bouncing bugtraq mailing list emails from Yahoo

What really irks me about this is that I deliberately use gigantic, stupid MTAs like gmail and live mail to deliberately avoid this sort of garbage (deliberately). Those familiar with administrating large volume email can appreciate that you can perfectly configure your mail server and end up bounding all over the place because almost everyone with a mail server is not an actual email administrator and has no clue what they are doing. Email, like high school, is ultimately all about popularity. Even the least competent of email server owners will eventually get tech support to make sure google and microsoft can deliver to and receive from their Zimbra abomination.

At least that's what I figured until I started getting bounces like the one below. It seems Microsoft has decided that Security Focus mailing lists are too dangerous. To step up the oddity of this policy, bounces only occur when the originating MTA is with Yahoo. I can receive email directly from I can receive email from when the originating mail server is a one-off IP address from Finland that is part of a DSL netblock. But Yahoo is a bridge too far. Stupid stupid stupid.

Return-Path: <>
Received: (qmail 22048 invoked from network); 15 Jul 2015 15:26:46 -0000
Received: from (HELO (
by with SMTP; 15 Jul 2015 15:26:46 -0000
Received: (qmail 27445 invoked by alias); 15 Jul 2015 15:26:31 -0000
Received: (qmail 21710 invoked from network); 15 Jul 2015 15:26:06 -0000
Received: from (
by with SMTP; 15 Jul 2015 15:26:06 -0000
Received: by (Postfix)
id E771981455; Wed, 15 Jul 2015 10:31:59 -0700 (PDT)
Date: Wed, 15 Jul 2015 10:31:59 -0700 (PDT)
From: (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: bugtraq-return-55766-(redacted)
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
Content-Transfer-Encoding: 8bit
Message-Id: <20150715173159 data-blogger-escaped-.e771981455="""">

This is a MIME-encapsulated message.

Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

This is the mail system at host

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<(redacted)="""">: host[] said: 550 5.7.0
(SNT004-MC2F10) Unfortunately, messages from ( on behalf of
( could not be delivered due to domain owner policy restrictions.
(in reply to end of DATA command)

Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns;
X-Postfix-Queue-ID: 5D865812F6
X-Postfix-Sender: rfc822; (redacted)
Arrival-Date: Wed, 15 Jul 2015 10:18:42 -0700 (PDT)

Final-Recipient: rfc822; (redacted)
Action: failed
Status: 5.7.0
Remote-MTA: dns;
Diagnostic-Code: smtp; 550 5.7.0 (SNT004-MC2F10) Unfortunately, messages from
( on behalf of ( could not be delivered due to
domain owner policy restrictions.

Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Received: from ( [])
by (Postfix) with QMQP
id 5D865812F6; Wed, 15 Jul 2015 10:18:42 -0700 (PDT)
Precedence: bulk
Delivered-To: mailing list (redacted)
Delivered-To: moderator for (redacted)
Received: (qmail 9417 invoked from network); 15 Jul 2015 10:14:32 -0000
Date: Wed, 15 Jul 2015 10:14:31 GMT
Message-Id: <201507151014 data-blogger-escaped-.t6faevnw013232="""">
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)
From: (redacted)
To: (redacted)
Subject: XSS vulnerability in OFBiz forms

Wednesday, July 15, 2015

Malware discovered in the Stratfor email file dump provided by Wikileaks is not limited to torrents - curated content on the Wikileaks website also infected

Several months ago I identified malicious software contained within a torrent available for download from Wikileaks. The torrent was the most recent and most complete copy of what Wikileaks titled the "Global Intelligence Files" - a large trove of emails and attachments from defense contractor Stratfor. The story as it is widely understood is that former Lulzsec member and hacktivist Jeremy Hammond was involved in the acquisition of these files from Stratfor and provided them to Wikileaks. Among the many files included in the leak I have identified 18 that have malicious software; most of those are embedded within PDF and DOC files. Some of the attacks I discovered are old, others are less old. Only two of the 18 files are blocked from downloading using Google Chrome's malware protection service, for example. In a second post, I decompile one of these two (older) files using PE Explorer and Hex-Rays IDA to demonstrate how the file corrupts the Microsoft Connection Manager while posing as an application called iPassConnect in order to faciliate infection with a Magistr worm variant.

Since that time I have made numerous attempts to contact Wikileaks so that they could inform their users that the torrent contained malicious software. After receiving no response, I began to publicize my findings by posting them on Hacker News/Ycombinator and similar sites like Slashdot and Reddit. My post on Hacker News quickly reached the front page and attracted the attention of the former leader of Lulzsec, Hector Monsegur (aka sabu), who confirmed the validity and importance of my findings in a series of public tweets.

In my original post, I speculated that:
"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)."
The publication of the Global Intelligence Files by Wikileaks began on February 27th, 2012. The entire email server spool was not dumped onto the internet at one time. The publication was curated, with only a small percentage of the emails being published initially. Over time, more emails were published. This progression can be easily viewed on the directory hosting the torrents for the Stratfor leaks:
wikileaks josh wieder stratfor torrent download index
The file name of each torrent contains the date of its publication. Meanwhile, the number to the far right, beginning with 1603, indicates the size of the torrent in bytes. While the relationship between the size of a torrent and the size of the files it contains is not a direct one in all cases, in this case it is a fairly direct relationship because we are dealing with large lists of small files. The last torrent, which I have identified as containing malware, has a size of 121071 bytes. The point here is that you can see that the number of files contained in the archive grows over time.

The torrent file that contains malware is the only file in the directory with a nomenclature that does not include a full date (it was also created using bzip instead of 7zip); the filename is simply gifiles-2014.tar.bz2.torrent. Initially, this meant I was not sure of the exact date that the torrent was released.

I knew that the relatively small number of curated content was available on the website. Today I was able to confirm that malicious files and their related attachments are also being hosted on, as individual uncompressed files. I have composed a list of these files, their URLs and basic file information on pastebin: (I have embedded the pastebin below as an iframe; if you don't trust iframes in your browser you can click through the prior link instead)

NOTE: Wikileaks has multiple URLs servicing multiple directory structures, all that eventually seem to point to the same place. So for example, and both point to the same content (and include the same malware attachment available for download).

While I am not alone in my concern over the circulation of an infected torrent of the nature I described in my first post, posting individual infected files directly to * domain and several subdomains in a curated manner is likely more dangerous - users are more likely to consider the following a link to content that has in some fashion been secured:

wikileaks josh wieder stratfor emails research

An expectation that a video posted on Fox News will not contain an embedded script is not a wild expectation. Similarly a New York Times article that includes a photo in an article is usually believed to not contain spyware. This is a basic expectation of service on every website, not just news outlets. Primary sources are important. User transparency is also important.

The attached file above, "18714_Research_and_R.xls", appears to be a normal Excel spreadsheet but in fact contains an embedded OLE. It is the exact size in bytes as the same attachment I discovered within the torrent that started this series of posts:

wikileaks josh wieder stratfor emails research

Of course there is no need to take my word for it. The file contains an embedded OLE and PE file - the hallmarks of malware designed to exploit vulnerabilities in the Microsoft Office Suit. Of note are the following:

An API-Hashing signature is stored at 0x3ad1
There are two decryption loops at 0x00003932 and 0x00003934
The embedded OLE signature is stored at 0x7a00
A XOR encrypted MZ/PE signature is stored at 0x5a00 and the encryption key is 0x97
A ROL encrypted OLE signature is stored at 0x7a00 and the encryption key is 0x08

OfficeMalScanner can duplicate these results. When I ran OfficeMalScanner against "18714_Research_and_R.xls" using the brute debug scan mode, the scan produced a malicious index of 62. Several antiviruses will detect this file. Depending on which you use, it might declare the file to use CVE-2009-3129 or CVE-2009-0557 (it probably relies on both exploits at different points). I have created bin files from memory dumps of the embedded OLE and PE (as I have for the roughly dozen similar malware payloads); I am happy to provide those to interested researchers. Here are the relevant signatures:

MD5 2746a014bdd9f7bf252262b82cf63e11
SHA1 cf525700b9e1027c4628fa9689bf68777291c60d
SHA256 4f9550c3f3abbfac4153b4467666e7a46e29ab974627ffd7feed7a711d55ffcd

As I mentioned earlier in this post, Google malware service in Chrome detects only three of the so far 18 infected attachments. The two that are detected are the two oldest malware by the date sent and are both compressed executables (one a .COM and the other two are .EXE) rather than embedded within documents. Here is what downloading one of these off of the Wikileaks website looks like as of now:

wikileaks josh wieder stratfor emails research

Both of the old nasty .EXE's appear to have been sent from, which as far as I can tell, was/is the email address of Meredith Friedman, the VP of Communications for Stratfor:

 Email-ID 3451016
 Date 2003-11-04 15:32:57
 Subject: FW: Re[2]: our private photos bkarngkr
 Email-ID 3491917
 Date 2004-01-27 01:03:10
 Subject: FW: HI

Would anyone care to bet me a dollar that in late 2003 her email password was "mfriedman", her birthday, "12345" or some combination thereof?

The source of the .COM file is as follows:

 Email-ID 3547802
 Date 2001-11-10 05:16:54
 To undisclosed-recipients:
 Subject: Plans, coordinates, and executes

Finally for today, please do not make the mistake of assuming that all of the exploits are from this time period and thus are of no important to modern computer users. I cannot make this clear enough: these two files are the *oldest* of the malicious files I have discovered.

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.

This is the link for my conversation with Hector Monsegur AKA sabu of Lulzsec on the Wikileaks / Strafor email malware. 

RAT Bastard

Earlier this week, several servers I maintain were targeted by automated attempts to upload a remote access trojan (RAT). The RAT is a simpl...