Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Sunday, June 23, 2019

TV WiFi Adaptor Hax

I was looking for a cheap 802.11ac USB adaptor based on an MT76 chip when I found some ZDGFMT7612U WiFi boards on eBay. The ZDGFMT7612U is meant to add networking capabilities to a TV, but it includes a USB interface and seems conveniently packaged, so I decided to see if I could it would work as a normal USB/WiFi adaptor for use with Kismet, etc.

The eBay item description read:
Sharp ZDGFMT7612U P/N: 1178206 Wifi Module Board for LC-55P6000U
Not super helpful, but the back of the board clearly shows the FCC ID 2AJVQ-ZDGFMT7612U.  If you didn't already know, the FCC equipment authorization database contains useful documents about electronic equipment authorized for RF transmission in the United States, including user manuals and internal photographs.
Using the FCC Equipment Authorization Search (EAS) I was able to find the exhibits for this device's authorization application, which include a user manual and internal photos (the search page is a little weird, and I ended up searching by the Grantee Code 2AJVQ and scrolling through the results until I found it).  The internal photos reveal that the ZDGFMT7612U is based on the MT7612U chip from MediaTek, and the user manual has a somewhat helpful pinout for the board's connector.
Looking at the pinout and the wiring harness that came with the board, it looks like pins 3-6 are the USB connection to the host, and pin 7 is the shield for USB cable.  Unfortunately only USB 2 pins are connected.  I de-pinned the pins I don't care about from the white connector going to the board, and spliced a USB A male connector to the other end.  All the colors matched up, so this was pretty easy.
When I plugged the resulting thing into a computer, nothing happened.  No smoke, which is good, but also no wireless device.  After some guesswork and some help from the folks in the Wireless Village Discord, I figured out that the WIFI_REG_ON pin turns on the voltage regulator that converts the 5 volts supplied by USB to the 3.3 volts required by the WiFi chip.  I used a 4.3k resistor to make a pull-up connecting pin 1 to the 5v pad on the board.

Note: The resistor value I chose probably isn't right, and there are probably better ways to do this, but I'm not an EE and it's working so far.  If you have any advice please leave a comment!
After adding the pullup, the device is seen by the Linux kernel and a new wireless interface is added using the mt76x2u driver.  Yay!

[758511.999389] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[758512.150403] usb 1-1: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00
[758512.150409] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[758512.150412] usb 1-1: Product: 802.11a㜵呃䴷NA
[758512.150415] usb 1-1: Manufacturer: MediaTek Inc.
[758512.150417] usb 1-1: SerialNumber: 000000000
[758512.323849] usb 1-1: reset high-speed USB device number 5 using xhci_hcd
[758512.500874] mt76x2u 1-1:1.0: ASIC revision: 76120044
[758512.534205] mt76x2u 1-1:1.0: ROM patch build: 20141115060606a
[758512.871760] mt76x2u 1-1:1.0: Firmware Version: 0.0.00
[758512.871761] mt76x2u 1-1:1.0: Build: 1
[758512.871762] mt76x2u 1-1:1.0: Build Time: 201507311614____
[758513.913630] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[758513.914392] usbcore: registered new interface driver mt76x2u

[758513.951582] mt76x2u 1-1:1.0 wlx40cd7a083350: renamed from wlan0

My next step is to do some performance testing against the venerable AWUS-036AC and see how well it works in monitor mode.  I think the small on-board antennas may put it at a disadvantage (I have no idea what the beam pattern for those things would look like).

Sunday, July 22, 2018

802.11n monitoring

Today I learned that from the perspective of monitoring wireless networks, 802.11n differs from 802.11b/g in a couple of important ways:

First, there's an option to use 40 MHz channels, where, if I understand correcty, 802.11b/g are limited to 20 MHz.

Second, there's the option to use multiple data streams to increase performance.

Why am I talking about this?

I'm talking about these differences because if you want to monitor 802.11n communications, you need to match the negotiated capabilities between the AP and client you intend to monitor. I've been doing some work involving monitoring a wireless network, and I spent longer than I'd like to admit trying to understand why my AWUS036NH/airmon-ng/wireshark monitoring setup was failing to capture all of the packets. Eventually I came across this question on Superuser about a similar topic. Some smart person responded with a wonderful enumeration of some reasons why I may not see all of the traffic, which made me remember that I used a different client for my initial work.

