Forked-daapd path traversal vulnerability Nuclei template

I went to a local OWASP chapter meeting last week and saw a presentation on the Nuclei vulnerability scanner by Alex Archondakis. I was previously vaguely aware of the tool, but thought this was a good opportunity to take a look in more depth.

A good place to start was creating a detection template for a vulnerability I discovered which has had a patch for a couple of years now.

I was very pleased with the results. With relatively little effort on my part, I was able to create a working template – essentially a signature for the vulnerability.

You can find it on GitHub.

Impressive vulnerability fix turnaround

I was probing the web service on Saturday on some software I have running on my Raspberry Pi, when I discovered a serious Path Traversal vulnerability, allowing access to arbitrary files on the system.

I reported this privately on Saturday afternoon, and a new release containing the fix went live yesterday.

That’s what taking security seriously looks like – excellent work!

How to fill storage space on an iPhone or iPad with little effort

Before I sell-on my old gadgets, I always try to do a factory reset and erase all data. I want to make it as difficult as I can for future owners to recover my personal data.

As an additional step, I like to fill the device’s storage with data in an attempt to overwrite any previously deleted data. Call me paranoid 🙂

One way of doing this could be to install some big apps after wiping the device, but this may then involve entering your credentials to access the relevant app store. I don’t like the idea of entering personal data when I’m trying to delete personal data!

Here’s a simple solution you may find helpful:

1. Using a laptop (or PC), create a file that’s big enough to fill the mobile device
2. Create a HTTP server on the laptop to serve up the big file to the mobile device
3. From the mobile device, browse to the IP address of the laptop, and download the large file.

That may look complicated, but really it takes seconds to set up!

Here’s the detail:

1. Take a look at the available disk space on your mobile device. Let’s say there is 22GB free. A new 22GB file (‘bigfile’) can be created in a split second in Linux without taking up any disk space (yes – you read that correctly!) by creating a sparse file as follows:
   truncate -s 22G bigfile
   It is recommended that you store the new file in a directory by itself. You’ll be sharing this directory over the network in a moment – you may not want to share your entire home folder!
2. At the command prompt/terminal, make sure you’re in the directory containing the ‘large’ file above, and enter the following command to start the HTTP server:
   python3 -m http.server
   You will, of course, need Python 3 installed for that command to work.
3. If the IP address of the laptop is 192.168.0.2, go the browser on your mobile device and browse to http://192.168.0.2:8000 where you should see something like the following:

4. Click on ‘bigfile’ to start the download. There’s no getting away from the fact that a 22GB download will not be lightning fast (at the time of writing)!

How to share a Bluetooth mouse between Windows 10 and Ubuntu Linux (dual boot)

Here’s a little python script I put together to help get a Bluetooth mouse to work across both partitions on my daughter’s laptop. I’ve included some potentially helpful pix at the bottom of the post.

	r"""
	Bluetooth mouse – Windows and Ubuntu dual boot.
	[ more info on my blog here https://wp.me/p1u8Xj-ib ]
	Ordinarily, if you pair a Bluetooth mouse in Linux,
	then boot into a Windows partition, you'll need to
	pair the mouse again in Windows for it to work. As a
	consequence, the pairing will be lost in Linux. You'll
	have to pair again when you switch partition to get it
	to work. This is not sustainable!
	To get it to work across both partitions once and for
	all, you need to export some of the pairing data from
	the registry of the Windows partition, manipulate the
	data a little, then import it into the relevant
	Bluetooth config file in Linux.
	There are quite a few guides out there on how to do
	this – I tried a few and none of them quite worked for
	me, though they did help me to put this solution
	together.
	In this instance, I used a Microsoft Bluetooth Mouse,
	pairing with an Inateck Bluetooth USB dongle. The
	operating systems were Windows 10 and Ubuntu 18.04.
	Step 1 – pair the mouse in the Linux partition
	Step 2 – pair the mouse in the Windows partition
	Step 3 – using regedit running as administrator in
	Windows, browse to
	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys
	Step 4 – change the permissions on the registry key
	to give yourself read access
	Step 5 – press f5 to refresh the view
	Step 6 – this should reveal a key with an 'adapter
	address' as its name, and a similar-looking
	'remote device address' sub-key
	Step 7 – you'll hopefully see some values called LTK,
	KeyLength, EDIV and ERand
	Step 8 – fill those values in in the section below,
	replacing the example values:
	"""
	LTK = "f3,c4,b6,43,51,70,8d,6a,ff,45,81,e4,4c,99,75,e4"
	KeyLength = "00000010"
	EDIV = "0000b333"
	ERand = "e6,5f,88,bc,cc,09,0b,32"
	"""
	Step 9 – run this Python code, and it'll generate the
	corresponding values that you'll need in Linux
	Step 10 – boot into Linux, and substitute the generated
	values into the 'info' file in
	/var/lib/bluetooth/<adapter address>/<remote device address>
	Step 11 – rename the <remote device address> folder to
	match the remote device address shown in the
	Windows registry
	Step 12 – reboot, or restart the bluetooth service
	('# service bluetooth restart')
	[I found it could take a couple of minutes for
	the mouse to show as connected]
	Step 13 – mouse!
	Step 14 – once you have it working, it's probably a good
	idea to go back and set the Windows registry
	permissions back to how they were originally
	"""
	# Calculate 'Key' value
	Key = "".join(LTK.split(",")).upper()
	print("Key={}".format(Key))
	# Calculate 'EncSize' value
	EncSize = int(KeyLength, 16) # Convert hex to decimal
	print("EncSize={}".format(EncSize))
	# Calculate EDiv value
	EDiv = int(EDIV, 16) # Convert hex to decimal
	print("EDiv={}".format(EDiv))
	# Calculate Rand value
	ERand_list = ERand.split(",")
	ERand_list.reverse() # Reverse order of hex pairs
	ERand_rev_hex = "".join(ERand_list)
	Rand = int(ERand_rev_hex, 16) # Convert hex to decimal
	print("Rand={}".format(Rand))

