News items for tag security - Koos van den Hout

In August 2022 I received a report of a cross-site scripting vulnerability in The Virtual Bookcase and the reporter of the vulnerability never replied after I told him there was no financial reward for reporting bugs.

In November the bug report became public at openbugbounty: virtualbookcase.com Cross Site Scripting Vulnerability Report ID: OBB-2858037 - Open Bug Bounty so this confirms my theory of what the vulnerability was. Which I have fixed, but this isn't visible at openbugbounty.

In this case the vulnerability wasn't severe and with the little amount of information I had from the report plus the access logs I was able to fix it. But in other cases the vulnerability may be more complex and the site-owner who deals with a report like this can't just analyze the logfiles to get an idea of where the vulnerability might be.

I don't think the world becomes a safer place if information about vulnerabilities is only available if you pay for it.

The About the Project of the Open Bug Bounty project seems to promote actual 'bounty':

A website owner can express a gratitude to a researcher for reporting vulnerability in a way s/he considers the most appropriate and proportional to the researcher's efforts and help.

As a matter of example, Google pays from $7,500 to $100 per XSS vulnerability submitted by security researchers. But Google is Google, you may adjust your remuneration range to any amounts comfortable for you.

At the same time demanding a bounty before disclosing the bug is not ok on this platform. From the same 'About' page:

We always encourage the researchers to be respectful, responsive and polite, to provide website owners with all reasonable help and assistance.

If a researcher violates the enacted standards of ethics and good faith including but not limited to:

• demanding remuneration to delete a submission
• demanding remuneration to disclose vulnerability details

such submissions will be immediately deleted from our platform.

I hope the next vulnerability disclosure causes less irritation.

On 9 December this year was the annual SURFcert Capture The Flag (CTF) event. The end result is that team "I'm not a robot" from Radbout University Nijmegen won with the most points.

When I participate in a CTF, I like to keep notes and write about my experiences and what I learned solving the challenges. Being on the 'other' side creating the challenges is as much fun, but while creating the challenges you have to be really silent about it. For me personally it is extra challenging because one of the regular SURFcert CTF players works with me in the same team.

But sometimes designing a challenge and making it happen gives the same great feeling as actually solving it! This was the case with the challenge that ended up as Scan the radio on the SURFcert CTF. The name of the challenge was somewhat confusing by design: there was a challenge which was designed to make people use a 1990s style ghettoblaster radio, there was a challenge mentioning 'broadcast' which was actually about names of wifi networks and this challenge. All three were marked 'physical' with a description of the challenge.

For this challenge I wanted to create an NFC tag that could be read easily. I found out information can be put in NFC tags using the NDEF standard (NFC Data Exchange Format) which has options to embed URLs, options to start certain apps or simple strings. I wanted a simple string with a flag as our flag format was SCF2022- plus 32 characters uppercase. I found out the developer of proxmark is working on NDEF support but it is all quite new.

At this point I was worried I had to write my own code and use parts from a fresh library to get an NDEF message on a card. I did bring some MiFare classic cards home to test on. But searching for information I came across NDEF and Magic Mifare Cards with the very important remark:

My suggestion would be to get an Android phone with nxp reader chip (there are many) and use tagwriter from NXP to format and write ndef data to the Mifare classic chip.

I do have NFC TagWriter by NXP on a smartphone, I just haven't used it a lot.

And indeed it was really easy to create an NDEF dataset with a string, write this to a MiFare classic and read this with an Android phone with NFC support, even without opening the NXP TagInfo application.

So that was an easy challenge to make, a lot easier than I first thought. Or was it? The final test would be to read this on an Apple iphone too.

And there came the snag, the Apple iphone doesn't work with MiFare classic tags somehow. But the person who helped me test it had another tag with an NDEF message on it, and that worked fine. So the conclusion was that another type of tag would work better. Luckily one of the other people of the team creating the SURFcert CTF has a big collection of NFC tags and it turned out the tag given out by Tweakers reads fine on Android and iphone.

So that's how the 'scan the radio' challenge was to notice the clearly not from 1992 tweakers tag on the ghettoblaster radio, scan it with the standard NFC support in a smartphone or use NXP TagInfo and find the flag.

While creating this challenge I also tried writing information to the tags which were given out / sold about 15 years ago which looked like a circle with a hex serial number. I always assumed they were just a serial number to look up in a database. But they turned out to be actual NDEF tags with the hex serial number on the outside as an URL:

For the tag with 04B7CC193E2580 on the outside:
protocol 01 http://www uri field ttag.be/m/04B7CC193E2580

