Make or break

Single use vaping seriously harms everyone on the planet

2023-09-24T00:00:00+00:00

One of my friends is into vaping and has recently switched to single-use e-cigarettes, which resemble the normal smoking experience: you can buy them over the counter or from a vending machine, it comes packaged with all the warning signs, it is self-contained (no need to charge, refill, etc.), just unwrap the package, vap and when you are done you just throw it away. In summary: convenience. I am not going to go into the health aspects of vaping, anyone is free to do what they want with their body - but instead on the impact it has on the environment and, by extension, everyone else. I guess you could summarise as “Single use vaping seriously harms everyone on the planet”.

Getting into the e-cigarette

For our analysis we have chosen one of the brands that can be easily found available on the street in Gibraltar, “Lost Mary”. The device comes packaged in a cardboard box roughly the size of a cigarette pack.

With the actual e-cigarette measuring 66mm tall x 35mm wide x 16mm thick. The box claims that the e-cigarette lasts for up to 600 puffs.

The exterior body of the e-cigarette unit (marketed as a “pod”) is made up of a metallic main body and hard thermoplastic puffing at the top plus a cover at the bottom. It should be easy to disassemble by removing the plastic cover, however for our analysis we decided to open it with a grinder so that we can see the interior:

The e-cigarette is broken down into clearly separated areas which we discuss in the following sections.

Liquid container

The units I used for analysis had been already “smoked” so most of the liquid was gone, although when new it comes with 2ml of a chemical compound that, according to the package, is FATAL when in contact with skin, so if you are going to open one of these units please take appropriate protections.

The liquid is kept in the soaked sponge, which is protected by a transparent hard plastic case. This, heated up, is what goes into the lungs.

Heating element

I was expecting a more complex mechanism, but the simplicity surprised me. The heating element is a peeled-off cable, wrapped around a cigarette filter-like material that acts as a wick for the liquid stored in the container. The wick pulls the liquid through capillarity to keep it wet, and when electricity flows through the cable / resistor / coil it heats up and creates the water vapour infused with the liquid:

Battery

The largest component in the e-cigarette is the battery, a 3.7v 360mAh rechargeable Lithium Ion battery.

Although the battery is rechargeable the e-cigarette does not offer any functionality to recharge it, once the battery falls below 3.3v the chip flashes the LED 10 times, then shuts down. This is the signal to the owner to throw this pod away, and go get a new one.

The difficulty to access the battery makes it nearly-impossible to recycle, sending all its components into landfill (toxic metals such as cobalt, nickel and manganese) and increasing the change of a landfill fire due to short-circuits.

Electronics

To control the heating mechanism the e-cigarette incorporates a small number of electronic components, all of them integrated in an S085 ASIC or similar:

Electret microphone, which works as a pressure sensor to determine when the user puffs on the cigarette
SMD LED, to let the user know whether it is operational or has ran out of puffs
SMD driver chip, to coordinate the microphone, LED and heater
SMD capacitor. to filter noise from the battery out

Whenever the user puffs on the cigarette, the air starts flowing and activates the microphone membrane at the bottom of the e-cigarette (which works as a pressure sensor). The driver picks up on this and switches on the LED and sends current to the coil, which heats up the liquid and creates the vapour. When the user stops sucking on the e-cigarette, the microphone membrane stops making contact and the driver goes into low-power consumption mode waiting until the next puf.

Whenever the battery is low, the LED blinks to let the user know it is time to get a new pod.

Recycling

It is clear that the number and type of components make this a hard to recycle device:

The pod itself contains plastic, metal, battery, electronics so it will go straight into landfill.

Each pod weights approximately 25 grams, broken down by the components:

Battery: 8g
Metal: 7g
Plastic: 10g

Looks like the only bit that can be recycled is the cardboard package that the pod comes in.

Conclusion

Clearly disposable e-cigarettes are designed for convenience and not for ease of recycling.

If we consider that a smoker takes 15 puffs out of a traditional cigarette on average and that e-cigarette lasts for 600 puffs, it means that a smoker would smoke 2 packs of 20 cigarettes for each e-cigarette pod. The waste generated by two packs of cigarettes are two cardboard packets, the plastic wrappers and 40 filters.

Leaving aside the health implications, if you compare the traditional cigarette waste against e-cigarettes, the amount of waste that is produced after you finish smoking it is much worse in the electronic version. Assuming that a smoker of single use e-cigarettes goes through a pod every couple of days this means that over 180 of each of these will end up in landfill - 180 batteries, 180 electronics, 180 pieces of non-biodegradable plastic and metal casing.

That is 4.5kg of highly contaminant landfill waste each year produced by each single use e-cigarette smoker person. Please consider the implications for the environment before switching to single-use products.

Making it in cybersecurity

2022-10-26T00:00:00+00:00

What’s the fastest / funniest / more satisfying / less risky way to make a career in cybersecurity? Every now and then I get asked by colleagues starting in information security what is the best area for them to focus on; this article summarises my views on choosing a successful career in cybersecurity.

My default answer is to go for the area that you enjoy the most and where you think you can put your skills to work: is it attack or defence skills, compliance work, application security, product visionary… ? This post discusses some of the available paths and roles within those paths to be able to make a living out of cybersecurity.

My views are based on experience and those of friends and colleagues that have taken the various paths described below, however it is still a subjective view. If you disagree or want to add additional career paths or roles just submit a pull-request, always happy to learn.

You can sort the following summary matrix based on your goals and skills:

Nikko Hawg 1/10 RC car transmission steering column replacement

2021-08-23T00:00:00+00:00

The Nikko Hawg RC car piece for the steering-transmission is made of ABS plastic and is held in place through two metal screws which eventually eat into the plastic, loosening the connection and preventing the steering from working. I ran out of replacement screws so decided to 3D print a redesigned piece with nut catchers that would not suffer from the same problem, you can find the STL files on our Deprogramming Obsolescence repository (along with editable OpenSCAD files in case you need to adjust the sizes for other similar Nikko cars). If you modify the designs can you share them back with the community please?

To be fair with Nikko, this piece has withstood on and off usage over the past 35 years, from well before things had a programmed obsolescence :-)

The issue is quite easy to diagnose: one of the wheels starts wobbling to the point that the car comes to a stand-still. When you inspect it closely you notice that one of the screws holding the transmission steering column is missing. This happens because the screw is held in place by threads cast into the ABS piece which eventually wear out and are unable to hold the screw in place:

The new piece has some simplifications over the original design to ease printing, but the key items and strength should be the same. The main change is the addition of an M3 nut catcher which is used to secure the screw, removing the reliance on the plastic:

The piece is symmetric, so you can print it for both the right and left sides of the car.

Considering the shape of the piece I printed it using supports so that the base of the “pipe” rests against the printer bed. While I printed the pieces in PLA it would probably be more sensible to print them in ABS, so they are not as brittle and can withstand the wheels hitting obstacles. I will keep you posted on how I fare.

Once printed the installation is quite simple. Start by removing the original piece from the car and disassembling it: remove the metal drive shaft that connects the transmission to the wheels and then the two white plastic rings that are attached to each end of the piece.

After transferring the rings and drive shaft to the newly printed part, install the two M3 nuts inside the nut catchers by sliding them in with your finger (or with the help of small needle-nose pliers), make sure the nuts are centered on the screw holes.

And that should be it, the result is a one-to-one replacement of the original piece, but with less concerns for losing screws in the middle of a driving session.

RSA SecurID hardware token reverse engineering

2021-07-04T00:00:00+00:00

Reverse engineering an RSA SecurID hardware token to understand its key operation principles and how resistant they are to attacks to obtain the seed vs the software token option.

Hardware tokens vs Software tokens

At work we regularly have the discussion on whether we should introduce the convenient two-factor authentication software tokens to replace the physical RSA SecurID hardware tokens that we all carry around. The outcome of the review is nearly always that software tokens are good and convenient, but they are not as tamper proof / tamper evident as hardware tokens: it does not take much to steal the seed from a general purpose CPU and OS, it can be done without leaving any trace that the seed has been compromised, you do not need physical access to the device - effectively cloning the software token without the user knowledge and completely removing one of the factors.

To be fair it is relatively easy to reverse engineer the soft tokens and point out their flaws, while on the other side we just take RSA’s word at face value when they say that the hardware tokens are tamper resistant.

So, is it really that difficult to steal the seed from a SecurID hardware token or are we just relying on security through obscurity? Let’s find out…

Hardware token theory of operation

