Insecurity #2 (comic strip)

Insecurity, second strip of this new comics.

Insecurity #2

Click on the image for full size.

Mitigating botnet C&Cs has become useless

Here is a recent email message I sent to the botnets mailing list and nanog:

The few hundred *new* IRC-based C&Cs a month (and change), have been
around and static (somewhat) for a while now. At a steady rate of change which
maintains the status quo, plus a bit of new blood.

In this post I ask the community about what you see, against what we have
observed, and try and test my conclusions and numbers against your
findings.

The subject line “why mitigating botnet C&Cs has become useless” is
misleading. It has been useless for a long time, but someone
had to hold back the tide, which several online mitigation communities
have been doing.

Today it has become (close to) completely useless. I will present the case
on why that is in my opinion, in a few bullets, and we can discuss what
alternatives we have, or if perhaps I am misreading what’s going on.

*. When a botnet C&C is mitigated, it is immediately re-created on
another host on the same ISP or another.
*. Most botnet C&Cs are a part of a larger group, such as an IRC network
or another, possibly hidden “behind the scenes” network. lusers are being
redirected on the spot or reconnect to another host.
*. Most botnet C&Cs are a compartmentalized group out of the whole,
possibly a sub-group several tiers down. Much like a terrorism cell.
*. If the above measures and features fail, most botnets have a secondary
control channel with which an immense host can be re-directed. This has
been seen back a few years ago.
*. Many botnet C&Cs now use fast-flux technology, moving IP addresses
quite often.
*. When the C&C is taken down, the bot may not jump to a new host, a new
one may simply be installed.
*. Coordinated take-down of entire networks is extremely difficult, relies
on incomplete intelligence and only takes care of the problem for an
extremely short period of time until re-assembly.

The name of the game is the SPBC: Simple Primitive Botnet Control (C&C).

Simple - as it is simple, vs. a complex dynamic control channel.
Primitive - old and quite unimpressive.
Botnet - d’oh
C&C - Command and Control

It’s simple, we can see most of them with our tools. Primitive, hey, they
have been using these for a long long time. It works.

As what we mainly did is concentrate on taking the C&C down, as well as
academically study how to detect or quantify it, what we achieved was
teaching the Bad Guys their business. That is yesterday’s news.

They are an oiled machine. We don’t hurt them any more. Botnet have
become mainstream. They are part of sales pitches now.

SPBC for the botnet controllers these days relies on proven and tested
techniques, concentarting and backing themselves on:
Reliability - Efficient and stable.
Robust - Easily replaced.
Diverse - varying control channels, from DNS, other IRC servers and direct
connect to a downloader ready to download a new bot or re-infect a known
bad network.
Distributed - need I speak of that one?

What taking down C&C’s does achieve?
1. Coordination on security issues between ISP’s, continued and
peer-pressure based. Slowly but surely becoming more and more LEO,
regulation and vendor-run in comparison to what it used to be.

2. Responsiveness to abuse - gaging ISP response is interesting and shows
how interested they are.

3. Feeling good - cleaning the back yard and moving the problem to someone
else (another ISP). Hmm, yeah.. not really. In most cases the same ISP’s
have the same problems month after month. They just make the C&C’s
“unknwon” vs. “yes, we know where they are”.

We are now past the point where killing C&Cs has been harmful. It
was. These days the only real use a C&C can have for an organization with
a network, is to check for infected clients connecting in.

When it was harmful, creating the current situation, we were comfortable
with it as it helped hold back the immediate problem - which was important
by itself.

That’s my educated opinion, following this since 1996, and gathering
statistics for several years, some of which are seen by this community
every month.

Please, I would love to hear your opinions, disputes and how you find the
operational intell on botnet C&Cs useful to this day on networks for
mitigation purposes.

Then I would like to try and check my facts against your findings as well,
and see if my conclusions hold up or if I miscalculated.

Please try and limit your answers on this thread (unless you start
another) to network mitigation issues.

Thank you all for your input. Oh, and I wasn’t very accurate. Killing C&Cs
these days is still harmful, just that now it doesn’t even hold back the
tide.

Gadi.

Note: this is also being sent to the public botnets mailing list.

Gadi Evron,
ge@linuxbox.org.

Yahoo! Finance sites as target of attackers

- Entry updated to include information about site us.biz.yahoo.com -

It appears that three Yahoo! Finance sites have been defaced recently.

The main site

http://biz.yahoo.com/

is accessible, but attacker’s signs are still available.
UPDATE: At 08:45UTC signs removed

NOTE: http://biz.yahoo.com/ redirects to http://finance.yahoo.com/
and http://biz.yahoo.com/ is still owned.

