SSH and SFTP Servers on OpenBSD 6.1 – Part 1

Share

Introduction

In this tutorial, we will continue to learn about OpenBSD 6 by setting up a SSH server alongside a SFTP server. As most of you may know, SSH is essential for remote administration. Nowadays, more and more network administration is done remotely and it is more important than ever to properly configure and secure outward facing services. Additionally, we often need to transfer files, either for patches, reuse configuration files or install additional applications, especially if your OpenBSD server is not Internet-accessible. In a later post of this tutorial, we will use a specific form of port knocking to hide the presence of our services to background scans to prevent brute-force and dictionary attacks. However for now, we will setup our SSH and SFTP servers. A companion video is available on YouTube.

Overview

While OpenBSD makes it easy to enable SSH and SFTP, we will do some additional preparation for increased robustness. First we will create the appropriate users and groups and then we will install each of these services within their own chroot directory to limit damage should ever these services get compromised. Once that done, we’ll enable the SSH daemon, including the internal SFTP service, and make sure they are accessible and working properly. Once done, we will customize and harden their configuration. For the purpose of this post, we will assume that you have a fresh install of OpenBSD 6.1 as if you just finished the steps listed in this previous tutorial, i.e. SSHD was NOT enabled during installation.

Creating the Chroot Directories

While optional, enclosing your services in chroot, especially the one exposed to external hosts, is an excellent security practice. Ideally, they should even be on their own partition. To keep the scope of this post on SSH and SFTP, we will simply create a new tree node and setup our chroot containers from there:

We will then install the basic required files from the OpenBSD 6.1 CD to create our chroot. Within the SSH chroot:
# mount -t cd9660 /dev/cd0a /mnt

And unarchive the base packages unto our chroot:

In any chroot, we need the /dev  directory to exist and populated with the required sub directory. Fortunately, OpenBSD makes it easy for us to do so using the MAKEDEV script:

Finally, we will link the shared libraries required by most programs with out chroot and enable our new sandbox:

The chroot directory doesn’t require any special action since it doesn’t need to execute any program. The only thing left to do now is to set the ownership and permissions:

Creating the users and groups

This step is optional if you intent to have this server only for your own personal use or a very few selected people. However if you expect your user base to grow and have different permissions, having groups makes it so much easier to manage your server while ensuring tighter controls on permissions. We’ll create 2 groups: ssh-users and ftp-users. Within each of these groups, we will have a single user. We’ll create ssh-user for accessing the SSH service and ftp-user for accessing the SFTP service by using the useradd and groupadd commands:

While adding groups requires no explanation, it is important to note that ftp-user requires some specific parameters. Namely, the shell is set to /sbin/nologin. FTP are not required to use a shell and are limited to the FTP server, which is actually integrated into the SSH daemon.

Setting up SSHD

In many cases, sshd will have been enabled during installation and automatically starts at boot. If you are unsure, you can quickly verify if the sshd is running:

If there’s no output, then the sshd is not started. Let’s quickly check that SSH works by first enabling and starting the service, and then testing it out. To enable the service, use the rcctl command:

Then start the daemon to actively listen for SSH connections:

And confirm that the SSH daemon is listening by using netstat:

And now, lets try to connect to our SSH service using the IPv6 loopback interface using  # ssh root@::1 . After entering your password, you should be greeted in your new shell.

Without much work, you already have a solid SSH server available within minutes with OpenBSD. However, let’s configure it further to our needs. We’ll stop the server for now:

First configuration items we will change is to disable remote root login and allow users part of the ssh-users group to access SSH. All configuration for the SSH and SFTP services are done thru the /etc/ssh/sshd_config file. Before editing it, you may want to make a backup to your /root directory. We will edit using the vi editor:

The first change we will make is to prevent the root account from using SSH. We’ll do this by setting the PermitRootLogin option to no. If the line is commented, uncommented it by deleting the ‘#‘:

Next we’ll specify SSH to use our specially created chroot sandbox for any SSH connection by adding or setting the following property:

And the last thing for now, we’ll allow only users part of the ssh-users and ftp-users groups to use SSH by setting this line in our configuration file:

Save you configuration and let’s restart our SSH server using rcctl to confirm these basic settings:

First, we should not be allow to login as root anymore. If you try to login as root, you should get denied access:

Excellent. Now let’s log as ssh-user and confirm we are in our chroot sandbox:

Setting up the SFTP Server

Now that we have a basic SSH server running, we’ll configure the basic SFTP server as well. The SFTP server is provided through the SSH daemon and as such, is configured via the sshd_config file as well. This is because SFTP is actually the FTP protocol tunneled through the SSH protocol. As such, the sshd includes a FTP server within itself. To enable SFTP, we simply need to tell sshd to

And ask sshd to use the internal-sftp subsystem by modifying the Subsystem sftp option to Subsystem sftp internal-sftp. Save the file again and restart the SSH server:

And let’s test our SFTP server.