Without going too much into detail on how SecurID works, suffice to say that the token and the authentication server are time synchronised and share a secret (the seed). Using the current time and the seed, they use a non-reversible algorithm (older versions used an RSA proprietary algorithm but recent versions have moved to AES) to compute a 6-digit number. This number changes every minute and is not predictable, so it is used by a client to prove to the server that they are in physical posession of the token (the “something you have” factor).

Based on how the SecurID system operates let’s try to make a first guess on how the various components are implemented. For our analysis we are using the SecurID SID700 token, easily the most widely deployed RSA token.

Power

RSA tokens are purchased with a certain pre-programmed lifespan of 2 to 5 years: the longer the lifespan the more the token costs. When you receive a new token after purchase it is already showing token codes every minute, as a matter of fact the token does not have an “off” switch or a “show me my token code” button, it is simple and easy to use: the user just looks at the token and types the number they see.

The tokens are self-contained and are non-rechargeable, the battery that powers the whole system needs to last up to 5 years of continuous operation so this means that the implementation will focus on ultra-low current consumption.

Time synchronisation

While it is easy to keep synchronisation on the server-side, the tokens are totally self-contained so they must include a really accurate oscillator that does not drift substantially over the 3-5 years of token lifetime. The token will be imprinted with the timestamp when it is initialised and will keep track of the number of oscillations since then. The server will need to know, for each token, the time when it was initialised so it can work in sync.

Seed management

When you buy a batch of tokens, you also receive a “seed file” which needs to be loaded into the authentication server. There is nothing for you to do to the tokens, e.g. they come preloaded with the seeds and already showing valid numbers, the only thing you need to do is to assign a token to a user, and they are ready to go.

This means that, at some point in time, a random seed was generated and programmed into the token, the “imprint time” recorded and incorporated into a database at RSA which includes:

Token serial
Activation timestamp
Seed

When somebody purchases a batch, the tokens are shipped from a warehouse and the corresponding database entries are sent to the customer as part of the “seed file”. At this point of time there is no need for RSA to keep a copy of the seeds, however it seems that they actually do keep the seeds after that as highlighted in the 2011 compromise of the RSA SecurID seed database. A good example on how retaining information beyond the point it ceases to be useful is a bad practice and just increases your exposure to attacks.

What would be your guess if you had to venture a reason why they kept a copy of the token seeds?

Updated Dec’2022: Mihai commented on this point (thanks!) and put forward the proposal of RSA keeping a copy of the seeds for customers who lose them, and they may not be too far off: an article published 10 years after the hack reveals the following nugget of information: “Even after the CD was shipped to a client, those seeds remained on the seed warehouse server as a backup if the customer’s SecurID server or its setup CD were somehow corrupted.”

Token manufacture

Because the token arrives with the seed preloaded it needs to be programmed before it gets to us.

The serial number and expiration date of the token are printed on a piece of rubber on the back of the token that is easily removed to expose 7 circuit pads, an expensive arrangement if these pads are used just for testing as part of the manufacturer quality assurance process. Instead we believe that these pads are used to program the token with the seed.

This makes sense as the act of programming the seed into the token requires access to the secrets database to retrieve the serial and seed that the token needs to use, and to record the activation timestamp. It is likely that RSA would want to separate token manufacture from token “imprinting” given the very different security requirements for both processes.

With this in mind we believe that the manufacturing process would be split in two steps:

Assembly: Assemble the circuit and the physical token, likely in a standard fab facility. This step will include manufacturing the PCB, assembling the components, installing the battery and sealing the token. At this stage the token will be running without a seed.
Imprinting: Ship the tokens to a secure RSA facility where the token seeds are programmed using the 7 circuit pads and the serial number plus expiration dates are printed on the rubber cover and the imprinting time recorded in the central SecurID database.

The only sensitive component that would be exposed in step #1 would be the algorithm that would run inside the token, the microcontroller will probably have protections against extractions of the code - and in any event the algorithm is implemented in the soft tokens nowadays, so hardly a secret.

The cost of maintaining security in these separate scenarios would come at the expense of manufacturing efficiency, adding queueing between both facilities which probably explains the world-wide shortage of RSA tokens during COVID-19 due to the increased demand. You can easily ramp up assembly by using additional fabs, but the bottleneck would be the imprinting process as we assume there is a limited number of “imprinting” facilities.

Attacking the token

Hypothesis #1: Dump seed from EEPROM

Because the seed needs to be programmed at the time of imprinting, it needs to be stored somewhere where the microcontroller can access it, likely to be an EEPROM, maybe external to the microcontroller. It is possible that the data is somehow encrypted, but it will be great if we can extract it from the memory using something like eepeep. This is probably a naive assumption as the strength of the device depends on the security of the seed, but then again if we do not test the hypothesis we will never know.

To find out the location of the memory used to store the seed we need to disassemble the token and identify the components that make up the circuit - I used an expired token from my online banking (if you do not have one laying around you can get a batch of expired tokens off eBay).

The external case of the token comes out quite easily, we just apply some force in the hole that the keyring holder is attached to and extract the circuit that is sandwiched between the top and bottom covers:

We can see that it uses a CR2032 3V battery to power the whole circuit, and the only visible areas are the 7 programming pads on one side (along with a few test pins and vias) and the LCD display on the other. The whole circuit is enclosed in semi-rigid transparent resin potting to waterproof the token. The removal of this resin is a matter of patience and exacto-knife and tweezers work, slowly cut into the resin and make sure you do not damage any of the components, then pull away chunks of resin using the tweezers.

You will soon run out of resin and be left with the LCD display that hides the actual circuit so you can try to de-solder it or to pry it away with a screwdriver and a bit more of patience. With the LCD display removed we can see a few components, continue removing the resin (really carefully) until you get as much a clean as PCB as you can, something like this:

There are a couple of interesting markings on the PCB:

P/N 430P000012 REV A4, the part number and revision of this token design
E187451, a UL certificate for LEAD JUMP PCB (ZHUHAI) LTD, likely the fab used for the assembly of the token during the manufacturing process. The logo on the PCB also matches that of Lead Jump.

But that is about it, apart from a bunch of capacitors and resistors there appears to be only two active components:

An SMD oscillator: likely a 32.768KHz clock as used in real-time clock applications - markings on my oscillator are CB701, no datasheet identified.
An epoxy blob which seems to cover the MCU that drives the token.

No external EEPROM or any kind of memory, so the storage must be embedded as part of the MCU - no way to dump it using traditional methods, so let’s think of something else.

Hypothesis #2: Access memory using MCU pin functionality

For this attack attempt we need to understand the MCU architecture underneath the blob. Considering that RSA has manufactured close to 100 million of these devices and that the security of the device depends on the protection of the seed I expect this will be a custom die.

I do not have the lab equipment to remove the epoxy, x-ray the blob or de-layer the MCU so I looked for previous work undertaken in this area. I found the work by Travis Goodspeed who had exposed the MCU and done an initial analysis of the chip, however the resolution of the die images was too low so I could not look at the detail. Thanks to the contribution of Eduardo Cruz he located high-resolution images of the MCU put together by John McMaster.

Looking through the images I found work already done on reverse engineering the MCU in the siliconpr0n archives a few years ago. Going through the material I saw that they had identified a marking in the die “1C573718A” and that led them to the Sanyo LC573718A MCU, a general-purpose 4-bit MCU with some very familiar specs:

Built-in LCD drivers to drive up to 120 segments (the SID700 SecurID token has a total of 49 LCD segments)
Operates at 2.4V-3.6V
Very low power consumption
ROM: 8192 x 8 bits
RAM: 512 x 4 bits
Chronograph function with 100ms resolution
Requires an external 32.768KHz oscillator and a bunch of capacitors

Funnily enough this MCU was originally created to run LCD games (it has a built-in buzzer port for instance). I could not find any references, but it will not be surprising if you found one powering a few Sanyo game watches.

At this stage it is impossible to know if Sanyo customised the MCU for RSA, however the pinout matches 100% that of the chip images (left image from Sanyo datasheet, right image SecurID die from siliconpr0n [credits]):

The datasheet is not very extensive, but it covers the pinout, which can be summarised as follows:

SEG1-SEG32 + COM1-COM4: LCD segment connections
VDD1, VDD2, VDD3, VDDX, VSS, VSSX: Power connections
XT1, XT2: Oscillator input
CUP1-CUP2: Capacitor pins for step-up, step-down (whatever this may be)
P00, P01, P02, P03: 4-bit I/O port
P10, P11: 2-bit I/O port
M1, M2: 2-bit input port
S1, S2, S3, S4: 4-bit input port
ALM: Buzzer output (it would be nice to have a bleeping fob)
RES: Reset
T3, TST, HZ32: Test pins

