Rhys Industries

The boring introduction

I’ve recently been interested in access control systems, vaguely inspired by an information risk management module I took last year. As part of the module, I had the opportunity to take a “deep dive” on RFID security to determine whether a faux hotel’s security systems were up to scratch – spoiler, they were not.

From my own research following the module, I decided I wanted to purchase a Proxmark3 RDV4.01. Following a further look at my bank balance, I decided the Proxmark3 Easy would be far more appropriate. It does also make more sense with my use-case in mind; I’m not looking to perform in the field penetration tests, I’m looking to research (play around with) RFID card security systems at my leisure.

Fortunately, there are a couple of vendors where you can purchase devices pre-flashed with Iceman firmware, and I decided on KSEC labs as my vendor of choice – Lab401 would have been my second choice. These pre-flashed devices mean you don’t have to bother with bootloaders, and worry about bricking your device – this can be an issue with the cheaper clones sold. I also found that the “cheaper” clones were only a few pounds cheaper, so I decided a more reputable buyer would be beneficial.

Even more fortunately this isn’t a blog on the set-up of the environment and device, so I won’t bore with the details – I followed the excellent tutorial created by Dangerous Things, you can find it here: https://youtu.be/o6WOTM4D970

The less boring “research”

After purchasing and setting up the working environment, it was time to investigate the technology embedded in the cards I’ve been carting around in my wallet – both my Swift card and University ID card use RFID technology. Since I’m not going to break any laws, and ideally don’t want to void any policies I did check the University policy on card usage:

Fortunately I’m not even particularly able to do that, seeing as the card is a Mifare Classic 4k card, with a 4-byte UID; with the Proxmark3 Easy I also received a Mifare Classic 1k magic card. Sadly, 4k ≠ 1k. Therefore I may as well crack the encryption, dump the data, and see what they’re storing about me on the card – it is my data after all, and there’s no policy telling me I can’t.

As the above screen capture shows you (found by running the “auto” command), we’re dealing with a Mifare Classic 4k 4-byte UID card – vaguely rare, seeing as most available “magic” 4k cards seem to be of the 7-byte UID variety. In the context of Mifare cards, “magic” cards refer to a card’s ability to change the usually static UID (Unique ID) of a card – something that should worry you if your security solely relies on simply checking the UID of the presented card. These are also known as UID-Writable cards; the “magic” refers to the magic bytes used to write to the original faux Mifare cards. Lab401 already has a great article on the matter, which can be found here: https://lab401.com/blogs/academy/know-your-magic-cards

Just for clarity’s sake, I’ve included a scan of Mifare Classic 4k Magic 7-byte UID card below. In my experience, it’s very easy to confuse a 4k 4-byte UID and a 4k 7-byte UID magic card when purchasing them online.

Having modified the data on the card, I appear to have changed the data such that it identifies as being manufactured by Motorola – I doubt the authenticity of this claim.

The capabilities of the Iceman firmware

With the Iceman firmware, a huge variety of options are available specifically for manipulating Mifare Classic cards. I’ve included the options related to key recovery below – I might do a specific post on the different types of attack in another post, however we’re going to focus on the most boring of all here – the “autopwn”.

This attack will attempt to automatically break the encryption via different methods until a successful one is found – in the case of this card, a nested/hardnested attack is used. The details of this attack are a little above the complexities of this post, so I’ll save them for a later one. The attack takes some time to complete, which gives you time to regret buying the wrong UID size magic card, something very easy to do.

After all that regret, we get the encryption keys – lovely.

We also get a message telling us that a MAD key has been detected – on running the command given, it tells us what is stored where on the card, useful stuff.

We can then use one of the operations that the Iceman firmware gives us to view the data stored in those sectors; the “rdsc” command in particular.