You may run into a few issues here if something is misconfigured.  To help you diagnosed the problem, consult the /var/log/authlog. For example, you encounter this rather cryptic error message when trying to connect to your ftp server:  "Received message too long 1416128883" . This is often caused by the server producing an unexpected output message. In the context of OpenBSD. This may be caused by the banner send by default which is contained in /etc/motd, in which case you need to specify  Banner none in sections relating to the SFTP server.

You may also get disconnected as soon as you attempt to reach your SFTP server, in which case you will get an error message stating:

In which, you can check the log file to troubleshoot your problem

In this case, OpenBSD is complaining about the permissions set on the SFTP chroot directory. If they are too lax, sshd will simply refuse to allow connections to it. As such, make sure you have the appropriate directory permissions.

At this point, you have a server with SSH and SFTP enabled. You can be stop here if this configuration fills you needs, otherwise we can still customize furthermore the servers.

Additional Settings

For one thing, you may want to disable IPv4 if it’s not needed and allow only IPv6. In your sshd_config file, we will do so by setting the AddressFamily to inet6:

Another useful customization depending on your line of work is to change the SSH port. In this case, we will change the port to 443, which is usually reserved for HTTPS connections. The reason for that is that if I need to reach back to my server from a network with connection restrictions, local connections to remote hosts via port 443 is usually allows. In other words, if a firewall is blocking outbound connections to port 22, establishing as SSH connections via port 443 will usually be allowed, unless there are protocol restrictions in place. In any case, we can change the port with:

Depending on your level of paranoia, we can also tighten some controls relating to connectivity to mitigate brute-force or dictionary attacks:

The MaxStartups property is interesting and warrant further details. From the man page:

it specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection.

It allows for unauthenticated connections to be denied at random in order to mitigate noisy scanning or DDoS from the Internet. In the example above, we specified the value “5:60:10“, which means that if 5 unauthenticated connections are alive, further unauthenticated connections will be refused with a 60% probability. If 10 unauthenticated connections are established, all further attempts will be denied.

And to further ensure additional security controls, confirm that the following parameters are commented so that the defaults value be used:

Authentication Modes

Another feature that you may want to customize based on your needs is how you or your users connect to the server. Three modes are usually considered to do so:

  • PubkeyAuthentication: requires your client to provide a public key in order to connect to your SSH client. If you have a limited number of users which connects from the same location, this is probably the best option. However if you intent to connect to your SSH server from multiple hosts, you would have to bring your public key with you.
  • PasswordAuthentication and ChallengeResponseAuthentication are very similar in practice. PasswordAuthentication request the client to provide a password via the SSH connection while the ChallengeResponseAuthentication can ask the client one or more question via a TTY. However in most cases, ChallengeResponseAuthentication is configured to ask a password and the only real difference is that the requesting client must type the password rather than providing it via the command line.

For example, the following command would not work with PasswordAuthentication set to “no” and ChallengeResponseAuthentication  set to “yes“:

That being said, there are ways to provide SSH password via the command line, such as using the sshpass package. There is therefore little difference between them. In this example, we configure these parameters as follow:

Hashing Known Hosts Files

When a client connects, the SSHD will store information about the client in the known_host file, which is located in ~/.ssh/. This file will contain the hostname of the client, its IP address and its key. This information is stored in plain text. An additional step to make the life of an intruder harder should your server get compromised is to obfuscated the data in this file be hashing its contents.

The listing above shows the contents of the file before hashing it. To tell SSHD to hash newly added data of the known_hosts file, we will add the following the HashKnownHosts line  in ~/.ssh/config.

From now on, all data added will be hashed. Should you need to hash data already residing in this file, use the command below:

We now have a very solid SSH server. You still have to remain vigilant about new vulnerabilities that may pop up for SSHD or one of its component. In the second part of this series, we’ll cloak our SSH server using some form of port knocking. For now, let’s just tweak our SFTP server slightly. Before that, let’s restart our server.

Final Touch on the SFTP server

We previously set our FTP chroot readonly, but we might want to upload some files to it. If we try it right now, we’ll get the following error message:

We’ll finish this tutorial by adding an upload directory and make it writable to the users of the ftp-users group:

Conclusion

We’ll conclude this part of the tutorial for now. In this post, we detailed how to enable a SSH server on OpenBSD 6.1. We also enabled SFTP and securely configure each service to increase robustness. That being said, nothing is impossible and vulnerabilities may remain: keys can be stolen or confiscated, misconfiguration of other services may be present or malicious internal users may still abuse the system. If you’re a network admin, make sure logging is enabled and more importantly, that logs are analyze either via software or if you have time, manually. In the next part of this tutorial, we will enable a form of port knocking to hide our SSH service to scanning from external hosts. By doing so, we will prevent detection by roaming threats and prevent or at least greatly limit effectiveness of brute force and dictionary attacks against our server.

References

Additional Readings

Reversing the Trendnet TS-402

Share

The Trendnet TS-S402 is a discontinued network storage enclosure that was sold to individuals for personal data storage. Like every Internet-of-Things (IoT) device, it runs on software programmed and/or configured by the manufacturer before shipping it to the end-user, i.e. the firmware. Firmware versions 2.00.10 and below of this particular device have a serious vulnerability allowing remote root access . This target thus provides an excellent exercise for reverse engineering while providing an example of a vulnerability that is unfortunately way too common in IoT: backdoors by design. In this post, we will introduce Binwalk and provide the background necessary to do the same on a large variety of firmware for consumer-level devices, using the TS-S402 as a practical example. A video of this post is also available.