As we can see there are no references to pins to read/write from memory (or for in-system programming), so either the MCU does not have that capability to access and program memory or it is not documented on the datasheet.

A closer look at the MCU specs shows why there is no functionality to write into the MCU memory: the ROM is actually masked ROM which is written during the die manufacturing process by Sanyo, following RSA specs, and that cannot be modified at run-time. This means that all the tokens share the same ROM contents: static data and program code for the MCU but not the seed - as by the time the imprinting process happens the ROM can no longer be modified.

The only location where the seed can be stored is the MCU SRAM (!), a location that is wiped whenever the MCU loses power. But because the token is designed to constantly run on battery power the RAM is never wiped and the MCU holds the values stored there. If at any point the MCU loses power, the token loses the seed and it goes back to a pre-imprinting state (where the fob flashes with the “888888” message):

(While I was trying to free the old battery I managed to break the LCD, so only the unbroken segments flash - but you get the idea)

Because the SRAM is only accessible internally by the MCU there are no pins that expose its contents, so this attack cannot be progressed any more and the hypothesis needs to be abandoned.

Hypothesis #3: Extract the key from SRAM using die analysis

If the seed is stored in SRAM, can we not extract it directly from the die? Data stored in a SRAM is not optically visible, as each SRAM bit looks the same - to write and modify the bit a voltage is applied and a flip-flop is activated to hold the zero or the 1. Potentially and if you could remove the epoxy and chip cover without disconnecting the power supply you could use a SEM to measure voltage contrasts and systematically dump the contents of the SRAM.

While this sounds plausible this is well beyond my knowledge of electronics, so it is not a hypothesis that I could personally progress. Any comments, views or experiences on this welcome.

Hypothesis #4: Reverse engineer the imprinting process and use it to extract the seed instead of storing it

We have seen that the Sanyo MCU does not have any specific pins to access the SRAM, however this is not totally accurate for the RSA fobs: during the imprinting process the seed must be written to the SRAM using the 7 pads on the back of the token, so there are memory access capabilities through these external pads.

Let’s see if we can understand what each of the pads do and how they fit together to write the seed to the token - and then find out if the process can be used to read the seed back.

Quite a few hours of tracing with a multimeter show the following connections for the seven pad connectors (labelled from left to right):

T1: Ground?
T2: Power?
T3: Power / Reset?
T4-T7: These four pins are connected through a 2.2k resistor network to the MCU. Because the connections go under the blob it is not possible to trace them easily, but judging from the pin positions and some of the MCU image pin usage these are likely to be connected to the M1, M2 (input only), P10 and P11 (input and output) ports.

These are GPIO pins whose functionality needs to be implemented in the ROM firmware by the developer of the particular application, in this case RSA. This means that the imprinting process does not use MCU native ports, but that the imprinting functionality is implemented in the firmware, so in order to understand what the pins do (and how the imprinting protocol works) we need to reverse engineer the firmware first.

Extracting the ROM using image processing

We go back to the previous work done by siliconpr0n who have really close-up images of the SecurID MCU available. As opposed to SRAM the mask ROM is static so it can be pre-programmed using fixed logical gate arrangements to store a zero or a one. There are various technologies for mask ROMs however with the appropriate decapping and staining it is possible to visually recognise when a zero or a one is stored on each memory position.

From the images we can see that there are 8KB of ROM organised in two banks. Each bank has 128 rows and each rows is 16 columns with 16 bits in each column, totalling 65536 bits (8 KB).

Using the images linked above and rompar, a masked ROM optical data extraction tool which takes an image of the masked ROM and produces the binary representation of the zeros and ones stored in it we were able to obtain the 8KB of the ROM that stores the configuration and program for the RSA token.

ROM structure

Now that we have the dump we need to try and make heads or tails of it, so that we can obtain the program running on the MCU. The main problem is understanding how the ROM is laid out, what part is the IC configuration and which part is the MCU program, so we can disassemble it.

At this point of time we would use the MCU documentation and development toolkit to compile a sample program, see how the data is stored and try to find patterns to understand how the masked ROM is created, however it seems that the age of this MCU coupled with the fact that Sanyo semiconductors has been resold multiple times leaves us with very little information and no working toolset to explore how the memory is laid down (if you happen to have access to such a toolkit drop me a line please).

During my research I have come across the following nuggets of information:

From the datasheets of the LC5734 family, LC573104A and LC573406A we have been able to extract the opcodes for the various instructions.
From the similar LC65E1104_datasheet:
- Part of the mask ROM is the IC configuration, e.g. type of oscillator, watchdog reset, port output levels, etc. .
- The option data is stored between 0x1000 and 0x100a (10 bits)
From the LC5862H datasheet:
- The option data is written to the end of the EPROM at 0x4000 to 0x40FF in blocks of 8 bits (256 bits)

I spent a considerable amount of time looking at the dump and the images to try and reverse-engineer the memory access method but it is just not my area of expertise. Looking at different permutations of the memory dump, coupled with a hand-made disassembler for the Sanyo MCUs did not bear any results so it seems like the memory layout is not straight-forward, the data is somehow encoded (e.g. RSA customised the chip to encode the instructions in the ROM, or the opcodes differ for this particular MCU). Considering that there are areas of memory with contiguous 1s or 0s, it does not seem like the encoding/encryption hypothesis holds up.

Completing the work

If you are successful in identifying the memory layout let me know, it should be a breeze afterwards to get the software decompiled and the imprinting process identified - as it stands though I need to abandon this avenue of work until there is a breakthrough in this area which will allow us to:

Document how the imprinting process works
Identify the SRAM addresses where the seed is written to
Search for loopholes in the imprinting process to read back data from SRAM

Conclusion

We set ourselves to prove whether the hardware token seeds are substantially harder to compromise that soft tokens and, while there are still avenues for attack opened, it seems that the trust we put in hardware tokens is well-placed and that the design, although very surprising (seed stored in volatile RAM, non-dedicated IC), does hold itself to more than a casual effort at reverse engineering.

eepeep: Dumping an in-circuit EEPROM

2020-07-20T00:00:00+00:00

While trying to reverse engineer the VidCon Youtube OnStage bracelets I had the need to access the contents of an EEPROM that is used as external storage by the main microcontroller, however I did not want to de-solder the EEPROM to get access to it so I started looking at ways to dump the contents while the EEPROM was still in-circuit.

I found a couple of articles (1,2) explaining how to access and dump EEPROMs using an Arduino but the firmware needed to be adapted for each type of EEPROM and re-flashed, and the transfer of the chip contents depended on a generic serial port application so it seemed like coming up with something more generic that could be used for a wide range of EEPROMS could be an interesting project.

eepeep was developed with the following design principles in mind:

It needs to be open source / open hardware so it is easy for people to modify and extend it
It needs to be easy to use (within reason, after all it is designed for reverse-engineers)
It must support as many EEPROMs as possible out of the box
It needs to be easy for users to contribute new EEPROM details
It must, at least, support I²C and SPI protocols
The client must be multiplatform and run, at least, on Windows, Linux and MacOS
The hardware component must be affordable and easy to implement across multiple platforms

You can find the code and hardware design in the project repository.

Setting up your equipment

Start by downloading eepeep, v1.0 was just released - it has been tested on a range of EEPROMs, however your mileage may vary. Use with caution and do not use in any circuit you would mind going up in smoke, and please file any issues you encounter with it.

Put together the hardware component using the following circuit:

The circuit is just a basic setup to allow the Arduino to access the I²C bus that the EEPROM is connected to. The terminals labelled SCL, SDA, GND and 5v/3.3v will be connected to the in-circuit EEPROM, you can find more details in the Hardware design section and the detailed bill of materials in the project repository.

After assembling the circuit flash the Arduino board with this script and you are ready to go.

Dumping an in-circuit EEPROM

Start by identifying the EEPROM part number and finding a datasheet for it, this will indicate the key parameters you need to feed to eepeep to access the data stored in the device.

This is what you are after:

Protocols supported: at the moment eepeep only supports dumping I²C-enabled EEPROMs
Pinout: find out the EEPROM pins for SDA, SCL, Vcc and GND.
Voltage level: whether it will need a 3.3v or a 5v power line.
Frequency of the I²C bus: typically 100KHz or 400KHz
Unique I²C device address
EEPROM size