Specifically, using my AWUS036NH I'm able to capture all wireless traffic from the AP to/from a Samsung Galaxy Tab A (SM-T280), but almost none of the traffic (except some TCP retransmits once in a while) to/from a Motorola Z. My guess is that the Moto Z has more advanced capabilities than the AWUS036NH has, which means the AWUS036NH can't see all of the traffic. As soon as I switched back to the Tab A, I was able to see all of the traffic again.

I'd like to dig up the details of these devices to try to confirm my suspicion, but a quick googling didn't turn up the specifications I was looking for.

Monday, May 28, 2018

Living with NetwokManager: Configuring an 802.11 Monitoring Interface

Background


In a previous post about reverse engineering a network protocol, I included some information about monitoring 802.11 wireless networks. After configuring a monitoring interface more than a few times, I started looking for ways to streamline the setup.

I'm using an EliteBook 8570p running Fedora 27 for my analysis work. I'd like to use my laptop's internal wifi card to stay connected to my home wifi network while monitoring another network with a USB wifi adapter. After reading some blog posts [1] and the terrible NetworkManager documentation, I was able to get this working and I thought I'd share. These modifications are probably specific to Fedora, but I suspect any distribution using NetworkManager could be configured similarly.

When I connect my USB adapter, the output from nmcli dev status indicates that NetworkManager wants to control it.



The first time I tried to automate disabling NetworkManager control of a wireless device, I went down the path of configuring NetworkManager to ignore the device by its MAC address. In order to do that, I had to disable NetworkManager's built-in MAC randomization for wireless devices, and after some thought I decided I'd rather not do that. The method described below uses a UDEV rule to tell NetworkManager to leave my USB wifi adapter alone, which seems simpler and safer.

UDEV Rule


First I gathered some info about the device by running udevadm info /sys/class/net/wlp0s20u4 (replace wlp0s20u4 with the name of your interface). The parts I'm interested in are ID_VENDOR_ID and ID_MODEL_ID.

P: /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/net/wlp0s20u4
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/net/wlp0s20u4
E: DEVTYPE=wlan
E: ID_BUS=usb
E: ID_MM_CANDIDATE=1
E: ID_MODEL=802.11_n_WLAN
E: ID_MODEL_ENC=802.11\x20n\x20WLAN
E: ID_MODEL_FROM_DATABASE=RT2870/RT3070 Wireless Adapter
E: ID_MODEL_ID=3070
E: ID_NET_DRIVER=rt2800usb
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_NET_NAME=wlp0s20u4
E: ID_NET_NAME_MAC=wlx00c0ca96aee3
E: ID_NET_NAME_PATH=wlp0s20u4
E: ID_OUI_FROM_DATABASE=ALFA, INC.
E: ID_PATH=pci-0000:00:14.0-usb-0:4:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_1_0
E: ID_REVISION=0101
E: ID_SERIAL=Ralink_802.11_n_WLAN_1.0
E: ID_SERIAL_SHORT=1.0
E: ID_TYPE=generic
E: ID_USB_DRIVER=rt2800usb
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Ralink
E: ID_VENDOR_ENC=Ralink
E: ID_VENDOR_FROM_DATABASE=Ralink Technology, Corp.
E: ID_VENDOR_ID=148f
E: IFINDEX=36
E: INTERFACE=wlp0s20u4
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlp0s20u4 /sys/subsystem/net/devices/wlp0s20u4
E: TAGS=:systemd:
E: USEC_INITIALIZED=129405399440

I used this info to write the following UDEV rule, which I saved in a file called /etc/udev/rules.d/99-alfa.rules, that sets the NM_UNMANAGED environment variable to 1:

SUBSYSTEM=="net", ACTION=="add", ENV{ID_VENDOR_ID}=="148f", ENV{ID_MODEL_ID}=="3070", ENV{NM_UNMANAGED}="1"

That's it. Now when I plug my USB wifi adapter in, NetworkManager shows it as "unmanaged".


Follow up


Now that my USB wifi adapter won't be misconfigured by NetworkManager, I should have an easier time setting up my system for monitoring. As a follow up, I'm working on configuring UDEV to execute a script to automatically put this interface into monitor mode as soon as it's connected. I'll share that in my next post.