Trendnet TS-S402
The Trendnet TS-S402 Network Storage Enclosure (from trendnet.com)

The Trendnet TS-S402

Before reversing any device, it’s important to actually understand its functionalities, components and any other piece of information that may help along the analysis of its firmware. The webpage of the product highlights the following features:

  • Access your data from the Internet (FTP) and on your local network
  • Microprocessor: Marvell 88F5182
  • IDE Controller: ITE IT8211F
  • Real Time OS: Embedded Linux (Kernel Version 2.4.25)
  • File Protocols: Microsoft Networks (CIFS / SMB) Internet (HTTP 1.1) FTP, FTPS (SSL FTP)

Why are these facts important? Not all of the will be useful, but some may provide you with an overall idea of what to expects once you start analyzing the firmware file. In many cases, especially with consumer-level devices, reversing firmware is fairly straightforward and common open-source tools will do the heavy lifting for you. But if you move on to industrial firmware, awareness of the device is important as you will be faced with unheard operating systems, libraries and unknown file formats. In this case, we can expect to see a Linux-based Operating System (OS) hosting a HTTP and FTP server, along with Samba compatibility. The manufacturer is even generous enough to provide the underlying microprocessor, which can be helpful when conducting even deeper analysis for vulnerabilities in the binaries.

Reversing the Firmware

The vulnerability we are looking for is present only in versions 2.00.10 and below of the firmware, which you can download from the repository of the company. Unzip the archive and you’ll to obtain the following files:

  • TS-S402_FW_2_00_10.bin
  • readme.txt
  • release_TS-S402.txt
  • REMOTE_PACKAGE_2_20.bin

It’s always a good idea to read the release notes and README files. Doing so may save you time and headaches trying to figure things out. If you’re into bug hunting, the release notes can be useful to list the changes and patches included in this version, providing potential hints to patched vulnerabilities of previous versions.

The two “.bin” files contain the programs and OS of the device. In this case, based on the filename, the TS-S402_FW_2_00_10.bin is the main firmware file and thus, the focus of this post. The first step is always to check if we can determine the file type by using the file command. If we are lucky, it is a known file type and some application exists to extract the relevant files/information out of it.

However we are not so lucky. The file command returns “data”, which means it found the file to be binary data without any specific structure or format. So we will need to use a more powerful tool: binwalk. Binwalk is very useful reverse engineering toolkit which can analyze and extract files from unknown binary files. However note that it can also return quite a few false positives. The only way to recognize them is with experience and trial-and-error. If not already done, install binwalk with apt using  sudo apt-get install binwalk and run the following command:

The command above asks binwalk to check out the TS-S402_FW_2_00_10.bin file and try to find interesting files or structures inside it. We use the “-x lzma” argument to eXclude any findings about LZMA-compressed data: these are false positives in this case. You will obtain the following result:

In other words, there seems to be a 32-bytes header followed by a GZip-compressed file. At this point, we want to carve this gzip file out of the binary file for further investigation. You can use the dd command to do so, but binwalk provides the -e option to Extract files for you.

The carved files will be outputted to a directory labelled _TS-S402_FW_2_00_10.bin.extracted, in which you will find a single file called 20, which is the offset of the file in the larger firmware. Using the file command again, we now get a more interesting result:

This time, the file command clearly recognized a TAR archive, meaning we can simply untar the file with the command below:

This archive contained even more files: a uImage and a filesystem:

  • uImage
  • rootfs.armeb.squashfs

The uImage is the boot loader of the firmware and you will often find this file or something similar in most Linux-based firmware. Analysis of the uImage will be left for another post. For now, we are interested in the filesystem contained in rootfs.armeb.squashfs, which as its name implies, is a SquashFS. To access the files it contains, we can normally use the unsquashfs tool, however in this case doing so won’t work:

Depending on how the file system was created and the development software used, it may have incompatibilities with the way unsquashfs expects the file system to be structured. As a workaround, we will use Sasquatch, which is more flexible when it comes to extracting file from non-standard Squash file systems. Clone the project and build the code by following the instructions n the README.md file, or you can download a pre-compiled binary for Ubuntu and variants. Now let’s try again carving out the files, but with Sasquatch this time by typing  ./sasquatch rootfs.armeb.squashfs . After a while, Sasquatch will extract all files in the squashfs-root directory, at which point you can finally access the files hosted on the targeted device.

Find the Backdoor

There is a fairly obvious backdoor hidden in the file system. Go ahead and explore the files and configuration and see if you can find it. When you are ready read on.

Most commercial devices are accessible remotely via a web interface. The web server and its contents are therefore a good starting point to hunt down potential vulnerabilities. On the TS-S402, the web application is located in the /home/httpd directory. The partial listing of the contents of this directory is included below:

As you can see, one of the web page is named “backdoor.html”; quite an obvious indicator that something is wrong. If you look at the webpage, you’ll notice that it seems to enable the telnetd daemon, thus allowing Telnet connections to the device. Unless specially configured to be blocked in the network firewall, this web page should be accessible to anyone on the network, potentially anyone if facing the Web. All that is missing right now is credentials to access the device. Let’s look at /etc/shadow to see if we can potentially figure out the default password for the root account:

Well, there isn’t any password setup for the root account. So in other words, anyone who can access the backdoor.html page on the device can enabled remote Telnet connections, and then login as root. While I haven’t tested it as I do not own this device. this vulnerability was previously confirmed and reported.

Conclusion

This post provided an example of reversing the firmware of a consumer-level IT appliance to locate vulnerabilities allowing remote access to the device. Such vulnerabilities may seem trivial an unimportant until a botnet such as the Mirai botnet comes along and use tens of thousands of these vulnerable devices – which are rarely updated – to DDoS websites across the web. Hence the need to understand the techniques and skills require to pwn these devices in order to defend them.

See Also

Learn More

 

 

Useful T-Shark Commands for Intelligence Gathering from Network Traffic

T-Shark is practically the command-line version of Wireshark. It has the same basic capabilities but with the added flexibility offered by using the command-line to process outputs and send them to other applications. Below I’ve enclosed some of the commands that I have found myself reusing over and over again.

Share

Introduction

T-Shark is practically the command-line version of Wireshark. It has the same basic capabilities but with the added flexibility offered by using the command-line to process outputs and send them to other applications.  Furthermore, T-shark is ideal for large PCAP files which Wireshark may have difficulty digesting, especially since it has to load the entire contents of the file prior to any kind of filtering. As such, T-Shark is my main tool for analyzing PCAPs. One of my main use is to extract specific information from the network for investigation. Below I’ve enclosed some of the commands that I have found myself reusing over and over again.

Contents

When analyzing PCAPs, I’m mostly concern to locate anomalies based on intelligence on various current actors. I’m especially interested in analyzing covert channels for specific indicators that are usually indicative of malicious traffic. These often include typos in popular URLs, weird looking domain names, emails with suspicious attachments or certificates with random fields. To extract the data, I’ve used the following T-shark commands:

Extracting URLs from HTTP Requests

In the example above (and the ones below), I’m reading network traffic from a offline PCAP file, which is why the -r lab1.http.pcap parameters is present. The -T fields specify to output the value of the fields specified with the -e parameter. For each field you want to output, you specify it using the -e <field> option. The -R <filter> is the filter to apply to the traffic. For example in this case we filter only HTTP traffic. Sort and Uniq are Linux applications used to sort the output of a program and remove duplicate entries.

Extracting Filenames from FTP uploads

Extracting URLs from DNS Requests

Extracting Recipients’ Email Addresses of Inbound Emails

Extracting Senders’ Email Addresses of Inbound Emails

Extracting Subjects of Inbound Emails

Extracting Source URLs of X509 Certificates

Extracting Information from X509 Certificates

Netminecraft

Since these proved useful on many occasions, a simple Bash script called Netminecraft was made to automate their usage.

Usage

To split a larger PCAP file into protocol-specific PCAPs, use;

Note that the scripts only passes the contents of <protocol> to
t-shark. As such, you can specify any Wireshark filter to extract
even more specific information, for example:

However avoid filters with spaces as the current version of the
script does not manage spaces. The results will be saved in a file
in the current directory as <protocol>.pcap, for example http.pcap.

To mine for data relating to a specific protocol, use;

The output file will contain text data that have been sorted and in
which the doubles will have been removed using ‘uniq -i‘, i.e.
we ignore the case of the items.

Examples

The example above will extract the URLs of all the DNS queries found
in the file dns.pcap and will output a list of URLs in dns.queries.txt:

Conclusion

Learning to use T-shark has many advantages that can increase efficiency, security and flexibility. It allows for scripting the extraction of data and storage into databases from which further analysis can quickly be done for anomalies. In this short post, we have listed some examples of how T-shark can be used, but it barely scraps the surface.

References

T-Shark Manual, The Wireshark Network Analyzer, https://www.wireshark.org/docs/man-pages/tshark.html, accessed on 2015-02-24

A small and quick introduction to ARP poisoning

Share

This article won’t be about something new nor something extraordinary for any experienced computer security or even the average hacker, but since I’ve been ask this question quite often by some of my friends, I decided to explain how to sniff passwords from a network.  Moreover, I’m well aware I haven’t been writing anything for a while, and I want to get back to it once all my personal matters are resolved. I’ll concentrate on WEP wireless networks since they are almost certain to be cracked easily. Although those a deprecated, there are still used in many household as the out-of-the-box default configuration, so it’s still pertinent in my opinion. Then I will explain the ARP (Address Resolution Protocol) poisoning attack, which will be used to intercept packets between the target and the Internet.

Attacking the WEP wireless network