Through this article we will use the following EEPROM as the target we want to dump:

From the markings we can make out it is a 24C02S, a 2048bits serial EEPROM with a widely available datasheet. We can extract the following details from the datasheet:

Protocols supported: it supports I²C
Pinout: we can see the pinout for the SOT-23 package in the datasheet, we have annotated the picture above with the pins
Voltage level: the accepted ranges mean it can operate both at 3.3v and 5v. We will stick to 5v.
Frequency of the I²C bus: both 100KHz and 400KHz supported
Unique I²C device address: we can see the device can be addressed from 1010000 to 1010111 (e.g. 0x50 to 0x57)
EEPROM size: 2048 bits, e.g. 256 bytes

Remove any power source from the target circuit that the EEPROM is connected to (e.g. the one you are reverse engineering) as we will be powering the EEPROM and the I²C bus through the Arduino.

Using the pinout that you have identified connect it to the eepeep hardware component headers, using logical probes or anything else that works for you. Make sure you select the appropriate voltage header and that the pin connections are accurate, this is the only point where you can destroy the EEPROM (and the rest of the circuit it is attached to).

I have some small logical probes that are ideal for this:

Connect the Arduino to the host through USB and launch the software component, choose the serial port the Arduino is connected to and then click on “Connect”.

If all goes well you should receive a confirmation that a connection has been established to the software component, and that the hardware is ready. If you cannot see this double-check the firmware flashing was successful.

Enter the bus frequency obtained from the datasheet; if you do not have this try 100 or 400 KHz as these are the standard I²C bus frequencies.

Click on the “Scan” button to scan the I²C bus for the addresses of all valid connected devices - if your target circuit has multiple devices connected to the bus all of these will show up on the scan results:

Use the datasheet to identify which address belongs to your EEPROM module, beware as a device may have multiple addresses. If the scan result comes back empty please double-check the connection between the hardware component and the EEPROM.

Input the desired device I²C address to dump in the “Address” field and enter the start and end memory addresses to dump, typically these will be zero as the start address and the total memory size as the end address. For instance in the case of the 24c02s the I²C address is between 0x50 and 0x57 and it can hold 256 bytes of data, so we will set the memory end address to dump at 0xFF:

After you click on “Dump EEPROM contents” you will see the progress on the console output, after a while (depending on the EEPROM size) a window will pop-up asking where do you want to save the extracted EEPROM contents for further analysis.

If you use eepeep to dump a new EEPROM type we encourage you to share the parameters used for that EEPROM so that others may benefit from your work, just submit an issue with the EEPROM details so we can add it to a future version of the software.

Architecture

Software design

To meet the multiplatform requirement for the software component it has been implemented in electronjs, relying on the serialport library for communications with the hardware component. The cost of the multiplatform capability is an exagerated memory consumption (after all we are running Chromium inside the application) and a software package size close to 100MB for an application that developed in C may not take more than a few KBs.

The software has two key components: a serial protocol parser and a state machine that exchanges messages with the hardware component. The serial protocol parser has been implemented like a stream Transform and takes care of the low-level protocol implementation, including reassembly of frames and message passing to the core process. The state machine is implemented using a set of case/switch statements that ensure the client and the hardware components are kept in sync.

Hardware design

The hardware component acts as a bridge between the client and the EEPROM, implementing the bus scanning and EEPROM access protocols. At its core it is a state machine that receives messages from the client (scan bus, dump eeprom) and translates these to the I²C protocol commands that interact with the EEPROMs.

The interaction with the EEPROM happens over the I²C protocol, so the hardware circuit is a simple implementation of an I²C access setup by using a couple of 4.7k pull-up resistors.

The hardware component has been designed with simplicity in mind so it can be easily ported to other architectures, the firmware must implement the following functionality:

Command control loop for messages coming from the software client
I²C bus scanning
I²C memory dump

COVID-19 Gibraltar historical statistics

2020-04-03T00:00:00+00:00

The Gibraltar Government publishes a daily COVID-19 report that includes number of conducted tests, how many cases are active and how many people have recovered. There is no historical information available so I have recorded the series since these started being published on the 12th March 2020 and generated the charts below. The raw numbers can be downloaded so you can run your own analysis.

Today's update

New cases:

Active cases:

People in isolation:

Deaths:

People with a single dose:

People with two doses:

People with three doses:

People with full dosage and 1st booster:

Total doses administered:

Statistics updated on

Note that on the 31st August the Gibraltar Government decided to stop reporting on non-resident cases identified in Gibraltar, so as of that date there are no longer accurate numbers for overall cases detected in Gibraltar. We continue reporting on the total number of cases identified in Gibraltar by using the difference between detected cases and resolved cases.

Last updated:

Tests conducted:

Population confirmed as infected after testing:

Recovery rate:

Mortality rate:

Source: HM Government of Gibraltar

BSides San Francisco 2020 write-up

2020-02-24T00:00:00+00:00

Key highlights of the sessions and hacking villages that I attended at the 2020 BSidesSF conference in San Francisco. This year the conversation inspired discussions around changing the way in which we work in cybersecurity, by getting people more involved or approaching the same problems in a different, more efficient way. Read on to find out what the SF cybersecurity scene had to say.

I thoroughly enjoyed my first BSidesSF conference, a volunteer-run engineering-oriented security conference which deals with real problems that security teams face day in and day out. As the name implies the BSides conference is always paired with a more mainstream security conference (in this case it happens on the two days before the RSA Conference). I had high expectations after attending BSides London a few years back in the run-up to 44Con, and the San Francisco version did not let me down.

Sessions

Sessions were one of the main reasons why I attended the conference as it provides a wealth of knowledge of what other organisations security teams are facing without the vendor pitch. Below is a rendition in chronological order of the chats I attended - there were up to four tracks running in parallel so this is by no means a representation of everything that went on at BSides. You can find recordings of these sessions and all the other ones here.

Keynote for Day One: Give Away Security’s Legos: Dumping Traditional Security Teams by @fredrickl

The keynote for the first day was a fresh approach to the “you are doing it wrong” theme: move away from the bureaucracy that your security organisation may be trapped in by devolving security to the departments you usually work with, let them take ownership, and allow the team to focus on doing real cybersecurity work that no-one else at the company can do: threat hunting, developing security components and consulting on security topics.

The presentation was full of pragmatic approaches on how to do this, here are some of my personal takeaways (but I strongly recommend you watch the recording of the presentation, Flee has a lot to say):

You do not have the full context of your business: during security reviews we spend a lot more time trying to familiarise ourselves with the proposed change and the business it supports than actually conducting the security review. While I agree that we cannot be in the middle of every single change, there still needs to be exposure of the cybersecurity team to the business, we need to be able to understand our organisation challenges and do security that makes sense and is aligned with the company strategy.
Product manager involvement: moving the responsibility for threat assessments and security reviews to Product Management, making security part of their product (like we always preach) but letting them do the risk assessments and discuss with the Product Owners the prioritisation (something I never do). But see my point above, we still need to be close to Product, just not in the middle of it.
Awareness training: moving away from the generic “policy” mandatory training and doing role-focused training, giving each team the knowledge and tools they know to do security - not just to follow the rules. Train them on how to do threat analysis, risk assessments, manage vulnerabilities and how to use the tools that the organisation has invested in.
Table top exercises: we have done paper exercises to simulate attacks and crisis management, however modelling after a D&D game may be the way to go to get people really engaged and after all, as Flee says, everyone loves D&D - even if they do not yet know it :-)
Security people are not the smartest. Security people get it wrong: we seem to be at the centre of the universe, hiding behind the disguise of consultants and advisors when we really are the gatekeepers/cops. People humour us as a necessary evil, but really are happy to see our back and get on with their work. We are neither the smarter kids on the block and can also do mistakes, so stop pretending - letting the other teams do security makes the organisation take better security decisions.

Having the risk ownership with to the business owners, where it really resides, allows the right people to make the right decisions when it comes to trade-offs - supported whenever necessary by the security team. We should spend less time trying to get our fingers in all the pies, pretending we are the centre of the business and focusing on delivering the outcomes we are uniquely placed to deliver.

Graph Based Detection and Response with Grapl by @insanitybit

Although some of the security products we are currently using are already incorporating graph-based analysis (endpoint protection, network anomaly detection or auditing - like the speaker-referenced BloodHoundAD come to mind), I thought that Grapl, the open-source tool that the speaker has developed, was a novel way of looking at attack detection beyond traditional log analysis.

