News archive August 2022 - Koos van den Hout

Since last Thursday the aprs server at aprs.pa4tw.nl is down. I used that aprs server for the weather station and for the igate.

The change for the weather station was one word in a script, for the igate I had to remember how to change this with the Arduino development environment set up to support the esp32 board. The easiest way seemed to be from the computer, but every time after the igate started the running process after the setup it crashed and rebooted itself. I spent a lot of time looking for the answers, added debug statements all over the code and ended up in the WiFi initialization code as the place of crashing. And that was the hint, according to Crash when trying to connect to wifi - Issue #3935 - espressif/arduino-esp32 this is a sign of a power shortage.

This is purely my fault: the pi4raz igate design calls for an external power supply feeding it.

The solution was to go back to the separate USB power supply and not use a USB hub connected to the computer. Now the igate is started again and visible on the APRS network: track PE4KH-10 on aprs.fi.

I wanted to use wapiti as scanner to check for other vulnerabilities in The Virtual Bookcase after receiving a report about a cross-site scripting vulnerability. Wapiti is open source and free, which is a fitting price for scanning a hobby project site.

I quickly ran into wapiti taking hours to scan because of the URL structure of the site: all /book/detail/x/y URLs map to one handler that deals with the X and Y parameters in SQL queries. Yes those queries are surrounded by very defensive checking and I use positional parameters. Everything to avoid SQL injection and becoming the next Little Bobby Tables.

Wapiti has no simple method that I can find to crawl for a list of URLs and stop at that to allow for selecting the list of URLs to scan. But it has an option to minimize crawling and import a list of additional URLs to scan so I used that option to get at the same result.

Gathering URLs was done with wget:

$ wget --spider -r http://developer.virtualbookcase.com 2>&1 | grep '^--' | egrep -v '\.(css|jpg|gif|png)' | awk '{ print $3}' > developer.virtualbookcase.com-urls.txt

After that I sorted the file with URLs and threw out a lot of them, making sure all the scripts with several variants of input were still tested.

With that list I start wapiti with some special options. It still needs a starting url at -u so I give it the root but I limit the crawling with the depth parameter -d 1 and the max files parameter --max-files-per-dir 50. Then I add the additional urls from the earlier scan with the -s parameter. It's a lot of tweaking but it does the trick.

$ wapiti -u http://developer.virtualbookcase.com/ -d 1 --max-files-per-dir 50 -s developer.virtualbookcase.com-urls.txt -o ~/wapiti/ -v 2

No vulnerabilities were found. I found one PHP warning which only triggered in the kind of corner case a web vulnerability scanner causes, or an attacker. So I fixed that corner case too.

I received a responsible disclosure report of a vulnerability in The Virtual Bookcase.

I will directly admit I haven't done a lot of maintenance on this site in the past few years but I want to keep my sites secure.

The report came via openbugbounty.org and has no details about the vulnerability, so I am not 100% sure where the reported vulnerability is. But based on the report text XSS (Cross Site Scripting) and a peek in the access-log looking for specific requests I found I made a beginner mistake in dealing with a search query: displaying it as-is within an HTML context. I immediately fixed that error in the site.

Now I wonder why it took so long for me to realize the error of my ways or for someone to notice it!

Checking the logs some more finds huge amounts of attempts at SQL injection, which is a vulnerability I am very aware of and where I put up standard defenses. But this is the first time a security researcher made me aware of the cross-site scripting vulnerability.

Update: I contacted the reporter about the vulnerability who responded quickly inquiring about the possible bounty for finding the bug. As this is a site that hasn't delivered any income in years the best I can do is a mention in the credits of the site or on a separate hall of fame.

Update: I also started a vulnerability scanner on the site myself, to find any other vulnerabilities I might have missed. This scanner is going through the development site at the moment. Like many other scanners it doesn't see by default how certain urls all map to the same PHP script.

I already committed a few minor updates to improve handling of corner cases in not set variables and other things popping up in the scan.

Update 2022-09-23: I realized the reporter has never responded with the actual bug information.

After digging into setting up radius and WPA Enterprise with an Asus WL300g accesspoint the next step was to peek into the traffic on a client.

For that part I used a linux machine with a wired and wireless interface and used tcpdump to try to capture the wireless authentication packets. I configured /etc/network/interfaces for wpa enterprise, based on the eduroam examples.

