Wandering Thoughts archives

2017-10-31

We've now seen malware in a tar archive

Our anti-spam system recently logged the following information about an incoming message:

1e92K6-0007yD-37 attachment application/octet-stream; MIME file ext: .tar; tar exts: .exe; email is in-dnsbl
rejected 1e92K6-0007yD-37 from 74.194.116.87/brand27@emediasol.com to <redacted>: identified virus: Mal/DrodTar-A

Sophos's information on Mal/DrodTar-A plus some Internet searches suggest that this .exe had attributes of a relatively generic Windows trojan. We also logged the message headers, and they make it clear that this wasn't a case of someone wrapping up a malware sample in a tar file in order to mail it to one of our people for research; it was an honest to goodness piece of Windows malware trying to propagate itself in a tar archive. Tell-tale headers include:

From: "Account Manager"<brand27@emediasol.com>
Subject: Purchase Order
To: undisclosed-recipients:;

(Our users do get emailed .tar and .tar.gz files, but they have actual contents and they're hopefully not showing up in email that looks like that.)

It turns out that this is not the first .exe-in-.tar attachment we've seen in the past several months; back in May and June we saw a few that were identified (at the time) as Mal/FareitVB-M. More recently we saw a couple that sadly weren't identified as malware, so they sailed right through the mail system (I suspect that they were malware; a single .exe file in a .tar is unusual, and most of our .tar attachments are actually .tar.gzs).

On further inspection we've also seen a number of other plain .tar attachments that seem to be malware, based on what they contain. In addition to .exes, we've logged single .scrs and .cmds, some of which have also been identified as Mal/FareitVB-M. Probably this means we should extend our rejection of bad things in ZIP archives to also cover bad things in tar archives.

(All this goes to show that things can be hiding under innocent looking rocks.)

I'm a little bit surprised that Windows malware distributes itself as tar archives, because I would have thought that not many Windows machines can actually extract them without having to go find additional software. However, I may be wrong about this; some searches suggest that common Windows archive handling programs (such as 7-zip) are sufficiently polymorphic that they'll also unpack tar archives for you. Perhaps the malware authors have discovered that malware packed up in tar archives gets through defenses slightly more readily than malware in ZIP archives.

(Sadly, this is certainly the case here, where we'd have immediately rejected these attachments if they'd been ZIP archives instead of tarballs.)

I guess I'm a little bit sad and disappointed that tar archives are now being exploited by malware, in a 'is nothing sacred?' kind of way.

(Where malware and spam in general is concerned, the answer has always been 'of course not'. But I still like to think of Unix things as existing in a separate world, one not contaminated by the grubby realities of the modern malware-in-email environment.)

MalwareInTarArchive written at 22:54:49; Add Comment

2017-10-23

I've now seen something doing SMTP probing of IPv6 addresses

One of the machines that I run my sinkhole SMTP server on has an IPv6 address. This address is present in DNS, but wasn't directly visible as the target of an MX record or anything else that would lead it to clearly being associated with email. To my surprise, yesterday a machine connected to my sinkhole SMTP server on this relatively obscure IPv6 address.

(This machine is the MX target of an old hostname that spammers and other people have latched on to, but the MX target didn't have an IPv6 address, just an IPv4 one.)

The source IPv6 is 2607:ff10:c5:509a::1 in cari.net, and an Internet search found an interesting report about it, which seems vaguely sloppy given how easy it usually is to change IPv6 addresses. The actual activity I saw appears to have been TLS probes; on its first two connections, it STARTTLS'd with different ciphers and then abandoned the connection after TLS had started. Different EHLOs were used too, first 'k7wyLkmlLdInG.com' and then 'openssl.client.net'.

(The first connection used ECDHE-RSA-AES256-GCM-SHA384, a TLS v1.2 cipher; the second used the much older ECDHE-RSA-AES256-SHA, originally from SSLv3.)

Looking at my logs, I've seen similar TLS probes with similar EHLOs (especially 'openssl.client.net') from a cari.net IPv4 address, 66.240.219.146. This has a PTR record of 'burger.census.shodan.io', although the IP address listed for that name doesn't match. If this is a Shodan source point, SMTP TLS scanning isn't particularly surprising in general (although it didn't work very well against my sinkhole SMTP server). It does surprise me that people are clearly trying IPv6 addresses for this, presumably by crawling DNS to find IPv6 addresses and then probing all ports on them just to see.

(Checking my logs, I see that my SSH daemon refused to talk to 2607:ff10:c5:509a::1 at around the same time, so this is probably port scanning and probing in general and may well be Shodan. Shodan once exploited NTP to find active IPv6 addresses, and may be back to this sort of tricks.)

Going back further in my SMTP logs, I see that 198.20.70.114 aka 'census3.shodan.io' also did this sort of probing. So perhaps Shodan has turned its unblinking eye on my corner of the network world in general, and the IPv6 probes are just a manifestation of this. Sadly that makes them less interesting and means that I've yet to actually encounter a spammer trying to use IPv6. Maybe someday.

IPv6SMTPProbing written at 01:40:19; Add Comment

2017-10-06

Spam issues need to be considered from the start

A number of Google's issues from the spammer I talked about yesterday come down to issues of product design, where Google's design decisions opened them up to being used by a spammer. I considered these issues mistakes, because they fundamentally enable spammers, but I suspect that Google would say that they are not, and any spam problems they cause should get cleaned up by Google's overall anti-spam and systems that watch for warning signs and take action. Well, we've already seen how that one works out, but there's a larger problem here; this is simply the wrong approach.

In a strong way, anti-spam considerations in product design are like (computer) security. We know that you don't get genuinely secure products by just building away as normal and then bringing in a security team to spray some magic security stuff over the product when it's almost done; this spray-coated security approach has been tried repeatedly and it fails pretty much every time. The way you get genuinely secure products is considering security from the very start of the product, when it is still being designed, and then continuing to pay attention to security (among other things) all through building the product, at every step along the way. See, for example, Microsoft's Security Development Lifecycle, which is typical of the modern approach to building secure software.

(That you need to take a holistic approach to security is not really surprising; you also need to take a holistic approach to things like performance. If no one cares about performance until the very end, you can easily wind up digging yourself into a deep performance hole that is very painful and time-consuming to get out of, if it's even feasible to do so.)

Similarly, you don't get products that can stand up to spammers by designing and building your products without thinking about spam, and then coming along at the end to spray-coat some scanning and monitoring magic on top and add an abuse@... address (or web form). If you want products that will not attract spammers like ants to honey, you need to be worrying about how your products could be abused right from the start of their design. By now the basics of this are not particularly difficult, because we have lots of painful experience with spammers (eg).

AntiSpamFromTheStart written at 01:27:17; Add Comment

2017-10-05

Google is objectively running a spammer mailing list service

If you are a mailing list service provider, there are a number of things that you need to do, things that fall under not so much best practices as self defense. My little list is:

  • You shouldn't allow random people you don't know and haven't carefully authenticated to set up mailing lists that you'll send out for them.
  • If you do let such people set up mailing lists, you should require that all email addresses added to them be explicitly confirmed with the usual two step 'do you really want to subscribe to this' process.
  • If you actually allow random people you don't know to add random email addresses to their mailing lists, you absolutely must keep a very close eye on the volume of rejections to such mailing lists. A significant rate of rejections is an extremely dangerous warning sign.

Google, of course, does none of these, perhaps because doing any of these would require more people or reduce 'user engagement', also known as the number of theoretical eyeballs that ads can be shown to. The result is predictable:

2017-10-04 08:19 H=mail-io0-f199.google.com [209.85.223.199] [...] F=<emails1+[...]@offpay.party> rejected [...]
2017-10-04 08:26 H=mail-ua0-f200.google.com [209.85.217.200] [...] F=<emails5+[...]@offpay.party> rejected [...]
2017-10-04 08:31 H=mail-vk0-f71.google.com [209.85.213.71] [...] F=<emails7+[...]@offpay.party> rejected [...]
2017-10-04 08:31 H=mail-pf0-f198.google.com [209.85.192.198] [...] F=<emails7+[...]@offpay.party> rejected [...]
2017-10-04 08:32 H=mail-qk0-f198.google.com [209.85.220.198] [...] F=<emails8+[...]@offpay.party> rejected [...]
2017-10-04 08:39 H=mail-qk0-f199.google.com [209.85.220.199] [...] F=<emails9+[...]@offpay.party> rejected [...]
2017-10-04 08:40 H=mail-it0-f70.google.com [209.85.214.70] [...] F=<emails9+[...]@offpay.party> rejected [...]
2017-10-04 08:40 H=mail-io0-f200.google.com [209.85.223.200] [...] F=<emails11+[...]@offpay.party> rejected [...]
2017-10-04 08:40 H=mail-io0-f197.google.com [209.85.223.197] [...] F=<emails11+[...]@offpay.party> rejected [...]
2017-10-04 08:41 H=mail-ua0-f197.google.com [209.85.217.197] [...] F=<emails11+[...]@offpay.party> rejected [...]
2017-10-04 11:57 H=mail-vk0-f69.google.com [209.85.213.69] [...] F=<emails15+[...]@offpay.party> rejected [...]
2017-10-04 12:06 H=mail-pg0-f71.google.com [74.125.83.71] [...] F=<emails16+[...]@offpay.party> rejected [...]
2017-10-04 12:09 H=mail-qt0-f200.google.com [209.85.216.200] [...] F=<emails18+[...]@offpay.party> rejected [...]

That's just from today; we have more from yesterday, October 2nd, and October 1st. They're a mixture of RCPT TO rejections (generally due to 'no such user') and post-DATA rejections from our commercial anti-spam system laughing very loudly at the idea of accepting the email. Many other copies made it through, not because they weren't seen as spam but because they were sent to users who hadn't opted into our SMTP time spam rejection.

Google has deliberately chosen to mix all of its outgoing email into one big collection of mail servers that third parties like us can't easily tell apart. For Google, this has the useful effect of forcing recipients to choke down much of Google's spam because of GMail, instead of letting people block it selectively. In this case, we have some trapped mail headers that suggest that this is something to do with Google Groups, which is of course something that we've seen before, with bonus failures. That was about six years ago and apparently Google still doesn't care.

(Individual people at Google may care, and they may be very passionate about caring, but clearly the corporate entity that is Google doesn't care. If it did care, this would not happen. At a minimum, there would be absolutely no way to add email addresses to any form of mailing list without positive confirmation from said addresses. Instead, well, it's been six years and this stuff is still happening.)

PS: My unhappy reactions yesterday on Twitter may have produced some results, which is better than nothing, but it should go without saying that that's not exactly a good solution to the general issue. Spammers are like ants; getting rid of one is simply dealing with the symptoms, not the problems.

GoogleSpammerMailingListProvider written at 00:31:56; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.