The concept is simple and powerful, which typically a good combination: you feed logs to the tool in real-time and it applies a set of graph-based models to detect when something is not as it should be, not that different to how ESP works.

The models are defined in python, which means you do not need to learn an additional language and that you can apply all software engineering best practices to it (repositories, versioning, sharing, testing…).

GRAPL parses logs using a set of connectors (sysmon and a json-specific format) and converts this into a graph database, adding nodes and edges as each log provides additional information to an existing process, network connection, user, etc. This means that your detection rules no longer need to operate on a single log-line (or even the context of the past 30minutes of log-lines) but on an entity that evolves and that is enriched by every log line that is received. This makes it really simple something that is difficult for SIEMs without using unapproachable amount of memory: matching logs from 2/3 different sources over a period beyond a few hours.

This graph database is then analysed using a set of rules, such as “identify all nodes started by Word/Adobe/Excel/Outlook that have created subprocesses that have connected to an external IP address and downloaded a new file that was then subsequently ran” or “identify all services that are exposed externally and that have executed a subprocess less than 5 times in the past month”, etc. I can see the value of sharing these rule-sets which are technology-agnostic and really try to model process and user behaviour, something similar to what Microsoft is doing with Sentinel play-books.

The concept of “lenses” was also introduced as a way of exploring and doing forensics by starting at a node and moving through it to other nodes.

I can’t really wait to give Grapl a try!

The speaker hinted at interest from commercial vendors for the solution, so I guess the advice is to fork it while it lasts :-)

Secure by Design: Usable Security Tooling by @hxnyk

An interesting, although brief, discussion on how improving the usability of security tools leads to increased adoption amongst your internal customers.

As a security engineer I tend to focus a lot on the core functionality of the application I am working on, e.g. what makes it different from anything else out there. I spend a lot of time on that core functionality, testing, being amazed at how awesome the research results are and celebrating. It is only at that point that I just patch together a UI around it, as quickly as I can, before I release it to the world.

It is usually at that stage when the application fails.

Hon’s talk starts with a typical security engineer designed UI, pointing at several common and easy to overcome flaws such as confusing controls (my favourite sin), lack of intuitiveness, no deep-linking ability, etc. All of these flows make the application intimidating and, to quote Han “Instead of learning security the user need to learn about your tool before they can start learning security”.

While these are easy to avoid flaws, the secret is on putting yourselves in the user shoes and using the work that already exists out there: if your company does public-facing products involve your UX designers in the development of your tool, sit down with users and listen to them and apply usability best practices such as Nielsen’s heuristics.

While I agree with most of the arguments in favour of the importance of a correctly designed UI to improve user engagement, there is one concept that I cannot get myself to agree on “UI before API”, e.g. designing the API around the UI instead of the other way around. To me an API needs to be created around the business domain and the models your application handles more than with a specific UI in mind. APIs exist only for a purpose: separating the frontend from the business logic concerns, so that any number of UIs can be created without having to modify the back-end. I cannot really see any API that I design be driven for how the UI will represent the information!

The Red Square: Mapping the Connections Inside Russia’s APT Ecosystem by @arieitan

A brief presentation by Ari Eitan at Intezer regarding an analysis of several APTs attributed to Russia state-sponsored groups, breaking down its components and trying to establish patterns amongst different apparently independent criminal groups. The findings proved that there was no technical link between the various APT groups, however whether this was by design or as a form of misdirection was left as an exercise for the reader. Of the various presentations this is the one that felt the most commercial, with the work based on proprietary technology only available to Intezer, so difficult to validate. They presented a couple of tools that were the result of the study, both available at apt-ecosystem.com.

Peeling the Web Application Security Onion Without Tears by Noam Lorberbaum and Keith Mashinter

A detailed view into how Adobe has re-architected Adobe Document Cloud and how they have leveraged existing security technologies to provide a defence in-depth approach, without reinventing the wheel. It was good to see how similar challenges are resolved in similar ways by different organisations, from providing DDoS protection layers to addressing the security of API gateways.

In an effort that would not be alien to any organisation that has to comply with multiple regulations across different jurisdictions, Adobe has created a common control framework and open-sourced it so that other organisations can put it in place - good reading to any organisation that operates any customer-facing product.

Keynote for Day Two: What’s New or Not in 2020: Are we Making Progress on the Intractable Security Problems? by @larkinryder

A review of what major shifts in cybersecurity over the past decade, presented in an entertaining way so make sure you check the whole video. Some of my key takeaways:

Third-parry trust: we are doing it too manually and too “point in time”, we need a better way to manage the trust of third-parties as we increasingly rely on them in our organisations
Privacy: an enabler to do security right over the past few years, take GDPR or the CCPA as a way to ensure that organisations are doing the right thing. A point that, without disagreeing, leaves many things unsaid on the values of those organisations that are only driven by compliance when it comes to the security of their customers and stakeholders.
Cloud cloud cloud: a common theme across the conference, everyone is shifting loads to the cloud and it is becoming rarer to find organisations that manage their own infrastructure. There were a couple of very visual slides on how the skill-set of Technology teams have moved a couple of layers up and is not focused on Applications. Through the conference and no matter who you spoke with it was difficult to find anyone that is running on-premises systems any more.
Mobile ubiquity is good for security: the push to be able to connect to all our data from wherever we are and through our mobile devices has opened opportunities to increase security authentication using mobile built-in 2FA mechanisms or even biometrics. We should leverage the use of devices to better identify our customers. On the other side losing mobile devices has become a real problem, encryption is a must if you do not want to see your data stolen.
Customer data is off limits: long gone are the days where customer data was passed around between teams with disregard on user information security. Nowadays it is difficult to demonstrate why a team needs access to personal data, creating guard-rails to ensure that data access is appropriately protected and audited goes a long way to avoid breaches on that information. One very interesting though that was presented is trying to understand how much criminals resell breached information for so that we understand what is an appropriate investment (e.g. if bad guys are selling passport information for USD1,000 then it makes sense we invest a similar amount of money to protect them).

Protecting the Bridge from Dollars to Bitcoin: Securing Coinbases’s Edge Payments Infrastructure by Nishil Shah

A deep-dive on how payment methods work in the US (and abroad) and how difficult it is to protect loses with the controls built into payment systems that have been around for decades, well before trust between the different entities that participate in a transaction was an issue. A threat analysis of various payment method flows was presented with call-out to understand what could go wrong and how companies address it.

Coinbase integrates lots of different payment methods, some of which are more creative than others - to ensure security on those payment methods a three-step process is followed:

Review the new payment provider during the procurement phase, and stop it at that stage if it does not provide appropriate assurances
Regularly test the payment integrations
Incorporate security test cases in the integrations developed, by having security champions embedded in the payments engineering teams

One of the interesting thoughts in Nishil’s presentation was whether a payment bug that led to money being lost was really an application security topic (something we can also extend to other items that contribute to fraud). The bottom line is that if we define security as ensuring that the amount of fraud is prevented then it falls spot on in our area, so do not shy away and work with those teams - even if it is not strictly your responsibility: in the end we are all trying to make our organisation as successful as possible, and preventing fraud sounds like a great way to contribute to that goal.

Lessons Learned from the DevSecOps Trenches

A panel of application security leads, CISOs, Red Teams leads and security researchers that have been working in DevSecOps for a while and that shared some of their success stories and pitfalls to avoid:

@astha_singhal, Director of Application Security, Netflix
@dugdep, Director of Defense, Datadog
@justine_osborne, Offensive Security Technical Lead, Apple
@zanelackey, Chief Security Officer, Signal Sciences
@clintgiblertldrsec.com, Research Director, NCC Group

The panel addressed topics in various areas which I have tried to capture below, however it is probably better if you watch the panel itself and form your own conclusions.

Failure stories

Testing matters - think about the actual operation of the tool you are developing before you release on your production environment
Set clear success criteria before you spend a year on projects that are going nowhere

Asset inventory: if you were to start embarking on a path from scratch how would you approach it?

Gotcha: realise that you do not need just security engineers, but data engineering analysts so that the tool scales
Positive: organisational side, send security champions to meetings with the product and build infrastructure team to learn and listen on new products that are coming up

Build vs Buy decisions

The key decision point are the resources that need to be dedicated to development and maintenance
Based on the vendor you are working with, getting 50% immediately from a vendor may be better than 100% in a few years time!
Get 80% coverage as quick as possible, so that when the resources are available they can go into the remaining 20%
Be open to deprecating internally developed tools once the vendors catch-up

