News items for tag security - Koos van den Hout

I noticed two weeks ago the number of IPs causing failed sshd login attempts as measured by fail2ban was dropping. It was dropping so far I did some tests to make sure all the rules were still working.

Things have returned to 'normal' now, attempts are back and quite visible in the graphs.

My favourite mix of subjects: security (or lack of security) and RF signals.

Joseph Gabay has researched how shopping carts with wheel locks are locked and unlocked, and found out it's really easy to replay these signals. The signals for the shopping carts with wheel locks from Gatekeeper systems are at 7.9 kHz (ELF or extremely low frequency) and at 2.4 GHz (UHF or Ultra High Frequency and the license free range also used by WiFi and Bluetooth).

After a lot of work with a coil to act as a (bad) antenna for 7.9 kHz he found out the magnetic field of a speaker in a smartphone can also create the field and do replay attacks via audio files.

All of this at Control Shopping Cart Wheels With Your Phone! including the video of the Defon 29 presentation about this.

Now I really wonder how the shopping carts at our nearby supermarket work! I know it is a wire loop in the parking lot, I've seen the loop transmitter in the supermarket.

Found via Issac Kelly: "Somebody linked this to me rec…" - Mastodon

Update

The nearby supermarket uses the Rocateq system which operates on 8.13 kHz. So I can probably do the same replay attacks to these carts. Found by taking a picture of the loop transmitter in the supermarket and checking for the name in some variations at the searchable FCC ID Database and finding COP Caster STD&OCS; COP User Manual Zhuhai Rocateq Technology which lists the VLF frequency: 8.13 kHz.

Somebody gave me a tag 'once used to access the bicycle parking at work' because of my interest in RFID tags. So I checked the tag with the proxmark3 and the proxmark3 had no trouble finding the keys and getting full access in very little time.

I made sure that these tags are no longer used because otherwise I had a good argument to replace that system fast! And they are indeed deprecated, which also means I can write about my experiences without causing new risks.

It's already known the mifare classic is insecure, no news here. But seeing how fast a current proxmark3 can find the keys and dump the contents of the card with the full access confirms this insecurity again.

First I tried seeing what kind of tag this was:

[usb|script] pm3 --> hf search

[+]  UID: 6A BB 43 5C 
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Prng detection: weak
[#] Auth error
[?] Hint: try `hf mf` commands


[+] Valid ISO 14443-A tag found

[usb|script] pm3 --> hf mf list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 68 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)

      Start |        End | Src | Data (! denotes parity error)                  
                         | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |       2048 | Rdr |0d  37  21! 92  f2                                                       |  !! | 
      32544 |      34592 | Rdr |5d  37  21! 71! 71                                                       |  !! | 
      35808 |      36064 | Rdr |a1(1)                                                                    |     | 
      37088 |      37344 | Rdr |a3(1)                                                                    |     | 
      38368 |      38624 | Rdr |a5(1)                                                                    |     | INCR(0)
      39648 |      39904 | Rdr |a7(1)                                                                    |     | 

So far I've read the public information the card gives to any compatible NFC reader.

While working with the other NFC tags I had a crazy idea: what if I can 'recycle' used one-time public transport tickets as NDEF tags. The one-time public transport tickets are mifare ultralight tags just like the touchatag tag.

I've been interested in RFID and RFID security for years, the first post on my website is from 2010: I found out this week that the rfid card my employer uses to give out coffee is also a mifare classic card. Since that moment I collected all kinds of contactless cards with the idea to check into their security. Mostly from our wintersport holidays since ski passes use rfid technology to make reading them on wintersport easy.

Now the time has come to check my collection with the proxmark3. The simple approach is to scan for tags with lf search or hf search.

Touchatag tags

In 2010 these were a great idea to put tags on products. These are Mifare Ultralight MF0ICU1:

[usb] pm3 --> hf mfu info 

[=] --- Tag Information --------------------------
[=] -------------------------------------------------------------
[+]       TYPE: MIFARE Ultralight (MF0ICU1)  
[+]        UID: 04 C8 54 19 3E 25 80 
[+]     UID[0]: 04, NXP Semiconductors Germany
[+]       BCC0: 10 ( ok )
[+]       BCC1: 82 ( ok )
[+]   Internal: 48 ( default )
[+]       Lock: FF 7F  - 1111111101111111
[+] OneTimePad: E1 10 06 00  - 11100001000100000000011000000000