Sites biz22.finance.dcn.yahoo.com and biz26.finance.dcn.yahoo.com running FreeBSD and unknown Web server have ‘Yahoo owned’ text as well.

The Netblock owner of biz.yahoo.com is HotJobs.com Ltd.

Zone-H mirror is here.

UPDATE:
http://us.biz.yahoo.com/ is one of the targets too, see mirror information here.

“Delete That”

Microsoft show-cased its Vista voice recognition, I just hope this voice recognition technology isn’t used in the security market :) , I can already imagine, “Stop Him”, no no don’t “Ignore him”, “Stop him!”.

More details here.

NASA sites running OS X defaced

Zone-H lists the following NASA Web sites defaced today:

#1
http://avdc.gsfc.nasa.gov/phpgdv2

See mirror at zone-h.org/index2.php?option=com_mirrorwrp&Itemid=44&id=4402740

#2
http://avdc1.gsfc.nasa.gov/phpgdv2

See mirror and details at zone-h.org/index2.php?option=com_mirrorwrp&Itemid=44&id=4402742

Zone-H.org archive lists these as mass defacements of Byond Hackers Team.

WHOIS results for 128.183.103.227 are the following:

OrgName: National Aeronautics and Space Administration
OrgID: NASA
Address: IS05/Office of the Chief Information Officer
City: MSFC
StateProv: AL
PostalCode: 35812
Country: US

NetRange: 128.183.0.0 - 128.183.255.25

They have a separate “Cyberwar: the beginning” posting too:
www.zone-h.org/content/view/13932/30/

First Firefox 1.5.0.4 exploit code is out

Only two days was the delay when the first PoC exploit was released to new Firefox vulnerabilities.

Navigator Object PoC release is part of Mr. Moore’s Browser Fun Blog disclosure at
browserfun.blogspot.com/2006/07/mobb-28-mozilla-navigator-object.html

This vulnerability is handled at Mozilla Foundation Security Advisory (MFSA) #45, link to the advisory is mozilla.org/security/announce/2006/mfsa2006-45.html
Mozilla Foundation has assigned this issue as Critical, highest severity used by organisation.

The entry states XP SP2 and fully patched Gentoo Linux tested as affected.
UPDATE: Mac OS X (Intel and PowerPC) are affected too.

An official workaround is to disable Java if update to the fixed FF1.5.0.5 is not possible.

SeaMonkey versions before 1.0.3 are probably affected as well.

Memory Leak #11 (comic strip)

Memory Leak, eleventh strip of this new comics.

Memory Leak #11

Click on the image for full size.

Insecurity #1 (comic strip)

Insecurity, first strip of this new comics.

Insecurity #1

Click on the image for full size.

To XSS or not?

Okay, so we all like to diss on Cross-site scripting vulnerabilities. They are indeed vulnerabilities, but there are so many of them that they have become tiresome, to say the least.

Today, a serious cookie-stealing XSS in paypal was reported. Automatically it was put down. I will try and address why XSS vulnerabilities are critical, and yet how they clog our security information channels, and thus our ability to do our jobs.

Honestly? Kiddies reporting XSS vulns in flying colours of a remote code execution is annoying to me, but again, these are still vulnerabilities. They deserve being reported.

I personally believe reporting them one by one to the world is important. They can cause, for example, if used on a news/commerce web site, significant losses from phishing or perhaps cause a massive scare, by a carefully crafted fake news message.
If, as another example, the XSS is in some publicly distributed PHP application, that indeed has relevance to the rest of the world. No matter how annoying the volumes of these may be.

More importantly, some XSS vulnerabilities can be used for stealing cookies and sessions, taking over an Inbox or a purchasing account, depending on what service the web site offers
(as seen before on.. lycos? hotmail? paypal?).

XSS vulnerabilities should not be looked down-at. Yet…..

All that said, acknowledging XSS for being a real vulnerability does not mean every XSS is “worth reporting” or even reading. Meaning: kiddies, for crying out loud, stop reporting every XSS client-side content manipulation you find in every second-rate online dating service. It has become comparable to reporting every spam message you get.

Philosophically, “Full disclosure all the way, baby!”. In practicality, who doesn’t look down at XSS vulnerabilities these days? They have become the trait of kiddies.
How about reporting them, but in batches as some researchers have shown they can do, recently? The impact is larger and they still go public.

Maybe if the volume of reports was lower and more digestible, and the importance/critically measurement were sane, the serious XSS vulnerabilities would be indeed taken as serious, with the respect they deserve.

As long as every 2-bit XSS is being reported in a near-flood of useless email messages, in most cases they won’t be taken very seriously.

