Opera the web browser is apparently now great at one thing: following the standards.

Yesterday, Opera 10 Alpha was released and flaunted its 100/100 score on the Acid3 test, passing with all the colors of the rainbow this time. But honestly, Opera, like several other ‘alternative’ browsers (and if your a hardcore fan/follower, excuse me), is just trying to catch up with the old dogs.

Firefox in particular has had many of Opera’s ‘new’ features and ‘improvements’ for quite a while. Security issues in Opera, often simple and totally trivial bugs, have been found and released. Not saying more than other browsers; both Firefox and Internet Explorer have them doubled to say the least, but I just never could bring myself to trust this unique web browser.

Auto-update has just been put in place, and I feel, as a security researcher, that it is an extremely valuable mitigation tool when new exploits spring up. Thank God the development team FINALLY put this sub-standard feature in place. Presto 2.2 has taken things to the next level with most of these improvements, more details of which you can find for windows, mac, and ‘linux/unix‘.

Has security been incorporated into Opera recently more than ever? Maybe. Has Opera been built with security from the ground up? Certainly not. Pay attention to your favorite XYZ exploit/advisory feed for inevitable updates.

CNet has a nice article about a Vietnamese company called BKIS that was able to login to the reporter’s laptop by simply recording him in a video chat and then using the blurry printout to authenticate with the face-recognition software.

I like to make fun of biometric authentication, mainly because it was overhyped in the 90′s as the authentication that will make remembering passwords obsolete. But it’s not useless technology – you just have to know how to use it.

Using a biometric system (this, or another) in a public place with a guard watching is good enough to make it difficult to hack. I imagine even a minimum-wage rentacop will notice when someone looking like Tom Cruise comes up to the biometric system with someone’s eyeballs in his hand. They should even notice if I come with a printout of someone else’s face. The same is true for passwods: a 50-character long password can be practically as strong as a 4 digit PIN if the proper lock out procedures are in place. Likewise, if I can try billions of password combinations per second then the difference between guessing a 8 character password and a 10 character password is just a few hours.

I’ve been registered with the SCADA Security Mailing List for a while now, and I must say it is very informative and has some solid discussion about SCADA systems and security. If you are not familiar with what SCADA is, it stands for Supervisory Control And Data Acquisition. SCADA systems are generally used for controlling and maintaining public services and private sector systems such as but not limited to nuclear plants, environmental systems, industrial stations, etc. You can google for more information or check our SCADA’s Wikipedia Page.

Security has and also been a big issue with running SCADA systems, especially those connected and maintained over the internet, or really any kind of network. Firewalls and IDS’s can only do so much; the integrity of the applications must be a part of the solution, AND NOT COLLAPSE! There are also many books at amazon that deal with SCADA systems. Could the internal workings of outdated coding practices and weak security in the systems, that control our precious resources and way of life, prove to be insecure? You better believe it.

In a hotel in Beijing, using their wifi in the lobby. Everything goes fine until Noam tells me my email headers are weird.

Return-Path: aviram@hsia.com.cn
[...]
Received: (qmail 9613 invoked from network); 19 Nov 2008 13:26:43 -0000
Received: from mail.hsia.com.cn (HELO hsia.com.cn) (61.152.154.60)
by 0 with SMTP; 19 Nov 2008 13:26:43 -0000
Received: from FBH.hsia.com.cn ([123.124.225.63])
by hsia.com.cn (8.13.1/8.13.1) with ESMTP id mAJDTJlY005475;
Wed, 19 Nov 2008 21:29:20 +0800
Received: from beat.local (unknown [172.31.8.65])
by FBH.hsia.com.cn (Postfix) with ESMTP id 8AFEB520B0;
Wed, 19 Nov 2008 21:13:54 +0800 (CST)

Clearly I’m sending through another SMTP server, who goes as far as mangling my ‘Return-Path’ address header.

Only I’m not. My SMTP server is set (as always) to the corporate SMTP who is accessible through the VPN, in an encrypted connection that should not allow anyone to change fields. Just in case, I check it again. Yup, the SMTP server is there. So what’s up?
A quick investigation shows the following: The hotel’s network blocks my VPN (as some of them do) but happily resolves any unresolvable host name (such as my SMTP server’s hostname). This is resolved to a catch-all server that proxies everything. Transparently. (well, almost)

Lesson learned. Changed the hostname to the IP, and will soon switch to SSL based SMTP who will authenticate the server. In the meanwhile – be careful from helpful Beijing wifi providers who are only too happy to forward your mail on! (with some changes, of course).

Randy Abrams recently pointed out to me that today is the 20th anniversary of the Morris Worm. For all you kids out there who have no recollection of this event, I’ve just posted a blog at http://www.eset.com/threat-center/blog/?p=165 that recaps on the worm and includes some relevant references, but right now I want to expand on a thought I had while I was writing it.

The Morris worm was very much of its time. It was a proof of concept (actually of several concepts) item of malware that showed a certain interest in and knowledge of some vulnerabilities that were current at that time (mostly a fingerd buffer overflow exploit and a somewhat flaky implementation of sendmail debugging), and was clearly meant to be self-launching. Most current malware, while it may well use drive-by downloads and other exploits, seems to use some form of social engineering. So maybe the earlier CHRISTMA EXEC worm was the real pioneer, with its mass mailing payload and its chainletter appeal to the gullibility of the victim. Well, we can draw dotted lines between old and new malware from now to Christmas, which is the sort of thing that interests saddos like me but doesn’t necessarily gain us much in terms of securing the internet.

Looking through some historical resources, it strikes me that there are some moments in malware history that not only define the time, but in some way draw a line under it, though Morris was followed by a copycat VMS worm the following year). After that, though, we waited quite a while for a real mass mailer epidemic and for the big network worms of this decade. Melissa managed to mark both the beginning of heavy duty mass mailers and the end (or at least the decline) of macro malware. Yet there are no full stops here. In 2008, we’re still seeing new(-ish) stuff cheek-by-jowl with the sort of malware we’ve mostly forgotten about: old-time boot sector viruses and new-age MBR rootkits; macro viruses and office suite exploits; overflows and drive-bys; and an endless loop of social engineering tricks (phishes, 419s, fake admin messages, fake codecs, fake updates…) The only really substantial change is the disappearance of the hobbyist hacker/malware author, promoted into full-blown cyber-criminality.

It seems that what we really need to patch is human nature: the evil gene, the greed gene, the careless gene, the “what’s a patch?” gene, the “I can click on anything because I have anti-virus software” gene…

David Harley CISSP FBCS CITP
ESET LLC

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@beyondsecurity.com.

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@beyondsecurity.com.

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

Sun Shine (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@beyondsecurity.com.

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@beyondsecurity.com.

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@beyondsecurity.com.