But ttag.be has changed owners since this was active and it's now redirecting to 609.es which is a real-estate agent in Spain. I guess everybody who scans a round tag with a serial number wonders how they end up with a real-estate agent.

Ik heb een tijd niet over de bitcoin afpersingsmails geschreven, maar deze kwam vandaag voorbij in redelijk goed nederlands. Het leest alsof de originele taal anders is maar het is goed vertaald zonder kromme zinnen.

Helaas begin ik met slecht nieuws voor je. Enkele maanden geleden heb ik toegang weten te krijgen tot het apparaat waarmee je nu op het internet zit te surfen. Sinds die tijd heb ik al je internetactiviteiten bijgehouden.

Omdat je een regelmatige bezoeker bent van pornosites, denk ik dat je nu even op moet letten. Je hebt je lot namelijk zelf in de hand. Ik zal het simpel houden, ik via de website die je hebt bezocht toegang gekregen tot je gegevens.

Ik heb een trojan horse geupload naar het driver systeem die zijn fingerprint meerdere keren per dag blijft updaten, zodat het onmogelijk is voor jouw antivirus software om hem te detecteren. Bovendien geeft deze me toegang tot je camera en microfoon. Ook heb ik een back-up gemaakt van alle gegevens, inclusief foto's, social media, chats en contacten.

Maak het bedrag van 950 USD in BTC over naar mijn Bitcoin-wallet, en ik zal deze hele situatie laten rusten. Ik garandeer dat ik alle data en video's permanent zal verwijderen zodra de betaling is ontvangen.

Dat lijkt me een bescheiden en redelijke vergoeding voor al mijn harde werk. Je kunt zelf wel uitzoeken hoe je Bitcoins kunt kopen met behulp van zoekmachines als Google of Bing, want dat is allemaal helemaal niet zo moeilijk.

Mijn Bitcoin-portemonnee (BTC): 1CKiipxrHHRz4HFWMxk6Q4v5hGUs7vHPML

Hier staat al een melding van iemand die hetzelfde mailtje heeft ontvangen, waarmee gelijk duidelijk is dat de afzender helemaal niets heeft maar het leuk zou vinden als de bitcoin-wallet bijgevuld wordt.

Er staat ook een link naar een site die beweerd je te helpen als je het slachtoffer wordt van bitcoin-oplichters. Die hulp zorgt er dan voor dat je twee keer het slachtoffer wordt van bitcoin-oplichters, dus dat is ook niet aan te raden.

From a perspective of security research I only touched the surface of the security research on the Corinex CXWC-HD200-WNeH and the Cab.Link CLS-D4E2WX1 by finding default credentials for telnet.

To get a further insight I need to first enumerate the network attack surface completely. What services are running, what programs run those services.

The ultimate step would be to build an emulation environment where I can run the programs from the routers under my control and find out about the programs and get a first few steps into reverse engineering. With qemu it is possible to emulate MIPS systems on x86 hardware, so I can build a test environment.

It would need some work to get old enough versions of code and kernels to create a compatible environment. The Corinex router mentions compilation in 2012 but with Linux kernel 2.6.21 which was released 25 april 2007. The Cab.Link router mentions compilation in 2013 but uses Linux kernel 2.6.31 which was released 9 september 2009.

After getting a good look at the Cab.Link CLS-D4E2WX1 from the outside it was time to void the warranty and open the box. The two screws are hiding under the little rubber feet at the front side and after removing those two screws the case opens with a bit of jiggling.

This device has an external 12 volt 1 ampere power supply.

Chips found on the board:

• Realtek RTL8306E - 6-port 10/100 mbps ethernet switch controller
• Winbond W9412G6KH-5 - DRAM 128MBIT memory
• Qualcomm QCA7411L-AL3C - Homeplug AV / IEEE 1901 the ethernet over cable interface I guess

I also see an extra board (leftside of the picture, blue) where the u.fl cable to the wifi antenna starts. It has a few larger chips but those have a label over them. I guess one of them must be the CPU because I haven't seen a chip with that function yet.

The makers of the Cab.Link CLS-D4E2WX1 were kind enough to include 4 pins labeled J30 (bottom left of the picture) which are a very obvious candidate for being the uart port. Again the process for find GND, TX, RX and Vcc was done and the right pins found. With the board in front and the J30 readable the pins are from left to right TX, RX, GND and 3.3 volt. I name the TX and RX pins from the view of the system, so I see data transmitted on TX and I send data to RX.

Weer een verse phishing mail, met dit keer de qrcode inline. Het pad:

• URL uit qrcode: http://lnkiy.in/MejZA
• Redirect: https://t.co/IwUW4C65FX
• Redirect: https://rebrand.ly/96piay7
• Redirect: https://s.id/1ph8T
• Redirect: https://gezat.co.tz/wp-admin/includes/kvk.php
• Redirect: https://21989-4437.s1.webspace.re/KVK/
• De echte phishing pagina! Eindelijk. Deze stuurt de ingevulde data naar https://21989-4437.s1.webspace.re/KVK/tmg1.php
• Daarna komt een redirect naar https://21989-4437.s1.webspace.re/KVK/2.php en die geeft uiteindelijk een redirect naar een KVK pagina.

Als ik kijk bij het overzicht Kamer van Koophandel - Fraudehelpdesk zie ik mijn specifieke bericht er niet tussen staan, maar er is keuze genoeg. Allemaal fraudepogingen, dus trap hier niet in!

The earlier Ethernet over Cable modem/router I poked at didn't come alone, from the same source I also got a Cab.Link CLS-D4E2WX1 cable modem/router.

Doing a search for it finds actual listings for trying to order them wholesale: Buy Wholesale China 7400-eoc Slave Modem, Separate Tv And Ethernet From One Cable, 4 Ethernet Ports Output & 7400-eoc Slave Modem at USD 127 | Global Sources and Eoc Male Slave 4 Ethernet Port With Wifi - Buy Eoc Esclavo Product on Alibaba.com.

Both listings call it an EOC slave. Given the terminology I expected EOC master devices to exist as well and I soon found out those exist and can be pricey. So I'm not going to spend money on this subject, but I may be interested in recycling an EOC master unit.

The unit has one external wifi antenna, 4 ethernet ports, external power supply 12V and 9 leds. The cable connection is via 2 female F connectors with one labeled 'Cable' and one labeled 'TV'. I do notice the case has a lot of ventilation holes.

On the underside is a label with the manufacturer name, model name, a default equipment management IP 10.10.1.250, a Wireless Network Name 'wifi' and the EOC and Wifi Mac addresses as numbers and barcodes, and the serial number as number and barcode. The unit has four little rubber feet (full LRF support) and two of those are hiding screws to open the unit.

On switching the Cab.Link router on I indeed see a wifi network appear with the name 'wifi' which on connecting gives me an IPv4 address in the 192.168.1.x range with the default gateway 192.168.1.1.

The Cab.Link router has a web interface listening on port 80. It directly asks for http authorization but using admin/admin for username and password gets me right in. Up until now I haven't found any reference to PLC or EOC in the webinterface.

The Cab.Link also has a telnet server running on port 23. It greets me with an OpenWRT banner but the first few attempts at finding username/password do not let me in:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
WARNING: telnet is a security risk
OpenWrt login: admin
Password: 
Login incorrect
OpenWrt login: root
Password: 
Login incorrect
OpenWrt login: 

I like the 'telnet is a security risk' warning!

A comment on irc made me have a look at the logs for my haproxy system to get an idea whether any weird vulnerability scan came by. No special vulnerability scan showed up, but my attention was drawn to a number of lines like:

Nov 18 08:05:01 wozniak haproxy[13987]: 2001:470:1:332::28:37618 [18/Nov/2022:08:05:01.900] https-in/1: SSL handshake failure
Nov 18 08:05:44 wozniak haproxy[13987]: 2001:470:1:332::28:27286 [18/Nov/2022:08:05:44.328] https-in/1: SSL handshake failure
Nov 18 08:06:22 wozniak haproxy[13987]: 2001:470:1:332::2e:3137 [18/Nov/2022:08:06:21.962] https-in/1: SSL handshake failure
Nov 18 08:06:22 wozniak haproxy[13987]: 2001:470:1:332::2d:33085 [18/Nov/2022:08:06:22.278] https-in/1: SSL handshake failure
Nov 18 08:06:22 wozniak haproxy[13987]: 2001:470:1:332::2d:17531 [18/Nov/2022:08:06:22.593] https-in/1: SSL handshake failure
Nov 18 08:06:22 wozniak haproxy[13987]: 2001:470:1:332::30:58869 [18/Nov/2022:08:06:22.915] https-in/1: SSL handshake failure
Nov 18 08:06:23 wozniak haproxy[13987]: 2001:470:1:332::2e:46537 [18/Nov/2022:08:06:23.228] https-in/1: SSL handshake failure
Nov 18 08:06:23 wozniak haproxy[13987]: 2001:470:1:332::29:20027 [18/Nov/2022:08:06:23.544] https-in/1: SSL handshake failure
Nov 18 08:06:24 wozniak haproxy[13987]: 2001:470:1:332::31:13423 [18/Nov/2022:08:06:23.872] https-in/1: SSL handshake failure
Nov 18 08:06:24 wozniak haproxy[13987]: 2001:470:1:332::28:56683 [18/Nov/2022:08:06:24.197] https-in/1: SSL handshake failure
Nov 18 08:06:24 wozniak haproxy[13987]: 2001:470:1:332::31:5055 [18/Nov/2022:08:06:24.524] https-in/1: SSL handshake failure
Nov 18 08:06:24 wozniak haproxy[13987]: 2001:470:1:332::2e:20907 [18/Nov/2022:08:06:24.841] https-in/1: SSL handshake failure