Security analysis in pipelines in CI/CD

“Trying to find all the bugs” vs “Are we using the frameworks in use”? It is better to build guardrails for developers than trying to find complex issues (e.g. use mutual-TLS between services, use secret management, etc.)
A lot of critical vulnerabilities found at Netflix could have been resolved by implementing best practices, so they focused on the controls, e.g. not avoiding the vulnerabilities but limiting the impact.
..but it’s not always about using security components to get security but default but doing security and understanding unique risks as well.

Red Teams: how do you make sure it is improving the security posture

Measuring security risk is a hard problem, but security testing boils down to hypothesis, experiment and analyse the results. Defining the correct hypothesis for the organisation is the key.
Red Teams allow to see the bigger picture: there are always loopholes, etc. It also allows to move beyond jut AppSec and find issues in other areas (infra, corp)
The impact is not just the number of bugs found, but the new types of attacks you are identifying as a blue team
Do not call it done until all the things you found are no longer possible to be exploited
Red Teams can also be a good tool, but you also need to balance that by not breaking trust with internal customers (e.g. so you are not perceived as showing how dumb they are by breaking into their systems)

Threat modelling and security reviews: how important and how do you scale?

Use MITRE ATT&CK framework as the basis for thread modelling, so that the whole detection is improved
Scaling thread model is a requirement: self-service questionnaires for developers (so that the output recommends specific guidance on what to do and it computes a risk score, so the dev security can focus on the riskiest), or integrating threat modelling on the development life-cycle or thread-model as code (e.g. adding security tests as abuse in integration testing)

AppSec pipelines: What static/dynamic analysis has brought the highest ROI?

Really targeted scanning, e.g. instead of doing everything well focus on a class of bugs and kill it everywhere
Start bottoms-up and define initial security controls, so that the development team self-manages the issues and their resolution.
Focus on dangerous patterns that are specific to the frameworks in use
Identify as quickly as possible, e.g. on code commit or in the IDE - or at the worst case in CI/CD pipeline
Finding vulnerable dependencies in close partnership with build teams (they have the same challenges to manage dependencies) so that we can flag dependencies

What is the most effective engagement and awareness initiative you have done with your engineering teams?

Find ways to have engineering teams engaged with security, so that security is centrally located or balls of candy on people coming to central team. Budget for drinks on engineering teams happy hour last two rounds :-)
Asking Engineering to join the Red Team the exploitation of a vulnerability
Create a good experience when folks come to talk to you, e.g. be realistic on the goals and be as responsible as possible

New organisation: what would be the first investment you will do?

2 x Visibility into what you have, what it is and who owns it - e.g. visibility on your systems
Protect a number of security analysts from interruptions so they can take the long-view on some hard problems (e.g. framework creation, etc.)
Make sure you understand the risk you are trying to reduce at the enterprise level (e.g. what are the corporate nightmares when it comes to risk) so you can prioritise
Going into a new security roles: get the buy-in from the other teams, they for sure had negative experiences in the past, so you need to change that perception for future successes
Vulnerability management: so you can measure when something worked or not

2FA in 2020 and beyond by @kelleyrobinson

This was a really useful session with Kelley presenting research on the usability and effectiveness of various two-factor authentication mechanisms, covering SMS, TOTP, Push and Physical security keys. I believe that a quote from the speaker “We are so owned passwords are no longer safe” mimics reality, for all our important accounts we are demanding further authentication mechanisms, so I found the talk very interesting - specially if you are deciding what next 2FA mechanism to deploy. I recommend you watch the whole presentation as it covers a lot of useful statistics around 2FA methods penetration and usability.

Some of the results of the research were learnings for me, specifically the following two:

Push is not as effective as we think: It is probably the easiest and less-friction mechanism for 2FA, but this seamlessness makes users feel that the system is not adding that much security. It does not help that there is no standard around Push security approvals and that everyone needs to install its own app for this.
TOTP has a wider adoption than thought: It combines the security that SMS cannot offer, the ability to work offline and it only requires the user to install an app - which they have already done if they are using YOUR app. Entering the codes gives the right amount of security perception that customers are looking for, and it uses open standards so there are multiple ways of getting the codes.

OTR: Tears from The Cloud by @theckman

BSidesSF has introduced a new type of sessions this year labelled OTR (“Off the Record”) where any recording of the session or discussion on what was mentioned is discouraged, in a concept similar to the DEFCON Sky Talks.

These sesssions are out of bounds for the press, with the goal of having open and frank discussions without the risk of being shot down for bringing up sensitive topics. I attended this particular session and, while I cannot really discuss what was mentioned, I think that the OTR sessions are still far from perfect both in content and interest - and from what I heard from people in my team that attended DEFCON this year the same can be said for the Sky Talks.

Mental Health for Hackers: Contents under pressure by @v33na, @ryanlouie and @ChloeMessdaghi

This was the final session I attended at BSidesSF this year, I wanted to understand the specific mental problems that people in Cybersecurity face so I can be proactive in identifying, thinking of team sanity more than anything else. While the session was useful on getting some background information it lacked specifics on how employment in a cyber position contributes to these mental health issues. We know people in our space are affected by Anxiety, Depression or Burnout - but what is it in our job that makes these problems so prominent and what can we do about it?

One of the key points I took away was the concept that all of these problems are easier to handle if you share it with someone, if you do not go through it alone - it’s the community that matters and both in cyber and security research there is a large amount of those. So do not do it alone :-)

The closing notes of the presentation gave some pointers for further research:

Villages

There are five “hacking” villages where you can learn the basics around tinkering with various areas that require some basic hardware you may not have around your workshop, using a self-learning tutorial style - just sit down and get started:

IoT: a very introductory tutorial around firmware analysis, spotting hard-coded credentials and exploiting them through telnet. Learnt about binwalk as a tool to identify known structures in a packed firmware (for instance the bootloader, a squash FS, etc.) and extracting them, really cool and something that goes beyond my “strings” skills.
Reverse Engineering: a focus on reverse-engineering firmware from a Buffalo NAS server, identifying and exploiting vulnerabilities. I learnt a couple of tricks such as the uncompyle6 tool for decompiling .pyc to an approximation of the original Python source code. Throughout the tutorial
Car hacking: Simulating a set of vehicle components, the lab focused around CAN bus hacking, which is an area we had touched in the past when doing SCADA security research with @xpanadero for S4. Unfortunately the environment was being reset when I sat down so did not get to learn anything new.

The conference was packed with sessions so I was unable to sit down at the Lockpicking or the Crypto hacking villages.

Vendors

I did not spend that much time visiting vendors booths as I will have plenty of opportunities at RSA during the rest of the week, but there were three that caught my eye:

>_cmd: a command-line auditing and blocking solution, similar to what Balabit are doing with PSM, but without the RDP or file transfer support. Instead of installing a gateway before accessing the system. _cmd is installing as an agent on each Linux system (it only supports Linux) which injects a library into each process which (I assume) patches syscalls so that it can monitor what the application is doing. It sends the recorded events (input/output/UID change/etc.) to a cloud-based central repository that can be used for auditing. Activities can also be blocked from happening. It feels like a good solution, but given the limited platform availability I am not sure if we are not better off with auditd for the time being. The cloud-based console is cool though, and it makes it easy to review sessions but, again, only for Linux based systems.
snykj: an open source vulnerability tracking outfit that helps identify known vulnerabilities that you are importing into your code through dependencies, similar to what WhiteSource or BlackDuck are doing.
nightfall AI: a cloud-based solution that monitors your information and automatically classifies based on its content and certain AI models, allowing you to apply DLP-like policies to it. It has connectors for several cloud-based services, however does not support on-premises systems, which limits its use in environments where some of the critical assets are still maintained internally, think legacy databases.

Closing thoughts

All in all a very enjoyable and useful conference, created by and for the community and for a meagre USD50 that covers sessions, villages, free swag, stickers, food, drinks and a lot of fun. There seems to be a shift in focus from extremely technical sessions towards a more “how do we improve security by looking at the human side” in general, something that I also feeling as RSAC2020 gets started (this years’s motto is “Human Element”). Let’s see where this leads from here, if you have any feedback/correction or further thoughts please reach out on twitter (@lluismh).

Azure AD authentication and authorisation in Angular applications

2020-01-06T00:00:00+00:00

