Archive

Articles taggués ‘VPN’

IP leak affecting VPN providers with port forwarding

27/05/2022 Comments off

Vulnerability “Port Fail” reveals real IP address

We have discovered a vulnerability in a number of providers that allows an attacker to expose the real IP address of a victim. “Port Fail” affects VPN providers that offer port forwarding and have no protection against this specific attack. Perfect Privacy users are protected from this attack.

This IP leak affects all users: The victim does not need to use port forwarding, only the attacker has to set it up.

We have tested this with nine prominent VPN providers that offer port forwarding. Five of those were vulnerable to the attack and have been notified in advance so they could fix this issue before publication. However, other VPN providers may be vulnerable to this attack as we could not possibly test all existing VPN providers.

Details about the leak

The attacker needs to meet the following requirements:

  • Has an active account at the same VPN provider as the victim
  • Knows victim’s VPN exit IP address (can be obtained by various means, e.g. IRC or torrent client or by making the victim visit a website under the attackers control)
  • The attacker sets up port forwarding. It makes no difference whether the victim has port forwarding activated or not.

The IP leak can then be triggered as follows:

  1. Victim is connected to VPN server 1.2.3.4
  2. Victim’s routing table will look something like this:
    0.0.0.0/0 -> 10.0.0.1 (internal vpn gateway ip)
    1.2.3.4/32 -> 192.168.0.1 (old default gateway)
  3. Attacker connects to same server 1.2.3.4 (knows victim’s exit through IRC or other means)
  4. Attacker activates Port Forwarding on server 1.2.3.4, example port 12345
  5. Attacker gets the victim to visit 1.2.3.4:12345 (for example via embedding <img src=”http://1.2.3.4:12345/x.jpg”> on a website)
  6. This connection will reveal the victim’s real IP to the attacker because of the “1.2.3.4/32 -> 192.168.0.1” vpn route.

The crucial issue here is that a VPN user connecting to his own VPN server will use his default route with his real IP address, as this is required for the VPN connection to work. If another user (the attacker) has port forwarding activated for his account on the same server, he can find out the real IP addresses of any user on the same VPN server by tricking him into visiting a link that redirects the traffic to a port under his control.

Also note that due to the nature of this attack all VPN protocols (IPSec, OpenVPN, PPTP, etc.) and all operating systems are affected.

Mitigation

Affected VPN providers should implement one of the following:

  • Have multiple IP addresses, allow incoming connections to ip1, exit connections through ip2-ipx, have portforwardings on ip2-ipx
  • On Client connect set server side firewall rule to block access from Client real ip to portforwardings that are not his own.

 

Source: Perfect Privacy

Categories: Réseau Tags: , ,

How to Protect Yourself from NSA Attacks on 1024-bit DH

04/05/2022 Comments off

nsa attacksWhen NSA gets you worrying

In a post on Wednesday, researchers Alex Halderman and Nadia Heninger presented compelling research suggesting that the NSA has developed the capability to decrypt a large number of HTTPS, SSH, and VPN connections using an attack on common implementations of the Diffie-Hellman key exchange algorithm with 1024-bit primes. Earlier in the year, they were part of a research group that published a study of the Logjam attack, which leveraged overlooked and outdated code to enforce “export-grade” (downgraded, 512-bit) parameters for Diffie-Hellman. By performing a cost analysis of the algorithm with stronger 1024-bit parameters and comparing that with what we know of the NSA “black budget” (and reading between the lines of several leaked documents about NSA interception capabilities) they concluded that it’s likely NSA has been breaking 1024-bit Diffie-Hellman for some time now.

The good news is, in the time since this research was originally published, the major browser vendors (IE, Chrome, and Firefox) have removed support for 512-bit Diffie-Hellman, addressing the biggest vulnerability. However, 1024-bit Diffie-Hellman remains supported for the forseeable future despite its vulnerability to NSA surveillance. In this post, we present some practical tips to protect yourself from the surveillance machine, whether you’re using a web browser, an SSH client, or VPN software.

Disclaimer: This is not a complete guide, and not all software is covered.

Web Browser

To make sure you’re using the strongest crypto, you have to look at the encryption algorithms (or cipher suites) that your browser supports. There’s an excellent tool, How’s My SSL?, that will test your browser’s cipher suite support. The relevant area of the page is the bottom, Given Cipher Suites. You want to make sure that you don’t see the text “_DHE_” in the list of ciphersuites – although the Elliptic Curve variant of Diffie-Hellman, represented by suites with “_ECDHE_” is okay. It is important to note that there is a trade-off here: removing your clients support for “_DHE_” ciphers will eliminate the risk of this attack, but it may also remove Forward Secrecy support altogether for some sites. Here’s how to remove those “_DHE_” cipher suites if you still have them:

Firefox

(tested with 40.0.3)

Open a new tab, enter “about:config” into the location bar and hit the “Enter” key. If you get a warning page, click “I’ll be careful, I promise!” This will bring you to the Firefox configuration settings. In the search bar up top, type “.dhe_” and hit the “Enter” key. This should result in two settings being displayed: “security.ssl3.dhe_rsa_aes_128_sha” and “security.ssl3.dhe_rsa_aes_256_sha”. Double-click both of them to change the value from “true” to “false”.

ff

Now, if you refresh the How’s My SSL page, the “_DHE_” ciphersuites should be gone!

Lire la suite…

OpenVPN Documentation

25/03/2022 Comments off

Source: OpenVPN official documentation

OpenVPN daemons (JSON format):

./sacli VPNStatus

Show the number of users currently connected to the VPN:

./sacli VPNSummary

Show the status of internal Access Server services:

./sacli status

Stop internal Access Server services:

./sacli stop

Start/restart internal Access Server services:

./sacli start

The ‘start’ command is smart in the sense that if the Access Server
is already running, and you modified the configuration via
the Config DB, only those services whose parameters are changed
will be restarted. Note that if you modify any parameters in
the Access Server bootstrap configuration file
(/usr/local/openvpn_as/etc/as.conf), you will need to do a full unix
restart in order for those settings to take effect.

Also note that the start/stop commands above don’t actually start or
stop the Access Server daemon itself, only internal services
within the daemon. To start/stop the access server daemon itself,
use the traditional unix syntax:

Start the Access Server daemon:

/etc/init.d/openvpnas start

Stop the Access Server daemon:

/etc/init.d/openvpnas stop

Restart the Access Server daemon:

/etc/init.d/openvpnas restart
Categories: Réseau, Système Tags: , ,

Split OpenVPN configuration files

24/03/2022 Comments off

Source: npm

Splits OpenVPN (.ovpn) files into separate files for private key, user+ca certificates and tls-auth key, for use with network-manager in debian/ubuntu.

openvpn-config-splitter can be installed using npm:

# NPM:
npm install -g openvpn-config-splitter
# Install globally
$ npm install -g openvpn-config-splitter
# Run it, specifying your unsplit OpenVPN configuration file
$ ovpnsplit path/to/some/config.ovpn
# Config is now split into separate files, new configuration
# linking to the split files has been generated
$ ls path/to/some
ca.crt  client.key  client.ovpn  client.split.ovpn  ta.key  user.crt
var fs = require('fs'),
 configPath = '/some/path/to',
 splitter = require('openvpn-config-splitter');
 
var paths = {
 'caCert': configPath + '/openvpn-ca.crt',
 'userCert': configPath + '/openvpn-user.crt',
 'privateKey': configPath + '/openvpn-private.key',
 'tlsAuth': configPath + '/openvpn-tls.key'
};
 
fs.readFile(configPath + '/config.ovpn', function(err, originalConfig) {
 if (err) {
 console.error('Could not read file (' + err.path + ')');
 process.exit(1);
 }
 
 splitter.split(originalConfig, paths, function(err, parts, missing) {
 if (err) {
 console.error(err);
 process.exit(1);
 }
 
 /**
 * `parts` now contain the matched parts of the config + new config
 * (caCert, userCert, privateKey, tlsAuth, config)
 *
 * `missing` is an array containing the parts that were NOT found -
 * use this if you want to warn the user or fall back if you require
 * a specific part to be present
 */
 // Want to write the split files? 
 splitter.writeToFiles(parts, paths, function(err) {
 if (err) {
 console.log(err);
 process.exit(1);
 }
 
 console.log('Hooray, we split the files and wrote them to disk!');
 });
 
 });
});
Categories: Réseau, Système Tags: , ,

Arethusa le test

19/03/2022 Comments off

Un nouveau test VPN publié par le blog du VPN. Ici les VPN sont testés , configurés par créer une base de données la plus fiable possible. Arethusa à ses adeptes, il a déjà été l’ objet d’ une publication par alipaxe. Comme toujours on essayera d’ insister sur les particularités: méthode de configuration – protocole rare – tutos techniques.

Arethusa est proposé par S6N.org: une organisation internationale à but non lucratif fondée en 2003, pour promouvoir liberté d’expression sur Internet. La juridiction dont dépend ce VPN est celle des îles Seychelles: « Applicable jurisdiction for the handling of personal data is the Republic of Seychelles. Only Seychelles authorities can ask us to reveal your personal details. The only details we have about you are the ones you entered yourself. » Le whois de S6N.org confirme l’ enregistrement de nom de domaine de  l’ organisation à Victoria, capitale de cette République. Bien que le site soit en Anglais, le support technique et l’ interface sont en français. Lire la suite…