A Linux expert is defending the way Debian Project leaders handled a recent security breach that took down the servers of the 10-year-old open source effort.
Jay Beale, lead developer on the Bastille Linux project and a consultant at JJB Security Consulting & Training, told internetnews.com that it’s impossible to secure any server connected to the Internet, and it’s even more difficult for an open source project like Debian, which has a large group of developers accessing the servers.
But he said the steps Debian Project administrators took before the breach were key to slowing any damage the attack caused before detection.
As internetnews.com first reported on Nov. 21st, administrators of Debian, an operating system using the Linux kernel that is popular among Linux enthusiasts, had to take down four of its servers handling Web searches, bug tracking, mailing lists and security updates after an intruder gained root level access on those machines.
The administrators were able to get most of the services up and running three days later on mirrored sites
“The Debian project has been pretty smart and made their machines more
restrictive than others based on its purpose,” Beale said. “That was a
really good move — taking machines, considering their purpose and
configuring them so they only allow what access to what people should be
required for that purpose. That specialization is one of the best
things you can do to protect servers.”
Using a program that collects data passing through a network, called a
sniffer
login information off the personal computer of one of Debian’s
developers and use it to logon to one of the project’s servers, klecker.
After gaining entry, the attacker was able to run an exploit giving
him/her superuser access to the server. To further cover up the trail,
the attacker used a program called TESO’s Burneye Protection to encrypt
the true purpose of the program, thus evading firewall filters,
anti-virus software and intrusion detection systems.
After doing so, the attacker then employed a hacker tool called the
SucKIT root-kit, a kernel level application that sits in place of
/sbin/init, loading malware
running the real /sbin/init” (the first program an operating system
loads in Linux) with its own. From there, it was almost an easy matter
to similarly take over three other Debian servers by using the same
techniques and abusing one necessary trust relationship between the
machines.
But Debian Project administrators said two of its machines were
installed with an Advanced Intrusion Detection Environment (AIDE)
program that was able to look past the SucKIT application. AIDE found
that the /sbin/init file had been replaced and produced a log to warn
administrators.
The attacker was able to gain access to the machines through a known
vulnerability in the Linux kernel. In September, a bug was found that
overwrote kernel memory using an integer overflow in the brk system
call, giving an attacker full control of the kernel memory space and the potential to alter any value in memory.
Software vendors didn’t consider the vulnerability a vulnerability at all, so didn’t issue a security advisory. The vulnerability was actually just a missing piece of code that checks for correct input values, but many system administrators unaware of the
possible hole. The problem has since been fixed with the release of
Linux 2.4.23 last weekend, and a separate security advisory by the
Debian Project, Debian Security Advisory (DSA) 403.
For the time being, until all services are up and running again on
secured machines, all developer accounts have been suspended and
security certificates used between the machines removed.
Joey Schulze,
Debian Project stable release manager, told members in an e-mail Monday
that it’s uncertain when all services would be available again. He also
told developers worried about their own machines being compromised to
run a program called “chkrootkit” and monitor the output.
The methods used by the attacker lead Beale to believe the breach was
not a prank caused by a script kiddie — a neophyte computer user who
relies on applications like SucKIT to do all the work — but by someone
more skilled than most in hacking into systems.
But at the same time, the event has provided a check on the steps Debian Project administrators are taking to ensure the compromise is completely out of the system before
resuming operations, such as disabling every developer account and taking
out the secure shell SSH
machines, even though it means any public work is now effectively on
hold. Administrators also ensured that the Debian OS in the archives was not modified, which could have caused major headaches down the road.
“They’ve been taking very good measures, I’m impressed with their
ability to organize that much and both store that data in other places
and check it,” he said.