After specifying which key (A or B) to use, as well as the sector number, it gives us an ASCII decode of the data stored. All of this data makes sense, bar the “xw” at the bottom – the numbers represent dates between which the card is valid – I wonder if changed the card would still be accepted by a reader? The stray “xw” is also worth wondering about – it could denote student status, or perhaps course.

The first sector solves that question by revealing my student ID number, my student status, but it also repeats the dates that my card is valid between.

The third sector then shows my department, WMG – this is assumedly for access control, allowing me to use my card to open doors in their buildings – or it could simply hold the information in case the card is queried. Again, “xw” features at the end of the data.

The fourth and reserved sector of the card also contains information about the university as opposed to me personally – I wonder if it’s reserved because it’s set by default to all cards the university programs?

The reason I’m not taking a dump of the card and then reading through the data is due to the universities policy – by reading the data live from certain sectors, it means I don’t copy the data at any point. However it does have the negative trade off that I have to have the card on the reader at all times.

A Conclusion

I’m a big fan of the Proxmark3 Easy, and I think it enables a lot more people to explore the world of RFID that wouldn’t have otherwise been able to – which includes cheap students like myself. I’ll continue to play around using the Iceman firmware (obviously legally). I might have to invest in a little lab set-up if I want to explore cloning cards, it’s either that or find a card in the real world with a lax policy – either way I’ll post any updates on this site.

Disclaimer – this blog is old, and was imported from an old site – remember this when reading what’s below.

The script in question

The script I’ve written is designed to provide an easy user interface for performing de-authentication attacks against known devices. For those who don’t know, a de-authentication attack is one that removes a targets connection to the access point it’s connected to. The specifics of how this works are explained later in the post

I decided to do this after finding it inconvenient to perform the attacks manually, what with the large amount of both command syntax and raw data that is necessary for the attempt to be successful. I figured it would be far easier to spend several days straight creating a script rather than an extra minute every now and again. The script is designed to work best on networks that have already been infiltrated, as then the internet providers own router hosted site can provide an accurate list of both the MAC addresses that are essential and the custom device names that make the script particularly useful and unique. It’s functionality is entirely based around the pre-existing suite of aircrack-ng tools, information on which can be found here: https://www.aircrack-ng.org/. These tools are some of the most commonly used in cracking (breaking into) WiFi, particularly networks with outdated WEP and WPA security.

In my attempts to give this blog the semblance of being useful to people interested in my coding style and experience for genuine reasons, I’ve uploaded the project to GitHub, which can be accessed through the provided URL at the bottom of the post.

I’ve decided to be original and split my code into small sections, so that I can then delve into these sections in reasonable depth one at a time. That way if a particular area takes your fancy, you can skip to the relevant sub-title.
Libraries and startup()

The libraries in question shouldn’t be surprising to anyone who’s attempted to integrate other tools into a python script without much work or effort required. However, I feel I could have avoided using sys, as it was only used in a single line of the program, highlighted below.

Although there may be a more elegant solution out there, I decided that throwing an entire library at the issue was the most python-esque way of dealing with the problem.

For those unaware, the os library allows python to essentially use the command line of the host OS – in this case, by running this command:

This command opens up a separate terminal window running the tool needed to set the wireless interface, wlan0, into monitor mode. This allows the interface to inject packets into wireless devices, in a similar fashion to how a router does. Monitor mode isn’t available to all hardware, so you should take care if you wish to experiment with WiFi based penetration testing. This process also renames the interface from wlan0 to wlan0mon, which can clearly be seen referenced in the rest of the code.

The rest of the code

The largest chunk of the code can half be seen below:

Creatively named “main”, this function contains almost all the actual functionality of the code. It begins by creating variables that would otherwise cause errors if left undefined.

The next section of code, which could easily be its own function if the program was modulated correctly, is entirely focused on formatting the “addresses.txt” text file into a format usable in the program. I’ve included a copy of a default template in the git-hub project, as well as a screenshot below.