It's been a while since I played with rfid technology but recently some news around LF cards has made me interested again. The proxmark3 is the best device for going deep with rfid technology so I considered buying one.

Reading various sources about the availability of proxmark3 hardware taught me the latest and greatest version (currently Proxmark3 RDV4) has not a lot of advantages over the previous version (RDV3) which is available at seriously lower prices from several webshops. So I ordered one using aliexpress and the wait started.

Today the proxmark3 came in. I built the software for Linux using the guide at proxmark3 Linux Installation Instructions where I noticed I had to add packages libbz2-dev and gcc-arm-none-eabi by hand to get things to compile/build correctly.

After doing the firmware upgrade dance I started testing and looking around. The proxmark3 detects 125 kHz (LF) and 13.56 MHz (HF) cards fine. With the order came a blank card which is both a 13.56 MHz Mifare 1K with changeable UID and a 125 kHz T5577. There were also two small keyring tags, a mifare 1K and a mifare 4K.

First attempts

The proxmark3 shows information for all the cards I tried. To my surprise the skipass from our last ski trip to Austria was an HF only card, I thought ski passes used 125 kHz technology so they could be read through jackets or other layers more easily. It's an ISO 15693 tag and I can access all data easily.

[usb] pm3 --> hf search 
 🕗  Searching for ISO15693 tag...            
[+]  UID: E0 16 24 66 09 99 B3 70
[+] TYPE: EM-Marin SA (Skidata); EM4233 [IC id = 09] 23,5pF CustomerID-102

[+] Valid ISO 15693 tag found
[usb] pm3 --> hf 15 info

[+]  UID: E0 16 24 66 09 99 B3 70
[+] TYPE: EM-Marin SA (Skidata); EM4233 [IC id = 09] 23,5pF CustomerID-102
[+] Using UID... E0 16 24 66 09 99 B3 70

[=] --- Tag Information ---------------------------
[=] -------------------------------------------------------------
[+]       TYPE: EM-Marin SA (Skidata); EM4233 [IC id = 09] 23,5pF CustomerID-102
[+]        UID: E0 16 24 66 09 99 B3 70
[+]    SYSINFO: 00 0F 70 B3 99 09 66 24 16 E0 02 00 33 03 02 
[+]      - DSFID supported        [0x02]
[+]      - AFI   supported        [0x00]
[+]      - IC reference supported [0x02]
[+]      - Tag provides info on memory layout (vendor dependent)
[+]            4 (or 3) bytes/blocks x 52 blocks

As all the tag readers in that ski area are on-line anyway, I guess the card is just a big serial number and all the checking whether the user isn't trying to do something that wasn't paid for is done in central computers.

First error

While trying to clone an LF card into the T5577 I managed to make the T5577 card end up in a weird state: it now only returns 0x0000 or 0xFFFF patterns on read depending on the communication configuration.

I noticed in 2016 that putting services like ssh on a different port does not change much in the attacks and the last few days I noticed this is true as ever.

I use fail2ban for sshd and other services that are prone to brute-force attempts. I've been using influxdb and grafana to visualize measurements and I use telegraf to gather a lot of system data.

I recently enabled gathering fail2ban statistics and it's interesting to see the numbers of blocked addresses is very similar for the sshd on port 22 and the sshd on port 2022. It's not exactly the same number and interestingly not the same attackers but the numbers are within 5%. And yes the numbers are high enough to make the output of fail2ban-client status sshd several screenfulls of IP addresses.

My PGP key expired, but I reset the expiry date. I do this so I have to actively update the key every few years. Should I ever lose access to the private key, it will go away by itself.

But this also means I have to ask the users of my key to refresh it by hand because the simple refresh doesn't "see" the update (even though this adds new signatures to the key).

So please use the command to receive my 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.

