Re: [gnso-ff-pdp-may08] Choke points

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

George mentioned...

#So, to register a domain name, they need funds. Is it from a stolen
#credit card? 

Could be from a stolen credit card, but for domains which are needed
for longer than the comparatively brief detect-bad-CC-and-hold window, 
domains can also be anonymously registered using an untraceable online 
currencies. Googling for

   register domain name <name of your favorite anonymous online currency here>
 
should get you started. 

#They also need an identity (for mandatory WHOIS). Is that WHOIS completely 
#fake, or a stolen one, or a borrowed one of a legit registrant?

Whois may be concealed by a whois privacy service, or be completely bogus,
or stolen, etc., yes. Another interesting google search:

   bullet proof domain name registration

[BTW, whois has been ruled off topic by definition for this working group, 
although I believe that happened before you joined the group]

#Ok, so one choke point is to eliminate/attack the network of virus
#infected/hacked webservers. 

That's a pretty broad "choke point." One of my favorite graphics 
is from http://www.sans.org/top20/ entitled "4396 Total 
Vulnerabilities Reported in SANS @RISK Data from November 2006 - 
October 2007" showing a pie chart. 

Web application vulnerabilities are in blue, other vulnerabilities 
are in red. The pie chart isn't perfectly split down the middle, 
but it is probably just about as close as you might have gotten if 
you were resposible for cutting a real pie knowing that having 
been in charge of cutting, your friend would get to pick the half 
of the pie that would be theirs to enjoy. :-;

Combine that with things like a plethora of exploits (for example,
I think the XSS Cheat Sheet does an excellent job of cataloging
exploits in the XSS area for a variety of browsers, see
http://ha.ckers.org/xss.html ), and the reality that the malware
d00dz can repack and re-release faster than signature based A/V
vendors can re-analyze/build new signatures/distribute new signatures,
and I think malware will remain an ongoing threat for the dominant
operating system for the forseeable future. Classic quote to show
you just how bad things have gotten, malware-wise:

   "At the start of 2007, computer security firm F-Secure had about
   250,000 malware signatures in its database, the result of almost
   20 years of antivirus research. Now, near the end of 2007, the 
   company has about 500,000 malware signatures."'We added as many 
   detections this year as for the previous 20 years combined,' said 
   Patrik Runald, security response managerat F-Secure. 
   
   http://www.informationweek.com/news/mobility/showArticle.jhtml?art
   icleID=204701370 (URL broken over two lines due to its length)

#In the botnets, how many are on residential ISP blocks (that conceivably 
#block incoming port 80, like many do for outgoing/incoming SMTP blocking)?

Let's assume that the CBL is probably the best currently available 
listing of bot'd hosts, typically listing in excess of 5,000,000 dotted
quads at any given time. 

The CBL folks compare coverage of the CBL with coverage of the Spamhaus 
PBL ("Policy Block List") which lists hosts that should not be emitting 
email direct-to-MX. The PBL has two types of listings, ISP provided
listings and non-ISP provided listings. 

In the most recent data available at http://cbl.abuseat.org/country.html
we can see that of 5,042,860 CBL listings, 946,570 of them (18.77%) are 
also on the PBL ISP-supplied list. 3,600,642 of them (71.40%) are on
the PBL non-ISP-supplied list, and by subtraction that leaves 495,648 of 
'em that are on neither (assuming their's no overlap between the ISP
supplied and the non-ISP supplied lists).

So, bottom line, it looks like ~10% of the botted hosts are NOT on 
PBL-listed space. 

But keep in mind that many ISPs do NOT block http servers hosted in
user space, so the point may be somewhat moot. 

#Can the webserver software (IIS, Apache) be adjusted or put into a
#safe mode so that if example.com's server is hacked and has malware at
#http://www.example.com/user/hidden/malware/gotcha.html it won't serve
#up that content to a different domain, i.e. www.fakebank.com ? (i.e.
#creating fewer vulnerable hosts that an attacker can find that are
#usable)

I don't think that's possible. As long as people accept something other
than plain text (e.g., such as HTML), dangerous constructs will make
it possible to deliver unwanted content (see the XSS example mentioned
above). 

