Showing posts with label spam. Show all posts
Showing posts with label spam. Show all posts

Monday, March 20, 2017

Chop That Dollar

Its been quite some time since I've received a 419 spam message in my inbox. But - like matter itself - 419 never dies - only changes form. I found the message below in my inbox this morning.

I was pleased to note that the message originated from Yahoo, and contained several classic red flags for spam that even the neophyte mail server admin knows to watch out for, like from & reply-to headers with different different domains. This is the kind of l33t security I've come to expect from Yahoo. But hey, the Russians did it, and no one can be expected to secure their customers from state sponsored attacks. Susan here is no doubt a member of Nigeria's elite NIA.


From: Susan ***** desmondwilliams614 yahoo.com
Subject: Hello,
Date: Sat, 18 Mar 2017 12:12:52 +0000 (UTC)
Reply-To: desmondwilliams614 yahoo.com Susan ***** deswill0119 yahoo.fr

Hello,

Greetings. With warm heart I offer my friendship and greetings, and I hope that this mail will meets you in good time.

However strange or surprising this contact might seem to you as we have not meet personally or had any dealings in the past. I humbly ask that you take due consideration of its importance and immense benefit.

My name is Susan Williams from Republic of Sierra-Leone. I have something very important that i would like to confide in you please,I have a reasonable amount of money which i inherited from my late father (Nine Million Five Hundred thousand United States Dollar}.US$9.500.000.00.which I want to invest in your country with you and again in a very profitable venture.

Currently I am residing in Ivory coast now with my Brother Desmond Williams where my late father deposited the money, so i will like you to reply me immediatly so that i will give you more details about everything.

Iam expecting your reply for more explanation. Please i am urgently waiting for your response and I am conceding 15% of this money to you for your efforts assistance.

I will wait to hear from you.

Thanks and God bless you.

Our sincere regards to you,

Susan and Desmond Williams


The NIA's battle cry:

Wednesday, January 13, 2016

Email server using amavisd-new fails with (!)DENIED ACCESS from IP 1.2.3.4, 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: "[192.168.1.1]:40209" Local: "[127.0.0.1]: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="192.168.1.1", no match
Jan 13 18:17:34 hostname amavis[31578]: (!)DENIED ACCESS from IP 192.168.1.1, 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 127.0.0.0/8, 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 0.0.0.0, so that it can easily accept local connections from 127.0.0.1 or connections from the world through eth0, which let's say is 192.168.1.1. 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
250-[::1]
250-VRFY
250-PIPELINING
250-SIZE
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SMTPUTF8
250-DSN
250 XFORWARD NAME ADDR PORT PROTO HELO IDENT SOURCE
QUIT
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
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.domain.ext ESMTP Postfix
EHLO localhost
250-mailserver.domain.ext
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN
250-AUTH=PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
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 main.cf file, except it uses Perl syntax, like adding @ before lists). By default, @mynetworks looks like this:

@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
                  10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 );

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( 127.0.0.0/8 [::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: "[192.168.1.1]:40209" Local: "[127.0.0.1]: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="192.168.1.1", no match
Jan 13 18:17:34 hostname amavis[31578]: (!)DENIED ACCESS from IP 192.168.1.1, policy bank ''

So what this means is that Postfix is receiving an email from eth0, which is assigned IP 192.168.1.1. Postfix than establishes a connection with amavisd from 192.168.1.1 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 = 192.168.1.1;

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( 192.168.1.1 127.0.0.1 [::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 192.168.1.1 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, September 1, 2015

Nasty little Dropbox phishing spam

This morning I received an interesting message from someone I haven't heard from in a while through email. The subject line was "FIND PDF COPY" (in all caps). Inside the body of the message, embedded within the normal garbage footer attached by their email client, was this:

Joshua Wieder dropbox spam phishing embedded image

I may very well have gotten suckered into this one if it weren't for the all caps subject line. The person who ostensibly sent me this message is, somewhat ironically, the type of person to include all caps text in their email - but there was something a little too weird about the grammatical solipsism intrinsic to the phrase "FIND PDF COPY" even for this supposed sender.

So I took the two seconds out of my day to hover my mouse over the link and, what would you know, dropbox was not the target at all. The link forwarded to "goto-saketen.com" instead.

Just to be sure I took a look at the headers of the message. This did in fact come from the sender it claimed to, although I'm quite certain he had no idea his computer is sending these messages. I was a bit relieved; this sender is one of my contacts, so at least I knew that *his* email account was screwed, and not mine (by for example someone enumerating my contacts and sending messages to me with forged From: fields). And it does look like its just the guy's email account; the headers originated from Yahoo's email servers.

Whoever at Yahoo decided to add a custom header called the Newman ID deserves a raise btw. Newman, of course, was the mailman on Seinfeld. Get it?

Joshua Wieder - Newman
Neeeeeewwwman. ID.
Anyway, I won't drag this out very long because there's not much interesting here. Its just phishing, no malware. Plain, silly phishing. You get to a sign-on page that will never allow you to login:

function validation(){

        if(!document.docContainer.username.value.match(/^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,4}$/) || document.docContainer.password.value.lengt
h < 4){ $('#usernameError').fadeIn(50); $('#passwordError').fadeIn(50); return false;}



        if(!document.docContainer.username.value.match(/^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,4}$/)){ $('#usernameError').fadeIn(50);  return fal
se;}



        if(document.docContainer.password.value.length < 4){ $('#passwordError').fadeIn(50);  return false;}


        return true;

}


"goto-saketen.com" is, as you might have guessed, a website that sells sake (you can check out some of their booze on their Twitter account). I suspect they are just patsies. Their domain is registered from an hosted in Japan, and their website is entirely in Japanese, which sounds like NBD except snowshoe spam domains almost never meet the basic requirement of being where they say they should be.

Keep an eye out for Dropbox notifications over the next few weeks so you don't get burned.

Wednesday, January 30, 2013

DocuSign Spam

Spam has been going out appearing as sourced from DocuSign. Examples are included below. According to DocuSign, this issue has been ongoing since at least as early as January 3rd.

Recent activity has accelarted in the last week, with new evidence and examples coming to light. Stay safe out there.




Wednesday, December 12, 2012

Phishing Alert - NACHA Spam with BONUS: How to Read Headers to Identify the Source of Fraudulent Email

A few million of the emails below are making the rounds. The phishing emails attempt to be from NACHA, an ACH trade organization, and tell readers that a recent direct deposit was declined and to just DOWNLOAD THIS SOFTWARE to CLAIM YOUR FREE CASH NOW!!!11!


NACHA itself is aware of the tomfoolery:


The From: and Reply To: headers are both forged in this email. Because of this, I suspect that jamnaytac.com, who is included in the Reply To: but now the From: is going to be receiving some grief / spam complaints that have nothing to do with them.

So who is responsible for this? Below I have included the email headers for this spam message. This one is mildly interesting because it makes some shallow attempts at being deceptive to a lazy reader. When reading headers, what we are interested in mostly are the Received: lines. Almost every other item (mouth breathers: note the almost) can be forged. Received: lines can be forged to, but only by adding lines that should not be there. Received: lines that should be there cannot be removed. When reading these lines from top to bottom, we are retracing the steps that the email took to reach us. The first lines are for the recipient - the last email server in the chain is the email server that received the email. In this case, the email was received by my gmail account (I've replaced my email address with a phony one - the other email addresses I have not modified because they were fake to begin with). 

Delivered-To: 1coolguy@yomamahouse.com****NOTAREALADDRESS****DERP
Received: by 10.194.0.225 with SMTP id 1csp142932wjh;
        Tue, 11 Dec 2012 13:31:16 -0800 (PST)
Received: by 10.69.16.100 with SMTP id fv4mr52027767pbd.135.1355261475662;
        Tue, 11 Dec 2012 13:31:15 -0800 (PST)
Return-Path: <vegetatesgh0@planetsegur.com>
Received: from dalerojo.ning.com ([83.70.178.81])
        by mx.google.com with ESMTP id yl9si26859320pbc.272.2012.12.11.13.31.14;
        Tue, 11 Dec 2012 13:31:15 -0800 (PST)
Received-SPF: neutral (google.com: 83.70.178.81 is neither permitted nor denied by best guess record for domain of vegetatesgh0@planetsegur.com) client-ip=83.70.178.81;
Authentication-Results: mx.google.com; spf=neutral (google.com: 83.70.178.81 is neither permitted nor denied by best guess record for domain of vegetatesgh0@planetsegur.com) smtp.mail=vegetatesgh0@planetsegur.com
Received: from rbdrhasvgdrhjataahsc (192.168.1.8) by rbdrhasvgdrhjataahsc.barronheating.com (83.70.178.81) with Microsoft SMTP Server id 8.0.685.24; Tue, 11 Dec 2012 14:32:23 +0000
Message-ID: <50C7837A.901050@planetsegur.com>
Date: Tue, 11 Dec 2012 14:32:23 +0000
From: "noreply@direct.nacha.org" <limbereds64@jamnaytac.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100328 Thunderbird/2.0.0.24
MIME-Version: 1.0
To: <1coolguy@yomamahouse.com****NOTAREALADDRESS****DERP>
Subject: Direct Deposit payment was declined
Content-Type: multipart/alternative;
 boundary="------------05090300301030906090103"

We want to typically ignore the hostnames in these lines as irrelevant. These hostnames are provided by the email server and can be anything the administrator wants them to be. In cases where the originating sender is a computer and not an email server (AKA a Mail Transfer Agent or MTA), in other words when someone uses Outlook on their desktop computer and not webmail, you'll often see a Windows machine name there that is not a Fully Qualified Domain Name (FQDN). So again, the IP is what is important, the hostnames aren't.
I stress the hostnames in this case because they are deliberately deceptive in this case. The spammer has used hostnames for other legitimate mail servers as the hostnames on their mail servers to make it look to the casual reader as though someone else was responsible. Hostnames included below like "rbdrhasvgdrhjataahsc.barronheating.com" - barronheating.com is a regular business, and one that appears to have been harassed as the result of this. Their mail server is 173.10.124.129, which has nothing to do with the 83.70.178.81 that rbdrhasvgdrhjataahsc.barronheating.com was assigned. rbdrhasvgdrhjataahsc.barronheating.com is not even an A record / forward DNS entry, and 83.70.178.81 contains no reverse. A quick bit of help from ARIN, and it appears that 83.70.178.81 is registered to a Internet Service Provider in Cork, Ireland named Eircom Limited. Most likely this message was sent after some poor sap in Ireland click on the spam, downloaded a nasty bit of business that turned their crappy PC into a tiny mail server, and there you go.
Other hostnames involved that have nothing to do with this are planetsegur.com and ning.com. Why would a spammer involve innocent third party mailers like this? Largely, to be obnoxious. When blacklists filter email for legitimate email servers, it wastes everyone's time and decreases faith in those services (there are good reasons to ignore a large number of modern RBL services, but that's a post for another day).
So what is to be done? Unfortunately, not much. 83.70.178.81 is a broadband IP address, meaning it is almost certainly assigned as part of a dynamic range of IPs - IPs that are not assigned to a specific user or organization, and whose assignment changes regularly using something like DHCP for example. Any email administrator worth even part of their paycheck would have sent this to the Junk Email box or rejected it before even touching the mailbox. Worthwhile RBLs like Spamhaus publish lists of dynamically assigned IPs to be filtered be email administrators - Spamhaus publishes these numbers as part of their PBL [Full disclosure: I provided data center support for and was at one time a coworker of the creator of NJABL. NJABL has since been acquired and merged with Spamhaus.] Recipient email administrators should filter dynamically assigned IPs, because email servers hosted on commercial internet connections are almost exclusively regular computers that have been compromised. Even those who opt not to host in a data center (pttthhhbbbtttt) can at least scrape together a few dollars for a dedicated IP address and associated reverse DNS / PTR entry. Email readers should stop downloading software from emails that promise them FREE MONEY!!1!1! Email has been around for 40 years now. My 90 year old grandmother has email. There's no longer any reason to be a dupe. 
Finally, and most importantly, Internet Police, Email Vigilantes and Armchair Warriors need to take a deep breath and stop what they are doing. Just - stop. Please. After a number of years working at this email business, I feel comfortable saying that we have begun to reach a critical mass where the Internet Police are a larger waste of time and money than the spammers are. Why? Internet Police are the ones who make bizarre phone calls and send threatening emails over spam. They blacklist hosting companies and data centers, preventing normal email communication for tens of thousands of people, after identifying one or two spam emails. They force companies who *do not send spam* to release statements like this one. If this is you - please know that you are the problem for those of us whose job it is to make email work for people. If that is not your goal in fighting spam, what is your goal?
Remember - all data is posted on this website with the hopes that sharing data and an increased understanding of the internet and how it works will result in a better, safer internet for all of us. Thanks for reading!

Saturday, November 17, 2012

Weekly Links

Isn't it strange that the most successful sites aren't ones that produce content, but rather are gate keepers to the content of others? The phenomenon of network traffic is strangely circular - go to a website, click a link, from that site find a link, click it to find more links to click.

I know you're not hear to read. You are here to CLICK. Well, never let it be said that I don't give my public what it wants. I'll try to make this minor aggregation a weekly event.

Network World - Are the Spam Police Worse Than the Spammers? ("Spoiler Alert" - More so Every Day)
Fierce Telecom - CenturyLink Goes 100G, Puts On Big Boy Pants
Reason Magazine - Manipulating the Media For Fun and Profit

Finally, CEI has brought to magnificent life Leonard Read’s 1958 essay "I, Pencil" - the concise work of genius that lead me to the study of economics - in the form of a beautiful short film. At a time when so many of us find it so difficult to appreciate the power of spontaneous order and creative destruction (because each of us has a grand plan that, if enacted by principled leaders, would solve everything), spare 6 minutes for this. With an open mind Read's ideas just might change your life.

Friday, September 28, 2012

Windows 8 Rootkit Discovered in the Wild

That Was Quick

Italian security consultants ITSEC discovered the security hole following an analysis of the Unified Extensible Firmware Interface (UEFI), a successor to the legacy BIOS firmware interface, that Microsoft began fully supporting with 64-bit versions of Windows 7.

Tip of the Hat to The Register, linked above. 


[EDIT: The article specifies the payload as a "bootkit". This was deliberately omitted on my part. The word "bootkit" strikes me as part of that trend to modify prefixes of words to make them ludicrously specific, like how Watergate became EverythingUnderTheSun-Gate. Its a cheap way to feign familiarity through reference. Is there a relevant disharmony between the terms bootloader and rootkit I'm ignoring? If so feel free to shine light on my ignorance via email or in the comments.]

Since we are on the topic of hardware hacking, last week I caught a printer spamming - as in, a printer that was network available that had been compromised by malware and became part of a snowshoe spam run. While I'm sure this is nothing new, I just haven't seen too much of it - the idea of a botnet composed entirely of printers terrifies me every time I think about it. Peripherals are awful.