Packets in a WEP network are encryted, so in order to sniff packets off from it, you’ll first need to acquire the WEP key. This can be done easily with a wireless network adapter that supports monitor mode and the aircrack suite. For the adapter, I’m using the Linksys  Compact Wireless-G USB adapter, model no WUSB54GC. Plug your adapter into a USB connector and boot up your machine. Once you have booted up, make sure Backtrack or any other distribution has detected your adapter:

ifconfig rausb0 up

and then put the adapter in “Monitor Mode”

iwconfig rausb0 mode monitor

The goal of a WEP attack is to capture as many initialization vectors (IVs) as possible. IVs are random numbers used with a either 64, 128 and 256-bit key to encrypt a stream cipher. Those are used so that two exact same plain text do not produce the same ciphertext. The problem with WEP is that IVs are very short, and on a busy network, the same vectors get reused quickly. The IV is 24 bit long, therefore there are 16 777 216 possibilities1. Moreover, changing the IV for each packet is optional. The keys are also quite short, therefore opening the possibility of finding the key with some brute force calculation. No matter what is they key length, you will just need more packets.

The WEP protocol then use the randomly generated IV, the WEP key and pass it throught the RC4 cipher to produce a keystream. The keystream is then XORed with the plain text stream to produce the cipher text, as shown in the picture below:

WEP Encryption Schema
WEP Encryption Schema (from Wikipedia)

So basically, if you get many packets with the same Ivs, different ciphertext, you can now try to brute-force the WEP key. And to get those packets, you need traffic on the network. Now if there are already some people connected and surfing the web, you can easily capture packets and replay them to get more IVs, otherwise, you need to generate the traffic yourself.

Once you’ve tell airodump to capture IVs, we will use aireplay to generate more traffic, and therefore capture more IVs quickly. If you look at the airodump screen, you’ll see it capturing packets.

Once you have the key, you can finally start the poisoning process. As you have seen, I have not detailed how to crack a WEP network as it is widely described all over the net. You can find find good video tutorials from InfinityExists here and here. The last 2600 issue also had a good article about it.

The ARP poisoning attack

The concept behind this is simple. ARP is the protocol that maintains network devices tables up-to-date by associating an IP address with a MAC address. The problem with ARP is that it doesn’t really care about who answered, it will gladly update the tables from whoever says so. Most of the time, it won’t even ask. So the idea behind the attack, is to send the client an ARP answer saying “hey, I’m the gateway, send stuff to me” and a second ARP answer to the real gateway saying “hey there, I’m this guy, send me his stuff”. Then you just have to relay the packets between the victim and the gateway.Those schemas are more simply to understand:

Schema of an ARP Poisoning Attack
Schema of an ARP Poisoning Attack

In Linux, the rerouting can be done using the following iptables commands:

iptables -t nat -A PREROUTING -i <interface> -p tcp –dport <port> -j REDIRECT –to-port <redirection port>

iptables -t nat -D PREROUTING -i <interface> -p tcp –dport <port> -j REDIRECT –to-port <redirection port>

I’m showing those commands because you can do a lot with those. Many web applications such as some Flash applications use RTMP (Real-time messaging protocol) to control web applications, which run locally.  Flash server send commands to the application using message. Using those commands, you can filter the packets send or receive from the Flash server. Simply use a sniffer first, then locate which packets you wish to drop, alter or whatever.

For example, some sites gives you samples of live music or videos for 30 seconds, then nag you to pay. Using a sniffer, analyze the traffic and find that RTMP Invoke packet that closes the connection with the server. Code a quick proxy that will let all packets go to the flash application except for the connection closing RTMP packet. Then use the commands above to redirect traffic to your proxy.

00 03 0d 4f c0 6d 00 11  20 a8 32 8b 08 00 45 00 …O.m..  .2…E.
00 b2 7e 52 40 00 78 06  d0 a1 50 4d 74 05 43 c1 ..~R@.x. ..PMt.C.
ab 3e 07 8f d0 d8 9b a6  b0 eb ea 61 49 3d 80 18 .>…… …aI=..
fe 4a 76 52 00 00 01 01  08 0a 00 ef a6 d0 02 43 .JvR…. …….C
f4 32 43 00 00 00 00 00  76 14 02 00 0f 63 6c 6f .2C….. v….clo
73 65 43 6f 6e 6e 65 63  74 69 6f 6e 00 00 00 00 seConnec tion….
00 00 00 00 00 05 02 00  57 32 30 38 20 46 72 65 …….. W208 Fre
65 63 68 61 74 20 61 63  74 69 76 69 74 79 20 74 echat ac tivity t
69 6d 65 6f 75 74 2e 20  49 66 20 79 6f 75 20 77 imeout.  If you w
65 72 65 20 61 20 6d 65  6d 62 65 72 2c 20 74 68 ere a me mber, th
65 20 66 72 65 65 20 63  68 61 74 20 77 6f 75 6c e free c hat woul
64 20 6e 6f 74 20 74 69  6d 65 20 6f 75 74 21 20 d not ti me out!

Example of a RTMP Invoke packet to close a connection.

Of course you could just use Ettercap, which does exactly what have been mentioned above. Start Ettercap with the following:

sudo ettercap -G -W 128:p:25AAAAC18DEADDADA433332B65