If there is one of two of these lines from one address, it is a sign of a client which can't finish the SSL negotiation. With my site that probably means and old client which doesn't understand LetsEncrypt certificates without an extra certification path.

But this is quote a number of SSL errors from the same IPv6 range in a short time. I wondered what was behind this and did a bit of testing, until I found it's simple to cause this by doing an SSL test. For example with the famous Qualys SSL test or with an ssl scan tool. This is logical: ssltest uses a lot of different negotiations to test what actually works.

I closed the case of a vulnerability in the Corinex CXWC-HD200-WNeH with a confirmation from the vendor that this is a device completely out of support. Which confirms the public information I found when I started looking into this device. This was all related to the course in hardware hacking I took and applying the new knowledge.

So now I can look back on this experience and think about my future here. Hardware hacking has serious links to my current job as technical security specialist. In my work I regularly have to look at vulnerabilities and assess the chance and impact of misuse of the vulnerability. With hardware hacking I find vulnerabilities by researching hardware. This helps me understand the chance and impact factor of other vulnerabilities.

There is also a link to my education: part of that was MTS electronics. I learned how to solder, before SMD components were a thing and I think I got some explanation about switching mode power supplies at the end. As I got into computers I didn't do much with this education but the last years in amateur radio have made me get out the soldering iron again.

There is a clear link to my hobby of amateur radio. My interest in amateur radio is linked to wanting to know how things actually work. Hardware hacking is also done with RF signals so I may get into more RF related hardware hacking.

My current thought is that I want to continue in this subject. It's given me joy: getting into a device in new and unexpected ways gives joy! I have learned new things. I noticed I need to feed the brain regularly with new information and actually learning something new is much better brainfood than browsing social media. At the same time social media is the way to learn more about this subject and interact with other people interested in this subject. I ended up on /r/hardwarehacking on reddit and already learned from others and shared some of my own insights!

There is the thing about RFID/NFC security. I have looked into this in the past, mostly by getting the tools to peek into the MiFare classic cards. I am considering going further with this area of hardware hacking. Prices of hacking tools for this area like the proxmark3 or the flipper zero are above the 'nice to try a few things' level. On the other hand I think I could have loads of fun there, and the overlap with amateur radio is very clear.

At the end of this bit of writing: thanks to people who share their hardware hacking experiences on-line! Thanks to Jilles Groenendijk, Router Archeology: Sitecom WL-330 - Habbie's journal, @Flashback Team on youtube, Make Me Hack on youtube, and Boschko Security for sharing their stories and knowledge.

Ik zag een phishing mail met daarin een qrcode om te volgen. Dat is natuurlijk een manier om te voorkomen dat mailscanners direct de URL herkennen als verdacht. Alleen wilde mijn mailclient die afbeelding niet zomaar inladen want remote, want dat is allang verdacht.

• Afbeelding: https://qr.de/code/ySVDbB.png
• URL uit qrcode: https://qr.de/ySVDbB
• Redirect https://lnkd.in/dqiBJCcD
• Redirect http://bit.do/0214nl85479651
• Redirect https://21981-4426.s3.webspace.re/

En daar is de phishing pagina die om allerlei persoonsgegevens vraagt.

Correctie: was. De pagina is al weg. Maar als een van de redirects bijgesteld wordt door de crimineel gaat een en ander natuurlijk weer verder!

Als ik kijk bij het overzicht Kamer van Koophandel - Fraudehelpdesk zie ik mijn specifieke bericht er niet tussen staan, maar er is keuze genoeg. Allemaal fraudepogingen, dus trap hier niet in!

Update: De qr.de redirect is zelfs weg, dus de crimineel zal nieuwe spam mails moeten versturen.