#Ok, say I give you my bank account number and password for
#realbank.com, but that realbank.com is protected by a 2nd factor, e.g.
#a password sent by SMS to my cell phone, 

Some folks have tried this approach. At least one successful attack has
been demonstrated as being able to overcome it:

"South African fraudsters hack account through SIM card"
http://www.punchng.com/Articl.aspx?theartic=Art200801033461637

#or to by that PayPal security key ($5). 

Hardware crypto tokens are nice, but are not a perfect solution for a 
few reasons. See, for example:

"The Failure of Two-Factor Authentication"
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html

or think about scaling issues (if we can't figure out a way to 
federate trust for two factor auth, you'll need a token for each
account that needs protection, and once you have one for your email,
and your bank, and your broker, and your workplace, and eBay, and 
<fill in the blank here>, you'll need a bandolier to carry all those 
fobs without your pants falling down. 

#More basic still, how are you logging in to my account? Are you
#logging in via a Russian IP address? Or using one of the botnet PCs?
#Or, through my own computer that you've taken over?

Most of the bad guys seem to overcome geographic restrictions through
use of compromised machines in the US, combined with US based
reshipping operations. 

#More detail here please. You have my bank account, and you're somehow
#in to my account. How do you get the money from you to me? 

Money is normally extracted from compromised accounts by "cashiers,"
who perform that service in exchange for a flat fee, or more typically
a share of the funds extracted. See for example the discussion ion
"An Inquiry Into the Nature and Causes of the Wealth of Internet
Miscreants," http://www.icir.org/vern/papers/miscreant-wealth.ccs07.pdf
at page two, right hand column near the bottom. 

#What can
#the bank do to thwart that completely? (i.e. maybe this is the choke
#point that is most effective, and we're wasting everyone's time trying
#to implement a more complex system, a more expensive system, on a
#different choke point).

You may want to review the excellent "U.S. Money Laundering Threat
Assessment," http://www.treas.gov/offices/enforcement/pdf/mlta.pdf

Like malware, covert or illegal financial transactions may be any
awfully broad gap to try to seal. 

#Who loses the money here, the bank, or me? (i.e. if the responsibility
#shifts to the bank, they might take security more seriously, or would
#help cover the costs of internet improvements/safety, see below)

Varies by country. Shift the burden to customers, and they may stay 
away from online financial activities, and that may impose a cost
larger than the bank's cost of absorbing the losses directly.

#Ok, when do they send out the spam, in relation to the domain
#creation/registration date above? Immediately? What happens if that is
#delayed for a week?

Folks have noticed that spammers like to promptly exploit newly
registered domains in the hope that by doing so, anti-spammers won't
yet have listed the new domains on things like the SURBL or URIBL. 
Their ability to do so, however, is impacted by the existence of
things like the "Day Old Bread" list, which lists domains registered
within the last five days (see http://www.support-intelligence.com/dob/ ).
DOB tests are incorporated in anti-spam products as popular as 
SpamAssassin (see http://spamassassin.apache.org/tests_3_2_x.html )

#The spam "pretends" -- does this mean they are using a "from" of
#realbank.com, which can be thwarted my most people through Domain Keys
#email or Sender ID/SPF? 

DK/DKIM and Sender ID/SPF are sometimes challenged by things like "look 
alike" domains which can be hard to casually spot; in that regard,
DK/DKIM and Sender ID/SPF really only protect the *true* domains that
have DK/DKIM or Sender ID/SPF coverage.

#Are only companies opting not to use these email authentication methods 
#vulnerable? 

No, as mentioned just a second ago, even companies that do use these
approaches can still run into issues with traffic from "look alike" domains.

#Are email users opting not to have up to date email clients vulnerable, 
#but those using latest versions are safe?

DK/DKIM and Sender ID/SPF are typically implemented at the MTA level
(e.g., on the mail server, or perhaps in an appliance conceptually
sitting in front of the mail server), not on the MUA (e.g., not client 
side). Thus you can be running a positively rancid version of some
no-longer supported mail client, or the latest and greatest version of
Thunderbird, say, and it won't matter for the most part when it comes
to email authentication technologies. (And that's good -- if you need
to fight the battle on the desktop, you scale poorly and will inevitably
lose)

#How does one convert that link to a visitor? i.e. educating people not
#to click links can thwart this attack vector? 

There are vulnerabilities that do not require any active clicking to
take place. :-(

#Does having the email
#client actually remove the link (by filtering the HTML/mesage source)
#thwart the attack? 

Sanitizing potentially dangerous email constructs with something like
Procmail Email Sanitizer (see 
http://www.impsec.org/email-tools/procmail-security.html ) can be 
very helpful, but note that by the time you're doing so, many HTML
formatted messages are NOT going to look very pretty.

Using a text-based email client will also significantly improve one's
risk profile, but most folks require the ability to accept spreadsheets
or other attachments from co-workers, PDF-formatted documents, pictures
from friends and relatives, etc.

#(i.e. compel people to type in the link in an
#email, thereby also compelling banks, etc. either not to send links,
#but to send "friendly" links that people can type in, e.g.
#http://www.realbank.com/ or http://www.realbank.com/1234 instead of a
#50 character URL.

Back to www.rea1bank.com and kin (note the 1)

More people than you might think will cut and paste and NOT notice the
substituted numeral for letter

#Going a step further, once I've clicked that link, why does the link
#even resolve? If my ISP won't resolve that link, or if my browser
#won't resolve that link, does that thwart the attack? 

Folks have also tried that approach. Notably, see http://www.opendns.org/

That falls apart, however, if the bad guys hijack the user's DNS server
settings on the user's PC, as discussed in "Port 53 Wars: Security of
the Domain Name System and Thinking About DNSSEC,"
http://www.uoregon.edu/~joe/port53wars/port53wars.pdf

#In other words,
#is the problem solved by having the ISP choose not to resolve things
#(i.e. a "clean" ISP that automatically filters out phishing domains,
#or a clean set of nameservers like OpenDNS that actively filters out
#phishing domains, or modern browsers that warn/filter out phishing
#domains?)?

No, for the reason just mentioned... you can't trust user DNS not to 
have been hijacked. 

Oh yes, and before anyone asks, blocking or redirecting all customer
port 53 traffic to the ISP's own name servers (only) is not something
that I'd recommend for reasons I discuss in the Port 53 Wars talk. 

#Back up a little, and assume I'm dumb/crazy. Why report it to the
#registrars at all? If the system is 100% accurate, I should never see
#the email to begin with, it ends up in my junk mail folder, or is
#rejected by my incoming mail server before it even gets to me, or is
#filtered by other opt-in non-centralized systems, besides the
#registrar/registry?

While some users enjoy extremely accurate spam filtering, others make
do with a somewhat leakier umbrella, shall we say, and there's the
constant tension between false positives and false negatives.

#If the only people that are actually making reports to the
#registrar/registry are automated bots, because they "perfectly detect
#the spam and have eliminated the potential to be victimized, then
#aren't these reports low priority? (i.e. if a phishing site gets 1000
#visits from automated scanning tools, but 0 visits from real people,
#then we've "won" already, right?)

While fastflux enables spam, and leverages spam (and vice versa), 
fastflux is not exclusively a spam (or exclusively a spam and phishing)
issue. For example, fastflux enables malware distribution (and we've
already conceded that signature based malware detection is an imperfect
art at best), child exploitation, and other criminal activity, and as
such will still need to be addressed. 

#> get thousand of complains from many reporting operation. The real choke
#> point is taking down the fakebank.com domain. Once that is done then the
#
#See above (and below). That's not the only choke point.

Actually, it pretty much is. Hate to say, and sure have looked at a lot
of other options (as my commentary above may illustrate), but for fastflux,
you really DO need registrar/registry cooperation.

#Why does it work? The attacker then creates 10,000 new domains, and
#the process starts all over again. 

Processes which scale well are highly desirable. :-)

#In other words, when one's only tool is a hammer, you start to think
#that every problem is a nail (i.e. taking down the domain quickly
#being the hammer).

The anti-spam community has a large workshop full of tools, but sometimes
you either have the right tool (making even a tricky job a snap), or you
can spend a LONG time trying to work around the tool you need but don't
have. This is a case where the desperately needed tool is under the
glass at the registrars.

#> So - if the registrar of the domain in question is getting thousands of
#> complains from many reporters about fakebank.com and fakebank.com is fluxing
#> and it's still in the tasting period it could be shut down through
#> automation within minutes of the fraud starting. If such a system were in
#> place then Fast Flux would stop working for fraud than the criminals would
#> abandon it's use and the problem would be solved.
#
#Ok, suppose you have such a great system, 

The great system he's talking about implies the ability to get prompt 
action from registrars to take down these domains.

#why isn't every ISP using it instead, or why isn't every user opting 
#into it. 

One cannot use what doesn't exist (as an ISP); user's don't have the
knowledge and technical ability to do so.

#Or if the system is "perfect", why aren't those who are making reports 
#willing to provide a huge bond against liability should they take down 
#a legitimate site by mistake?

For the same reason that "Good Samaritan" laws are needed in most states
to shelter public spirited individuals against malicious lawsuits or 
unforseeable misadventures in non-cyber situations.

#Remember, even Yahoo/McAfee classified Google as a malware site:
#
# http://www.techcrunch.com/2008/05/11/google-is-a-malware-site-says-yahoo/
#
#and that was only three months ago. Even the US government shut down
#the California government's domain (ca.gov).
#
#http://www.networkworld.com/community/node/20192
#
#less than a year ago.

I would always assume that automated classification systems may occaisionally
make mistakes. That's one reason I have consistently suggested the 
desirability of having human review of proposed decision making, and 
other checks and balances (this discussion took place before you joined;
for backstory, see the archives at forum.icann.org/lists/gnso-ff-pdp-may08/ )

#Some folks threw out stats of $500 billion in annual losses to this
#list (which I've not seen backed up yet). 

See the archives for details.

#Other sources say less:
#
# http://www.ic3.gov/media/2008/080403.aspx
# http://www.ic3.gov/media/annualreport/2007-IC3Report.pdf
#
#$240 million in reported losses. Even allowing for unreported crimes,
#that's a lot less than $500 billion.

Only a fraction of all losses are reported. The IC3 report, in particular,
substantially over-represents auction related fraud for reasons they
acknowledge and discuss, e.g., see page 40 of "A Succinct Cyber Crime Tour 
Meant To Illustrate By Way of Assorted Examples The Sort of Online Crimes
Which Are Occurring -- And Why We Need More Cyber Crime-Trained Attorneys,"
http://www.uoregon.edu/~joe/tour/cybercrime.pdf

#Suppose we actually had $500 billion in losses, then we'd have
#essentially unlimited resources to fight back with (i.e. we save the
#banking system $50 billion/yr, and they'd gladly pay up $1 billion to
#do XYZ), and no solution should be ruled out.

The vast majority of the hundreds of billions in losses are associated
with losses of intellectual property, including things as diverse as
running shoes, prescription drugs, luxury goods such as watches and 
designer handbags, copyrighted music and movies, pirated software, etc.

#Hopefully we can come up with more choke points, before we start
#picking the registry/registrars as "THE" solution (there might not
#even be a solution, to play Devil's Advocate; is there a possibility
#we are already at the best solution today?), 

I truly don't believe that there are other alternatives. Trust me, if
there was any other avenue left unexplored when it comes to dealing
with fastflux, if folks could take it, they would.

Because there isn't, that's why some registrars get hammered with court
orders currently -- but THAT's an unweildy and expensive process if
there ever was one. 

#and IF they *are* the
#solution, how to effectively pick out the malefactors from the
#responsible registrants.

The fastflux domains really jump out at you once you start to look
at them, truly, and if you're worried about false positives, things
like bogus/incomplete whois data along with criminal activity on the
domain itself reduces inhibition to action quite rapidly.

Anyhow, if you haven't had a chance to look at the Mannheim paper
( http://pi1.informatik.uni-mannheim.de/filepool/research/publica
tions/fast-flux-ndss08.pdf (URL wrapped due to length)), I'd encourage
you to do so.

Regards,

Joe

Disclaimer: all opinions strictly my own.