And this worked, starting the capture:

root@ritchie:~# ifconfig wlan0 up
root@ritchie:~# tcpdump -ni wlan0 -w wlanstart.pcap -s 0 -u -v

And I typed in another window 'ifup wlan0'. This resulted in a capture with the right Extensible Authentication Protocol (EAP) packets included:

root@ritchie:~# tcpdump -nr wlanstart.pcap -v
reading from file wlanstart.pcap, link-type EN10MB (Ethernet)
16:47:39.658963 EAP packet (0) v2, len 5, Request (1), id 0, len 5
                 Type Identity (1)
16:47:39.660863 EAP packet (0) v1, len 25, Response (2), id 0, len 25
                 Type Identity (1), Identity: anonymous@idefix.net
16:47:39.662840 IP6 (hlim 1, next-header Options (0) payload length: 56) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr ff02::1:ff23:123 to_in, 0 source(s)] [gaddr ff02::1:ff84:afe0 to_ex, 0 source(s)]
16:47:39.668736 EAP packet (0) v2, len 6, Request (1), id 1, len 6
                 Type TTLS (21) TTLSv0 flags [Start bit] 0x20,
16:47:39.670420 EAP packet (0) v1, len 6, Response (2), id 1, len 6
                 Type Nak (3) unknown (25),
16:47:39.682125 EAP packet (0) v2, len 6, Request (1), id 2, len 6
                 Type unknown (25)
16:47:39.741150 EAP packet (0) v1, len 203, Response (2), id 2, len 203
                 Type unknown (25)
16:47:39.756343 EAP packet (0) v2, len 1004, Request (1), id 3, len 1004
                 Type unknown (25)
16:47:39.756598 EAP packet (0) v1, len 6, Response (2), id 3, len 6
                 Type unknown (25)
16:47:39.834920 EAP packet (0) v2, len 1000, Request (1), id 4, len 1000
                 Type unknown (25)
16:47:39.835159 EAP packet (0) v1, len 6, Response (2), id 4, len 6
                 Type unknown (25)
16:47:39.842070 EAP packet (0) v2, len 1000, Request (1), id 5, len 1000
                 Type unknown (25)
16:47:39.842318 EAP packet (0) v1, len 6, Response (2), id 5, len 6
                 Type unknown (25)
16:47:39.866174 EAP packet (0) v2, len 79, Request (1), id 6, len 79
                 Type unknown (25)
16:47:40.006260 EAP packet (0) v1, len 144, Response (2), id 6, len 144
                 Type unknown (25)
16:47:40.014338 EAP packet (0) v2, len 65, Request (1), id 7, len 65
                 Type unknown (25)
16:47:40.016467 EAP packet (0) v1, len 6, Response (2), id 7, len 6
                 Type unknown (25)
16:47:40.028765 EAP packet (0) v2, len 43, Request (1), id 8, len 43
                 Type unknown (25)
16:47:40.029290 EAP packet (0) v1, len 96, Response (2), id 8, len 96
                 Type unknown (25)
16:47:40.036381 EAP packet (0) v2, len 75, Request (1), id 9, len 75
                 Type unknown (25)
16:47:40.043383 EAP packet (0) v1, len 144, Response (2), id 9, len 144
                 Type unknown (25)
16:47:40.057720 EAP packet (0) v2, len 91, Request (1), id 10, len 91
                 Type unknown (25)
16:47:40.058739 EAP packet (0) v1, len 80, Response (2), id 10, len 80
                 Type unknown (25)
16:47:40.071176 EAP packet (0) v2, len 43, Request (1), id 11, len 43
                 Type unknown (25)
16:47:40.072087 EAP packet (0) v1, len 80, Response (2), id 11, len 80
                 Type unknown (25)
16:47:40.082689 EAP packet (0) v2, len 4, Success (3), id 11, len 4
16:47:40.082865 EAPOL key (3) v2, len 117
16:47:40.091607 EAPOL key (3) v1, len 117
16:47:40.107041 EAPOL key (3) v2, len 175
16:47:40.107839 EAPOL key (3) v1, len 95

At the same time I captured the radius traffic. Now time to correlate those two traffic streams in wireshark.

For work I am looking into how Wi-Fi Protected Access (WPA) actually works down to the byte level, to be able to explain what actually happens and where the security strenghts and weaknesses are.