There is plenty of documentation on integrating javascript applications with Microsoft cloud authentication, however there is little information on how to define which users are allowed to log-in, managing them and assigning the roles your application uses to them using Azure AD. Read on to learn how to do an end-to-end integration of Angular, Azure AD and user+role management.

I recently had the need to add cloud-based Microsoft authentication to an angular+rails application which uses role-based access control, including integrating authorization of users who are assigned roles directly in AzureAD. This removes the need for the application from having to manage users locally (urgh) and separates the management of the application from the management of its users (yey!).

Users choose to log-in using their Microsoft AzureAD credentials (aka their Office365 account) by clicking on a link on the application login page. They are then redirected to the Microsoft login page and, once authenticated, a JWT token is sent back to the application which includes the users roles. The application extracts these roles and uses them to authorise the user access.

To achieve this we will implement the following steps:

Register your application with Azure
Assign application roles to users or groups
Integrate AzureAD authentication with your application
Access AzureAD JWT token and extract roles

While there are plenty of articles and libraries that integrate angular and azure authentication, I did not find much information on using azure for user application role management, I hope you find this article and the accompanying code useful.

Register your application with Azure

Azure needs to learn about your application in advance (amongst other things to decide which user repository to authenticate against and where to send authentication results to).

To register the application you need to access the Azure Active Directory admin centre, either get permissions or find a friendly Azure admin in your organisation who can help you with making the required changes. The Microsoft admin centres are a bit like shifting sand, so the names of the options below may have changed since this article was published - if you can’t find the specific option mentioned try to find for something that sounds similar…

After you login to the Azure Active Directory admin centre click on “Azure Active Directory” on the left menu, then select “App Registrations” from the Manage section and register the application you want to integrate with Azure AD.

The information required during registration is quite straight-forward, but here is a brief description to help you fill in the details:

Name: a descriptive name that will be used to refer to your application, we will use “testapp” throughout the article
Supported account types: select the scope of user accounts that you want authenticating against your application, either restricted to your own Office365 tenant, to other Office365 tenants or including personal accounts. For our application we will go with “Single tenant”
Redirect URI: enter the URL that your users will be clicking on the ‘Login with Microsoft’ button

After submitting the registration form, we will be provided with two of the key values we need to configure Azure authentication in our application, the “Client ID” (which identified our application to Azure) and the “Tenant ID” (a common ID which tells Azure which organisation to authenticate against). Write down these values as we will need to use them later on.

For our application we will be using the OAuth 2.0 Implicit Grant flow, as we need to access the ID tokens directly. After registering the application, we will click on ‘testapp’ and then select ‘Authentication’ from the left-side menu, scroll down to ‘Implicit grant’, tick the ‘ID tokens’ checkbox and then save so that the application is updated.

Define application roles

Once we have the application registered with Azure, we need to let Azure know the various roles your application supports. There is no nice and easy GUI to add the roles, instead we will edit the application manifest directly, e.g. the JSON file Azure uses to understand and register your application.

On the application menu, select “Manifest” which will open the application definition and find this section:

"appRoles": [],

For each role we need to provide the following information:

allowedMemberTypes: list of allowed member types, it should include a single User entry
displayName: The friendly name we will use when assigning roles to users
description: A brief description of what the role allows the user to do
isEnabled: Set it to true to enable the role
value: The value your application will receive inside the JWT token, when the logged in user has this role assigned, this is the important one
id: A unique GUID, generate something random which meets this format (hexadecimal characters): “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”

Microsoft provides some documentation around the definition of application roles you may find helpful.

In our case let’s assume we have an ‘admin’ role which allows users to manage the application, our appRole would be filled-in with this information:

{
  "allowedMemberTypes": [
    "User"
  ],
  "displayName": "Admin",
  "description": "Can manage application settings",
  "id": "84ecd32a-8829-a8d8-cb4d-93dcfe8f7dab",
  "isEnabled": true,
  "value": "admin"
}

Just add as many roles as you require to the JSON file as a list of items assigned to appRoles, your file should look similar to this:

"appRoles": [
{
  "allowedMemberTypes": [
    "User"
  ],
  "displayName": "Admin",
  "description": "Can manage application settings",
  "id": "84ecd32a-8829-a8d8-cb4d-93dcfe8f7dab",
  "isEnabled": true,
  "value": "admin"
},
{
"allowedMemberTypes": [
    "User"
  ],
  "displayName": "Editor",
  "description": "Can edit content",
  "id": "84ecd32a-8829-adda-cb4d-93dcfe8f7dac",
  "isEnabled": true,
  "value": "editor"
},
{
  "allowedMemberTypes": [
    "User"
  ],
  "displayName": "Reader",
  "description": "Can read content",
  "id": "84ecd32a-8829-9abd-cb4d-93dcfe8f7dad",
  "isEnabled": true,
  "value": "reader"
}]

Once you are happy with the changes save the manifest, after verifying the syntax Azure will make the roles available for user management.

Assign application roles to users or groups

To assign the roles to Azure users you will continue in the Azure AD admin centre, select “Enterprise applications” on the left pane and then click on the name of the application you created (in our case “testapp”). Then select “Users and groups” to start assigning roles.

Click on “Add user” and select the user (or group) you want to assign a role to when accessing your application, then under “Select role” pick one of the role friendly names we created in the previous section, and repeat for as many roles, users and groups as needed.

Integrate AzureAD authentication with your application

Microsoft provides MSAL, a javascript library to authenticate against AzureAD which has an angular version.

My initial approach was to try and use the Angular wrapper (available in NPM as @azure/msal-angular), as it makes for an easier integration - however the wrapper hides the idToken property of the javascript MSAL object which is required to extract user roles which made me integrate against the MSAL.js library directly. The angular wrapper is still in preview as of this writing, but in the future it may be an option to consider.

The MSAL workflow is quite simple:

Our login component will initialise the MSAL library by passing the azure client and tenant IDs
When the user clicks on the “Login with Microsoft” button we will use the MSAL object to open a pop-up which will take the user to Microsoft to authenticate
On successful authentication, Azure will redirect the user back to our application where we will use the MSAL object to read the user roles and authorise the access

Install and initialise MSAL

Start by installing the MSAL js library:

$ npm install @azure/msal

In the initialisation of our login component we will obtain a UserAgentApplication instance:

  var msalConfig: Configuration = {
    auth: {
      clientId: 'abcdef-0123-456789ab-cdef-012345' // AAD Client ID
    },

    system: {
      logger: this.azureLogger // This easies MSAL debugging, check the [accompanying code](https://github.com/llmora/azuread-angular-example) for details on this property
    }
  };

  if (aad_tenant_id) { // To support single-tenant applications, not needed if supporting multi-tenant
    msalConfig['auth']['authority'] = `https://login.microsoftonline.com/${aad_tenant_id}`
  }

  this.azureADmsalInstance = new UserAgentApplication(msalConfig)

Authenticate the user against Azure

When the user decides to authenticate through Azure we have two integration options:

A pop-up that, after authentication, closes down and sends the results of authentication to our client-side application
A redirect to Microsoft which, after authentication, redirects back to one of the URIs we have configured when registering the application

