Friday, January 16, 2015

VPN from a misconfigured cafe using NAT and Linux network namespaces (netns)

Recently I found myself at a cafe that had a wifi connection that was using the whole 10.0.0.0/8 subnet, meaning all addresses from 10.0.0.1-10.255.255.254. This was set up by a professional networking company. In my opinion, someone needs to re-do their CCNA.

So what this means is that if your corporate network is, say, on 10.34.0.0, you will be unable to route traffic easily over the VPN.

I am told there are 2 ways of getting around this

  1. Use network namespaces and NAT'ing to run your chosen applications in their own namespace that is NAT'ed through your real connection
  2. Use iptables prerouting if you know which subnets you are trying to get to on the other side of the VPN.
  3. Convince your coffee shop to use a sane network architecture
I chose #1 for now, and this guide goes over that.

Let's Get Started

Add the network namespace and confirm that it was created:

# ip netns add vpn_nat
# ip netns list

Add virtual ethernet interfaces (peers)
# ip link add name veth0 type veth peer name veth1

Move one of those peers into the vpn_nat namespace
# ip link set veth1 netns vpn_nat

In the namespace context, set up the network
# ip netns exec vpn_nat ifconfig lo up
# ip netns exec vpn_nat ifconfig veth1 192.168.148.2/24 up
# ip netns exec vpn_nat route add default gw 192.168.148.1

The eagle-eyed reader will notice that I am pointing to a gateway that doesn't exist! We fix that like so:
# ifconfig veth0 192.168.148.1/24 up

Test that the vpn_nat namespace can reach veth0

Execute ping in the namespace context vpn_nat:
# ip netns exec vpn_nat ping 192.168.148.1
PING 192.168.148.1 (192.168.148.1) 56(84) bytes of data.
64 bytes from 192.168.148.1: icmp_seq=1 ttl=64 time=0.088 ms
64 bytes from 192.168.148.1: icmp_seq=2 ttl=64 time=0.041 ms

The next step is to connect the veth0 to your physical network either using NAT or bridging. This requires the masquerading kernel module, but I believe it gets loaded automatically.
# sysctl net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -s 192.168.148/24 -d 0.0.0.0/0 -j MASQUERADE

Verify the routing tables

# iptables -t nat -L -n

Ping a google address in the namespace context

#  ip netns exec vpn_nat ping www.google.com

Verify the routing table in the netns

# ip netns exec vpn_natroute

Run your application in the namespace

I am running as an unprivileged user
$  ip netns exec vpn_nat firefox

Undoing

# iptables -t nat -D POSTROUTING 1

References

http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/
http://how-to.wikia.com/wiki/How_to_set_up_a_NAT_router_on_a_Linux-based_computer
http://www.opencloudblog.com/?p=66

Thursday, January 8, 2015

Recovering Tinder messages from users who've deleted their accounts

Okay, I've used Tinder.

However, we'll put that aside and get more technical here.

I ran into the situation where a person had given me some info to add her on Facebook, so that we could continue the conversation, but then deleted/disabled her Tinder account!

For those who don't know, Tinder will remove such a person from your matches and you cannot look at the conversation history anymore. Well, that sucks!

So here's a really, really, technical solution.

For security reasons, Android will not let you look in /data/com.tinder. Inside /data/com.tinder/db/tinder.db is a copy of all of the messages you've sent and received in the app. So we need this file, but without a rooted phone, the only way to access this data is to access it through Tinder, which would require us to modify and recompile Tinder ;-). If you try to use a file manager to browse /data, nothing will show up.

At this point you can root your phone, which requires unlocking the bootloader, which has been claimed to void your warranty, and naturally, when you unlock the bootloader the phone is wiped for security reasons.

So rooting is really not an option for such a silly little thing. You might as well give up on this potential person, even if they are your soul mate? :-(

The workaround is to enable ADB USB debugging in Android, and take a backup using the adb tool on your computer, while it's connected to the handset. Do not set a password!

adb backup -f my_backup.ab -apk -shared -all

And confirm from the phone that you want to allow this backup.

At this point you'll have a huge file called my_backup.ab. You'll need to extract this using the Android Backup Extractor which will require Java7 to be installed. Then you can run:

java -jar abe.jar unpack my_backup.ab my_backup.tar

Which will create a standard .tar file called my_backup.tar.

We can then extract this using tar

tar -xf my_backup.tar

Then navigate to the folder that's created, apps/ then com.tinder/db

From here, open the database (a SQLite DB) using sqlite3 command:

sqlite3 tinder.db

Let's view some messages!

select * from main.messages LIMIT 10;

Anything look familiar here? It should!

Okay so this is all out of order. What we are looking for are the most recent conversations. The field we are interested in is called 'created', so let's order messages by that!

SELECT * from main.messages ORDER BY created ASC;

54ef7ac30147af1b7d000192|53ef05f9f6061a2f32055da4||2014-02-08T19:28:06.922Z||Lol I am, do you want to add me on Facebook? Suzy Queens|

The names and unique IDs have been changed to protect everyone involved. But hey! There's the message I've been looking for! A match made in heaven. The person will owe you a drink for all of the hard work you've done ;-)

So my advice would be, if you get a phone number or last name from someone you are interested in...take a screenshot right then and there...Tinder will hide the conversation if that person then leaves Tinder or unmatches you. Otherwise, use this method if you are nerdy, or just can't take a hint. ;-)