Sunday, April 29, 2018

Oracle JDK on Fedora 27

This post explains how I install the Oracle JDK on Fedora 27.

1. Download


Validate the checksum against the published values listed here: https://www.oracle.com/webfolder/s/digest/10-0-1checksum.html
$ shasum -a 256 jdk-10.0.1_linux-x64_bin.tar.gz

2. Install

I like to install the JDK in /opt/java.
$ cd /opt/java
$ tar -xf jdk-10.0.1_linux-x64_bin.tar.gz

Now there should be a directory on the system that looks like /opt/java/jdk-10.0.1. In order to make updating the JDK easier in the future, create a symlink at /opt/java/latest that points to the latest installed version. This way we won't have to update the alternatives every time we update!
$ ln -s jdk-10.0.1 latest

3. Update alternatives

Fedora ships with OpenJDK installed by default and there are a bunch of packages that depend on it. However, we can use the alternatives command to allow the Oracle JDK and OpenJDK to coexist.

First let's tell alternatives about the Oracle JDK binaries:
$ alternatives --install /usr/bin/java java /opt/java/latest/bin/java 1000
$ alternatives --install /usr/bin/javaws javaws /opt/java/latest/bin/javaws 1000
$ alternatives --install /usr/bin/javac javac /opt/java/latest/bin/javac 1000
$ alternatives --install /usr/bin/jar jar /opt/java/latest/bin/jar 1000

Now we can make sure the correct version of the java command is selected, and update the configuration if necessary:
$ alternatives --config java

4. Verify

Let's make sure the Oracle JDK version of /usr/bin/java is being used:
$ java -version
java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)

Final Thoughts

When a new Oracle JDK is released, we can just install it in /opt/java and update the symlink!

Monday, November 4, 2013

Suricata on CentOS 6

This post will cover building and installing the Suricata IDS on CentOS 6.4.  This procedure is adapted from the following documentation from openinfosecfoundation.org:

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/CentOS_56_Installation
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Basic_Setup

The following procedure assumes at least a minimal CentOS 6.4 installation with the base package group installed.

Not all of the prerequisite packages for building suricata are included in the CentOS repositories, so the EPEL package repository will fill in the gaps.

Add the EPEL repo to your system if you haven't already:

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
Start by installing the prerequisite packages: (may take some time depending on your system and internet connection)

# yum install gcc gcc-c++ make automake autoconf libtool pcre pcre-devel libyaml libyaml-devel libpcap libpcap-devel file-libs file-devel libpcap libpcap-devel zlib zlib-devel libnet libnet-devel libcap-ng libcap-ng-devel
I've chosen to install gcc and autotools individually rather than install the Development Tools package group.  I think it's a good practice to limit unnecessary software on internet-accessible systems or systems with security-related roles, so I don't want a lot of the packages that come in the Development Tools group.  In fact, if you're really serious about security you would probably want to compile suricata on a development machine and leave gcc and autotools off of your production systems altogether.

Download and extract the suricata source tarball from openinfosecfoundation.org:

# wget http://www.openinfosecfoundation.org/download/suricata-1.4.6.tar.gz # tar -xzf suricata-1.4.6.tar.gz
Now build and install suricata:
# cd suricata-1.4.6 # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # make # make install-full
I've chosen the install-full target for installation, because this will create directories and install some rules and configuration files for us.

Now that suricata is built and installed we can go about configuring it and installing some support scripts.  I'm using oinkmaster set up to take care of updating the rules on my system.  Download the oinkmaster tarball from http://oinkmaster.sourceforge.net/download.shtml.  (I don't want to post a direct link because I'd have to choose a mirror for you, and I'd rather not)

Extract the files and install oinkmaster.conf and oinkmaster.pl on your system.
# tar -xzf oinkmaster-2.0.tar.gz # cd oinkmaster-2.0 # cp oinkmaster.pl /usr/bin # cp oinkmaster.conf /etc
Edit /etc/oinkmaster.conf and correct the url:
url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
We can now test oinkmaster:
# oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules
If all went well you should have a whole bunch of *.rules files in /etc/suricata/rules.  You probably want oinkmaster to update your IDS rules automatically, so something like the following in your crontab will do the trick.  For more information see: http://oinkmaster.sourceforge.net/readme.shtml.

