Re: Remote log injection on DenyHosts, Fail2ban and BlockHosts

["Daniel Cid" <daniel.cid () gmail com>]

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:

http://www.aczoom.com/tools/blockhosts/CHANGES
http://www.ossec.net/en/attacking-loganalysis.html#patches

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.


Thanks,

--
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/