Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

CryptoStorm filtering web traffic.

Looking for assistance with a cryptostorm connection issue? Post here & we'll help out. Also: if you're not sure where to post, do so here & we'll move things around as needed. Also: for quickest support, email our oddly calm & easygoing support reps at support@cryptostorm.is :)

Topic Author
Pentester908

CryptoStorm filtering web traffic.

Postby Pentester908 » Thu Jan 12, 2017 8:05 pm

Hey All,

I'm a pentester who uses Cryptostorm to conduct authorized tests. While doing a nmap scan with scripts, I received the following output:
SF:<title>Access\x20Denied</title>\
SF:r\n</head>\r\n<body>\r\n<h1>Access\x20Denied</h1>\r\n<p>Cryptostorm\x20
SF:recently\x20implemented\x20a\x20<a\x20href=https://snort\.org>snort</a>
SF:-based\x20IPS\x20\(Intrusion\x20Prevention\x20System\)\x20to\x20help\x2
SF:0reduce\x20the\x20number\x20of\x20malicious\x20attacks\x20coming\x20fro
SF:m\x20our\x20VPN\x20servers\.<br>The\x20URL\x20you\x20are\x20requesting\
SF:x20has\x20alerted\x20this\x20IPS,\x20which\x20means\x20you\x20were\x20p
SF:robably\x20attempting\x20to\x20perform\x20a\x20SQL\x20injection\x20atta
SF:ck,\x20or\x20an\x20automated\x20web\x20vulnerability\x20scan,\x20or\x20
SF:some\x20other\x20generic\x20web-based\x20attack\.<br\x20/>If\x20this\x2
SF:0is\x20not\x20the\x20case,\x20please\x20email\x20<a\x20href=mailto:supp
SF:ort@cryptostorm\.is>s");
I wasn't aware that Cryptostorm was filtering and altering web traffic. I do a lot of web app pentests as well and SQL injection tests are a part of that.

Is there any documentation or blogposts on this? Are there any remedies to this? If this is standard for CS, I'll have to find a new VPN provider. I love CS and really don't want to have to do that.

I appreciate any response.

User avatar

marzametal
Posts: 520
Joined: Mon Aug 05, 2013 11:39 am

Re: CryptoStorm filtering web traffic.

Postby marzametal » Fri Jan 13, 2017 8:08 am

I know the Windows Widget can disable IPv6 and prevent STUN/WebRTC leaks. CS also has something called Tracker Smacker.

If the above relates to anything you are doing, then hmmm... bummer.


Topic Author
Pentester908

Re: CryptoStorm filtering web traffic.

Postby Pentester908 » Fri Jan 13, 2017 6:32 pm

No, I'm not worried about anti-tracking. That won't affect me much. I'm using OpenVPN and dns leaks aren't something that affects me, either.

The above message from Cryptostorm specifically references "Snort" an open sourced IDS/IPS. This means Cryptostorm is specifically monitoring and then altering web traffic. Now, they may not be logging what they monitor and it may all be automated, but they are changing traffic.

Can anyone from CryptoStorm point to their own documentation or announcement concerning this? I don't mind if CS will not allow "malicious" (even if its for security testing) traffic. I just need to make a decision on a VPN here shortly. I've been with CS for about three years now. I love them, but I have to be able to do my job.

User avatar

marzametal
Posts: 520
Joined: Mon Aug 05, 2013 11:39 am

Re: CryptoStorm filtering web traffic.

Postby marzametal » Sat Jan 14, 2017 6:55 am

Pentester908 wrote:No, I'm not worried about anti-tracking. That won't affect me much. I'm using OpenVPN and dns leaks aren't something that affects me, either.

The above message from Cryptostorm specifically references "Snort" an open sourced IDS/IPS. This means Cryptostorm is specifically monitoring and then altering web traffic. Now, they may not be logging what they monitor and it may all be automated, but they are changing traffic.

Can anyone from CryptoStorm point to their own documentation or announcement concerning this? I don't mind if CS will not allow "malicious" (even if its for security testing) traffic. I just need to make a decision on a VPN here shortly. I've been with CS for about three years now. I love them, but I have to be able to do my job.

This is a Reddit page which discusses SNORT, and has a reply/explanation after the opening post provided by df @ CS.


Khariz
Posts: 163
Joined: Sun Jan 17, 2016 7:48 am

Re: CryptoStorm filtering web traffic.

Postby Khariz » Fri Jan 20, 2017 7:28 am

In case you are feeling lazy:

df_cryptostorm• 211d
Seeing as how I'm the person that implemented the snort IPS you're referring to, I thought I should weigh in.

As it says in the "Access Denied" message, Cryptostorm owns servers at various data centers all over the world. Whenever someone tries to perform an automated/noisy vulnerability scan while connected to the VPN, those data centers will be the ones who receive abuse complaints from whatever server/website is being targeted. If any data center receives enough abuse complaints about a particular server under their roof, they will shut down that server and suspend the associated account.