view raw bt_mouse.py hosted with ❤ by GitHub

• 

• 

• 

• 

• 

• 

• 

Secure administration of Splunk Free on Linux using SSH port forwarding (or tunnelling)

Splunk is a great data search, monitoring and analysis tool, and a cut-down version of the tool – Splunk Free – is available for learning/testing purposes.

One of the limitations of the free version is that there are no user roles – you just login directly as an administrator without authentication. I guess this is one way of encouraging businesses to pay for the product, as nobody is going to want to put sensitive data on the network allowing anonymous access (right?).

For me, even on my home network, I would prefer not to have anonymous admin services available. Here’s what it looks like – straight in with no logon:

There is a relatively simple solution – SSH port forwarding (also commonly known as SSH tunnelling). SSH is a standard administration tool for Linux, and it includes some useful functionality that we can leverage here. If you’re using a Windows client machine, you can do the same thing with PuTTY.

Regular connectivity works like this:

The Splunk Web service listens by default on TCP port 8000 on all network interfaces, making it accessible on the local network.

Using SSH port forwarding (see below), port 8000 on the client machine is forwarded to localhost port 8000 on the Splunk Linux server. All the traffic goes over the network using the encrypted SSH connection. There is no need, therefore, for the Splunk Web service to be listening for requests on the local network. Disabling network access effectively disables unauthenticated access, which is what we want here. As far as the Splunk is concerned, you are accessing the Splunk Web service from the Splunk Linux server itself. Sneaky!

The steps to implement this are as follows:

Step 1: reconfigure the Splunk Web service so that it is only accessible locally from the server itself (i.e. not visible on the network)

To do this, create the following file (adapt accordingly if you installed Splunk to a different location):

/opt/splunk/etc/system/local/web.conf

Add the contents as follows:

[settings]
server.socket_host = 127.0.0.1

Restart Splunk for the changes to take effect. The web management interface will no longer be directly accessible from your client machine.

Step 2: make an SSH connection to the Splunk server

ssh -L 8000:127.0.0.1:8000 user@splunkserver

Step 3: browse to the Splunk web interface using the local port specified in the previous step

The following video shows the interface no longer being accessible directly, and then a connection being made over SSH by browsing to http://127.0.0.1:8000

The Splunk Web service is now only accessible to those with a valid logon to the Splunk Linux server.

Qualys Cloud Agent installation issue caused by ISP’s ‘helpful’ DNS response [Fixed!]

When I tried to do a Qualys vulnerability scan of a Fedora 29 system today, things didn’t go too smoothly.

First, I downloaded and installed the Qualys Cloud Agent – so far, so good.

The next step was to run an included shell script to activate the agent and associate it with my Qualys subscription. Shortly after this I would expect to see the new Fedora system appear as a new system in the Qualys portal. Half an hour passed. Nothing.

Looking in  /var/log/qualys/qualys-cloud-agent.log I could see the following entries:

2019-01-20 16:15:37.173 [qualys-cloud-agent][1657]:[Error]:Http request failed:HTTP response code said error: The requested URL returned error: 500 Internal Server Error
2019-01-20 16:15:37.173 [qualys-cloud-agent][1657]:[Error]:Http request failed: error code: 500
2019-01-20 16:15:37.173 [qualys-cloud-agent][1657]:[Error]:CAPI request failed:
2019-01-20 16:15:37.173 [qualys-cloud-agent][1657]:[Error]:CAPI event failed
2019-01-20 16:15:37.173 [qualys-cloud-agent][1657]:[Information]:Server busy error: adding network delay: 450 seconds

I had a search on the web, but it bore no fruit.

I fired up wireshark to see if there were any clues in the network traffic.

I noticed that there was a DNS lookup for ‘metadata.google.internal’. ‘What did Google have to do with anything?’ I thought. I found this Qualys Press Release from November 2018 announcing new integration with the Google Cloud Platform.

The response for the above DNS query was as follows:

metadata.google.internal: type A, class IN, addr 92.242.132.24

