Tracks of the defacement of MSN site http://beta.cmt.msn.com/ are still located at Microsoft’s Web server.

Zone-H lists the following attack timestamp:

Mirror saved on: 2007/02/25 10:00

The site mentioned is running Windows 2003 and IIS version 6.0.

I have confirmed that Microsoft security is aware.

Update: 20:30UTC the address generates ‘Invalid URL’ error and tracks are being removed.

Jamie Riden, Ryan McGeehan, Brian Engert and Michael Mueter just released an Honeynet paper on Web security called: Know your Enemy: Web Application Threats.

The paper is very good, and deals with all kinds of web threats such as SQL Injection and XSS. Of most interest to me were the Code Injection and Remote Code-Inclusion, as you remember we published a paper of our own this month on these specific issues in the Virus Bulletin magazine. The Honeynet paper deals with many issues other than these, and is most definitely recommended reading.

In our paper we linked to an older paper by Jamie Riden. These guys know what they are talking about.

Gadi Evron,
ge@linuxbox.org.

It don’t know exactly when it started…but, at some point a few years ago, network pen-tests started becoming 10% network scanning and 90% web application scanning. I guess it was around 2003 or so???? At any rate, I was working on a pen-test team for a large Fortune ^[1-9]{2}$ company and we ran out of vulnerable network apps. We were scared, since lack of vulnerable apps meant that the network pen-testing team was gonna lose staff, lose resources, or both. Not good. We knew that we had about 6 months until the current flaws made it through the Compliance team, out to the business units, down to the IT director, down to the first manager, down to the second manager, down a few more managers, and finally to the admin who would fix the bug in about 10 minutes (albeit 6 months late).

In a hysterical state, we tried the obvious. Yes, we elevated Traceroute and non-ICMP-filtering issues to High Risk. Bad move - we’re losing credebility.

So, in what can only be considered a move of sheer genius, we turned up our timeout values on Nessus, told it to recurse more than 20 pages into the webserver, and let the scan run for a few hours. OMG! We found flaws. XSS? “Could this be a ‘High’ Risk?”, we whispered amongst ourselves. SQL Injection? Oh Yes! We were ecstatic. For the first time in years, my wife heard me hollering ‘I’ve got root…errr Admin’ from the downstairs office. Our plate was full. We were feasting on hearty portions of web flaws. The compliance team had to double-up in staff. The scan team started working 5 days a week from home during scan window. Looking back, I think of these times as our ‘Salad Days’. Our blood wasn’t cold but our judgement was surely green…and autumn was coming….
(more…)

I’ve been a happy customer of my ISP BeThere for a few months now. Overall they’re great, they are quick to sort you out with your connection, their emails and other communications are very humerous and actually make good reading (I remember the routers documentation CD has a warning label reading something like “warning: geeky content inside”). When I signed up I managed to get the username root, this pleased me no end and I thought I’d finally found an ISP I want to stay with forever.

Finding the hole
Recently though a friend of mine was extremely bored and decided to nmap my IP address. He found, and told me, that I seemed to be listening on port 23, telnet. I was extremely puzzled by this, I haven’t port forwarded port 23, I would never use a telnet daemon for anything. It occured to me that it must be the router itself running the daemon. I telnetted to 192.168.1.254 and lo and behold it asked me to log in. I log in with default credentials (yes, I had never gotten around to changing those), which are Administrator:null
(more…)

There has been a trojan horse making the rounds, sending email informing people that the Australian prime minister suffered from a heart attack (which of course isn’t true).

Websense released a nice advisory on it:
http://www.websense.com/securitylabs/alerts/alert.php?AlertID=741

Gadi Evron,
ge@linuxbox.org.

We touched on this subject in the past, but recently Rich Kulawiek wrote a very interesting email to NANOG to which I replied, and decided to share my answer here as well –

I stopped really counting bots a while back. I insisted, along with many friends, that counting botnets was what matters. When we reached thousands we gave that up.

We often quoted anti-nuclear weapons proliferation sentiments from the Cold War, such as: “why be able to destroy the world a thousand times over if once is more than enough?” we often also changed it to say “3 times” as redundancy could be important. :>

Today, it is clear the bad guys can get their hands on as many bots as they need, or in a more scary scenario, want. They don’t need that many.

As a prime example, I believe that VeriSign made it public that only 200 bots were used in the DNS amplification attacks against them last year. Even if they missed one, two or even three zeroes, it speaks quite a bit as to our fragile infrastructure.
(more…)

Several users of Flickr.com noticed that there was wrong photos included to their photo galleries during the weekend.