This will open the graphical interface (-G), that is if you have installed the GTK interface to Ettercap. -W specify to listen for wireless networks and to use a 128-bit key with key found earlier. I don’t know what the p is really for. You can also use the text mode.

Ettercap
Ettercap

Then select Sniffing > Unified Sniffing > select on which interface you want to sniff. Then start the sniffing: File > Start Sniffing. Now let’s specify which targets you wanna sniff. Go to Hosts > Scan for hosts. That will locate the hosts on the current network. Then popup the hosts list, Hosts > Show Hosts List.

Ettercap - Hosts Found on the Network
Ettercap - Hosts Found on the Network

On the list, add the router to target 2 and the hosts you wanna sniff to target 1. Only one step left: MITM > ARP poisoning.  Select Sniff Remote Connections > OK.

Ettercap ARP Poisoining Options
Ettercap ARP Poisoining Options

Then you wait for users to connect to pages like MySpace or Hotmail etc…and Ettercap will find out the sensitive information for you.

See also:

Wireless Networking, Praphul Chandra, Alan Bensky, Ron Olexa, Daniel Mark Dobkin, David A. Lide, Farid Dowla

RFC 826 – Ethernet Address Resolution Protocol, David C. Plummer, November 1982, http://www.faqs.org/rfcs/rfc826.html

Wired Equivalent Protocol, Wikipedia, http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

Ettercap, http://ettercap.sourceforge.net/

LATimes: Agent.BTZ Might be Concerted Cyber-Attack

Share

The Los Angeles Times reports that the reports about the Agent.BTZ worm spreading to the U.S Army networks might be a coordinated attacks originating from Russia[1].

The U.S Central Command is now infected with the worm and a high-classified network has been hit also.

It is unclear if the author of the article thinks that an infection is the same things as an ‘attack’ though. From the article:

“Military electronics experts have not pinpointed the source or motive of the attack and could not say whether the destructive program was created by an individual hacker or whether the Russian government may have had some involvement.”

This infection has been report at the beginning of the month. This might just be sensationalism ofrcomplete ignorance from the author who might think than an infection by a worm made in Russia is a deliberate attack.

Officials would not describe the exact threat from agent.btz, or say whether it could shut down computers or steal information. Some computer experts have reported that agent.btz can allow an attacker to take control of a computer remotely and to take files and other information from it.

Then maybe they should just call Symantec or F-Secure or even better, Google it…or this if they are having a hard time..

See also:

“U.S Army Infected by Worm”, Jonathan Racicot, Cyberwarfare Magazine, November 11, 2008, http://cyberwarfaremag.wordpress.com/2008/11/20/us-army-infected-by-worm/

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to Furl


[1] “Cyber-attack on Defense Department computers raises concerns”, Julian E. Barnes, Los Angeles Times,  November 28, 2008, http://www.latimes.com/news/nationworld/iraq/complete/la-na-cyberattack28-2008nov28,0,230046.story (accessed on November 28, 2008)

U.S Army Infected by Worm

Share

Wired reports that the U.S Army network is under assault by a variant of the SillyFDC worm called Agent-BTZ [1]. In order to restrain the infection, the U.S. Strategic Command has ban the use of every portable media on its network, this include USB keys, CDs, flash cards, floppies etc… Both the SIPRNet and NIPRNet are affected by this directive.

The SillyFDC worm infects systems through replication, i.e. by copying itself to various locations such as these folders[2]:

  • %System%
  • %Windir%
  • %Temp%
  • %UserProfile%
  • %ProgramFiles%
  • %SystemDrive%
  • %CommonProgramFiles%
  • %CurrentFolder%

Computer Virus Looming
Computer Virus Looming

It will also try to copy itself to any drive connected to the machine by scanning drives A:\ to Z:\, which is why the U.S Army is banning the use of portable media for the time being.  According to F-Secure who first discovered the worm[3], the variant in question will also create these files[4]:

  • %windir%\system32\muxbde40.dll
  • %windir%\system32\winview.ocx
  • %temp%\6D73776D706461742E746C62FA.tmp
  • %windir%\system32\mswmpdat.tlb

It will then install itself into the registry to make sure the worm starts every time the computer is booted. It will also attempt to download a JPG file from http://worldnews.ath.cx/update/img0008/[REMOVED].jpg and create an AUTORUN.INF file on each drive on the computer, which contains the following:

[autorun]
open=
shell\open=Explore
shell\open\Command=rundll32.exe .\\[RANDOM].dll,InstallM
shell\open\Default=1

[RANDOM] is a randomly generated filename for the malicious DLL. Each time a new partition or a new drive is plugged in, Agent.BTZ will infect it immediately.

The SillyFDC worm doesn’t have any payload, as it only replicates itself through systems it finds using physical medias only. But its variant, the Agent.BTZ is a known Trojan dropper. A dropper is the kind of Trojan that will look to download and execute other malware. It’s surprising that it found its way into the U.S Army network. So that might be a tip for any worm/Trojan writer: add physical media replication to your malware like in the good ol’ days before e-mail, as it seems sending it by e-mail or click jacking is pretty well filtered in military networks, but peripherals such as USB keys are still often used by personnel. And this will surely open the eyes of the network admins of the U.S Army: scan anything plugged into the network.