Several people were using cryptostorm while running automated vulnerability scanners such as OpenVAS, Nessus, and Nikto (We know because we were forwarded the abuse emails containing WAF/IDS logs from the target and that included the User Agent that advertises the scanner program used, which the attacker was too lazy or dumb to change). We don't know if it was some script kiddies playing with a few tools, or if it was an intentional attempt to get our servers shut down. Either way, it was the reason that at least 3 of our servers were shut down by the data center (they've since been replaced with other servers in different data centers).

Most VPN providers prevent their servers from getting shut down due to these types of attacks by simply enabling logging (yes, even if they claim not to), or at the very least they'll set up some sort of server-side identifier (ID number, etc.) tied to every connection that can be used to trace which session belongs to which customer. An obvious sign that your VPN provider is doing this is if you ever receive any emails from them complaining about you attacking something (how did they know it was you performing that scan/hack unless they were logging?).

Cryptostorm needed to implement something to prevent these attacks from killing our servers, but we also didn't want to start logging anything that could potentially be used to identify any individual customer (that would defeat the whole purpose of our anonymous token authorization system).

The best solution I could think of was to use snort's NFQ DAQ directly against the tunnel interface, along with a generic ruleset that would prevent the most basic attacks before they even left the server. This allows us to keep our servers online without having to associate our customers with their sessions. This was also the only method I could think of that would allow us to block outgoing attacks without having to store any real client IPs anywhere (including RAM). When a block occurs, your internal (10.x.x.x) VPN IP is what gets temporarily added to iptables, not your real IP, and those internal IPs are randomly generated.

I've tried to remove most of the rules that were so generic or all-encompassing that it would definitely cause false positives, but even then there will be a few legitimate requests that get caught in this IPS. In those cases, emailing us will get the rule removed or modified to be more specific.

Regarding your http://example.com/?q=union%20select example, this was to prevent most SQL injection attacks because the majority of them do include "union select", but since that particular rule could also prevent someone from researching mysql related queries (http://stackoverflow.com/questions/8572 ... lect-query or http://stackoverflow.com/questions/3562 ... -in-clause for example), I'll go ahead and remove it.

As for your concern that we could possibly log all URLs or inject malicious HTML/JS/etc., you're right, we could (for HTTP at least). The implementation of this IPS isn't the reason for that possibility though. Any VPN server you're connected to could use something like http://www.linux-magazine.com/Issues/2015/173/Netsed to transparently inject/replace data in any plaintext stream between you and the server. That's why, as others have pointed out, using HTTPS is still a necessity even when using a VPN. A VPN only encrypts traffic between you and the VPN server. If you're using any plaintext protocols (HTTP, telnet, FTP, etc.) then the VPN server or any hop/route between the server and the destination could potentially perform a MiTM attack.

We try to alleviate any trust concerns by providing as much information as possible about how our network is structured:
https://github.com/cryptostorm/cstorm_deepDNS
https://github.com/cryptostorm/voodoo.network
viewtopic.php?t=6332
https://github.com/cryptostorm/cryptost ... tion_files
and by providing the source code to our custom client:
https://github.com/cryptostorm/cstorm_widget
But in the end, regarding our server-side setup, we could be making this all up and could really be using ancient/insecure software, or we could be logging all packets. Seems like a lot of trouble though to research possible ways to operate a VPN without that sort of logging and then not implement it.



Topic Author
NOYB

Re: CryptoStorm filtering web traffic.

Postby NOYB » Fri Jan 20, 2017 7:55 pm

Khariz wrote:In case you are feeling lazy:

df_cryptostorm• 211d
Seeing as how I'm the person that implemented the snort IPS you're referring to, I thought I should weigh in.

As it says in the "Access Denied" message, Cryptostorm owns servers at various data centers all over the world. Whenever someone tries to perform an automated/noisy vulnerability scan while connected to the VPN, those data centers will be the ones who receive abuse complaints from whatever server/website is being targeted. If any data center receives enough abuse complaints about a particular server under their roof, they will shut down that server and suspend the associated account.

Several people were using cryptostorm while running automated vulnerability scanners such as OpenVAS, Nessus, and Nikto (We know because we were forwarded the abuse emails containing WAF/IDS logs from the target and that included the User Agent that advertises the scanner program used, which the attacker was too lazy or dumb to change). We don't know if it was some script kiddies playing with a few tools, or if it was an intentional attempt to get our servers shut down. Either way, it was the reason that at least 3 of our servers were shut down by the data center (they've since been replaced with other servers in different data centers).