Information posted to Flickr forum states that problems in cache servers enabled to see private, porn-type pictures too.

And how the users react: some users changed their passwords and some users just deleted the pictures appeared to their galleries!

The number of comments posted to the thread is worth of noticing - 900+!

As we already know, vulnerabilities are evolving. In the past, the worst case we could imagine was vulnerability in a service which we run on our own server. After 2000, increasing worm and dDoS trends in the vulnerability market changed our priority to the rest of Internet: Clients.When we remember the worms and dDoS attacks which paralyzed backbones, it’s clear that we expect the worst case from client threats.

The most popular vulnerability of this past week (I ignore MS-patches) seems to be SunOS telnetd. In IRC channels and security forums, people say “Woaaw! Hey! You heard that?” Everybody is talking about this.

Another vulnerability published this week got lost in the SunOS noise: uTorrent.
(more…)

Update:

Read this before reading this blog entry.

This was posted to bugtraq today. Let’s see what this is about…

Date: Thu, 15 Feb 2007 13:02:46 -0800
From: Zulfikar Ramzan
Subject: Drive-by Pharming Threat

We discovered a new potential threat that we term “Drive-by Pharming”. An attacker can create a web page containing a simple piece of malicious JavaScript code. When the page is viewed, the code makes a login attempt into the user’s home broadband router and attempts to change its DNS server settings (e.g., to point the user to an attacker-controlled DNS server).
Once the user’s machine receives the updated DNS settings from the router (e.g., after the machine is rebooted) future DNS request are made to and resolved by the attacker’s DNS server.

The main condition for the attack to be successful is that the attacker can
guess the router password (which can be very easy to do since these home
routers come with a default password that is uniform, well known, and often
never changed).  Note that the attack does not require the user to download
any malicious software - simply viewing a web page with the malicious
JavaScript code is enough.

We\’ve written proof of concept code that can successfully carry out the
steps of the attack on Linksys, D-Link, and NETGEAR home routers.  If users
change their home broadband router passwords to something difficult for an
attacker to guess, they are safe from this threat.

Additional details on the attack can be found at:
http://www.symantec.com/enterprise/security_response/weblog/2007/02/driveby_pharming_how_clicking_1.html

Thanks,

Zulfikar Ramzan

________________________________________

Zulfikar Ramzan
Sr. Principal Security Researcher
Advanced Threat Research
Symantec Corporation
- —————————————————–
- —————————————————–
This message (including any attachments) is intended only for the use of
the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law or may constitute as attorney

The main condition for the attack to be successful is that the attacker can guess the router password (which can be very easy to do since these home routers come with a default password that is uniform, well known, and often never changed). Note that the attack does not require the user to download any malicious software - simply viewing a web page with the malicious JavaScript code is enough.

We’ve written proof of concept code that can successfully carry out the steps of the attack on Linksys, D-Link, and NETGEAR home routers. If users change their home broadband router passwords to something difficult for an attacker to guess, they are safe from this threat.

Additional details on the attack can be found at:
Drive-by Phraming

Thanks,

Zulfikar Ramzan
__________

Zulfikar Ramzan
Sr. Principal Security Researcher
Advanced Threat Research
Symantec Corporation
www.symantec.com

In discussions of this issue, Fergie (Paul Ferguson) said, and I replied:

On Fri, 16 Feb 2007, Fergie wrote:
>
> I don’t know — I found this whole “report” somewhat dubious, if
> not downright opportunist: hasn’t this “vulnerability” basically
> existed since, like, forever?
>
> I write it off as marketing opportunism… among other things.

Well duh. Think RSA and a brand new idea they did a PR about - Phishing MiTM kit (think phishing: user >> fake site >> bank).

Nothing is really new in security, we have seen malware/etc. change the hosts file for years now, not to mention domain hijacking.

We have also seen wireless brute-forcing/etc./what-not.

The one thing about the folks at SYMC who did this release is that they actually know their ****. Meaning, someone took these two technology ideas and made something new from them, which is:
Break into wireless routers and put your DNS server in them for hijacking purposes. Symantec just reported it to us.

It’s cool, it’s “new” and it won’t be a huge problem quite yet.

I remember a thread from NANOG a couple of years back when I mentioned Google and all these other national/International wireless providers better be ready with physical operational folks that will track down rougeAPs, etc. Cop cars with triangulation devices?

It was a vulnerability waiting to happen which wasn’t exploited, meaning it didn’t get much attention. This is much like the days when bots weretrojan horses as botnets didn’t yet exist.

