A few media sources seem to be picking up a press release from the University of Michigan.

http://www.ns.umich.edu/htdocs/releases/story.php?id=6666

This reports on “CloudAV,” a project and series of papers about having antivirus  etection run “in the cloud” rather than on the PC.

http://www.eecs.umich.edu/fjgroup/cloudav/

As usual, there seems to be some misunderstanding about what is going on here.   CloudAV is not really a new approach, it is simply the use of multiple scanners, which the  AV research community has advocated for years.  It’s like having a bunch of scanners installed on your desktop, or a system like Virustotal, with the exception that the scanners run on different computers so you get a bit of performance advantage (absent the bandwidth lag/drain for submitting files to multiple systems).

We recently did some work finding inherited vulnerabilities in SNMP supporting devices - mainly embedded/hardware.

SNMP like many other protocols is defined in several RFCs, starting with the basic RFC that describes the protocol structure and goes up to RFC 3414 which describes how authentication and encryption (referred to as privacy by the SNMP spec) are done.

The RFC describes a few algorithms, such as the one for key localization, in great detail - i.e. providing a C source code:


void password_to_key_md5(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength,/* IN - length of snmpEngineID */
u_char *key) /* OUT - pointer to caller 16-octet buffer */
{
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;

MD5Init(&MD);
MD5Update(&MD, password_buf, 32+engineLength);
MD5Final(key, &MD);
return;
}


People reading this RFC would jump with joy and just copy paste the above code into their own code and continue on their work of getting SNMP to work on their hardware.

Little will they know that the RFC team has made notice that:

May want to ensure that engineLength < = 32, otherwise need to use a buffer larger than 64

“Ohh pff, who needs to ensure anything on my robust hardware - what is the worst that can happen, a server crash ”

Actually, the worst that can happen is a neat buffer overflow, as no one guarantees that the engineID is limited to 32 bytes, in reality the length is not limited by the transport layer (the ASN.1) but rather only by the RFC specification, which again not everyone checks or conforms to it by 100%.

I would expect the RFC editors/creators to place sample code that is secure. Something like so would have sufficed to prevent the code from being easily exploited:
memcpy(password_buf, key, 16);
memcpy(password_buf+16, engineID, engineLength < 32 ? engineLength : 32);
memcpy(password_buf+16+(engineLength < 32 ? engineLength : 32), key, 16);
Especially since Google searching the above example proved that quite a few people were too lazy to not only fix the security issue but too lazy to remove the embarrassing comment.

Following up on that strange title, ISOI 3 (Internet Security Operations and Intelligence), a workshop for do-ers who work on the security of the Internet and its users, is happening Monday and Tuesday in Washington, DC.

This time around we have even more government participation (we’re in DC, duh), but a bit less from academia (who can try and look at long term solutions), rather than just us security researchers, and operators (who respond, contain and mitigate incidents).

I am very pleased with our progress on encouraging global cooperation, and getting more industry information sharing going. I am also happy we are moving from “just” good-will based relationships to the physical world with our efforts, being able to take things to the next level with world-wide operational task forces and, indeed, affecting change.

If you are interested in this realm of Internet security operations, take a look at ISOI 3’s schedule, and perhaps submit something for the next workshop.

Some reporters are somewhat annoyed that entrance is barred to them, but I hope they’d understand that although we make things public whenever we can as full disclosure is a strong weapon in the fight against cyber crime, folks can not share as openly when they have to be on their toes all the time.

The third ISOI is here because after DHS ended up unable to host it, sponsors emerged who were happy to assist:

Afilias Ltd.: http://www.afilias.info/
ICANN: http://www.icann.org/
The Internet Society: http://www.isoc.org/
Shinkuro, Inc.: http://www.shinkuro.com/

It’s going to be an interesting next week here at the swamp. Atendees better show up with their two forms of ID.

Gadi Evron,
ge@linuxbox.org.

I posted a column on eWeek on what critical infrastructure means, looking back at the Estonia incident.

They edited out some of what I had to say on home computers and their impact as a critical infrasrtcuture, but hey, word limitations.

http://www.eweek.com/article2/0,1895,2166125,00.asp