Every web site out there likely has an XSS or 10. This is not scalable for the regular security vulnerabilities information channels the way things go now. Report the “less important ones”, but do so in digest mode, m’Kay?

A few years ago we used to joke about auto-generating PHP vulnerability reports and send them to bugtraq. Who would be able to tell the difference? Today, in my opinion, it’s become a joke.

The paypal vulnerability reported today as found by securitylab.ru is critical, as it allows stealing the cookie. All credit naturally belongs to them, good work guys.

To make a point though, after this was published, a friend of mine looked back to an XSS he found in passing 2 years ago, and reported to paypal. Obviously, it is still there and haven’t been acted on.

This does not take from their finding, the credit is theirs, but perhaps if full disclosure was applied 2 years ago (as paypal didn’t do much about it), others who very likely found this vulnerability since would not have been able to exploit paypal users.

If it was, would it have gotten much attention? Did it today when it was released in Full Disclosure?

This is what Full disclosure was created for.

Enough with silly XXS vulnerabilities, people. Let’s be able to distinguish what’s important and report it accordingly. Then give the due respect to everything else and still report it, but in a digestible form.

Again, what’s not-so-important can still (and should still) be reported, but please, stop clogging our lines of communication!

Gadi Evron,
ge@linuxbox.org.

The sun will come out tomorrow

I remember when I was first introduced to DES. It was in some computer magazine whose name I can’t recall and it went something like “the DES algorithm is so powerful, that even if you could run several DES brute force attempts per second, the sun will die and our galaxy will be destroyed before you can try all the DES combinations. It made sense – 2^56 is a very big number, more than the measly 5-10 billion years our sun has to live. Back then there was also speculation on how the NSA could break it. It was a well-documented fact that the NSA made some subtle changes to the DES algorithm and the popular assumption was that they put in a ‘back door’ so that their supercomputer can break it. There had to be an NSA backdoor, since there were mathematical proofs on the impossibility of breaking DES in a reasonable time (like, within the age of the universe) or reasonable amount of money (lets say, within the entire worth of the world’s economy). Who can argue with a mathematical proof that contains a lot of exponents and relies on bullet proof analogies?

Almost a decade later I learned cryptology from Eli Biham, the inventor of differential cryptology. He spent a full lecture on the DES design and algorithm and we were all quite convinced that its 16 rounds and mysterious S-box design was unbreakable. Biham finished the lecture by saying “…and next week, I’ll tell you how DES is broken” and indeed the following week he taught us differential cryptanalysis. The method was unpractical and mostly theoretical, so it didn’t really “break” DES, but it showed the first weakness and I started losing faith in the whole “the world will end before…” jive.

It was only a few years after, that DES collapsed. It wasn’t with smart differential cryptology, though. It wasn’t even by finding the ’secret NSA backdoor’ everybody was looking for in the 80s. In fact, many were shocked to discover the NSA change to the S-boxes actually made DES more resistance to differential cryptanalysis attacks. They didn’t want the algorithm to be weakened by other means, possibly because they could brute-force it way back then.
DES was broken because something unexpected happened. The processing power of a super computer from the 70s is weaker than the average PC sold at Walmart. In fact, a $500 PC running a standard operating system can try hundreds of thousands of DES combinations per second, while allowing its operator to play Solitaire. It’s not difficult to get hold of thousands or even tens of thousands of PCs (think a medium-size corporation after 5pm or a university during summer vacation) and you’ve got about a billion DES brute-force attempts per second. The sun will come up tomorrow, and the DES encrypted message will be broken by that time.

If I was to go back in time and tell a computer science professor that in 30 years an average person will have access to a processing power that is a billion times that of a super computer, I would be committed on the spot (or worse – sent to the social sciences department). Yes, I admit that it’s hard to anticipate something like that – keeping with the flawed analogies that would be like me telling you that in 30 years we’ll all be living in mansions like Bill Gates while paying 1/10 of the rent we pay today.

On the other hand, just because we can’t grasp something doesn’t make it impossible. I made that mistake myself, when 8 years ago I argued passionately that Windows vulnerabilities are impossible to exploit. I gave a very detailed reasoning. I thought I knew a lot about security. Two years later, David Litchfield gave a step-by-step explanation on how to exploit buffer overflows on Windows. Reading back what I wrote then, makes me want to get into the time machine again, visit the young me and hit myself with the clue stick (and tell the astonished me that whatever stupid thing I write will be saved forever and can be pulled by a search engine in less than a second. After that, I should probably give myself the lottery winning numbers and a travel brochure).

I figured people stopped making outrageous claims about what’s ‘impossible’ in computer security, and then I stumbled upon this. My favorite quote (attributed to Jon Callas, the CTO of PGP corporation):