Wireless used to be used for hacking into a network-connected machine, now it is suddenly used for the sake of it being wireless. Still network-connected as a goal, but it is no longer just TCP/IP which playsthe game.

GOOD NEWS: these are DNS servers we can take-down. Fun, yet another escalation war.

Gadi.

This is very interesting, although not too exciting. Nice work by the guys at Symantec.

Gadi Evron,
ge@linuxbox.org.

Apple has released fixes for four vulnerabilities reported by Month of Apple Bugs (aka MoAB) in January.

The issues are buffer overflow in Finder when handling volume names, null pointer dereference in iChat’s Bonjour when handling drafted messages, format string vulnerability in iChat (related to AIM URL handler) and problem “UserNotificationCenter process running with elevated privileges in the context of a local user”.

Link to the advisory here:
docs.info.apple.com/article.html?artnum=305102

Very, very, funny

…and, very very true.  But, we all play the game, don’t we?

!Dmitry

A couple of updates and a summary digest of useful information shared from all around on this vulnerability, for those of us trying to make sense of what it means to our networks:

1. Sun released a patch (although it is not a final one). It can be found on their site
( http://sunsolve.sun.com/tpatches - thanks to Casper Dik of Sun, for those who have been following the discussion).

To quote: “the simplest possible fix on such short notice”:
Open Solaris source diff

2. If you haven’t already, I strongly recommend checking your network for machines running telnet, and more specifcially, vulnerable to this particular issue.

Several folks are speaking of third-party appliances running on Solaris, as well as some back-end VoIP devices that have been confirmed as vulnerable.

Apparently, telnet returns a different answer when this vulnerability is used. We are not sure yet, but Noam Rathaus brought up the option that it looks like the client responds with a “Won’t Authentication Option” to the server’s “Do Authentication Option”. This could perhaps be used to actively detect the “attack”.

3. If this solution is viable for you and you haven’t already, ACLing 23/tcp at the border or from your user space may not be a bad idea, if it won’t kill anything. At least for now.

4. Bleeding Edge (ex Bleeding Snort) released snort signatures for this:
Bleeding Threats Snort signature

Quoting:
——–
Chris Byrd has submitted an accurate signature for the exploit.
# Submitted 2007-02-12 by Chris Byrd
alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:.BLEEDING-EDGE EXPLOIT
Solaris telnet USER environment
vuln.; flow:to_server,established; content: .|ff fa 27 00 00 55 53 45 52
01 2d
66|.; rawbytes; classtype:attempted-user; reference:url,riosec.com/solaris-telnet-0-day; sid:2003411; rev:1;)
——–

4. An analysis of how this vulnerability works can be found here:
http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf

And blogs by Sun on how this happened and was fixed (thanks to Georg Oppenberg):
http://blogs.sun.com/tpenta/entry/the_in_telnetd_vulnerability_exploit
http://blogs.sun.com/danmcd/entry/how_opensolaris_did_its_job

And a fine explanation by Casper Dik on Bugtraq:
http://seclists.org/bugtraq/2007/Feb/0205.html

A bit of background:
http://blogs.securiteam.com/index.php/archives/814

And some on how corporations responded as we saw from our own client base:
http://blogs.securiteam.com/index.php/archives/819

Opinion:

Whatever my thoughts are on how silly, sad or funny this vulnerability is (quaint really), how they use telnet (?!) and how Sun should be smacked on the back of the head for it, I have to honestly admit Sun’s response and the level they were open to the community and industry on this without too many PR/legal blocks getting in their way are very encouraging, releasing information on the vulnerability, how it happened and why, a quick beta patch and even discussing openly on mailing lists.
I am in awe. Now it is time for others to follow their example.

This one, despite its simplicity and age, is going to be with us for a while.

Gadi Evron,
ge@linuxbox.org.

While the original AIX rlogin -froot vulnerability is celebrating its Bar-Mitzvah, a Solaris telnet vulnerability with the same exploit path surfaces.

Looking at the code almost makes you cry. It’s very likely that both the original AIX rlogin problem and this recent Solaris problem stem from the same bad AT&T UNIX code fragment.

Is it possible that nobody knew about this problem until today? I wouldn’t bet on it. (Update: After reading the explanation by Casper it seems it’s not the same bug, but a set of incredible coincidence. It also seems to be a new problem for Solaris 10 only. Good thing I didn’t really bet on it…)

Watching our customers at Beyond Security trying to deal with this issue was very educational. I can roughly stereotype them into three categories:

The first category are those that are well on top of their security problems. They do daily or weekly VA scans and are used to receiving reports that show only minor problems (what we call “low risk”). An open telnet port would be in this classification, so they usually already knew about Solaris boxes with open telnet - they can quickly go around and close them. I especially like those customers - they are proactive, and they are usually very proud of their network’s security (one of our customers says he looks forward to the periodic audits since his business unit always passed them with flying colors). It took years for those customers to reach this level, routinely running scans and fixing issues until they got to this stage - but now they are reaping the rewards, and when everyone runs around in patch Tuesday they fix the one or two problems that they need to fix. Yes, these organizations are rare - but I’m mentioning them to let you all know those unicorns exist.

The second category use our scanning box “whenever there are problems”. We usually get a call from them on an outbreak like this, asking “are you testing for this problem?” (answer: “yes, and if you’d be running scans on a daily basis like we recommend you’d already have a report about it”). They usually opt to scanning the entire network for just this problem, ignoring all others. It’s hard to blame them - lack of IT security resources, impossible operating demands, support for legacy systems all make their jobs so much harder. So those guys typically scanned their network for this specific problem, hoping there are no old, unmaintained boxes or ’surprise’ installations nobody knows about. Would a simple nmap do the trick here? Possibly, but for many having a PDF report that can be sent to management is the key. For others, the fact you can open a trouble ticket is valuable.

This group also opts for the workarounds, like blocking the telnet port. They worked harder, but got through the day.

The third group I feel really sorry for. These guys got up in the morning and heard there is a new Solaris 0-day. How many Solaris boxes do we even have on the network?

So they login to our box and do a quick datamining to see how many Solaris boxes are on the network and where they are. But hey, there is no data for network segment XYZ! (didn’t we tell you to scan everything? Sorry, I take it back - now is not the time for an “I told you so”). So the scan data is outdated - they haven’t done a scan for over a month and god knows what changed since then. Ok, lets run a quick scan on the entire network. Results come back and the room starts spinning - customers machines running Solaris that they have no control over. Backend machines that are untouchable. Even VoIP servers running Solaris with the telnet open. Oh yeah, it’s gonna be a long night.

So you see, there’s this grasshopper, who is not preparing for winter. Oh, you got the moral of the story already? good.

kcope has put on a short PDF paper on why the vulnerability in telnetd happens:

/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c
3198
3199 } else /* default, no auth. info available, login does it all */ {
3200 (void) execl(LOGIN_PROGRAM, “login”,
3201 “-p”, “-h”, host, “-d”, slavename,
3202 getenv(”USER”), 0);
3203 }

/usr/src/cmd/login/login.c
1397 break;
1398
1399 case ‘f’:
1400 /*
1401 * Must be root to bypass authentication
1402 * otherwise we exit() as punishment for trying.
1403 */
1404 if (getuid() != 0 || geteuid() != 0) {
1405 audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407 login_exit(1); /* sigh */
1408 /*NOTREACHED*/
1409 }
1410 /* save fflag user name for future use */
1411 SCPYL(user_name, optarg);
1412 fflag = B_TRUE;

As you can see the “Must be root to bypass authentication” should already rise some worries, but what is funnier that because we are requesting a different user than ‘root’ we actually get ‘root’ access, as login thinks we are already ‘root’, when its called by in.telnetd.

The recent telnetd vuln brings two things to mind.

First, as a QA guy myself, I imagine there’s some QA person at Sun saying “D’oh!”.

Second, it makes me think of the full-disclosure argument.

(Wait, doesn’t everything make you think of the full-disclosure argument? Moving on…)

For the sake of discussion, assume you’re against disclosing unpatched vulnerabilities under any circumstances. In this case, we have a fine example of how this might work. You have a perfect opportunity to keep things from yourself. Delete all the emails, blog posts, and news articles that might inform you about the problem. Ignore any IDS signatures and third-party patches. Ignore the fact that absolutely no exploit code is needed, and that any script kid, no matter how unskilled, can pull this hack off.

Don’t disable telnetd on your Solaris 10 machine. Wait for Sun to tell you there’s a patch.
That’s one extreme end of the disclosure debate spectrum. You can refuse to participate in the disclosure game on a personal level.

I can’t stop you.

Websense just released a blog post on how sites get defaced for malicious purposes other than the defacement itself, such as installing malicious software on visiting users.

This is yet another layer of abuse of web server attack platforms.

You can find their post here:
http://www.websense.com/securitylabs/blog/blog.php?BlogID=109

Gadi Evron,
ge@linuxbox.org.