Gadi Evron,
ge@linuxbox.org.

Syngress was kind enough to allow me to post the chapter I wrote for Botnets: The Killer Web Application here as a free sample.

It is the third chapter in the book, and requires some prior knowledge of what a botnet C&C (command and control) is. It is basic, short, and to my belief covers quite a bit. It had to be short, as I had just 5 days to write it while doing other things, and not planning on any writing, but it is pretty good in my completely unbiased opinion.

You can download it from this link:
http://www.beyondsecurity.com/whitepapers/005_427_Botnet_03.pdf

For the full book, you would need to spend the cash.

Enjoy!

Gadi Evron,
ge@linuxbox.org.

CFP: ISOI III (a DA workshop)
=============================

Introduction
————

CFP information and current speakers below.

ISOI 3 (Internet Security Operations and Intelligence) will be held in
Washington DC this August the 27th, 28th.

This time around the folks at US-CERT (Department of Homeland Security -
DHS) are hosting. Sunbelt Software is running the after-party dinner.

We only have a partial agenda at this time (see below), but to remind you of what you will see, here are the previous ones:
http://isotf.org/isoi2.html
http://isotf.org/isoi.html

If you haven’t RSVP’d yet, please do so soon. Although we have 240 seats, we are running out of space.

A web page for ISOI 3 can be found at: http://isotf.org/isoi3.html

Details
——-
27th, 28th August, 2007
Washington DC -
AED conference center:
http://www.aedconferencecenter.org/main/html/main.html

Registration via contact@isotf.org is mandatory, no cost attached to attending. Check if you apply for a seat in our web page.

CFP
—

This is the official CFP for ISOI 3. Main subjects include: fastflux, fraud, DDoS, botnets. Other subjects relating to Internet security operations are also welcome.

Some of our current speakers as you can see below lecture on anything from Estonia’s “war” to current web 2.0 threats in-the-wild.

Please email contact@isotf.org as soon as possible to submit a proposal. I will gather them and give them to our committee (Jeff Moss) for review.

Current speakers (before committee decision)
——————————————–