Also, Graham Cluley, senior technology consultant at Sophos advises:

“… that users disable the autorun facility of Windows so removable devices such as USB keys and CD ROMs do not automatically launch when they are attached to a PC”

With whom I agree.

Update:

Since so many people asked me about this worm, I looked deeply into Internet and found this code, which seems to be part of the script of the Silly FDC worm (that’s the best I could do for now). This script basically copy files from one directory to another, renames the core of the worm and put it into another directory and add registry keys. I cannot confirm this as I found this on an Indonesian blog, so if anyone can look into this, please let me know. Thank you. Blog : http://morphians.wordpress.com/category/uncategorized/

See also:

“US Army bans USB devices to contain worm”, John Leyden, The Register, November 20, 2008, http://www.theregister.co.uk/2008/11/20/us_army_usb_ban/ (accessed on November 20, 2008)


[1] “Under Worm Assault, Military Bans Disks, USB Drives”, Noah Shachtman, Danger Room, Wired, http://blog.wired.com/defense/2008/11/army-bans-usb-d.html (accessed on November 20, 2008)

[2] “W32.SillyFDC”, Symantec, http://securityresponse.symantec.com/security_response/writeup.jsp?docid=2006-071111-0646-99&tabid=1 (accessed on November 20, 2008)

[3] “Troj/Agent-EMB”, Sophos, http://www.sophos.com/security/analyses/viruses-and-spyware/trojagentemb.html (accessed on November 20, 2008)

[4] “F-Secure Malware Information Pages: Worm:W32/Agent.BTZ”, F-Secure Corporation, http://www.f-secure.com/v-descs/worm_w32_agent_btz.shtml (accessed on November 20, 2008)

Cyber Espionage : The Triggerfish

Share

ArsTechnica had some bits of information how the triggerfish has been used to retrieve information from cell phones such as the electronic serial number (ESN), phone numbers and other information without the users’ knowledge and without the help of the telephone providers[1]. It was used back in the 90s by the FBI to track legendary hacker Kevin Mitnick[2].

When cell phones are on, they automatically look for cell sites around them in order to connect to the telephone company network. It will then connect to the one having the strongest signal, as it means a better signal. The triggerfish antenna is a high-powered cell site simulator to which any cell phone near enough will connect, as they will consider it as a normal cell site. Once the mobile registers to the triggerfish and the user wants to make or receive a call, the mobile will send the mobile identification number (MIN), which is actually the phone number, the ESN, cell site data, which contains the channel used and sub-geographical location all the incoming and outgoing data of the caller. It will also contain the outgoing or incoming MIN.  According to the documents released by the ACLU, the triggerfish is able to display the following:

“If the cellular telephone is used to make or receive a call, the screen of the digital analyzer/cell site/simulator/triggerfish would include the cellular telephone number (MIN), the call’s incoming or outgoing status, the telephone number dialled, the cellular telephone’s ESN, the date, time and duration of the call, and the cell site number/sector (location of the cellular telephone when the call was connected)[3]

The same document also writes that this device may be able to intercept the contents of the communication if the option is enabled. It’s important to note that the cell phone must be used to receive or send a call (SMS or web also) in other to for the triggerfish to work, as data about the location of the phone will be send in every data packet send and received by the user. This is how organization can track people using cell phones. Since mobiles always need to find new cell sites as the user moves around, it needs to exchange geographical information with the phone in order to locate the cell sites nearest to the mobile.

As told above, the antenna needs to be stronger than the local cell site in order to pickup the registration of the mobiles. Therefore it needs a lot of power and a high-gain. It also needs equipment such as a digital analyzer in order to make sense of the data intercepted by the triggerfish. And for tracking, it needs to be mounted on a truck to follow the signal of course.

There is a way for everyone to build something almost similar as the triggerfish by using an IMSI catcher. An IMSI catcher can be used to intercept GSM phone calls and use the same tactics as the triggerfish: by simulating a cell site. It will then relay data to a genuine cell site in the area. To do that, the IMSI catcher will need a SIM card and will then appear to the genuine cell site as a mobile phone. In other words, the IMSI catcher acts as a man-in-the-middle between the mobile phone and the genuine cell site.

representing the man-in-the-middle attack using an ISMI catcher
Diagram representing the man-in-the-middle attack using an ISMI catcher(4)

Even if it works in the same way as a triggerfish, the IMSI catcher has some serious drawbacks, among others[5]:

  • “It must be ensured, that the mobile phone of the observed person is in standby mode and the correct network operator is found out. Otherwise, for the Mobile Station, there is no need to log into the simulated Base Station.

  • All mobile phones in the catchment area have no access to the network. Incoming and outgoing calls cannot be patched through for these subscribers.

  • […] Since the network access is handled with the SIM/USIM of the IMSI Catcher, the receiver cannot see the number of the calling party. Of course, this also implicates that the tapped calls are not listed in the itemized bill.

  • The assignment near the Base Station can be difficult, due to the high signal level of the original Base Station.”