The text file is designed to contain all the information needed to run the program, namely the BSSID of the access point, and the device names with their associated MAC addresses. At this point in time the user of the script would have to enter in the data manually – but only once per access point. Although the formatting of the text file could be seen as the most vanilla part of the project, it probably cost me the most amount of time debugging, potentially due to my previous experience with Python 3. However my efforts proved not to be in vain, with the BSSID being stored separately to the rest of the data which is instead stored in a dictionary for easy calling of specific MAC addresses.

The last part of the code in this section lists the devices names, and prompts the user to select one. Again, note the slightly forced input validation.

The rest of the code part 2

Pictured above are the main workings of the script, in which the last user input is required in the form of a timeout length desired. I decided to use the “timeout” Linux tool to easily set a limit should the user desire, with the program first checking if “-1” had been entered, which would ensure the attack ran indefinitely. In either case, the following command had to be run.

This line is potentially the most confusing of the script, so I’ll break it down in a table.

Code	Description
os.system(“”)	Runs the string within to the Linux command line
xterm -e	Whatever string follows it will run in a newly opened window
timeout 5	Sets the command following to run five seconds
airodump-ng	Starts the airodump-ng tool
-d “+ BSSID	Filters the output to only display hosts of the correct BSSID
-c 11	Sets airodump to only search on channel 11
wlan0mon	Sets the interface used to wlan0mon

This line is necessary because another tool used in the script, aireplay-ng, is unable to distinguish which channel the network devices are communicating on when run first. In my extensive five minute testing session I found that the easiest method of ensuring the script would work on startup is to run this line, which essentially “discovers” the local networks – in this case filtered so that only the target access point is found. This apparently allows following probing of the network to run smoothly, perhaps due to the details of the network being saved into cache memory. In either case, it causes the following window to appear. Each line shows a de-authentication packet that has been sent.

The most important line of the script is also in this final section, in two separate variations – one includes a time cap, using the users input, and the other does not. The line can be seen in its timed variation below.

Due to the fact that the first three portions of the line have been explained already, I’ve decided not to indulge in another table.. “aireplay-ng” refers to the tool being used here, which is designed to inject packets into a device or devices. The content, type, destination, and frequency of the packets are determined by the commands “arguments”. Arguments are given to the command in the format of “command -argument_name argument_value”. In this particular case, the first argument given is “-0 0 “, referring to the fact that de-authentication packets should be sent without stop. These de-authentication packets are what interferes with the targeted device’s connection, as they essentially block the communication from both the access point and the target device. This is a concise explanation, and I can recommend the following Wikipedia page: https://en.wikipedia.org/wiki/Wi-Fi_deauthentication_attack. The next argument used is “-a”, followed by the BSSID that was taken from the text file used for data entry. This argument sets the access points MAC address, needed as this specific attack sends packets to both the AP and the target. The next argument, “-c “,followed by the MAC address associated with the device name selected earlier reinforces this. Almost finally, the argument “-x 15” is used to set a custom number of packets to be sent per second (surprisingly 15 in this case), as I found the default would still allow the target to communicate with the AP somewhat. Finally, “wlan0mon” is once again used to distinguish the wireless interface being used.

The last interesting line run by the script is as follows.

Using the same tool as first used, this will put the wireless interface back into “managed” mode, allowing for normal use of the device – as I discovered in far too long a time period, you cannot use a wireless adapter in monitor mode for normal internet browsing or indeed connection.

A conclusion of sorts

To draw an end to this blog, I thought it would be wise to finish with a witty and inspired quote. Unfortunately I couldn’t think of any. If you’ve managed to read this far, I can only give you my congratulations – and a link to the git-hub repository. In terms of plans and projects for the future, I already have a few ideas up my sleeve. I’ll leave you with the (hopefully) functioning URL for you to clone the repository for yourself.

https://github.com/rdav1es/kick_known.git

Rhys Industries

Posts

How not to use a Proxmark3 Easy

Using Python to easily deauth devices on a network.