Well, it happened that one user would connect to his shell account
at his ISP now and then, and that shell server was compromised. Unfortunately,
the user had the same password on both systems, and the cracker was
able to log onto this extremely important machine because of it. The
user never noticed that his account was being used from strange locations.
Now
the good news is that, since the machine was kept very up to date,
the cracker wasn't able to instantly leverage his shell access to
get root access. He twiddled around all over the place trying to find
something that could be attacked, and didn't find a thing. He too
was likely monitoring vulnerability mailing lists and IRC channels,
looking for anything that could be used, but nothing came of it.
A few months later, a bug was discovered in software that included
a program named /usr/sbin/buggy[1].
This program was suid (set-user-id) root which means that when it
is run it has an effective user id of root, regardless what user actually
launched it. Such programs need to be very secure due to the elevated
privileges.[2]
| On The Scene At Search Engine Strategies |  Our WebProNews editor, Garrett French will be reporting live from the Search Engine Strategies Conference in Chicago. Look for interviews from representatives from all the major search engine companies.
|
Getting back to /usr/sbin/buggy, this program turned
out to have a vulnerability. When it was invoked with a carefully
crafted environment, a buffer could be overflowed, and an attacker
could run commands as root. This, obviously, is bad.
Naturally, the machine's administrators upgraded the package as soon
as possible, and went about their business.
A few days later, they saw some interesting messages in their syslogs:
Dec 6 00:00 hst buggy[1930]: unable to parse ;g+gsz_zi.i|vDj2^qvCsOTD_b|SXD=DrmR^L+q
Dec 6 00:01 hst buggy[1957]: unable to parse ^F9LkKqg0NhYe[w|]]f-U=9d*f[gN!g^
The administrators had log monitoring tools running on this host,
and any anomalies were sent to them in email. The next day they investigated
the mysterious messages, and found (through a Google search, no doubt)
that they were the logs that would be created if the older version
of buggy were being exploited.
They quickly checked to make sure that their version was up to date,
and it was. They tried the exploits themselves to see if they could
reproduce the log messages:
jdoe$ ./exploit_buggy
==> Command to execute: /usr/bin/id
==> Setting environment variable
==> Running buggy
buggy: attempt to exploit vulnerability in version x.y.z detected.
buggy: this attempt has been logged.
# tail -500 /var/log/messages | grep buggy
Dec 6 09:31 hst buggy[20518]: attempt to exploit env bug by user jdoe
foiled
Dec 6 09:31 hst buggy[20518]: time to get out a can of whoop-a**
So, the software was clearly not vulnerable to the exploit, yet the
earlier logs seemed to indicate that it was. They left things alone
for the night, and decided to check on it in the morning.
Sure enough, the next morning there were more similar logs
Dec 6 23:40 hst buggy[12113]: unable to parse j_D^}qu^PLcnKvqjpH`x_
Dec 6 23:49 hst buggy[12189]: unable to parse xpEhh|=wnQ~tL|8e^k}
They thought that, perhaps, there was a new bug in the software that
wasn't publicly known yet. So, they decided to change the permissions
on buggy:
# ls -la /usr/sbin/buggy
-rwsr-xr-x 1 root root 29128 Nov 29 12:13 /usr/sbin/buggy
# chmod go-rx /usr/sbin/buggy
# ls -la /usr/sbin/buggy
-rws------ 1 root root 29128 Nov 29 12:13 /usr/sbin/buggy
Now the program could only be run as root, and should be safe from
any users. The next morning, what should happen to be in their logs
but yet more intrusions:
Dec 7 04:09 hst buggy[31203]: unable to parse bv,?cC!sFod`hys
Dec 7 04:54 hst buggy[32895]: unable to parse }hcj:j!Ul'kyaf$x}CI>|
Dec 7 04:54 hst buggy[32896]: unable to parse lv|3_t`avgfO3},y
What was going on? /usr/sbin/buggy could only be run by root. Presumably,
there'd be no reason for the attacker to attempt an exploit if they
were already running as root.
In a last ditch effort, they deleted the entire package.
# dpkg -P buggy
# ls -la /usr/sbin/buggy
ls: /usr/sbin/buggy: No such file or directory
There! Now that'll fix the problem, right?
Unsurprisingly[3],
the next morning there were more logs, and lots of other changes that
indicated someone had indeed been messing around the system as root,
presumably by exploiting the buggy program to gain said root privileges.
So, the question is, of course, how did the user manage to exploit
'buggy', in spite of all the steps the administrators took?
- Upgrading to secure version
- Removing global execute permissions
- Removing the program itself
If you think you have an answer, write me an email (send to me, do
not reply to the list software, please) with your thoughts. I'll send
the closest, best, or most well worded answer a copy of Hacking Linux
Exposed, 2nd Edition. I'll post the answer in December.[4]
NOTES:
[1]
Real pathname removed to protect the innocent, and because I can't
remember what it was any more
[2]
Programs only need a suid or sgid bit when they need to have access
to something not available to the invoking user. For example /bin/ping
needs to have root access in order to send ICMP packets. You should
never add a suid or sgid bit to a program unless you really really
know the security ramifications of it.
[3]
Otherwise it wouldn't be a very challenging contest, now would it?
[4]
Yes, I'll have another post between now and then.
About the Author:
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building
Linux VPNs. He's having twin girls (Yikes!) and you can help shape
them for life! Go to http://www.ifokr.org/bri/name-the-twins.cgi to pick your favorite name
from the possibilities! Brian can be reached at brian@hackinglinuxexposed.com.
Read this newsletter at: http://www.linuxpronews.com/2003/1210.html |
|
| From the Forum: | | Linux servers vulnerable |  I know this may be inviting flames but please resist that temptation. I post this not to claim that Linux is evil but solely to provide additional evidence that no OS is ever completely secure: ... |
 |
">
By
Brian Hatch