After some testing I opted for the pop-up integration due to it being easier to integrate (it requires less configuration, e.g. no redirect page to receive the response) and the impossibility to include a hash in the return URI of an AzureAD application, which makes it impossible to use it with angular if you are using a HashLocationStrategy (e.g. the angular paths separated with hashes, for instance /#/login). If you want to use redirect either ensure you are using PathLocationStrategy or use a static HTML served outside of your angular application, as described in this GitHub issue and configure that path in the ‘Redirect URI’ of your application registration.

Going with the pop-up option is quite simple, just bind this code to the action which executes when the user selects to authenticate through Microsoft:

var loginRequest = {
  scopes: ['user.read']
};

this.azureADmsalInstance.loginPopup(loginRequest)
  .then(response => {

    [... successfully authenticated ...]

  })

  .catch(err => {
    
    [... error authenticating ...]

  });

Troubleshooting MSAL

While developing with MSAL it can be a bit daunting to troubleshoot, these are some of the issues I have faced during implementation:

Make sure your client and tenant IDs are correct
If you are configuring the application for single-tenant you need to include the tenant ID in the authority URL
If you are using the redirect option, during development you will probably be using “localhost” as your landing page. Note that localhost and 127.0.0.1 are not the same as far as return pages are concerned (your application will work, but you will not receive the token back from Azure)
If you are getting an AADSTS700054 error (“response_type ‘id_token’ is not enabled for the application”) make sure you have selected the ‘ID token’ implicit grant, as described in the last step of Register your application with Azure
The first time you login to the application, an admin must consent for it to be authenticating against your AzureAD instance. Make sure an admin is the first one to login, and that they check the ‘Consent on behalf of your organisation’ when prompted:

MSAL offers a logger that is quite verbose about the errors it encounters, if you are facing issues I strongly recommend you use the logger - see the UserAgentApplication instance initialisation in the accompanying code for more details.

Access AzureAD JWT token and extract roles

After a successful login we will receive a JWT token which encodes the details of the authenticated user as well as the roles she has assigned. Use the getAccount() method of the MSAL object to retrieve the authenticated user e-mail:

var azureAccount = this.azureADmsalInstance.getAccount();

Retrieving the JWT token is even easier, as MSAL sets a ‘idToken’ in the response - this is the key to accessing roles as these are not exposed by MSAL directly:

var idToken = response.idToken

If for whatever reason you need to use an older version of MSAL, please note that the idToken was not exposed in the response but could be extracted from the sessionStorage:

var idToken = window.sessionStorage.getItem(Constants.idTokenKey)

idToken is the raw JWT token which we will use to extract the roles from, after validating it is correctly signed by the Microsoft login service to avoid login spoofing attacks. The validation of this token needs to happen on the server side, at a high-level these are the steps we need to follow:

Verify the signature, issuer, expiration and audience of the JWT token
Extract the claims, which give us access to the following information:

oid: Unique ID for the user across the Microsoft platform preferred_username: User e-mail roles: List of application roles the user has assigned

The roles entry is a list of role strings (the value we gave to the relevant appRoles in the manifest) which you can then use directly in the application to authorise the user actions.

Below is a ruby implementation which extracts the user e-mail and roles from the JWT token using the AzureActiveDirectory class (which does most of the heavy-lifting):

aad = AzureActiveDirectory.new(client_id, tenant_id)

# Verify signature, issuer and audience
azure_claims, azure_header = aad.validate_and_parse_id_token(id_token)

if azure_claims
  user = User.new
  user.external_identifier = azure_claims['oid']
  user.email = azure_claims['preferred_username']

  azure_claims['roles'].each do |role|
    user.add_role(role)
  end
end

Once you have the roles you know which permissions the user has and can authorise his next actions as appropriate, as if he was a local user. Because the JWT token is only passed on in the pop-up or redirect you need to assign the roles to the user session, which will depend on how you are managing your application sessions: a local JWT, an entry in the login session, etc.

Conclusion

Integrating Azure AD authentication and authorisation against an angular application is quite simple if you are familiar with how these steps work:

Creating appRoles for your application in Azure
Assigning roles to users in Azure
Extracting the application roles from the Azure JWT idToken

In this article and the accompanying code we have shown how to implement this integration, it should be fairly easy to adapt the approach to other web frameworks besides angular as we decided to integrate the Microsoft MSAL js library directly instead of the angular wrapper.

If you have comments, questions or improvements to the article please reach out on Twitter or submit a pull request in GitHub.

SMEG fridge shelf design and replacement

2019-03-03T00:00:00+00:00

The plastic shelf corners in our SMEG fridge are quite flimsy and after a couple of years they just broke away. It has been impossible to source replacements so we decided to design a simple functional 3D printable piece to replace them, you can find the STL files on our Deprogramming Obsolescence repository (along with editable OpenSCAD files in case you need to adjust the pieces). If you modify the designs can you share them back with the community please?

Back-side shelf

The piece around the back of the shelf is a bit more elaborate and is the one that tends to break more often, over half of our shelves back-side plastic corners have broken, sometime on both left and right side. This is what a healthy piece looks like:

And over time, the piece at the end that goes into the side rails and holds all the weight breaks away and ends up like this:

The new piece is a simple design, a replacement for the end that has broken away which is then attached using two screws to the old piece:

The piece is symmetric, so you can print it to replace both the right and left corners; it should print without supports.

Before you install the replacement piece you may need to remove any remaining bits of the broken piece, just try to fit the new piece and remove with a stanley cutter anything from the old piece that gets in the way.

Using the 3D-printed piece as a template, drill a couple of holes through the placeholders so that the old piece plastic ends up with two holes:

Using two M3x12 screws and a self-locking M3 nut attach the replacement piece to the old piece and tighten it as this piece will support most of the weight of the shelf once installed. I did not use any glue or other chemical bonding, just the mechanical screws - but if you have any suggestions here always happy to learn.

The shelf can now be replaced, or move on to the next section in case the front-side shelf plastic pieces are also broken.

Front-side shelf

The front-piece is quite straightforward, it holds the glass on two sides and works as a corner which in itself rests against the rails on the side of the fridge:

In our case the whole corner of the piece just broke out, leaving the piece with no support at the front. The design is again quite simple, just a corner with a grove for the glass to slide in:

If you print the design in the original STL orientation you should have no need to use supports, however given the height and the relatively low surface you need really good first layer adherence.

Because the piece is not glued the glass is a snug fit, you will need to use quite a but of force to insert the glass in - I suggest using a rubber hammer or, if you do not have one handy, just fit in the piece on the glass, then hit the whole assembly until the glass falls into place. Because this is a direct replacement for a part of the front-side, you will need to cut the old plastic part with a stanley knife so that the new piece fits in, the piece measures 8.5cm long:

We have used the pieces for the past month and it seems as if they are going to extend the life of the shelves for at least a couple of years, enjoy the pieces if you use them - and if you make any adjustments please share back on github so that everyone can benefit, let’s continue fighting obsolescence!

Installing a new Industrias Lorenzo Eurojoystick 2

2019-02-24T00:00:00+00:00

After replacing the actuator on our Happ Super joystick gameplay has been much better, however the microswitches are showing their age so I ordered a pair of Industrias Lorenzo Eurojoystick 2 for 18 EUR a piece.

These joysticks come with a trademark square actuator, which makes hitting diagonals much easier and high-quality Cherry D44X microswitches.

Replacing the joystick in an arcade cabinet is not really a major operation, however I could not find step-by-step instructions anywhere so I am documenting it here in case someone else benefits from it.

Removing the old joystick

Before you start take a picture of the cabling of the current joystick, making sure you can clearly identify the up/down/right/left connectors - this will ease up the reconnection of the cables once the new joystick is installed.

Make sure you capture how each cable is attached - for each microswitch there will be a “ground” cable which is typically daisy-chained across the four microswitches and a “signal” cable. Each microswitch may have 2 or 3 connectors, note which one is the “ground” (COM) and which one is the “signal”: for the “signal” you will typically have two options, make sure you connect it to the “Normally Open” (NO) connector, which is usually pictured as an open circuit.

While the joystick is still secured to the control panel we will remove the shaft. Use a small flat screwdriver and needle-nose pliers to ease the shaft “e-clip”, make sure you do not lose this piece.

After the “e-clip” is removed, pull the actuator away (in the pictures the tight actuator we built, not the original one) and then pull the shaft which should slide out without any problem.

Once you are satisfied the picture is good enough, unplug the eight connectors that go to the microswitches.

After that remove the four screws holding the joystick base attached to the control panel, which frees up the base.

Put together the old joystick (base, shaft, actuator and “e-clip”) so that you can put it away and use for future projects after some TLC (we will likely replace the aging microswitches before usign them again).

Installing the new joystick

Now that we have the old joysticks out of the way it may be a good opportunity to clean the control panel, after all you only change the joysticks once every generation.

Ensure that the new joystick mounting holes align with those of the old joystick we removed; in our case the Happ Super and the IL Eurojoystick 2 have exactly the same mounting holes (I guess there is a standard size for joystick mounts).

Remove the “e-clip” and actuator from the new joystick; the shaft should slide out easily after that.

Fit the base on the arcade control panel, using the same screws you removed with the old joystick.

Reinstall the shaft and actuator, and secure both pieces with the “e-clip”.

As a last step, and using the picture you took at the beginning of the process, re-connect the eight cables to the microswitches, ensuring that the “signal” cable is connected to the “Normally Open” (NO) connector. Before you close the cabinet I recommend you test the joystick is working as expected.

Close the cabinet and enjoy your new joysticks, they should last for another twenty years. The IL Eurojoystick2 feel really tight, tighter than our “modified” Happ Super and really responsive. I mostly use it for shot’em ups so I am really happy with the change, if you like other type of games your mileage may vary.