IMSI Catchers can be found online. They are sold by Rohde & Schwarz. You could buy the GC128 GSM Communication Unit R&S and apply the firmware to transform it into an ISMI catcher.

See also:

Electronic Surveillance Manual“, U.S Department of Justice, June 2005

IMSI Catcher“, Daehyun Strobel, Chair for Communication Security, Ruhr-Universität Bochum, July 13, 2007


[1] “FOIA docs show feds can lojack mobiles without telco help”, Julian Sanchez, ArsTechnica, November 16, 2008, http://arstechnica.com/news.ars/post/20081116-foia-docs-show-feds-can-lojack-mobiles-without-telco-help.html (accessed on November 18, 2008)

[2] “Computer hacker Kevin Mitnick”, Michael Cooke, Essortment.com, 2002, http://www.essortment.com/all/kevinmitnickco_rmap.htm (accessed on November 18, 2008)

[3] “Electronic Surveillance Book : XIV Cell Site Simulators/Digital Analyzer/Triggerfish”, Electronic Surveillance Unit, Department of Justice, June 2005, p.40

[4] “IMSI Catcher”, Daehyun Strobel, Chair for Communication Security, Ruhr-Universität Bochum, July 13. 2007, p.14

[5] Ibid. p.16

Survey Points to Energy Sector at Risk of Cyber Attacks

Share

A survey of 200 leaders from the critical infrastructure industries revealed that the energy sector is the most likely to be victim of a cyber attack. The survey was completed by IDC was conducted in August and October in Canada, the U.S and Europe[1].

The reasons to explain this phenomenon are the cost, apathy and government bureaucracy according to the survey. Also, industries are adding more and more possible access points to the internal network by connecting new sensors, meters and other equipment to their networks.

“]Percentage of respondents prepared and not prepared by industry sectors

Of course, energy industries networks are valuable targets, and would probably be the first victims in a case of a full-scale cyber attack. And as the events of 2003 shown[3], only a few power plants need to go down in order to create chaos on a wide region.

If costs are the main factor to wait before securing networks, security is not likely to be in the priorities of managers during the economic crisis that’s coming on the horizon. Unfortunately, those who take the risk of not hardening their security now may pay the price later…And according to Rick Nicholson, research vice president for IDC’s Energy Insights:

“Most utility CIOs [chief information officers] believe that their companies will be compliant with relevant standards, but still have a long way to go before being adequately prepared for all cyber attacks.”

Another interesting point, all these news come right after a newly president-elect enters the Whitehouse… see Whitehouse Hacked by Chinese Several Times, Both U.S Presidential Campaigns Hacked.


[1] “Survey: Critical infrastructure risks cyber attack”, Miya Knights, IT PRO, November 10, 2008, http://www.itpro.co.uk/608067/survey-critical-infrastructure-risks-cyber-attack (accessed on November 11, 2008)

[2] “Energy industry at risk of cyberattack, survey says”, Elinor Mills, November 11, 2008, http://news.cnet.com/8301-1009_3-10094382-83.html?part=rss&tag=feed&subj=News-Security (accessed on November 11, 2008)

[3] “Blackouts cause N America chaos”, BBC News, August 15, 2003,  http://news.bbc.co.uk/2/hi/americas/3152451.stm (accessed on November 11, 2008)

Whitehouse Hacked by Chinese Several Times

Share

An unnamed senior US official has declared to the Financial Times that the Whitehouse computer network was victim to numerous cyber attacks from China. According to the same official, the attackers had access to e-mails for short periods of time[1].

The unclassified network of the Whitehouse was breach numerous times by the attackers, which may have stole information. The sensibility of the information accessed is not specified, but since it was on the unclassified network, no data of value should have been viewed by the hackers. The attacks were detected by the National Cyber Investigative Joint Task Force, an agency created in 2007 and under the FBI[2].

No one from the American and Chinese sides commented on this event. This declaration comes amid many cyber attacks performed in previous years also and every time, blamed on the Chinese or Russians. In 2007, the Pentagon claimed to have been hacked by the cyber division of the People’s Liberation Army (PLA)[3]. It has been known for a while not that China has developed advanced cyber warfare capabilities and has gain a lot of experience.

It has been known for a while not that China has developed advanced cyber warfare capabilities and has gain a lot of experience in that domain.
It has been known for a while not that China has developed advanced cyber warfare capabilities and has gain a lot of experience in that domain.

[1] “Chinese hack into White House network”, Demetri Sevastopulo, The Financial Times, November 6, 2008, http://www.ft.com/cms/s/0/2931c542-ac35-11dd-bf71-000077b07658.html?nclick_check=1 (accessed on November 7, 2008)

[2] “New US National Cyber Investigative Joint Task Force Will Be Led by FBI”, ILBS, April 28, 2008, http://www.ibls.com/internet_law_news_portal_view.aspx?id=2044&s=latestnews (accessed on November 6, 2008)

[3] “Pentagon: Chinese military hacked us”, Lewis Page, The Register, http://www.theregister.co.uk/2007/09/04/china_hack_pentagon_leak/ (accessed on November 6, 2008)