Most VPN providers prevent their servers from getting shut down due to these types of attacks by simply enabling logging (yes, even if they claim not to), or at the very least they'll set up some sort of server-side identifier (ID number, etc.) tied to every connection that can be used to trace which session belongs to which customer. An obvious sign that your VPN provider is doing this is if you ever receive any emails from them complaining about you attacking something (how did they know it was you performing that scan/hack unless they were logging?).

Cryptostorm needed to implement something to prevent these attacks from killing our servers, but we also didn't want to start logging anything that could potentially be used to identify any individual customer (that would defeat the whole purpose of our anonymous token authorization system).

The best solution I could think of was to use snort's NFQ DAQ directly against the tunnel interface, along with a generic ruleset that would prevent the most basic attacks before they even left the server. This allows us to keep our servers online without having to associate our customers with their sessions. This was also the only method I could think of that would allow us to block outgoing attacks without having to store any real client IPs anywhere (including RAM). When a block occurs, your internal (10.x.x.x) VPN IP is what gets temporarily added to iptables, not your real IP, and those internal IPs are randomly generated.

I've tried to remove most of the rules that were so generic or all-encompassing that it would definitely cause false positives, but even then there will be a few legitimate requests that get caught in this IPS. In those cases, emailing us will get the rule removed or modified to be more specific.

Regarding your http://example.com/?q=union%20select example, this was to prevent most SQL injection attacks because the majority of them do include "union select", but since that particular rule could also prevent someone from researching mysql related queries (http://stackoverflow.com/questions/8572 ... lect-query or http://stackoverflow.com/questions/3562 ... -in-clause for example), I'll go ahead and remove it.

As for your concern that we could possibly log all URLs or inject malicious HTML/JS/etc., you're right, we could (for HTTP at least). The implementation of this IPS isn't the reason for that possibility though. Any VPN server you're connected to could use something like http://www.linux-magazine.com/Issues/2015/173/Netsed to transparently inject/replace data in any plaintext stream between you and the server. That's why, as others have pointed out, using HTTPS is still a necessity even when using a VPN. A VPN only encrypts traffic between you and the VPN server. If you're using any plaintext protocols (HTTP, telnet, FTP, etc.) then the VPN server or any hop/route between the server and the destination could potentially perform a MiTM attack.

We try to alleviate any trust concerns by providing as much information as possible about how our network is structured:
https://github.com/cryptostorm/cstorm_deepDNS
https://github.com/cryptostorm/voodoo.network
viewtopic.php?t=6332
https://github.com/cryptostorm/cryptost ... tion_files
and by providing the source code to our custom client:
https://github.com/cryptostorm/cstorm_widget
But in the end, regarding our server-side setup, we could be making this all up and could really be using ancient/insecure software, or we could be logging all packets. Seems like a lot of trouble though to research possible ways to operate a VPN without that sort of logging and then not implement it.




So I guess you are affiliated with Cryptostorm?

Good response to "tragedy of the commons"......Had always wondered how "no logging" was possible in a world of rental cars and people letting their dogs crap on anything :) Seemed twilight "zoneish". Not real.

Also means that anything done online leaves a trail (tooth fairy promises notwithstanding).


Khariz
Posts: 163
Joined: Sun Jan 17, 2016 7:48 am

Re: CryptoStorm filtering web traffic.

Postby Khariz » Sat Jan 21, 2017 7:55 am

Just to be clear, that was a quote from the cryptostorm admin "df" responding to the snort concern on Reddit.


Topic Author
Deimos

Re: CryptoStorm filtering web traffic.

Postby Deimos » Fri Feb 03, 2017 5:30 am

Sometimes i seem to trigger the Snort blocker when simply trying to load a web page. Thankfully, as of the past day or so, CS now provides a useful substitute web page instead of just blocking the connection.

Code: Select all

Access Denied

Cryptostorm recently implemented a snort-based IPS (Intrusion Prevention System) to help reduce the number of malicious attacks coming from our VPN servers.
The URL you are requesting has alerted this IPS, which means you were probably attempting to perform a SQL injection attack, or an automated web vulnerability scan, or some other generic web-based attack.
If this is not the case, please email support@cryptostorm.is with the URL you were trying to access and we will look into adding it to the IPS system's whitelist.
If you were trying to hack into something, knock it off. Cryptostorm does not allow such activity.
Our servers are in datacenters that will receive abuse complaints when anyone hacks or attempts to hack into a remote server or network while connected to cryptostorm,
and if enough complaints are received, most datacenters will shut down that particular server because we have no way of banning specific clients since we have no way of identifying which client performed the attack.
That's why we had to implement this IPS system, because some people have been performing some very noticable scans while connected to cryptostorm (possibly in an attempt to take down our servers).
Luckily, this IPS should be enough to prevent anymore of these simple attacks from continuing.


Return to “member support & tech assistance”

Who is online

Users browsing this forum: No registered users and 31 guests

cron

Login