A discussion on irc about how hard it is to set TLS options in some programs made me recall I still wanted courier-imap-ssl to give me the right SSL settings (Only TLS 1.2 and 1.3, and no weak algorithms). This has bothered me for a while but I couldn't find the right answers. Most documentation assumes courier-imap-ssl is compiled with OpenSSL. In Debian/Ubuntu/Devuan it is compiled with GnuTLS.

Searching this time found me Bug #1808649 “TLS_CIPHER_LIST and TLS_PROTOCOL Ignored” : Bugs : courier package : Ubuntu which points at debian-server-tools/mail/courier-check at master · szepeviktor/debian-server-tools · GitHub which lists the right parameter TLS_PRIORITY. And that page has usable answers for up to TLS v1.2, with some reading of the output of gnutls-cli --list I can imagine TLS v1.3 settings.

So with a minor adjustment to the given example to allow for TLS v1.3 I set this in /etc/courier/imapd-ssl:

##NAME: TLS_PRIORITY:0
#
# GnuTLS setting only
#
# Set TLS protocol priority settings (GnuTLS only)
#
# DEFAULT: NORMAL:-CTYPE-OPENPGP
#
# This setting is also used to select the available ciphers.
#
# The actual list of available ciphers depend on the options GnuTLS was
# compiled against. The possible ciphers are:
#
# AES256, 3DES, AES128, ARC128, ARC40, RC2, DES, NULL
#
# Also, the following aliases:
#
# HIGH -- all ciphers that use more than a 128 bit key size
# MEDIUM -- all ciphers that use a 128 bit key size
# LOW -- all ciphers that use fewer than a 128 bit key size, the NULL cipher
#        is not included
# ALL -- all ciphers except the NULL cipher
#
# See GnuTLS documentation, gnutls_priority_init(3) for additional
# documentation.

TLS_PRIORITY="NONE:+CHACHA20-POLY1305:+AES-128-GCM:+AES-256-GCM:+AES-128-CBC:+AES-256-CBC:+ECDHE-ECDSA:+ECDHE-RSA:+SHA256:+SHA384:+AEAD:+COMP-NULL:+VERS-TLS1.2:+VERS-TLS1.3:+SIGN-ALL:+CURVE-SECP521R1:+CURVE-SECP384R1:+CURVE-SECP256R1:+CTYPE-X509"

And now things are good! All green in sslscan:

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve P-256 DHE 256
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve P-256 DHE 256
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve P-256 DHE 256
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384     Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256     Curve P-256 DHE 256

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      secp384r1
ECC Key Strength:    192

I have been given a Genexis Platinum-4410 router with the reasoning that I like to play with embedded systems and test the security. Well, that is what I did.

How far did I get

I have serial console, I have extracted filesystem images, and I can't get a shell on the router.

The device

It's a router with 4+1 ethernet ports, wifi, two ports for analog telephones and a USB interface.

Looking at it from the network

In this specific instance the 4 ethernet ports which are logically the 'inside' don't give me a link after the router has booted up. The 1 port which would be the 'outside' or 'WAN' port gives a link and acts as a DHCP client.

The next step was to connect to the wifi network and play with the web interface. This like a custom web interface. Default credentials which match what is on the sticker on the underside of the router.

The router doesn't have a telnet server listening for 'easy' access.

Opening the case

Next step was to open the case and investigate the mainboard. Chips seen on the mainboard: Mindspeed J83100G System on a Chip (SoC), MXIC MX29GL256FHT2I-90Q flash memory, 2* Etrontech EM68B16CWQD-25H 512 mbit DRAM, Si32260-FM1 dual channel FXS (voip) chip and other electronics.

The mainboard has lots of test points, but no clear UART interface. There is an edge connector which looks like a PCI Express connector but it isn't. I asked help about this: What is this connector, does it include UART on a Genexis Platinum-4410 ? : hardwarehacking because r/hardwarehacking on reddit has helped me before.

This edge connector turned out the 'place to be' and with the standard tricks for finding the UART I soon had an idea. But nothing to stick a dupont wire on and no PCI express or cardedge breakout cable/board available. So I had to solder wires to the right lanes on the connector. I had permission to damage the router, so that was ok. Soldering within half a millimeter was really hard! This was the first time I actually used my soldering iron for hardware hacking. And a magnifying glass to actually see what I was soldering.