30 2 * * * oinkmaster.pl -C /etc/oinkmaster.conf -o /etc/suricata/rules 2>&1 | logger -t oinkmaster
In order to make suricata process these rules we'll have to update its configuration.  First get a list of all the rules in /etc/suricata/rules with something like:
# ls /etc/suricata/rules/*.rules
We need to make sure all these rule files are listed in the suricata configuration, so open up /etc/suricata/suricata.yaml and check the rule-files section against the list of rule files.

The rule-files section in my suricata.yaml looks like this:

rule-files: - botcc.rules - ciarmy.rules - compromised.rules - decoder-events.rules - drop.rules - dshield.rules - emerging-activex.rules - emerging-attack_response.rules - emerging-chat.rules - emerging-current_events.rules - emerging-deleted.rules - emerging-dns.rules - emerging-dos.rules - emerging-exploit.rules - emerging-ftp.rules - emerging-games.rules - emerging-icmp_info.rules - emerging-icmp.rules - emerging-imap.rules - emerging-inappropriate.rules - emerging-info.rules - emerging-malware.rules - emerging-misc.rules - emerging-mobile_malware.rules - emerging-netbios.rules - emerging-p2p.rules - emerging-policy.rules - emerging-pop3.rules - emerging-rpc.rules - emerging-scada.rules - emerging-scan.rules - emerging-shellcode.rules - emerging-smtp.rules - emerging-snmp.rules - emerging-sql.rules - emerging-telnet.rules - emerging-tftp.rules - emerging-trojan.rules - emerging-user_agents.rules - emerging-voip.rules - emerging-web_client.rules - emerging-web_server.rules - emerging-web_specific_apps.rules - emerging-worm.rules - files.rules - http-events.rules - rbn-malvertisers.rules - rbn.rules - smtp-events.rules - stream-events.rules - tls-events.rules - tor.rules While we're editing suricata.yaml, the classification-file and reference-config-file fields also need to be updated:

classification-file: /etc/suricata/rules/classification.config reference-config-file: /etc/suricata/rules/reference.config

At this point, suricata is configured and can be tested with the following command:

# suricata -c /etc/suricata/suricata.yaml -i eth0

For a real IDS setup, we also need an init script for suricata, but I'm going to cover that in a follow up post.

Hope this has been helpful, thanks for reading!


Friday, June 22, 2012

efw-upgrade behind a proxy

The efw-upgrade command will fail for an EFW living on a network that requires use of an HTTP proxy.  To make it work efw-upgrade needs to be configured to use the proxy to download updates and repo data, but there doesn't appear to be any official documentation on how to do this.  EFW uses the Smart Package Manager, and luckily there's good documentation for smart. 

To make efw-upgrade work, use SSH or the console of the EFW to log in as root then run this command:

smart config --set http-proxy=proxyurl

My proxy url looks something like: http://a.b.c.d:8080

Monday, April 2, 2012

libtool version mismatch

Building ec2new on CentOS 6.2, I came across the following error:

libtool: Version mismatch error.  This is libtool 2.4, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6b.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4
libtool: and run autoconf again.

I found references to LT_INIT in ltmain.sh, so I deleted it and ran libtoolize.  After that the build process suggested in INSTALL worked fine.

Saturday, March 31, 2012

WPAD with EFW

My home router is running Endian Firewall Community edition v2.5.1, and I wanted to configure it to support WPAD using DHCP option 252.  The answer is simple but a little harder to find than I expected, so here it is.

Add the following into the "Custom configuration lines" text box on the DHCP Server configuration page in the EFW web-management console, substituting a.b.c.d for the IP Address of your EFW router:

option wpad code 252 = text;
option wpad "http://a.b.c.d/wpad.dat";

In the first line you're telling your DHCP server that option 252 is going to be an ASCII text string with the name wpad.  In the second line you're assigning a string to that option so the server can give it out to clients.  What you're doing here is giving your DHCP clients the URL for a Proxy Auto-Config file, that will tell them the location of the proxy server and possibly some other options.  If you want to check out the PAC file that EFW creates for you, open up that wpad.dat file from your router and take a look at it.

Option 252 is still only a draft, but it's used commonly enough that many DHCP clients and servers implement it.