To set this up I need a separation between the access-point and the authentication server. I dug up an old Asus WL300g access-point and looked at FreeRADIUS as authentication, authorization and auditing (AAA) server. I followed the A very basic (but functional) eduroam configuration - FreeRADIUS wiki guide to get to a working setup, but with different passwords.

Getting the access-point to talk to a radius server took a bit of searching and trying: I assumed that "802.1x" which is extended to "Radius with 802.1x" was the right mode to use a radius server in the background, but it turned out this didn't do what I want. I saw no communication with the radius server and I didn't see the SSID advertised.

The right mode is "WPA" and things started to work that way. It still needs a few settings to talk to the radius server: IP address, port and shared secret.

I chose to go the 'eduroam' way because that is what I am used to from work. This does mean I had to set a home domain idefix.net for authentication. With eduroam I also get Extensible Authentication Protol (EAP) extensions to handle with the real user data. The result is an outer authentication layer visible to the first radius server in the path and an inner authentication layer only visible to the final radius server in the path. Although both the outer and the inner authentication servers run on the same freeradius server they are separate configurations with a trust relation between them.

The traffic to the inner authentication server is wrapped in TLS and needs a certificate. I used LetsEncrypt to generate a trusted certificate. I noticed I am at a point where generating a valid LetsEncrypt certificate was easier for me than fiddling with self-signed certificates. So I could set up my phone to require a valid certificate for radius.idefix.net.

All of this worked and I had a WPA Enterprise connection with the access-point and a lot of debug logging in freeradius.

My next plan is to find some computer with a network card where I can run wpa_supplicant while at the same time grabbing all the raw 802.11 frames and analyzing/understanding the traffic. I will also look at the radius traffic between access-point and outer radius server, and the radius traffic between outer and inner radius server.

Summertime is also time for some extortion scamming... this one just in:

Hi. How are you?

I know, it’s unpleasant to start the conversation with bad news, but I have no choice.
Few months ago, I have gained access to your devices that used by you for internet browsing.
Afterwards, I could track down all your internet activities.

Here is the history of how it could become possible:
At first, I purchased from hackers the access to multiple email accounts (nowadays, it is a really simple thing to do online).
As result, I could easily log in to your email account

One week later, I installed Trojan virus in Operating Systems of all devices of yours, which you use to open email.
Frankly speaking, it was rather straightforward (since you were opening the links from your inbox emails).
Everything ingenious is quite simple. (o_0)!

..

Here is my bitcoin wallet provided below: bc1q82tvkvmzjzyqf60guqpxhcn2tuapqup35a9ldr

You should complete the abovementioned transfer within 48 hours (2 days) after opening this email.

The following list contains actions you should avoid attempting:
#Do not try calling police as well as other security forces. In addition, abstain from sharing this story with your friends.
After I find out (be sure, I can easily do that, given that I keep complete control of all your devices) – your kinky video will end up being available to public right away.
#Do not try searching for me – there is absolutely no reason to do that. Moreover, all transactions in cryptocurrency are always anonymous.
#Do not try reinstalling the OS on your devices or throwing them away. It is pointless as well, since all your videos have already been uploaded to remote servers.

As always: don't fall for these scams.

Earlier items about bitcoin extortion scams: Earlier, earlier, earlier, earlier, earlier, earlier, earlier, earlier, earlier (although I think bitcoin is generally a really bad idea and a huge scam)

Someone reported to me my PGP key was expired and whether I was still using it or I gave up on PGP/GPG.

I have an expiry date on my key, but I do update it from time to time when expiry nears. I now notice just doing a gpg --refresh doesn't update the expiry moment. The solution is to hard fetch the key. In the case of my home pgp key:

$ gpg --keyserver pgp.surf.nl --receive-keys 0x5BA9368BE6F334E4

This updates the expiry date(s) and the uids. If you have my key and it looks expired and/or still has an old e-mail address with kzdoos in it please do this now. Complete data at pgp.surf.nl: Search results for '0x5BA9368BE6F334E4' where you can see all the details including the revoked bits. Those revoked bits won't show up in normal use.

I know gpg and other pgp related software has to be designed to be really really secure up to the last bit, but some attention to user friendlyness could be a good idea if it's possible to confuse even experienced pgp users.