Linux related stories

Broadband routers and botnets – being proactive

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”:

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:

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.


gadi evron,

It’s time to see iPodLinux PoC virus

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

Web Server Botnets and Server Farms as Attack Platforms

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.

Web Honeynet Project: announcement, exploit URLs this Wednesday

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! ]


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 ( )..

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), … | | 12 | http://m (4),
http://m (6),
http://m (2), | 11 | http://w

OpenOffice issued a WMF/EMF code execution fix

It appears that new security update has been released.

Red Hat adivsory is located here (rated as Important):

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

Several integer overflow bugs were found in the WMF file
processor. An attacker could create a carefully crafted WMF file that could
cause 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
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:

MIME Encoding Content Normalizer (SMTP gateway attacks counter-measures)

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).

ct: application/octet-stream
cd: attachment; filename=foo.dat
cte: base64

aa aa

perl segfault?

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:

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,

Plain life is just not random enough

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:
* 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:

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:

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