Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Remote log injection on DenyHosts, Fail2ban and BlockHosts
From: "Daniel Cid" <daniel.cid () gmail com>
Date: Thu, 7 Jun 2007 11:55:28 -0300

Hi Tavis,

Reply inline.

On 6/7/07, Tavis Ormandy <taviso () gentoo org> wrote:
These aren't exactly "0-day", I discussed several of these attacks last
year, such as CVE-2006-6301, and informed the authors that there were
undoubtedly more attacks against these tools. This topic is a favourite
rant of mine, as the software itself is simply fundamentally flawed.

These "log injection" attacks are nothing new, I know, but what CVE-2006-6301
and CVE-2006-6302 talks about are injecting the ip address in the user name
field. Both fail2ban and denyhosts were patched against it, but what I used
was the "bad protocol" log message to inject the data (as I say in the article).

So, well, I think it is 0-day, since these tools were still vulnerable
and patches
were just released:


Also, I showed that instead of just inserting arbitrary IP addresses to
the hosts.deny file, you can also add the "all" keyword, causing the box to
be completely locked (bypassing access lists).

Even unprivileged local users are usually permitted to create arbitrary
log entries (eg, using logger), which will match any regex you can
create. Even if that wasnt the case, obtaining data from untrusted
sources, where remote unauthenticated attackers can manipulate the
content with few restrictions, is clearly not a great idea.

That's the very "flawed" concept of IDS (or IPS). Where you obtain data from
untrusted sources and report the attackers or in the case of IPS, block
them. Theorically, you can do the same think with NIPS, by attacking
specific udp signatures (or tcp ones that do not require the full handshake)
and blocking fake ip addresses. But that's not the point of discussion, since
I agree with you (it is very dangerous). Every form of automated response have
serious risks.

There are better options, such as just ignoring the log noise
from these weak password scans. If you're concerned your users may
select passwords that can be easily guessed, use cracklib, jtr,
passwordqc, etc. This is a far superior solution.

* No additional privileged code is exposed to remote attackers.
* No risk of false positive banning legitimate users.
* No number of bad logins need to be permitted before action.

If you really do insist on parsing log entries created by remote
unauthenticated users as root, and realise how dangerous that is, the
only sane solution is to parse btmp (documented in utmp(5)).

That's  a good solution, no doubt about it. Regarding parsing utmp, the
issue is that you can not do it from a centralized location, which you can
with your syslog (not that syslog is any safer, but that's another issue too).

Thanks, Tavis.


Daniel B. Cid
dcid ( at ) ossec.net

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]