The newest releases of Google's Android O.S. introduced a long overdue feature: encryption of user data is now enabled out-of-the-box. Although Android users have had the option to encrypt their devices since Android 3.0, now you won't even have to think about it. Apple's IOS has been doing this for some time now, and now Android has caught up. This move has been quite a game changer for the smartphone industry and users alike.
To be more specific, it is only the data partition that is now encrypted by default, but that will do the trick because, well... that's where your private data is stored. It's also worth noting that if you upgraded your phone to Lollipop (Android 5.0) rather than purchasing phone with Lollipop pre-installed, you will need to manually encrypt your data from the settings menu. That's likely because the encryption process can take over an hour, and I can imagine a lot of people would be irritated if an update rendered their phone unusable for such a long amount of time. The algorithm Google chose to use is AES-128-CBC with SHA256, both are proven ciphers when properly implemented. Apparently it's possible to use AES-256 if desired, although at this point in time, I see no reason to do so. AES (Advanced Encryption Standard) is one of the more popular ciphers available today, and works well on embedded systems like smartphones. Curiously, Google is not using the hardware random number generators present inside devices (not even on its' own Nexus). I'm not sure what to make of that, but perhaps they are protecting users against possible backdoors being built into future (or present) random number generators. This does mean more overhead for the CPU, but personally I'd trade a little performance for security.
There is no doubt that Edward Snowden's revelations of the NSA's scandalous surveillance program played a role in this decision. Since those documents leaked, American's have started to care much more about their personal privacy, and the rest of the world has lost a lot of trust in the American tech market. Since Google is the largest tech company in the US, it's likely that they suffered lost revenue as well. In fact, according to Google's founder, Eric Schmidt, NSA spying will kill our technological industry. Because these activities were and continue to be unconstitutional-- and let's just call it what it is-- illegal, it's only natural that the people would seek ways to circumvent the system.
As soon as this was announced, the director of the FBI stated that he was not happy about it. One would think that the FBI's ability to tap almost any private conversation
anywhere at any given moment, and to intercept half of the traffic
flowing through the internet without due process of law would be enough
for them. I mean seriously, you can already intercept most of the
data on our phones before it's even stored in our little encrypted
partition, and now you want to take that away too? Google did the right thing and gave the user complete control over their data, and nobody but the device owner can decrypt it. That means law enforcement can't call Google and ask them to
unlock someone's phone, because Google does not have the key. The FBI
is so pissed about the idea of people getting this inkling of privacy
back that they are seriously trying to pressure phone manufactures to
put (and I quote) "Not [hardware] backdoors, but frontdoors" into their
products to circumvent the encryption. I'm sorry FBI, but no matter
which door you use and what you want to call it, it's still an
intentional way of undermining methods of protecting personal data, and thus by definition is still a backdoor. Not to mention that
if hackers have a history of exploiting such backdoors, they
surely will figure out how to exploit the 'front-doors' as well.
James Comey (director of the FBI) claims that as encryption is used more frequently, their ability to solve crime is diminished. And now I'd like to challenge that statement. His example was one of classic eye-rolling cliché: 'What if a little girl goes missing and we can't find her because we can't get into her phone?"
First of all, you, the federal government, has more data-mining resources available to you than Heinz has pickles. You could always retrieve her call log, text messages, entire location history (even if the gps was off), emails, and probably even her web history from the telecoms. If the phone is still on when the feds get to it, they can perform a cold boot attack to unlock it, because the passphrase must be cached in memory in order to decrypt that data. Than there is always Prism, and all the other creepy data mining&retention systems available to agencies such as the FBI. The point of those systems is in fact to capture and store as much data as possible while in transit. Common, this is supposed to be for our protection, right? Is the director of the FBI admitting that those systems are in fact a total waste of money? Not to mention that parents have the ability to track their kids everywhere they go these days, thanks to their cell phones. If you are a parent concerned about what your kids are hiding from you, don't buy them something they can lock, because it's your fault if you can't access it. And than there's the Google and Apple accounts. By default, pictures, contacts, settings, wifi passwords, location history, emails, and a lot more personal information is automatically uploaded to Google or Apple's servers. Google is certainly able to provide this data to law enforcement when they are legally obligated to do so.
It seems unless this little girl is a vigilant privacy advocate like myself and uses 64 character random strings for her passwords, never enables location services, does not run Google software on her devices, has data sync disabled, runs a firewall on her device, routes all her web traffic through the tor network, and uses end-to-end encryption for all of her text messages & phone calls, that dinky little encrypted partition will not drastically hinder your ability to locate her.
In the end, encrypted devices will simply give back to you the constitutionally guaranteed freedom of reasonable privacy in your home, papers, and locked containers. In most states, police need a warrant to search a locked container during a traffic stop. I would consider an encrypted smartphone a type of locked container; it is after all the most personal of all the electronic devices that we carry around today. So will encrypted phones make any difference at all? Yes, they absolutely will. During a routing traffic stop, the police will see the lockscreen and know that they will not be able to overstep their legal authority. In 99% of these cases, they will write your speeding ticket or whatever and send you on your way. Cases in which the police have reasonable suspicions that a crime has been committed and there is important evidence stored on your locked device, they will be forced to obtain a warrant in order to search your phone, at which point you likely will be obligated to provide them the passphrase. Isn't that the way it's supposed to work anyway? It appears that the FBI is simply butthurt over loosing about 1% of their ability to undermine our constitutional rights because Google & Apple are delivering a feature the people desperately need.
Finally, with all the money spent on these dragnet surveillance systems, Americans ought to be able to hold the NSA accountable for the accuracy of the
information that they store about us. I should be able to call them and
ask "Hey, remember that blonde chick I hooked up with last weekend?
Could you refresh my memory, when did she say her birthday is again?" At
least we'd be getting something useful from these systems of
control that we pay for. One conclusion we can draw from all this with certainty is that encryption works. Use it.
Thursday, April 30, 2015
Tuesday, April 28, 2015
OpenVZ Containers, the Kernel & Iptables: The Lowdown
OpenVZ is a virtualization solution used by many VPS providers and users alike. It's sort of like Virtualbox, allowing one to create many virtual computers and host them on the same hardware node. In comparison to other virtualization systems, such as KVM, it has some drawbacks. For one thing, all the containers (OpenVZ terminology for a guest virtual machine) sharing a hardware node will also share that nodes kernel, consequently you cannot load kernel modules on a guest container unless they are already loaded on the host.
This causes problems for the users. For example, I hate using swap unless I absolutely have to. I cannot simply run 'swapoff -a' on my OpenVZ vps because the administrator has disabled that feature on the host kernel. For a while I had a workaround, I would set the vmswappiness level down to 0, basically causing the system to not use swap until it really needs to. But than one day I got an 'access denied' error message when trying to do this. Another example would be trying to enable tun support. You can't just run 'modprobe tun'. It's either off or it's on. If it's off and you need to set up a VPN, than you have to contact your provider and ask if they will do so. Fortunately, almost all vps providers allow the users tun support.
Than there is iptables. It took a long time for me to understand how to configure iptables on an Openvz vps. Unlike normal linux systems (and KVM based virtual machines), you don't have interfaces like 'eth0' or 'eth1' that allow you to easily write iptables rules based on the interface. If you have an OpenVZ vps with multiple IP addresses, than you may have noticed that you have interfaces such as 'venet0', 'venet0:0', 'vnet0:1', and so on. If you try to write a firewall rule so that http connections are served on a particular IP, such as:
iptables -A INPUT -i venet0:1 -p tcp --dport 80 -j ACCEPT
It won't work, because iptables does not know what venet0:1 is, even though when you run ifconfig you can clearly see your IP address on an interface with that name. So, instead you have to use workarounds, referancing the destination IP of the incoming rule. You also use 'venet0' for every interface, don't ask me why. I am sure someone that understands OpenVZ knows. For example, let's say you wanted to serve http traffic from 1.2.3.4, and https from 1.2.3.5. This is how you could do that:
iptables -A INPUT -i venet0 -d 1.2.3.4 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i venet0 -d 1.2.3.5 -p tcp --dport 443 -j ACCEPT
I like to think doing that provides an equal level of security that you'd get on a physical system where you can reference separate interfaces. The following is an iptables script that I've put together from various sources on the net, made specifically for people running openvpn on openvz server. Overzealous security precaution was taken when writing these rules:
#!/bin/bash
# A Linux Shell Script with common rules for IPTABLES Firewall, customized
# for OpenVZ Openvpn servers running dnscrypt-proxy.
# -------------------------------------------------------------------------
# Credit: Copyright (c) 2004 nixCraft project <http://cyberciti.biz/fb/>
# This script is licensed under GNU GPL version 2.0 or above
# -------------------------------------------------------------------------
# Modified by Chev Y. #
#--------------------------------------------------------------------------
IPT="/sbin/iptables"
SPAMLIST="blockedip"
SPAMDROPMSG="BLOCKED IP DROP"
echo "Starting IPv4 Wall..."
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
modprobe ip_conntrack
[ -f /root/scripts/blocked.ips.txt ] && BADIPS=$(egrep -v -E "^#|^$" /root/scripts/blocked.ips.txt)
VPN_IF="tun+"
VPN_PRT="13959"
SSH_PRT="17171"
EXTIF="venet0"
EXTIP="1.2.3.4"
OUTIP="1.2.3.5"
VPN_SN="10.99.11.0/24"
VPNSRVR="10.99.0.1"
$STATIC_IP="some.static.ip.address" # Some ip to allow ssh in case vpn goes down
# Allow local connections
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
# Block weird stuff
iptables -A INPUT -s $EXTIP -j DROP
iptables -A OUTPUT -d $EXTIP -j DROP
# Stop floods
iptables -N flood
iptables -A INPUT -p tcp --syn -j flood
iptables -A flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A flood -j DROP
# DROP all incomming traffic
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
if [ -f /root/scripts/blocked.ips.txt ];
then
# create a new iptables list
$IPT -N $SPAMLIST
for ipblock in $BADIPS
do
$IPT -A $SPAMLIST -s $ipblock -j LOG --log-prefix "$SPAMDROPMSG"
$IPT -A $SPAMLIST -s $ipblock -j DROP
done
$IPT -I INPUT -j $SPAMLIST
$IPT -I OUTPUT -j $SPAMLIST
$IPT -I FORWARD -j $SPAMLIST
fi
# Block sync
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "Drop Sync"
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Block Fragments
$IPT -A INPUT -f -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "Fragments Packets"
$IPT -A INPUT -f -j DROP
# Block bad stuff
$IPT -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "NULL Packets"
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP # NULL packets
$IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "XMAS \ Packets"
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP #XMAS
$IPT -A INPUT -p tcp --tcp-flags FIN,ACK FIN -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "Fin Packets Scan"
$IPT -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP # FIN packet scans
$IPT -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
# Outgoing interface
$IPT -A INPUT -i venet0 -d $OUTIP -j DROP
# Allow full outgoing connection but no incomming stuff
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# allow incomming ICMP ping pong stuff
$IPT -A INPUT -i venet0 -d $EXTIP -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT
#### VPN ####
$IPT -A INPUT -i venet0 -d $EXTIP --source-port 1024:65535 -p udp -m udp --dport $VPN_PRT -j ACCEPT
$IPT -A INPUT -i venet0 -d $EXTIP --source-port 1024:65535 -p tcp -m tcp --dport $VPN_PRT -j ACCEPT
#### SSH ####
$IPT -A INPUT -i venet0 -d $EXTIP --source-port 1024:65535 -s $STATIC_IP -p tcp -m tcp --dport $SSH_PRT -j ACCEPT
$IPT -A INPUT -i tun+ -s $VPN_SN --source-port 1024:65535 -d $VPNSRVR -p tcp -m tcp --dport $SSH_PRT -j ACCEPT
# Allow port 53 tcp/udp (DNS Server)
$IPT -A INPUT -i tun+ -s $VPN_SN -d $VPNSRVR -p udp --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p udp -s $VPNSRVR -d $VPN_SN --sport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i tun+ -s $VPN_SN -d $VPNSRVR -p tcp --destination-port 53 -m state --state NEW,ESTABLISHED,RELATED -j \ ACCEPT
$IPT -A OUTPUT -p tcp -s $VPNSRVR -d $VPN_SN --sport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#### DNSCRYPT/VPN ####
$IPT -A OUTPUT -p udp -m owner --uid-owner dnscrypt -m udp --sport 1024:65535 --dport 443 -j ACCEPT
$IPT -A OUTPUT -p tcp -m owner --uid-owner dnscrypt -m tcp --sport 1024:65535 --dport 443 -j ACCEPT
$IPT -A OUTPUT -m owner --uid-owner dnscrypt -j DROP
#### VPN TUNNEL ####
$IPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT$IPT -A FORWARD -s 10.77.69.0/24 -j ACCEPT
$IPT -A FORWARD -j REJECT$IPT -t nat -A POSTROUTING -s 10.77.69.0/24 -o venet0 -j SNAT --to-source $OUTIP
#### Drop Source Spoofing ####
$IPT -A INPUT -s 127.0.0.0/8 -j DROP
$IPT -A INPUT -s 10.0.0.0/8 --j DROP $
$IPT -A INPUT -s 172.16.0.0/12 -j DROP
$IPT -A INPUT -s 192.168.0.0/16 -j DROP
$IPT -A INPUT -s 224.0.0.0/3 -j DROP
# Kill Windows Bullshit
$IPT -A INPUT -p tcp -i venet0 -d $EXTIP --dport 137:139 -j REJECT
$IPT -A INPUT -p udp -i venet0 -d $EXTIP --dport 137:139 -j REJECT
$IPT -A INPUT -p udp -i venet0 -d $EXTIP --dport 445 -j REJECT
# log everything else and drop
$IPT -A INPUT -j LOG
$IPT -A FORWARD -j LOG
$IPT -A INPUT -j DROP
exit 0
The font is stupid small so that it would format correctly on this blog. As you can see, this is tailored specifically to servers running on OpenVZ, running OpenVPN, and using dnscrypt-proxy to serve the vpn clients. Keep in mind that often times your vps is also behind your providers firewall as well. This in no way means that you should not configure a firewall, no matter what you read on the internet. Strong firewall rules, tight file permissions, and good user permission management are at the core of Linux security. Of course, don't forget to choose your provider wisely. All of the firewall rules in hell won't help you if the people with physical access to your vps have malicious intents.
This causes problems for the users. For example, I hate using swap unless I absolutely have to. I cannot simply run 'swapoff -a' on my OpenVZ vps because the administrator has disabled that feature on the host kernel. For a while I had a workaround, I would set the vmswappiness level down to 0, basically causing the system to not use swap until it really needs to. But than one day I got an 'access denied' error message when trying to do this. Another example would be trying to enable tun support. You can't just run 'modprobe tun'. It's either off or it's on. If it's off and you need to set up a VPN, than you have to contact your provider and ask if they will do so. Fortunately, almost all vps providers allow the users tun support.
Than there is iptables. It took a long time for me to understand how to configure iptables on an Openvz vps. Unlike normal linux systems (and KVM based virtual machines), you don't have interfaces like 'eth0' or 'eth1' that allow you to easily write iptables rules based on the interface. If you have an OpenVZ vps with multiple IP addresses, than you may have noticed that you have interfaces such as 'venet0', 'venet0:0', 'vnet0:1', and so on. If you try to write a firewall rule so that http connections are served on a particular IP, such as:
iptables -A INPUT -i venet0:1 -p tcp --dport 80 -j ACCEPT
It won't work, because iptables does not know what venet0:1 is, even though when you run ifconfig you can clearly see your IP address on an interface with that name. So, instead you have to use workarounds, referancing the destination IP of the incoming rule. You also use 'venet0' for every interface, don't ask me why. I am sure someone that understands OpenVZ knows. For example, let's say you wanted to serve http traffic from 1.2.3.4, and https from 1.2.3.5. This is how you could do that:
iptables -A INPUT -i venet0 -d 1.2.3.4 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i venet0 -d 1.2.3.5 -p tcp --dport 443 -j ACCEPT
I like to think doing that provides an equal level of security that you'd get on a physical system where you can reference separate interfaces. The following is an iptables script that I've put together from various sources on the net, made specifically for people running openvpn on openvz server. Overzealous security precaution was taken when writing these rules:
#!/bin/bash
# A Linux Shell Script with common rules for IPTABLES Firewall, customized
# for OpenVZ Openvpn servers running dnscrypt-proxy.
# -------------------------------------------------------------------------
# Credit: Copyright (c) 2004 nixCraft project <http://cyberciti.biz/fb/>
# This script is licensed under GNU GPL version 2.0 or above
# -------------------------------------------------------------------------
# Modified by Chev Y. #
#--------------------------------------------------------------------------
IPT="/sbin/iptables"
SPAMLIST="blockedip"
SPAMDROPMSG="BLOCKED IP DROP"
echo "Starting IPv4 Wall..."
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
modprobe ip_conntrack
[ -f /root/scripts/blocked.ips.txt ] && BADIPS=$(egrep -v -E "^#|^$" /root/scripts/blocked.ips.txt)
VPN_IF="tun+"
VPN_PRT="13959"
SSH_PRT="17171"
EXTIF="venet0"
EXTIP="1.2.3.4"
OUTIP="1.2.3.5"
VPN_SN="10.99.11.0/24"
VPNSRVR="10.99.0.1"
$STATIC_IP="some.static.ip.address" # Some ip to allow ssh in case vpn goes down
# Allow local connections
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
# Block weird stuff
iptables -A INPUT -s $EXTIP -j DROP
iptables -A OUTPUT -d $EXTIP -j DROP
# Stop floods
iptables -N flood
iptables -A INPUT -p tcp --syn -j flood
iptables -A flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A flood -j DROP
# DROP all incomming traffic
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
if [ -f /root/scripts/blocked.ips.txt ];
then
# create a new iptables list
$IPT -N $SPAMLIST
for ipblock in $BADIPS
do
$IPT -A $SPAMLIST -s $ipblock -j LOG --log-prefix "$SPAMDROPMSG"
$IPT -A $SPAMLIST -s $ipblock -j DROP
done
$IPT -I INPUT -j $SPAMLIST
$IPT -I OUTPUT -j $SPAMLIST
$IPT -I FORWARD -j $SPAMLIST
fi
# Block sync
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "Drop Sync"
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Block Fragments
$IPT -A INPUT -f -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "Fragments Packets"
$IPT -A INPUT -f -j DROP
# Block bad stuff
$IPT -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "NULL Packets"
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP # NULL packets
$IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "XMAS \ Packets"
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP #XMAS
$IPT -A INPUT -p tcp --tcp-flags FIN,ACK FIN -m limit --limit 5/m --limit-burst 7 -j LOG --log-level 4 --log-prefix "Fin Packets Scan"
$IPT -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP # FIN packet scans
$IPT -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
# Outgoing interface
$IPT -A INPUT -i venet0 -d $OUTIP -j DROP
# Allow full outgoing connection but no incomming stuff
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# allow incomming ICMP ping pong stuff
$IPT -A INPUT -i venet0 -d $EXTIP -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT
#### VPN ####
$IPT -A INPUT -i venet0 -d $EXTIP --source-port 1024:65535 -p udp -m udp --dport $VPN_PRT -j ACCEPT
$IPT -A INPUT -i venet0 -d $EXTIP --source-port 1024:65535 -p tcp -m tcp --dport $VPN_PRT -j ACCEPT
#### SSH ####
$IPT -A INPUT -i venet0 -d $EXTIP --source-port 1024:65535 -s $STATIC_IP -p tcp -m tcp --dport $SSH_PRT -j ACCEPT
$IPT -A INPUT -i tun+ -s $VPN_SN --source-port 1024:65535 -d $VPNSRVR -p tcp -m tcp --dport $SSH_PRT -j ACCEPT
# Allow port 53 tcp/udp (DNS Server)
$IPT -A INPUT -i tun+ -s $VPN_SN -d $VPNSRVR -p udp --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p udp -s $VPNSRVR -d $VPN_SN --sport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i tun+ -s $VPN_SN -d $VPNSRVR -p tcp --destination-port 53 -m state --state NEW,ESTABLISHED,RELATED -j \ ACCEPT
$IPT -A OUTPUT -p tcp -s $VPNSRVR -d $VPN_SN --sport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#### DNSCRYPT/VPN ####
$IPT -A OUTPUT -p udp -m owner --uid-owner dnscrypt -m udp --sport 1024:65535 --dport 443 -j ACCEPT
$IPT -A OUTPUT -p tcp -m owner --uid-owner dnscrypt -m tcp --sport 1024:65535 --dport 443 -j ACCEPT
$IPT -A OUTPUT -m owner --uid-owner dnscrypt -j DROP
#### VPN TUNNEL ####
$IPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT$IPT -A FORWARD -s 10.77.69.0/24 -j ACCEPT
$IPT -A FORWARD -j REJECT$IPT -t nat -A POSTROUTING -s 10.77.69.0/24 -o venet0 -j SNAT --to-source $OUTIP
#### Drop Source Spoofing ####
$IPT -A INPUT -s 127.0.0.0/8 -j DROP
$IPT -A INPUT -s 10.0.0.0/8 --j DROP $
$IPT -A INPUT -s 172.16.0.0/12 -j DROP
$IPT -A INPUT -s 192.168.0.0/16 -j DROP
$IPT -A INPUT -s 224.0.0.0/3 -j DROP
# Kill Windows Bullshit
$IPT -A INPUT -p tcp -i venet0 -d $EXTIP --dport 137:139 -j REJECT
$IPT -A INPUT -p udp -i venet0 -d $EXTIP --dport 137:139 -j REJECT
$IPT -A INPUT -p udp -i venet0 -d $EXTIP --dport 445 -j REJECT
# log everything else and drop
$IPT -A INPUT -j LOG
$IPT -A FORWARD -j LOG
$IPT -A INPUT -j DROP
exit 0
The font is stupid small so that it would format correctly on this blog. As you can see, this is tailored specifically to servers running on OpenVZ, running OpenVPN, and using dnscrypt-proxy to serve the vpn clients. Keep in mind that often times your vps is also behind your providers firewall as well. This in no way means that you should not configure a firewall, no matter what you read on the internet. Strong firewall rules, tight file permissions, and good user permission management are at the core of Linux security. Of course, don't forget to choose your provider wisely. All of the firewall rules in hell won't help you if the people with physical access to your vps have malicious intents.
Sunday, April 19, 2015
Dirty Hacking Dnscrypt so It Works On Debian 7
This is for the Debian lovers amongst you that can't use the Ubuntu repositories for dnscrypt-proxy, and also a follow up to this post. There is no version anywhere that I know of that is completely stable and will compile on a Debian Wheezy box without error. This assumes you installed libsodium, autoconf, build-essential, libevent, and whatever else it depends on. That's all a cakewalk, but the actual installer for dnscrypt is broken (on Debian systems, anway...). In my case, I could never get past this point while running the configure script:
$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a ustar tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles... no
./configure: line 3264: syntax error near unexpected token `SYSTEMD,'
./configure: line 3264: ` PKG_CHECK_MODULES(SYSTEMD, libsystemd, have_systemd=yes,'
First of all, just apt-get install systemd. Than you need to butcher that script and remove the check for the systemd daemon. I just commented it all out like this:
# Check whether --with-systemd was given.
#if test "${with_systemd+set}" = set; then :
# withval=$with_systemd;
#fi#
#
#
#have_systemd=no
#if test "x$with_systemd" = "xyes"; then :
# PKG_CHECK_MODULES([SYSTEMD], [libsystemd], have_systemd=yes, have_systemd=no))
# PKG_CHECK_MODULES([SYSTEMD_DAEMON], [libsystemd-daemon], [have_systemd=yes], [have_systemd=no]))
# )
# case $with_systemd:$have_systemd in #(
# yes:no) :
# as_fn_error $? "systemd expected but libsystemd not found" "$LINENO" 5 ;; #(
# *:yes) :
#$as_echo "#define HAVE_LIBSYSTEMD 1" >>confdefs.h
#
# ;; #(
# *) :
# ;;
#esac
#fi
# if test "x$have_systemd" = "xyes"; then
# HAVE_SYSTEMD_TRUE=
# HAVE_SYSTEMD_FALSE='#'
#else
# HAVE_SYSTEMD_TRUE='#'
# HAVE_SYSTEMD_FALSE=
#fi
And of course don't forget to tell the system that yes, you do have systemd... So add this line:
HAVE_SYSTEMD_TRUE='#'
Save the configure script and try again.
./configure && make && sudo make install
What do you know, success! Now you're not in the clear yet... the installer (for version 1.43 anyway) fails to add the user dnscrypt:
adduser --system --home /etc/dnscrypt/run --shell /bin/false --group --disabled-password --disabled-login dnscrypt
Now edit the init script if you have one. If you tried the dnscrypt-autoinstaller, and every other damn script in the world like I did, you will have one at /etc/init.d/dnscrypt-proxy
Comment out all that nonsense so that there is only ONE daemon launching, and it's simplified: (See my older post about configuring dnscrypt, unbound, and openvpn for more details.)
$DAEMON --daemonize --user=dnscrypt --local-address=127.0.0.1 -R opendns
And now run service dnscrypt-proxy start ... should be good!
This is what success looks like:
whatever@superfunbox:/etc/init.d$ dig debug.opendns.com txt
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debug.opendns.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9877
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debug.opendns.com. IN TXT
;; ANSWER SECTION:
debug.opendns.com. 0 IN TXT "server 1.otp"
debug.opendns.com. 0 IN TXT "flags 20 0 70 5950800000000000000"
debug.opendns.com. 0 IN TXT "originid 0"
debug.opendns.com. 0 IN TXT "actype 0"
debug.opendns.com. 0 IN TXT "source xx.xx.xx.xx"
debug.opendns.com. 0 IN TXT "dnscrypt enabled (7144576459C33377)"
;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 19 18:38:02 2015
;; MSG SIZE rcvd: 248
$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a ustar tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles... no
./configure: line 3264: syntax error near unexpected token `SYSTEMD,'
./configure: line 3264: ` PKG_CHECK_MODULES(SYSTEMD, libsystemd, have_systemd=yes,'
First of all, just apt-get install systemd. Than you need to butcher that script and remove the check for the systemd daemon. I just commented it all out like this:
# Check whether --with-systemd was given.
#if test "${with_systemd+set}" = set; then :
# withval=$with_systemd;
#fi#
#
#
#have_systemd=no
#if test "x$with_systemd" = "xyes"; then :
# PKG_CHECK_MODULES([SYSTEMD], [libsystemd], have_systemd=yes, have_systemd=no))
# PKG_CHECK_MODULES([SYSTEMD_DAEMON], [libsystemd-daemon], [have_systemd=yes], [have_systemd=no]))
# )
# case $with_systemd:$have_systemd in #(
# yes:no) :
# as_fn_error $? "systemd expected but libsystemd not found" "$LINENO" 5 ;; #(
# *:yes) :
#$as_echo "#define HAVE_LIBSYSTEMD 1" >>confdefs.h
#
# ;; #(
# *) :
# ;;
#esac
#fi
# if test "x$have_systemd" = "xyes"; then
# HAVE_SYSTEMD_TRUE=
# HAVE_SYSTEMD_FALSE='#'
#else
# HAVE_SYSTEMD_TRUE='#'
# HAVE_SYSTEMD_FALSE=
#fi
And of course don't forget to tell the system that yes, you do have systemd... So add this line:
HAVE_SYSTEMD_TRUE='#'
Save the configure script and try again.
./configure && make && sudo make install
What do you know, success! Now you're not in the clear yet... the installer (for version 1.43 anyway) fails to add the user dnscrypt:
adduser --system --home /etc/dnscrypt/run --shell /bin/false --group --disabled-password --disabled-login dnscrypt
Now edit the init script if you have one. If you tried the dnscrypt-autoinstaller, and every other damn script in the world like I did, you will have one at /etc/init.d/dnscrypt-proxy
Comment out all that nonsense so that there is only ONE daemon launching, and it's simplified: (See my older post about configuring dnscrypt, unbound, and openvpn for more details.)
$DAEMON --daemonize --user=dnscrypt --local-address=127.0.0.1 -R opendns
And now run service dnscrypt-proxy start ... should be good!
This is what success looks like:
whatever@superfunbox:/etc/init.d$ dig debug.opendns.com txt
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debug.opendns.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9877
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debug.opendns.com. IN TXT
;; ANSWER SECTION:
debug.opendns.com. 0 IN TXT "server 1.otp"
debug.opendns.com. 0 IN TXT "flags 20 0 70 5950800000000000000"
debug.opendns.com. 0 IN TXT "originid 0"
debug.opendns.com. 0 IN TXT "actype 0"
debug.opendns.com. 0 IN TXT "source xx.xx.xx.xx"
debug.opendns.com. 0 IN TXT "dnscrypt enabled (7144576459C33377)"
;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 19 18:38:02 2015
;; MSG SIZE rcvd: 248
Tuesday, April 14, 2015
Orweb for Android Leaks Private IPs
The popular tor browser for Android devices, Orweb is also vulnerable to the WebRTC leak if javascript is enabled. This is a vulnerability affecting all major browsers I've tested so far. Using the STUN protocol, an unpatched browser behind a VPN or socks proxy (like tor, or even ssh) will leak your real IP. Of course, Javascript is disabled by default in Orweb. However, I can only imagine that lots of people turn it on when they need to access content that requires it.
I tested it from behind an OpenVPN server, on a network behind two seperate firewalls. Although my true IP was not leaked, the VPN server's public IP, the VPN local IP, and both LAN network IP addresses were leaked...
It is fixable on all platforms I've tested with Firefox. As far as I know it's still broken in Chrome, as well as Chromium. But I was pretty surprised to see that this also affects Orbot. If you need to use tor on your mobile device, do not enable javascript. You may even be better off proxying Firefox through Orbot and using a script block plugin with https everywhere. Remember, you do need to patch Firefox first, however. That's as easy as navigating to about:config and scrolling to media.peerconnection.enabled and toggling it to false.
What a mess.
I tested it from behind an OpenVPN server, on a network behind two seperate firewalls. Although my true IP was not leaked, the VPN server's public IP, the VPN local IP, and both LAN network IP addresses were leaked...
It is fixable on all platforms I've tested with Firefox. As far as I know it's still broken in Chrome, as well as Chromium. But I was pretty surprised to see that this also affects Orbot. If you need to use tor on your mobile device, do not enable javascript. You may even be better off proxying Firefox through Orbot and using a script block plugin with https everywhere. Remember, you do need to patch Firefox first, however. That's as easy as navigating to about:config and scrolling to media.peerconnection.enabled and toggling it to false.
What a mess.
Sunday, April 12, 2015
How to Use Android and Not Be Google Dependent
Google is awesome, nobody is denying that. It's been clear since around 1997 that Google would do very well for itself. Yeah, you know all about Google, and Google knows all about you too, which brings me to the point. Over the years Google's web services have become so awesome that it is almost impossible to use the internet without using those services. That was okay for a while, and their advertisements were non-intrusive enough that I didn't mind them. But than they sort of monopolized the internet, purchasing many major companies like Facebook, YouTube, and even the Android O.S. The biggest problem with this is what some have coined filter bubbles. Seriously, I am encouraging to watch this video explaining what I am talking about. It is very enlightening.
Despite us all being connected to a world wide web, content providers like Google tend to personalize our search results and web experience so much that we are now living in our own little bubbles, seeing what the algorithm thinks we want to see, and missing out on a lot of information and new ideas as a result. So if you ever feel like your Facebook news feed is somehow rigged, that's because it is. Facebook is engaged in all sorts of social experiments and content filtering/tailoring as well.
And if you have a gmail account, than chances are that you are always signed into your Google account when you are surfing the web, and as a result everything you do is tracked and logged. Even if you are not signed in, thanks to Google Analytics, you are still being tracked! Then factor in the fact that Google owns Android, which is currently the most popular O.S. in the world, and almost everyone that has an Android device is also logged into a Google account. Than think about the Google ads built in to a majority of the apps on the Play Store. The data mining potential is starting to become unfathomable when you put it all together. Who needs the NSA when everyone just gives it all up voluntarily?
Mass dragnet surveillance is a whole different issue, but destroying the connectivity that united the web through content personalization is an equally tragic result of too much big brother. Another thing that irritates me is that Android is supposed to be open source, but much of what is in the Play Store is now proprietary, or semi-open source software. This destroys the thing that made Android so cool: freedom to run the software you want, security through transparency, and peer-review, open source based trust. Some people wonder if Google has the ability to push software to Android devices without the users consent it's is running their framework. Nobody knows how often corporations such as Google comply with request from law enforcement, and they are certainly in one hell of an advantageous position to do so. I'd like to think this is all paranoia, but recent events have made it clear you can never be too careful in the digital world.
So it should not come as a surprise that a lot of people are looking for ways to not be dependent on the almighty Google anymore. For instance, Mozilla recently decided to ditch Google as Firefox's default search again, using Yahoo instead. Cyanogenmod has also pledged to ditch it's Google dependence, and at this point it is possible.
But how do you use Android without Google and still have a decent user experience? I know it sounds impossible, but it's not. It's actually an interesting and worthwhile challenge, and who knows, you may be happier with the alternatives. The first thing you should do if you have not already, is purchase an Android device with a bootloader that can be unlocked. This will allow you to run customized Android operating systems, or custom ROM's. Many Motorola devices allow this, and in a secure way that does not require hacking the device through a exploit any more. Instead, you buy a device that qualifies for their Bootloader Unlock program, and they provide you the unlock code. This way you can load your custom ROM and relock the bootloader, giving you much, better security. Of course, there is one catch: doing so will void your warranty. It is also likely that your current device can be unlocked. I would check xda to find out.
If you run Cyanogenmod, the game becomes a lot easier. In addition to the freedoms of alternate app stores, you also get frequent updates and tons of features that stock Android does not have with CM. You can use your Cyanogemod account for a device management instead of a Google account, allowing secure remote location and wiping for anti theft, and other things you'd expect from that kind of service.
There are many app stores out there that you can use instead of the Google Play store, my favourites are FDroid and Aptoid. Aptoid has an incredible amount of apps, and FDroid is great because they strictly adhere to the open source guidelines. For instance, if an application does something sketchy like report your location periodically, FDroid will list it as an anti-feature. It's also really fun discovering what these alternate app stores recommend, and it's refreshing to see a variety of pure open source apps that are not in the Play Store for whatever reason.
If you still want to have the Google framework in case you need it occaisonally or change your mind, simply freeze the apps with Titanium Backup, and you can get them back any time. If you think you could not live without Maps, I would recommend checking out some of the OSM (open street map) applications. Many are fine navigators, and offer features Maps does not such as storing maps for offline use, allowing you to navigate without a data connection, using nothing but the satellites in the sky. This is also preferable because you can use the GPS without leaking your sensitive location data to random servers. The entire concept of A-GPS is a bit scary to me. Okay, that concludes this blog. Try the open source challenge. You may be pleasantly surprised.
Despite us all being connected to a world wide web, content providers like Google tend to personalize our search results and web experience so much that we are now living in our own little bubbles, seeing what the algorithm thinks we want to see, and missing out on a lot of information and new ideas as a result. So if you ever feel like your Facebook news feed is somehow rigged, that's because it is. Facebook is engaged in all sorts of social experiments and content filtering/tailoring as well.
And if you have a gmail account, than chances are that you are always signed into your Google account when you are surfing the web, and as a result everything you do is tracked and logged. Even if you are not signed in, thanks to Google Analytics, you are still being tracked! Then factor in the fact that Google owns Android, which is currently the most popular O.S. in the world, and almost everyone that has an Android device is also logged into a Google account. Than think about the Google ads built in to a majority of the apps on the Play Store. The data mining potential is starting to become unfathomable when you put it all together. Who needs the NSA when everyone just gives it all up voluntarily?
Mass dragnet surveillance is a whole different issue, but destroying the connectivity that united the web through content personalization is an equally tragic result of too much big brother. Another thing that irritates me is that Android is supposed to be open source, but much of what is in the Play Store is now proprietary, or semi-open source software. This destroys the thing that made Android so cool: freedom to run the software you want, security through transparency, and peer-review, open source based trust. Some people wonder if Google has the ability to push software to Android devices without the users consent it's is running their framework. Nobody knows how often corporations such as Google comply with request from law enforcement, and they are certainly in one hell of an advantageous position to do so. I'd like to think this is all paranoia, but recent events have made it clear you can never be too careful in the digital world.
So it should not come as a surprise that a lot of people are looking for ways to not be dependent on the almighty Google anymore. For instance, Mozilla recently decided to ditch Google as Firefox's default search again, using Yahoo instead. Cyanogenmod has also pledged to ditch it's Google dependence, and at this point it is possible.
But how do you use Android without Google and still have a decent user experience? I know it sounds impossible, but it's not. It's actually an interesting and worthwhile challenge, and who knows, you may be happier with the alternatives. The first thing you should do if you have not already, is purchase an Android device with a bootloader that can be unlocked. This will allow you to run customized Android operating systems, or custom ROM's. Many Motorola devices allow this, and in a secure way that does not require hacking the device through a exploit any more. Instead, you buy a device that qualifies for their Bootloader Unlock program, and they provide you the unlock code. This way you can load your custom ROM and relock the bootloader, giving you much, better security. Of course, there is one catch: doing so will void your warranty. It is also likely that your current device can be unlocked. I would check xda to find out.
If you run Cyanogenmod, the game becomes a lot easier. In addition to the freedoms of alternate app stores, you also get frequent updates and tons of features that stock Android does not have with CM. You can use your Cyanogemod account for a device management instead of a Google account, allowing secure remote location and wiping for anti theft, and other things you'd expect from that kind of service.
There are many app stores out there that you can use instead of the Google Play store, my favourites are FDroid and Aptoid. Aptoid has an incredible amount of apps, and FDroid is great because they strictly adhere to the open source guidelines. For instance, if an application does something sketchy like report your location periodically, FDroid will list it as an anti-feature. It's also really fun discovering what these alternate app stores recommend, and it's refreshing to see a variety of pure open source apps that are not in the Play Store for whatever reason.
If you still want to have the Google framework in case you need it occaisonally or change your mind, simply freeze the apps with Titanium Backup, and you can get them back any time. If you think you could not live without Maps, I would recommend checking out some of the OSM (open street map) applications. Many are fine navigators, and offer features Maps does not such as storing maps for offline use, allowing you to navigate without a data connection, using nothing but the satellites in the sky. This is also preferable because you can use the GPS without leaking your sensitive location data to random servers. The entire concept of A-GPS is a bit scary to me. Okay, that concludes this blog. Try the open source challenge. You may be pleasantly surprised.
Friday, April 3, 2015
AIMSICD vs SnoopSnitch & WebRTC Affects Mobile Users Too
The best security practices in the world may not protect your cellular communications, as it turns out. Even if you are running the most secure operating system in the world on your device, chances are your phone can still be used to spy on you, possibly even if the device is powered off. That's because of the baseband processor, which has it's own small O.S that is invisible, closed-source, insecure, and likely outdated.
The baseband is what controls the phone's radio functions, and hence all communications. The GPS, microphone, camera, and sensors are hard wired to it, and not much is known about how these chipsets work. However, over the last couple of years, significant progress had been made reverse engineering them. The Android applications AIMSICD and SnoopSnitch are both capable of interacting with the baseband processors on a limited scale.
I have long been a fan of the AIMSIDC project, despite limitations and the alpha development status. Recently, I discovered SnoopSnitch, which is another IMSI catcher detecting app. It currently only supports Qualcomm based phones, and requires a rooted phone to function. I am pretty impressed with it, because as far as I know, it is the only application that is capable of determining what kind of (if any) encryption is being used on your mobile network. It also claimed to detect an IMSI-catcher attack that AIMSICD did not detect. Of course, it is hard to confirm these events, this is a science that as of now, is it not well understood.
When comparing the two, AIMSICD has more features and is more portable, although some of these features are still in development. SnoopSnitch works great if you have a rooted phone with a Qualcomm processor, while AIMSICD does not require root or any specific baseband chip. What it boils down to is it's a shame that the developers of both are not able to combine their efforts to give us one awesome app. SnoopSnitch was developed by Security Research Labs, and apparently they were not interested in working with AIMSICD. Still, it's a great app for rooted Qualcomm users. They also offer 'active testing', which determines network information by sending and receiving a few calls and texts to their servers. Interestingly, it was during one of those tests on the train home from Boston that I got an IMSI attack alert.
Oh, one other thing. When I reported that Android devices are not affected by the WebRTC vulnerability, that was incorrect. Apparently, unknown factors can cause IP leaks at times. Edit: This problem can be patched the same way that Firefox can be patched on a desktop computer. Navigate to about:config and toggle media.peerconnection.enabled to false.
AIMSICD: A proof-of-concept app that helps identify mobile network attacks.
It gives detailed information about the base stations in your area, a feature SnoopSnitch lacks.
However, SnoopSnitch is unique in it's ability to determine what cipher/if any cipher is being used on your mobile network.
Sample AIMSICD map snapshot, showing base stations relative to location.
SnoopSnitch seems to work well on Qualcomm phones, and picked up at least one event AIMSICD did not.
From ipleak.net, connected to a VPN (openvpn) and still leaking local IP addresses.
The baseband is what controls the phone's radio functions, and hence all communications. The GPS, microphone, camera, and sensors are hard wired to it, and not much is known about how these chipsets work. However, over the last couple of years, significant progress had been made reverse engineering them. The Android applications AIMSICD and SnoopSnitch are both capable of interacting with the baseband processors on a limited scale.
I have long been a fan of the AIMSIDC project, despite limitations and the alpha development status. Recently, I discovered SnoopSnitch, which is another IMSI catcher detecting app. It currently only supports Qualcomm based phones, and requires a rooted phone to function. I am pretty impressed with it, because as far as I know, it is the only application that is capable of determining what kind of (if any) encryption is being used on your mobile network. It also claimed to detect an IMSI-catcher attack that AIMSICD did not detect. Of course, it is hard to confirm these events, this is a science that as of now, is it not well understood.
When comparing the two, AIMSICD has more features and is more portable, although some of these features are still in development. SnoopSnitch works great if you have a rooted phone with a Qualcomm processor, while AIMSICD does not require root or any specific baseband chip. What it boils down to is it's a shame that the developers of both are not able to combine their efforts to give us one awesome app. SnoopSnitch was developed by Security Research Labs, and apparently they were not interested in working with AIMSICD. Still, it's a great app for rooted Qualcomm users. They also offer 'active testing', which determines network information by sending and receiving a few calls and texts to their servers. Interestingly, it was during one of those tests on the train home from Boston that I got an IMSI attack alert.
Oh, one other thing. When I reported that Android devices are not affected by the WebRTC vulnerability, that was incorrect. Apparently, unknown factors can cause IP leaks at times. Edit: This problem can be patched the same way that Firefox can be patched on a desktop computer. Navigate to about:config and toggle media.peerconnection.enabled to false.
AIMSICD: A proof-of-concept app that helps identify mobile network attacks.
It gives detailed information about the base stations in your area, a feature SnoopSnitch lacks.
However, SnoopSnitch is unique in it's ability to determine what cipher/if any cipher is being used on your mobile network.
Sample AIMSICD map snapshot, showing base stations relative to location.
SnoopSnitch seems to work well on Qualcomm phones, and picked up at least one event AIMSICD did not.
Subscribe to:
Posts (Atom)