The Glider

On Monday, a number of Russian nationals got arrested for espionage against the US [1]. With all the talk and attention paid to cyber spies, spear phishing, APT and new high tech satellites and drones, it is almost refreshing to see that good old fashioned human spies are still used and apparently found valuable. Skynet hasn't taken over quite yet. However, the story has a few neat cyber security lessons.
Lesson 1: Encrypt your Wifi
The spies evidently used WiFi networks to communicate. However, instead of all of them to connect to a particular access point, they established Ad-Hoc networks. This idea is interesting in so far as it does make remote surveillance of the connection a bit harder. The FBI had to have a listening post close by in order to intercept the connection. It appears the FBI used to be parked close to coffee shops and such frequented by the spies in order to observe them meeting with their embassy contacts. The FBI was able to intercept the communication, and apparently used MAC addresses to track the participant. It is not clear if any kind of encryption was used for the WiFi connection. But Ad-Hoc networking would only allow for WEP unless encrypted chat software is used.
As a sub lesson one may take away that you should change your MAC address as a spy to avoid tracking. But it is not clear if this would have made a difference.
One neat side effect of this meeting method: The participants of the meeting never had to acknowledge each other visibly.
Lesson 2:Keep your password secure
The FBI followed these spies for a while already. A few years back, the FBI secretly searched the homes of some of the spies, copying various hard disks in the process. Small problem: The hard disk was encrypted. Luckily, an observant FBI agent noted a piece of paper during the search with a long number / letter combination. Turned out it was the password. This turned out to be critical as it allowed the agents to not only decrypt the hard disk, but after decrypting the hard disk the agents found steganography software and other encryption tools, as well as lists of web sites used to exchange steganographic messages.
Lesson 3:Obscurity != Security
The spies to some extend used steganography to exchange messages. These messages where encoded into an image, and then uploaded to various web sites. As explained above, the FBIwas able to obtain a list of these sites and the software used to encode them. However, at least according to some reports, the messages were not encrypted. Typically, if you want to do steganography right, first encrypt the message, then encode it in an image. In particular if you use standard software to perform your steganography. (Update:Some reports mention that the messages had been encrypted before encoding them into the images)
Lesson 4: Perfect forward security
Perfect forward security is an important cryptographic concept. You never want to use an old password to encrypt the new password. If you do, once an attacker figured out one password, they will be able to decrypt all future passwords. It appears that the spies frequently made arrangements about future meetings and communication protocols over insecure channels (like the ad-hoc wifi). In some ways this may also be considered as relying on obscurity again.
[1] http://newyork.fbi.gov/dojpressrel/pressrel10/nyfo062810a.htm

various other news reports like:
http://www.cnn.com/2010/POLITICS/06/28/russian.spying.arrests/index.html?hpt=T1

http://www.guardian.co.uk/world/2010/jun/29/russian-spies-uk-irish-passports

http://www.dailymail.co.uk/news/worldnews/article-1290475/U-S-charges-Russian-spies-FBI-swoop-Cold-War-style-espionage-plot.html

http://www.nytimes.com/2010/06/30/world/europe/30spy.html?hp

http://www.theregister.co.uk/2010/06/29/spy_ring_tech/

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

In my SANSFire presentation I described how and why to automate parts of the security testing process. The slides are posted here (handlers.dshield.org/adebeaupre/deBeaupre-SANSFire2010v011.pdf). Part of the process involves taking tool outputs, parsing them, and then importing the results to a database. In the example I am giving here we are taking nmap XML output, parsing it using a perl script and the nmap::parser (code.google.com/p/nmap-parser/) module, and then importing it to a MySQL database. The script I'm using is based on work by Paul Haas found here (www.redspin.com/blog/2009/10/27/nmap-database-output-xml-to-sql/). The table schema he uses is one of the better ones I have seen for nmap data storage. One of the major things the script lacks is the ability to parse nmap NSE output, still a work in progress. In any case the script is found here (handlers.dshield.org/adebeaupre/nmap_xml2mysql-v011.pl). The structure of the script is straight forward:
Main - reads command line arguments and calls the other functions