Roger Thompson (Exp Labs
- Google adwords .. .the dangers of dealing with the Russian mafia

Barry Raveendran Greene (Cisco)
- What you should be asking me as a routing vendor

John LaCour (Mark Monitor)
- Vulnerabilities used to hack sites for phishing
- Using XSS to track phishers

Dan Hubbard (Websense)
- Mpack and Honeyjax (Web 2.0 honeypots)

April Lorenzen
- Fastflux: Operational Update

William Salusky (AOL)
- The Spammer Evolves - Migration to WebMail

Hillar Aarelaid (Estonian CERT)
- Incident Response during the Recent Attack

Gadi Evron (Beyond Security)
- Strategic Lessons from the Estonian “First Internet War”

Jose Nazarijo (Arbor)
- Botnet statistics from the Estonian attack

Andrew Fried (Treasury Department)
- Phishing and the IRS - New Methods

Danny McPherson (Arbor)
- TBA

I’m writing this purely to pass on a message. If you’ve ever used the burp suite and have a comment about the software, now is the time to let the developers know. If you haven’t tried it yet, give it a go, you won’t regret it.

This is just to let you know that work is underway on the next release of Burp Suite, which should be available later this year. This will be a major upgrade with lots of new features in all of the tools.

At this point, it would be good to hear any other feature requests that you may have, however large or small. Please reply to me directly or join the discussion here:

http://blog.portswigger.net/

and I’ll address as many as I can.

I’d be grateful if you would pass this email on to anyone else in your team who uses Burp Suite.

People have been wondering why I’ve been keeping quiet on this issue, especially since I was right there helping out.

A lot of people had information to share and emotions to get out of the way. Also, it was really not my place reply on this - with all the work done by the Estonians, my contributions were secondary. Mr. Alexander Harrowell discussed this with me off mailing lists, and our discussions are public on his blog. Information from Bill Woodcock on NANOG was also sound.

As to what actually happened over there, more information should become available soon and I will send it here. I keep getting stuck when trying to write the post-mortem and attack/defense analysis as I keep hitting a stone wall I did not expect: strategy. Suggestions for the future is also a part of that document, so I will speed it up with a more down-to-Earth technical analysis (which is what I promised CERT-EE).

In the past I’ve been able to consider information warfare as a part of a larger strategy, utilizing it as a weapon. I was able to think of impact and tools, not to mention (mostly) disconnected attacks and defenses.

I keep seeing strategy for the use IN information warfare battles as I write this document on what happened in Estonia, and I believe I need more time to explore this against my previous take on the issue, as well as take a look at some classics such as Clausewitz, as posh as
it may sound.

Thanks,

Gadi Evron,
ge@linuxbox.org.

The New York Times carries a good popular-level accounting of what happened in the recent Estonian information warfare incident. Suggested reading.

http://www.nytimes.com/2007/05/29/technology/29estonia.html (subscription required)
Syndicated: Times Daily

Fergie replied on NANOG to my recent post on the subject of broadband routers insecurity:

> I’ll even go a step further, and say that if ISPs keep punting
> on the whole botnet issue, and continue to think of themselves
> as ‘common carriers’ in some sense — and continue to disengage
> on the issue — then you may eventually forced to address those
> issues at some point in the not-so-distant future.
>
> I understand the financial disincentives, etc., but if the problem
> continues to grow and fester, and consumer (and financial institutions)
> losses grow larger, things may take a really ugly turn.

He is right, but I have a comment I felt it was important - to me - to make. Not just on this particular vulnerability, but on the “war”.

I must admit, vulnerabilities are endless and new exploitation vectors will never end, even if it was possible and we were all 100% secure, someone (an attacker rather than a vulnerability) will find a way to make it 99% again for the right investment or with the right moment of brilliance.

Enough with cheap philosophy though… as tired (even exhausted) as I am of the endless repeating circle which security is, on all levels (from the people involved through the interests involved all the way to the same-old-FUD) I still haven’t burned out, and I am still here.

The world isn’t going to end tomorrow, and even if the Internet was to die (which I doubt it will), we will survive. However, in the recent couple of years a new community has been forming which we started refering to as “Internet security operations”. These folks, for various motives, work to make the Internet stay up and become safer (actually being safe is a long lost battle we should have never fought the way things were built).

With such a community being around, treating issues beyond our little corner of the `net is possible to a level, and at least some progress is made. Some anti virus engineers no longer care only about samples, some network engineers no longer care only about their networks, etc.

Is any of this a solution? No. The problems themselves will not go away, they aren’t in any significant fashion currently being dealt with beyond the tactical level of a fire brigade.

Is it the end than? Of course not. But operations vs. research are determined by intelligence. As we have some intelligence, I can point to yet another annoying vulnerability in the endless circle which those of us who will want to, can study, and if they feel it is justified, defend
against. That is the broadband routers issue, which personally I’d really rather avoid.

Unfortunately, this limited defense is what most of us can do at our own homes, or tops as a volunteer fire brigade or neighborhood watch.

The Internet is the most disconnected global village I can imagine, but we all have the funny uncle on another network and a weird one on yet another. I sometimes feel that the old analogy of the Internet to the Wild West is not quite it. Perhaps we are living in the Wild West, only if instead of wastelands and small towns, we have New York city and the laws
of a feudal dark ages Kingdom.

Things will eventually change, and some of us will stick around to help that change (or try to). For now though, it is about one vulnerability ignored at a time, and working on our communities.

Gadi Evron,
ge@linuxbox.org.

In this post I’d like to discuss the threat widely circulated insecure broadband routers pose today. We have touched on it before.

Today, yet another public report of a vulnerable DSL modem type was posted to bugtraq, this time about a potential WIRELESS flaw with broadband routers being insecure at Deutsche Telekom. I haven’t verified this one myself but it refers to “Deutsche Telekom Speedport w700v broadband router”:
http://seclists.org/bugtraq/2007/May/0178.html

If you all remember, there was another report a few months ago about a UK ISP named BeThere with their wireless router being accessible from the Internet and exploitable, as another example:
http://blogs.securiteam.com/index.php/archives/826

Two issues here:
1. Illegitimate access to broadband routers via wireless communication.
2. Illegitimate access to broadband routers via the WAN.

I’d like to discuss #2.

Some ISPs which provide such devices (as in the example of #2 above) use them as bridges only, preventing several attack vectors (although not all). Many others don’t. Most broadband ISPs have a vulnerable user-base on some level.

Many broadband ISPs around the world distribute such devices to their clients.

Although the general risk is well known, like with many other security issues many of us remained mostly quiet in the hope of avoiding massive exploitation. As usual, we only delayed the inevitable. I fear that the lack of awareness among some ISPs for this “not yet widely exploited threat” has resulted in us not being PROACTIVE and taking action to secure the Internet in this regard. What else is new, we are all busy with yesterday’s fires to worry about tomorrow’s.
Good people will REACT and solve the problem when it pops up in wide-exploitation, but what we may potentially be facing is yet another vector for massive infections and the creation of eventual bot armies on yet another platform.

My opinion is, that with all these public disclosures and a ripe pool of potential victims, us delaying massive exploitation of this threat may not last. I believe there is currently a window of opportunity for service providers to act and secure their user-base without rushing. Nothing in security is ever perfect, but actions such as changing default passwords and preventing connections from the WAN to these devices would be a good step to consider if you haven’t already.

My suggestion would be to take a look at your infrastructure and what your users use, and if you haven’t already, add some security there. You probably have a remote login option for your tech support staff which you may want to explore - and secure. That’s if things were not left at their defaults.

Then, I’d also suggest scanning your network for what types of broadband routers your users make use of, and how many of your clients have port 23 or 80 open. Whether you provide with the devices or not, many will be using different ones set to default which may pose a similar threat. Being aware of the current map of vulnerable devices of this type in your networks can’t hurt.

It is not often that we can predict which of the numerous threats out there that we do not address currently, is going to become exploited next. If you can spare the effort, I’d strongly urge you to explore this front and be proactive on your own networks.

The previous unaddressed threat which most of us chose to ignore was spoofing. We all knew of it for a very long time, but some of us believed it did not pose a threat to the Internet or their networks for no other reason than “it is not currently being exploited” and “there are enough bots out there for spoofing to not be necessary”. I still remember the bitter argument I had with Randy Bush over that one. This is a rare opportunity, let’s not waste it.

We are all busy, but I hope some of you will have the time to look into this.

I am aware of and have assisted several ISPs, who spent some time and effort exploring this threat and in some cases acting on it. If anyone can share their experience on dealing with securing their infrastructure in this regard publicly, it would be much appreciated.

Thanks.

Gadi Evron,
ge@linuxbox.org.

Support Intelligence releases daily reports on different fortune 500
companies which are heavily affected by the botnet problem, with many
compromised machines on their networks.

You can find more information on their blog:
http://blog.support-intelligence.com/

They are good people, and they know botnets.

Gadi Evron,
ge@linuxbox.org.

Isn’t security as important to discuss as .XSS?

The DNS has become an abuse infrastructure, it is no longer just a functional infrastructure. It is not being used by malware, phishing and other Bad Things [TM], it facilitates them.

Operational needs require the policy and governance folks to start taking notice.

It’s high time security got where it needs to be on the agenda, not just because it is important to consider security, but rather because lack of security controls made it a necessity.

In discussion of my latest post, some folks on NANOG raised interesting ideas, such as:
(these are displayed as I understood them)
1. Terminating domains found to be registered with stolen credit cards (raised by Chris Morrow)
2. Introducing a delay to registration (Douglas Otis)
3. Reviewing legacy engineering decisions (David Conrad)
4. A show of responsibility by Registries and Registrars to take care of bad domains (Paul Vixie)
5. Public shaming should be considered (Paul Vixie)
6. Closing the vulnerability with DNS should not be ignored just because bad guys will find something else to exploit (Hank Nussbacher)
7. Check out http://www.icann.org/participate/ (John Crain)

As well as other ideas and contributors. I won’t push my own here, there’s enough already up there to keep us busy for a while.

Whether these ideas are good remains to be seen, the fact is that we now discuss the issues.

Some other conclusions were that the domain registration system and process are a significant part of the current on-going abuse of the DNS infrastructure.

So, as important as the XXX TLD is, security should get as much attention, if not more.

It’s about the current policy which allows black hat registrars to exist (rather than controlling good ones - lower hanging fruit first?), as well as about the policy of registration and termination of domain names.
It is about old policy no longer fitting today’s threats, and, to a limited fashion, technology which needs to be revamped.

Here is one of the latest emails in the NANOG thread, by me in reply to David Conrad. Things start to make sense now that flames and personal attacks have died down.

This email message is about ICANN’s role, if it is to have one, as well as about practical suggestions:

Date: Mon, 2 Apr 2007 21:02:46 -0500 (CDT)
From: Gadi Evron
To: David Conrad
Cc: nanog@merit.edu
Subject: ICANNs role [was: Re: On-going …]

On Mon, 2 Apr 2007, David Conrad wrote:
> On Apr 1, 2007, at 8:45 AM, Gadi Evron wrote:
> > On Sun, 1 Apr 2007, David Conrad wrote:
> >> On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote:
> >> I’m not clear what “this realm” actually is.
> > Abuse and Security (non infrastructure).
>
> Well, ICANN is supposed to look after the “security and stability” of
> the Internet, which is sufficiently vague and ambiguous to cover
> pretty much anything. I was actually looking for something a bit
> more concrete.

So you are the guys asleep at the guard post?

> The one concrete suggestion I’ve seen is to induce a delay in zone
> creation and publish a list of newly created names within the zone.
> The problem with this is that is sort of assumes:

What are your thoughts on basic suggestions such as:
1. Allowing registrars to terminate domains based on abuse, rather than
just fake contact details.
2. Following these incidents as they happen so that YOU, in charge, can
make these suggestion?
3. For true emergencies threatening the survivability of the system,
shoudln’t we be able to black-list a domain in the core?
4. Black lists for providers are not perfect, but perhaps they could help
protect users significantly?
5. Enforcing that registrars act in say, not a whitehat fashion, but a
not blackhat fashion?
6. Yours here?

I can go to extremes in my suggestions, non are new:
1. Rather than terminate on fake details - verify details before a domain
is registered. Not just the credit card, either.
2. Domains are a commodity, ICANN should know, what of putting them under
a wider license on abuse and termination or suspension?

The whole system is almost completely unregulated, and this is money you
take care of that we speak of here.

You have a long way to go before claiming to take care of the
Internet. Please take that route if you believe you can. The Internet
needs your help.

How about some funding for research projects? Getting involved and perhaps
funding Incident response on a global scale?

Why does this have to be in the hands of volunteers, such as myself and
hundreds of others?

Why does Internet security have to be in the hands of those with “good
will” rather than those who are supposed to take care of it?

How about adding security to the main agenda along-side with the .xxx TLD?

I have no problem with ICANN, but there is a long way to go before you can
claim to protect the Internet, infrastructure, users, or what’s in the
middle. I’d encourage ICANN to take that road, much like I would encourage
any person or organization that wants to help.

You were not here before when we needed you, so organizations like
FIRST, the ISOTF and many good-will based groups were created. You are
here now, how do we proceed?

What is ICANNs next step? I will support it, so will others. It’s not
about politics as much as it is about who DOES. Maybe you just need to
work with the community rather than claim to run it when you don’t really
do anything in security quite yet.

> a) the registries all work on similar timescales
> b) that timescale is on the order of a day
> c) ICANN has a mechanism to induce the registries to make changes to
> those timescales
> d) making changes along these lines would be what end users actually
> want.
>
> Of these options:
>
> - (a) isn’t true (by observation)
> - (b) is currently true for com/net, but I don’t expect that to last
> — I’ve heard there is a lot of competitive pressure on the
> registries to be faster in doing zone modifications
> - (c) I don’t think is true now for even those TLDs ICANN has a
> contractual relationship with and is highly unlikely to ever be true
> for the vast majority of TLDs
> - (d) probably isn’t true, given lots of people complain about how
> long it takes to get zone changes done now and I believe registries
> are working to reduce the amount of time significantly due to
> customer demand.
>
> Even if a delay were imposed, I’m not sure I see how this would
> actually help as I would assume it would require folks to actually
> look at the list of newly created domains and discriminate between
> the ones that were created for good and the ones created for ill.
> How would one do this?

Well, if a domain was registered last month, last week, or 2 hours ago,
and is used to send spam, host a phishing site or changes name servers
that support phishing sites ALONE (nothing legit) in the thousands, or
support the sending of billions of email messages burdening messaging
across the board, I’d call it bad.

Who “one” is, now that is something to work out. We need help setting the
system in place with guidelines and policies so that the one or other can
start reporting and getting results.

Is ICANN willing to help?

> -drc

Gadi.

>
> P.S. I should point out that IANA has only glancing interaction with
> the registry/registrar world, so I’m working from a large amount of
> ignorance here. Fortunately, being ignorant rarely stops me…

Where do we go from here? If we do proceed, what legitimate business concerns stand to lose money? (or not earn as much?).

Gadi Evron,
ge@linuxbox.org.

There is a current on-going Internet emergency: a critical 0day vulnerability currently exploited in the wild threatens numerous desktop systems which are being compromised and turned into bots, and the domain names hosting it are a significant part of the reason why this attack has not yet been mitigated.

This incident is currenly being handled by several operational groups.

This past February, I sent an email to the Reg-Ops (Registrar Operations) mailing list. The email, which is quoted below, states how DNS abuse (not the DNS infrastructure) is the biggest unmitigated current vulnerability in day-to-day Internet security operations, not to mention abuse.

While we argue about this or that TLD, there are operational issues of the highest importance that are not being addressed.

The following is my original email message, elaborating on these above statements. Please note this was indeed just an email message, sent among friends.

Date: Fri, 16 Feb 2007 02:32:46 -0600 (CST)
From: Gadi Evron
To: reg-ops@…
Subject: [reg-ops] Internet security and domain names

Hi all, this is a tiny bit long. Please have patience, this is important.

On this list (which we maintain as low-traffic) you guys (the
registrars) have shown a lot of care and have become, on our sister mitigation and research lists (those of you who are subscribed), an integral part of our community we now call “The Internet Security Operations Community”.

We face problems today though, that you can not help us solve under the current setting. But only you can help us coming up with new ideas.

Day-to-day, we are able to report hundreds and thousands of completely bogus phishing and other bad domains, but both policy-wise and resources-wise, registrars can’t handle this. I don’t blame you.

In emergencies, we can only mitigate threats if one of you or yours are in control.. Just a week ago we faced the problem of the Dolphins stadium being hacked and malicious code being put on it:

1. We tracked down all the IP addresses involved and mitigated them (by we I mean also people other than me. Many were involved).
2. We helped the Dolphins Stadium IT staff take care of the malicious code on their web page - Specifically Gary Warner).
3. We coordinated with law enforcement.
4. We coordinated that no one does a press release which will hurt law enforcement.
5. We did a lot more. Including actually convincing a Chinese registrar to pull one of the domains in question. A miracle. There was another domain to be mitigated, unsuccessfully.

One thing though - at a second’s notice, this could all be for nothing as the DNS records could be updated with new IP addresses. There were hundreds of other sites also infected.

Even if we could find the name server admin, some of these domains have as many as 40 NSs. That doesn’t make life easy. Then, these could change, too.

This is the weakest link online today in Internet security, which we in most cases can’t mitigate, and the only mitigation route is the domain name.

Every day we see two types of fast-flux attacks:
1. Those that keep changing A records by using a very low TTL.
2. Those that keep changing NS records, pretty much the same.

Now, if we have a domain which can be mitigated to solve such
emergencies and one of you happen to run it, that’s great…
However, if we end up with a domain not under the care of you and yours.. we are simply.. fucked. Sorry for the language.

ICANN has a lot of policy issues as well, and the good guys there can’t help. ICANN has enough trouble taking care of all those who want money for .com, .net or .xxx.

All that being said, the current situation can not go on. We can no longer ignore it nor are current measures sufficient. It is imperative that we find some solutions, as limited as they may be.

We need to be able to get rid of domain names, at the very least during real emergencies. I am aware how it isn’t always easy to distinguish what is good and what is bad. Still, we need to find a way.

Members of reg-ops:
What do you think can be conce