Improved proxmark3 scanning of ioProx / Kantech fobs

I’ve been playing with my new proxmark3. It works great for HID cards, but ioProx code is still in its infancy. I made some improvements to it based on analysis by marshmellow:

  • Better accuracy: You no longer have to worry about centering your fob on the antenna or scan it repeatedly to get a “good” reading. Now you can just hold it in your fingers to scan. Before this update I was averaging 10 – 70% accuracy depending on how I held the fob. This version is pretty much 100% – I haven’t had a bad scan yet.
  • Correct decoding of human readable XSF number: Previous version had a bug that displayed the wrong unique code and the wrong facility IDs.

proxmark3

Download the binary firmware (including source code patch if you want to build it yourself) .

There is still more work to be done. For example, there appears to be CRC or checksum near the end – it’s still a mystery.

Quick and easy iptables based proxy

Today was a busy day dealing with power outage that affected 2100 businesses in downtown Calgary. Of course, couple of my clients were in the zone that went dark. I offered them to run their key infrastructure from my place for couple of days. Everything went great, except I have only 1 IP address on my connection. That’s not good when both clients want to come in on port 443. What to do?

Call up my ISP and order another IP? Nope: Takes too long, too expensive, I just need this temporarily. Also, ISP might mess it up and take me offline for a while.

Get VM with IPv4 IP and proxy the traffic over? Yes, but why go with something heavy handed like nginx?

I prefer this elegant solution brought to you by iptables:


# echo 1 >| /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A PREROUTING -p tcp -d $IP_OF_VM --dport 443 -j DNAT --to $IP_WHERE_IM_FORWARDING_TO:8443
# iptables -t nat -A POSTROUTING -j MASQUERADE

New Quantum Key Distribution Record by LANL

NIST, LANL and Albion College set two significant distance records for distributing “keys” (or codes) for quantum encryption.

Press release

Why does this matter?

– Will make it impossible for adversaries to “sniff” network traffic without being detected.
– Until now prototypes were specialized (read expensive) equipment. This technology is inexpensive so it could soon be mainstream.
– With the real possibility of quantum computing developing the point of making all SSL and VPN encryption methods obsolete, this technology is one piece of the puzzle in replacing current encryption technology with the next generation.

[Solved] Linux PPTP client NATed behind pfsense firewall

When migrating my PPTP client configuration from an older Linux server to a new one, I could not get a PPTP tunnel up and running on the new server.   I kept getting this error flow:


using channel 15
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xxxxx6a93> <pcomp> <accomp>]
Script pptp vpn.xxxxxxxx.com --nolaunchpppd finished (pid 23704), status = 0x0
Modem hangup

So I was sending, but getting nothing back.

I tripple checked my configuration, and tweaked a few settings.  No luck.  Then I stumbled on an article that talked about the challenges of PPTP behind NAT devices.    I already knew about the common issue of not being able to dial out with more than one client session to a remote PPTP server.  For that reason I was careful not to have  more than one open at the same time,  but I thought I’d dig a bit deeper to see if NAT was the culprit.

Long story short, I noticed that pfsense -> diagnostics -> pftop was showing a GRE state from old server to the destination VPN server.  It showed age of 3+ hours (forgot the exact number) even though I was sure that the PPTP session on the old server was shut down.   I reset the firewall state on pfsense, and it started to work immediately.

The moral of the story is that pfsense likes to keep the GRE state open for hours after it’s been disconnected.   That is a problem.   Packets go out, but they are NATed to the wrong server when they come back.

Version details:

Pfsense: 2.1.4-RELEASE (i386)
PPTP: 1.7.2
Linux: Ubuntu 14.04.1 LTS