Usage - prints out a usage message if no command line arguments are provided

CreateTables - creats the database tables

Nmap_info - reads in the xml file and populates the tables

Db_output - outputs a success message
Unfortunately it needs some more work, but does the trick. I am more than open to suggestions, or better ways of doing things. Part II will be a script to import v2 .nessus files into a MySQL database, also in perl. Let us know if you use this script, something like it, or some other technique to manage security test data. Contact us or use the comment fields below.
Cheers,

Adrien de Beaupr

EWA-Canada.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Couple of days ago, a fellow handler Joel sent an obfuscated PHP script he acquired. Having a PHP script that is 100KB+ and pretty heavily obfuscated definitely sounds like something I'm interested in, so with couple of extra days I decided to give it some time. At that point in time I did not know that I'm looking at the master PHP script (albeit an old version) that is being used by the RogueAV guys.
I managed to acquire the very latest version of the script that is being used at the moment which provided me with some unique insight into how their operations work. So, I will publish a series of diaries analyzing various parts in the script in next couple of days/weeks (depending on feedback/free time etc). Let's get to work.
First step: poison search engines
If you have been following campaigns by the RogueAV guys you probably noticed that they very quickly poison search engines with the latest events/keywords. The poisoning part is, of course, completely automated and partially done by the script I will talk about.
The scripts that are used are almost exclusively set on compromised web sites. They are mainly interested in web sites running Apache with PHP, of course. It looks like in many cases they are abusing incorrect installations or known vulnerabilities such as open TinyMCE editors. In any case, their goal is to install couple of PHP scripts on those compromised servers. The scripts will allow them to setup poisoning campaigns, offer redirections to other sites serving RogueAV, but at the same time to also conceal their activities as much as possible since they don't want the real owner to find out that his site has been compromised.
This means that the attackers modify the web site, but in such a way that the web site continues to operate normally, unless special parameters/keywords are used! So there are probably thousands of such compromised web sites which the attackers are not using at the moment. Since the scripts allow automatic updates they can use them at any time and configure for a specific campaign in a matter of seconds.
The following figure shows how the SEO part works, with steps described below. While I was researching this I was in contact with some colleagues in CA who posted an article about this back in January (great work by them!) with analysis similar to mine, but the script I analyzed is the latest version used at the moment. You can read CA's article here.




This is what is happening:

In first step, the master CC server(s) use Google Trends to collect keywords that are currently hot (interesting).
The master CC server(s) now use various methods to spam links to compromised sites containing specially crafted parameters with such keywords.
Now search engine crawlers either find spammed links or just crawl the compromised web sites again (in which case they get a bit different response I will cover that in the next diary).
When the crawler accesses a compromised web site, the master script immediately contacts the CC server and asks what to return to the crawler. The CC server creates a web page in real time containing a lot of references to the asked keyword, as well as links to other compromised web sites!
The custom web page is returned to the crawler and cached locally.

In step 2, besides spammed links, search engine crawlers will also visit compromised web sites. Now an interesting thing happens that helps poison the results: when the script detects a visit from a search engine crawler, but without the required poisoned parameters, the PHP script by the attackers will return the original requested web page, but with concatenated links to other compromised web sites that it has in the local database. This local database can be updated automatically through an interface on the PHP script so the attackers can update the database constantly as well.
Here we can see such a web page requested first time normally (normal user agent, main index.html requested) and second time pretending to be a search engine crawler. Notice the difference in size of the returned file:
$ ls -l index.html*

-rw-rw-r-- 1 nobody nobody 38383 Jun 26 12:53 index.html-normal

-rw-rw-r-- 1 nobody nobody 95703 Jun 26 14:47 index.html-crawler
And this is what gets appended in raw HTML:




(compromised sites deliberately removed as they are still live).
By doing this they are getting all compromised sites linked to each other, hopefully increasing their rating with various search engines. See the style setup as display:none? This makes sure that if someone renders this web page through a browser that the inserted links will be invisible. They are not invisible to a crawler, of course.
Redirecting to RogueAV
Now, after all this poisoning, if a normal user (plain user agent) accesses the web site directly, he will just get the same cached web page that the crawler got. However, if the web site is accessed by clicking the link that appeared as a search result in any search engine (Google, Yahoo, Bing ...), such a request will have a corresponding referrer set and the script will redirect the user to another web site that will serve (you guessed it) RogueAV, as shown in the figure below:




This time they are trying to get the user to install it by displaying an ActiveX error.
With this I will end with the first diary. In the next diary I'll go deeper into analyzing interesting details found in the script (will be posted on Thursday).
If you would like me to go into more details with anything let us know through our contact form.
--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

If you are looking for some activity on this sunday afternoon (2:37 PM GMT-5 here in Medelln, Colombia), I strongly suggest you to review the excellent paper published by Gustav Rydstedt, Elie Bursztein, Dan Boneh from Stanford University about clickjacking attacks and how to put in place proper defense against them.
Download the paper here: http://seclab.stanford.edu/websec/framebusting/framebust.pdf
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

---------------

Jim Clausing, jclausing --at-- isc [dot] sans (dot) org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Last week I published a diary on DNS Sinkhole. If you are looking at tracking the clients that are redirected into your sinkhole address, the method I have been successfully using is with a multipurpose relay tool, called socat (SOcket CAT) .
In order to capture the host information (true website name) the client is attempting to access, I have been using socat to simulate various web server ports (80, 443, 7070, 8080, etc) and you can capture that information with your favorite IDS or using a simple Snort signature. It is much easier then to figure out what site the client was attempting to connect to and figure out if the client is already infected. A direct client outbound connection might indicate the client is attempting to contact a CC and already compromised while a web site redirect is potentially malicious but blocked by the sinkhole.
Socat as a Web Site Simulator
socat TCP-LISTEN:80,bind=192.168.25.5,fork,reuseaddr,crlf SYSTEM:
This first socat example is used to simulate a web server listener on TCP port 80. The same line can be copied several times with different ports using the same address to simulate your web port list.
socat openssl-listen:443,bind=192.168.25.5,fork,reuseaddr,verify=1,cert=/home/certs/sinkhole32.pem PIPE=echo Media Center PC 6.0)
Accept-Encoding: gzip, deflate
Host: 00g00.ru
Connection: Keep-Alive

The socat binary is included in the DNS Sinkhole ISO and these two example are in the rc.local script. More information is available about socat's other features here.
-----------
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

This paper was written by Bert Hayes. Bert Hayes is a security professional at the University of Texas. When Bert originally wrote this paper, he submitted it to me for the SANS Gold process, and I helped push the paper in the right direction, however, while it was an excellent paper and well written, it didn't really meet the criteria we were looking for.
However, I thought Wow, what a great idea, what a great paper. I am sure a lot of organizations will benefit from this.
Of course Bert nor the Internet Storm Center can be held liable for any damage you to do a computer while using this, (just to get that disclaimer out of the way), and it's recommended that if you are going to use the contents of the computer you are doing the investigation on for a prosecution, don't use this. (Changing the state of the data on the drive during a forensic investigation is generally frowned upon.)
But, as I said, this is a great paper and you should definitely download it and give it a read.

http://security.utexas.edu/consensus/How_To_UTIRD2.pdf

Enjoy
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

According to Mozilla, the following updates are in Thunderbird 3.1:


New Quick Filter toolbar
New Migration Assistant
Saved Files Manager
Several fixes to improve upgrading from Thunderbird 2
Several design improvements and corrections to the interface
Stability, memory, and password handling improvements


So if you use Thunderbird, start your upgrade engine now. Available here. Or if you wan the local language version for our Non-English speaking customers: here.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Otto sent this article into us, and while it's not generally security related, I do feel as if it's interesting to the readers and it does relate to computers and automation in general.
Remember when the stock market (DJIA) took a dip on May 6th, 2010? Lost about 600 points? Here is a very interesting write up of the crash with charts:
http://www.nanex.net/20100506/FlashCrashAnalysis_Intro.html
There is also a Complete Text link on the page where you can read the full write up. Interesting stuff.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.