[…] consider a cluster of [grain sized] computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years.

Really Jon? Sure, it can be backed up by the ‘exponential growth’ problem and by looking at the results of various distributed cracking projects. But will an encrypted message sent by a Coca Cola executive containing the secret formula and encrypted by a 128-bit PGP key survive brute force attacks 5 years from now? 10 years? 20? 30? Would you wager $23B a year on that? I wouldn’t.

Don’t get me wrong, brute force should not be the primary concern of someone securing their system from attack. It’s much easier to find an unpatched network vulnerability, or run a social-engineering attack to get what’s needed. But 2005 was an amazing year for cryptanalysis, with weaknesses found in major hashing algorithms and Chinese crypto experts leap-frogging what we thought was possible in some fields.

My advice? Whenever someone describes ‘impossible’ in terms of planets, atoms or large exponents ask them to give it to you in writing. 10 years later go back to them with a “what were you thinking?”. With some luck, they’ll be rich and famous and you could shame them in public. I’m saving mine for Jon Callas. Modern cryptographic systems are essentially unbreakable? Yeah, and 640k should be enough for anybody.

More Google Hacking - Security Auditing

A nice use for what we wrote about a couple of days ago just came up on FD as posted on the cipher blog.

Use the filetype: feature to look for common programming errors.

Cute!

What’s your favorite new Google hack?

Gadi Evron,
ge@linuxbox.org.

Memory Leak #10 (comic strip)

Memory Leak, tenth strip of this new comics.

Memory Leak #10

Click on the image for full size.

References:
Google Adsense
Star Trek

XSS Everywhere - Another Full Disclosure Run

Much like before with dcrab, another security researcher decided to prove to the world what everyone knows and ignores - almost every web site has vulnerabilities and these are being ignored.

SkyOut just released a list of sites which are affected by XSS, in Full Disclosure mode:
http://web3.m34s11.vlinux.de/xss_research.htm

Among the sites are americanexpress.com, walmartstores.com, pcworld.co.uk, weather.com, netscape.com, thestreet.com and others. We are working to notify them and hopefully prevent some phishing. But once something is out there, it’s out there. Full Disclosure.

I expect we will start seeing such lists quite regularly, after all, these are everywhere.

Gadi Evron,
ge@linuxbox.org.

Internet Security Operations and Intelligence - a DA Workshop

The DA Workshop will be mostly on the subject of Botnets, while touching Phishing and DDoS.

It will take place on August 10th, hosted by Cisco in San Jose with a dinner, sponsored by the ISC.
Participation is open only to members of closed and vetted mitigation and security operations groups.

Main lineup:

“Bot, Botnets, Sandbox, Impact”
Righard J. Zwienenberg (Norman)

“MSRC Malware/Exploit Zero Day Response - Case Studies”
Greg Galford (Microsoft)

“The Rough Road Around Us in Botnet Tracking”
Jose Nazarijo (Arbor)

“Malcode Toolkit Profiteering:Feeding the Trend in M.O. from Fame to Fortune”
Hubbard Dan (Websense)

Case Study: ***
Levi Gundert (US Secret Service)

“Recent Bots Detection Information from Microsoft Security Products”
Ziv Mador (Microsoft)

“Security Inside the Router:How Network Gear Handles DDoS Attacks”
Barry Raveendran Greene (Cisco)

“What Keeps Us Up at Night:
New & Advanced Difficult to Mitigate DDoS Attacks”
Darrel Lewis (Cisco)

“The Global Infection Rate”
Rick Wesson (Alice’s Registry)

“Phishing and Botnets Organized Crime:
Globalization and Tehnology Intelligence Update”
Gadi Evron (Beyond Security)

“Fast-flux Botnet C&C Servers - Detection & Mitigation”
Randy Vaughn (Baylor)

TBA
David Ulevitch (EveryDNS / OpenDNS)

TBA
Jerry Dixon (DHS - US-CERT)

TBA
Paul Vixie (ISC)

The web site for the workshop is:
http://isotf.org/isoi.html

Gadi Evron,
ge@linuxbox.org.

Memory Leak #9 (comic strip)

Memory Leak, ninth strip of this new comics.

Memory Leak #9

Click on the image for full size.

RFID Malware: Is Your Cat Infected with a Computer Virus?

The BBC just came out with a story covering the now several months old work of Melanie R. Rieback, Bruno Crispo and Andrew S. Tanenbaum from the Vrije Universiteit Amsterdam on malware spreading through RFID. (hat tip to Dude)

You can find their work here and here.

Gadi Evron,
ge@linuxbox.org.