The address 92.242.132.24 is the IP address returned by Virgin Media’s DNS servers when there is no such DNS record. The idea being that if you’re using a web browser and click on a link to a site that doesn’t exist in DNS, you’ll be ‘helpfully’ presented with Virgin’s advancedsearch2.virginmedia.com page.

My gut feeling was that getting this DNS response might be confusing the agent, leading to the error.

As a test, I edited /etc/resolve.conf on the Fedora machine to point to Google’s DNS server 8.8.8.8.

I then restarted the Qualys Cloud Agent service:

service qualys-cloud-agent restart

and checked the logs again:

2019-01-20 16:22:29.560 [qualys-cloud-agent][1854]:[Information]:Http request completed successfully: 200
2019-01-20 16:22:29.563 [qualys-cloud-agent][1854]:[Warning]:Instance-id found empty, retry Count: 1
2019-01-20 16:22:29.626 [qualys-cloud-agent.provision][1854]:[Debug]:Found agent HostID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

2019-01-20 16:22:29.627 [qualys-cloud-agent][1854]:[Information]:CAPI event successfully completed
2019-01-20 16:22:29.635 [qualys-cloud-agent][1854]:[Information]:Next event: INTERVAL_EVENT_CONFIG, time left: 60 seconds

That looked more promising!

The new Google DNS response in wireshark looked as follows:

Flags: 0x8183 Standard query response, No such name

Checking in the Qualys portal a few moments later…. the Fedora system was listed. Good times!

Crazy how the simple choice of a DNS server can have such unexpected consequences.

After a bit of research, it looks like I can opt out of the ‘advanced error search’ here.

Secure hotel internet access #1 – Parallels FAIL

Before setting off on holiday recently, I wanted to come up with a solution for my family to be able to access the internet securely in our hotel.

I’ve been playing around with using a couple of small USB wireless adapters connected to a Linux VM running as a virtual access point in Parallels on my MacBook, with OpenVPN running in the VM to secure the internet connection. I was pretty pleased with how it was working during testing, and my plan was to properly document my setup on this site on my return.

When we arrived at the hotel, I fired up my MacBook, tried to open the access point VM, and…

Parallels was forcing me to connect to the internet before allowing me to launch my access point VM! But I needed this VM in order to connect to the internet securely! I have been using Parallels on this MacBook for years without any problems, so why it chose to force me to re-activate the software at this moment, I do not know.

Whatever the reason for this behaviour, this tells me is that Parallels is possibly not a fit-for-purpose solution to this particular problem. I’m now more inclined to work on a more ‘open source’ solution. I have some ideas.

Back to the drawing board, and watch this space for part 2!

Deactivating Facebook Messenger

Today I deactivated my Facebook account, including Messenger.

According to Facebook’s instructions, I needed to first deactivate my Facebook account, then deactivate Messenger. Deactivating Facebook was easy, but then I tried to follow the instructions to deactivate Messenger:

Screenshot from Facebook Help Centre 12th April 2018

Unfortunately, there was no such option under “Privacy & Terms” in the IOS Messenger app.

The solution was to re-activate my Facebook account, and in the “Security and Login” settings, log out of all the instances of the Messenger app listed under “Where You’re Logged In”. I then deactivated my Facebook account once more and – hooray – I’m no longer listed in Facebook Messenger.

 

IOS Speed Dial – .tel.qlnk.net – avoid!

Last night I was looking into how one might go about adding a ‘speed dial’ contact shortcut to the home screen on an iPhone. According to my Googling efforts, a commonly-proposed solution is to browse to 1111111111111.tel.qlnk.net in safari and then save that shortcut to the home screen (replace the ones with the number to be added).

Turns out this is not a special internal link that IOS internally converts to a phone call, but rather this relies on an external redirection service at qlnk.net.

The first issue, then, is that the phone number will be exposed in the clear over the internet when the DNS query is made as the browser tries to navigate to the .tel.qlnk.net address, so that would be a privacy concern.

The second issue is that this redirection service is not longer live and the domain is currently for sale. Searching on the Internet Archive Wayback Machine, it looks as though the service died between 18th April 2015 and 24th April 2015.

The third issue is that that this domain might get bought by ‘bad guys’ who reinstate the phone number redirection service, but do not respect the privacy of people using the service. If you are reading this post, and find that the .tel.qlnk.net trick is working just fine, then this may have already happened.

It would appear that I’m going to have to live without this ‘nice to have’ feature for the time being.

 

Facebook CTF (Capture The Flag) platform – Bad Gateway

Facebook recently released their CTF (Capture The Flag) platform as an Open Source project on GitHub, so I thought I’d check it out. I thought it might be fun to host some Capture The Flag competitions with friends and colleagues.

What I found particularly appealing was the idea that Facebook have done all the work for me – just run the script and I’ll be ready to go.

Sadly, all I got was a “Bad Gateway” error in the browser 😦

It turns out that you need install it on the 64-bit version of Ubuntu 14.04. No more Bad Gateway. I discovered this requirement whilst troubleshooting – Facebook do not tell you this! I was previously failing with the 32-bit version of the OS.

Anyway – I now appear to be good to go!