Hi guys. I notice a large increase in recent weeks of ISP directed
phishing - largely because of worms moving backward to using the user's
own domain for the spam, but not just in the from: address.
I believe this started out as a "let's feel this out" or "wow, that
worked, let's phish ISP's directly too". I now have several reports that point to this becoming a serious problem.
Old with a spark of new, but definitely a problem.
Anyone else dealing with this?
Gadi.
Due to the huge number of variants in the wild, our AV software can't keep up (probably nobody's can). Instead, we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
-Robert
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
Robert Boyle wrote:
Hi guys. I notice a large increase in recent weeks of ISP directed
phishing - largely because of worms moving backward to using the user's
own domain for the spam, but not just in the from: address.I believe this started out as a "let's feel this out" or "wow, that
worked, let's phish ISP's directly too". I now have several reports
that point to this becoming a serious problem.Old with a spark of new, but definitely a problem.
Anyone else dealing with this?
Due to the huge number of variants in the wild, our AV software can't
keep up (probably nobody's can). Instead, we enabled a global rule which
blocks any email from accounts such as billing, root, postmaster,
antivirus, abuse, security, etc. which don't originate from our
management IP space where our people work. As a result, we have stopped
these phishing scams for our users dead in their tracks.-Robert
We did as well, but we did not yet find a solution for legit bounces..
it naturally breaks that.
It's a temporary solution to what I see that is going to become very big.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Due to the huge number of variants in the wild, our AV software can't
keep up (probably nobody's can). Instead, we enabled a global rule which
blocks any email from accounts such as billing, root, postmaster,
antivirus, abuse, security, etc. which don't originate from our
management IP space where our people work. As a result, we have stopped
these phishing scams for our users dead in their tracks.-Robert
We did as well, but we did not yet find a solution for legit bounces..
it naturally breaks that.It's a temporary solution to what I see that is going to become very big.
The bigger issue is that users simply don't trust any kind of "official communication" anymore and I don't see anything other than pki that could actually restore that.
- -- - --------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Joel Jaeggli wrote:
<snip>
The bigger issue is that users simply don't trust any kind of "official
communication" anymore and I don't see anything other than pki that
could actually restore that.
PKI alone won't solve it, but we are not trying to "fix" phishing here
(good thought though!). I agree.
Thing is, user-trust or no user-trust, they click by the masses.
Gadi.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joel Jaeggli wrote:
<snip>
The bigger issue is that users simply don't trust any kind of "official
communication" anymore and I don't see anything other than pki that
could actually restore that.PKI alone won't solve it, but we are not trying to "fix" phishing here
(good thought though!). I agree.Thing is, user-trust or no user-trust, they click by the masses.
I agree, to elaborate:
For us, I see an increasing number of situations where our customers are begining to discard messages we send them about their account because the information we're imparting is hard to distinguish from all the other crap that we don't manage to filter.
Claude Shannon could be invoked here. What we have is a noisy communication channel. The phishers are counting on that because the end users are trying to filter all this crap, and the false postive rate of humans trying to distinguish signal from noise is non zero, so eventually people identify the noise as signal. When the noise level gets high enough the signal doesn't get through. There are two solutions really, increase the volume of signal that you send, (basically send more messages) in hopes that get through, apply forward error correction (something that gives the messages a higher likelyhood of being interpreted as signal. If the phishers can replicated the FEC method then the channel gets noisy again.
> Gadi.
- -- - --------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
One wonders how many people would click on a phish from the First
National Bank of Dancing Hamsters, just because....
We did as well, but we did not yet find a solution for legit bounces..
it naturally breaks that.
I've been thinking about what you said, but I can't imagine a scenario in which this would affect bounce delivery to or from our admin-type addresses. Incoming bounces would be from <> and to admin@domain.net. Outgoing bounces would be from <> and to whatever@domain.com. We only block mail sent with the from as one of our admin addresses when it was not sent from our management / customer service / noc address space. If there is a problem which this creates which I haven't thought of, please explain since I would like to eliminate the problem or be aware of it if elimination isn't an option.
It's a temporary solution to what I see that is going to become very big.
x% of people are stupid and will never cease to be stupid. Provided these users are easy enough to reach, they will continue to open naked pictures, free pirated software emailed to them, password protected zip files with really important executables, antivirus "cleaners", microsoft updates from bgates@microsoft.com, 'You gotta see this!' IM URL links from friends, etc. My goal is not to stop stupid people from infecting themselves, but to stop our users from thinking WE infected them by eliminating the one threat vector over which we have absolute control and hence responsibility in the eyes of our customers. "Why did you allow someone to send mail as support@tellurian.net to my account if it had a virus in it?"
-Robert
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
we enabled a global rule which blocks
any email from accounts such as billing, root, postmaster, antivirus,
abuse, security, etc. which don't originate from our management IP space
where our people work. As a result, we have stopped these phishing scams
for our users dead in their tracks.
You sound so sure about that... Am I missing something?
Yes. Any billing, root, postmaster, etc... messages that claim to be from his system have to be generated from their management IP space. You may be able to phish their customers by sending them bogus messages of this sort that claim to be from other sites or facilities, but you won't be able to phish his customers by sending them messages like this that claim to be from his system.
I applaud his move, and wish more groups did the same.
I recently got hit by a wave of phishing attempts from my own ISP. Unfortunately, the ISP in question refuses to interact with their customers via any method but the web, although they do send out their own notices by e-mail. Of course, none of those accounts will accept bounces or e-mail replies, which is why they're rightfully on the rfc-ignorant black list, among many others.
Fortunately for me, all the phishing attempts were pretty stupid, and failed because they relied too much on Windows-specific attacks, Windows-specific MUAs, etc....
We have stopped the phishing which looks like it is from us(tellurian.net/tellurian.com/garden.net). Not from "their" bank, paypal, ebay, credit card companies, etc. Our main concern was with messages which looked like they were from support@tellurian.net telling people there was a problem with their email and they have to run this file or a problem with their account payment from billing@tellurian.net and the details were in the attached file. To the novice user, it may look legitimate since we are their ISP and with that comes a certain amount of trust - despite the fact that we would never send files to our customers and tell them to run them. However, the spoofed messages from us have completely stopped now. The regular phishing scams continue, but SPF does help with this if the customers have turned it on for their account. Unfortunately, the customers smart enough to turn it on usually won't be suckered by phishing scams in the first place.
-Robert
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
It would have been better if he had just installed SPF, and published DNS
records for his own domain, and rejected them based on that. Then other
people receiving forged emails with his domain would also be able to just
drop those emails.
Paul
Of course we already do this! Dig before you speak. 
However, we do not filter our customer's email unless they turn on filtering. We tag everything including SPF failures and customers can turn on rejection based solely on SPF failures if they want, but that still doesn't help our users who haven't turned on filtering. Our "admin|root|support|etc" filter previously mentioned in this thread does. We do not have any ethical problem filtering those messages since they are impersonating us. We wouldn't presume that any other mail should be filtered unless a customer requested for us to do so.
-Robert
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
I disagree. Publishing SPF records of that nature would mean that any customers of his who may be roaming would be unable to send e-mail as themselves, and would create the known problems with forwarding. Since you're unlikely to be getting any phishing attempts claiming to come from j-random-user@hisdomains.example.com, the publishing of SPF records in this instance would not do anything measurable to stop spam coming from his systems nor would it have any visible impact on phishing attempts from his systems.
SPF is not a panacea.
In fact, it is pretty much totally worthless, unless you are the sole owner of a given domain and you can guarantee that all mail you ever send will always be routed through the machines that you own and control, and you know that you don't ever forward e-mail for any of your other accounts.
In that case, SPF can be useful to reduce the damage caused by joe-job attacks on you at your domain, but that's about it.
And i think you're doing yourself and the entire community a grave disservice by painting SPF as the FUSSP.
Actually, what you have to guarantee is that you never send email to
anyone who forwards their email elsewhere. This is impossible.
Tony.
> SPF is not a panacea.
>
> In fact, it is pretty much totally worthless, unless you are the sole
> owner of a given domain and you can guarantee that all mail you ever send will
> always be routed through the machines that you own and control, and you know
> that you don't ever forward e-mail for any of your other accounts.
See my other email in regards to this mobile user strawman argument.
Look in the archives for the same arguments against closing open relays.
Actually, what you have to guarantee is that you never send email to
anyone who forwards their email elsewhere. This is impossible.
This is incorrect.
SPF is an inbound filter.
This is in the recipients control, not yours.
Assume you send email to alice@alumni.miskatonic.edu and Alice forwards
that email address to alice@personaldomain.org.
If the inbound mail server for alumni.miskatonic.edu has SPF or MX+
enabled for alice@alumni.miskatonic.edu and and you pass the test and your
mail is accepted by alumni.miskatonic.edu then that is the end of your
responsibility.
If Alice then decides to forward to alice@personaldomain.org and Alice
wishes to use SPF or MX+ for the mailbox alice@personaldomain.org as well
then Alice would whitelist the IP of the outbound mail server for
alumni.miskatonic.edu.
You don't have control over what forwarding, filtering, or whitelisting
Alice does with her personal mailbox.
If Alice wants to forward alice@alumni.miskatonic.edu to
alice@personaldomain.org and use SPF or MX+ with alice@personaldomain.org
presumably she won't block email from her other account and she can check
if she got it right really easy by sending email to
alice@alumni.miskatonic.edu.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
Actually Alice doesnt have control over her ISP who believes that kool
aid about path authentication being a silver bullet and rejects
wholesale based on spf failures (sometimes treating ~all or ?all as
equivalent to -all)
-srs
See my other email in regards to this mobile user strawman argument.
Look in the archives for the same arguments against closing open relays.
Current mobile-user arguments against SPF do indeed remind of the anti open-relay battles 5-8 years ago. Not only that but often enough its
the same people who are doing this arguing ... (just look at the main
ietf mail list and you'll see what I mean).
If Alice wants to forward alice@alumni.miskatonic.edu to
alice@personaldomain.org and use SPF or MX+ with alice@personaldomain.org
presumably she won't block email from her other account and she can check
if she got it right really easy by sending email to
alice@alumni.miskatonic.edu.
Unfortunately per-user filters for SMTP transmission are notoriously difficult to implement (especially on large scale). Plus you may not
be able to say that email came in forwarded just from SMTP transmission (forwarders often do not leave its own marker, you can try to identify forwarder by EHLO name but that may not be forwarder by some kind of outbound relay server on the forwarding network site).
Another issue is that are doing the forwarding are the ones that
are most often least maintained as far as upgrading software and
enabling new SMTP features. As a result an idea that we will ask
all forwarders to change and identify themselves in forwarded mail
can not happen as quickly as path authentication proponents want.
Now I did propose one solution to this - a way to bypass forwarders
by having origin mail servers add crypto signatures with their own
hostname serving as base and then tie in further path authentication
to cryptographically verified hostname (see paper, I previously
posted, quick link at http://purl.org/NET/pacap), and I have more
hope in another system that I'll get to later this year.
[...]
Actually, what you have to guarantee is that you never send email to
anyone who forwards their email elsewhere. This is impossible.
How do you figure that?
The failure mode in this case is if somebody arranges "dumb" mail
forwarding that doesn't do envelope rewriting, and also applies a SPF
filter on their incoming mail. The problem is quite clearly of the
recipient's making rather than any fault of the sender's.
[...]
Actually Alice doesnt have control over her ISP who believes that kool
aid about path authentication being a silver bullet and rejects
wholesale based on spf failures (sometimes treating ~all or ?all as
equivalent to -all)
Sure Alice has control. Last week, I told my ISP where to stick their
shoddy service and took my business elsewhere.