A package from Lithuania arrived today that may be interesting for the Infosec Community at large. Arsenijs has finally implemented a theoretical approach to program SD Cards to be temporarily or 
permanently protected from write operations.  Having reliable read-only media can be very usefully in many situations - ranging from offensive to defensive. Implants will no longer suffer from premature SD Card failures, tools like CIRClean can get an additional layer of  tamper-resistance  and forensic operations become cost-effective.

Picture of the SD Card Locker

History

This device was developed by Karl Lunt back in 2013, then improved by Nephiel in 2014. Arsentijs recently discovered it was never sold or mass-manufactured. 

New in version 2

• Redesigned the laser-cut case to be thinner, making the "laser-cut case" locker version less bulky. It's also now transparent, except for the middle layer which is transparent orange.
• Added usage instructions on the bottom of the PCB. 
• Added a MicroSD slot on the bottom - it allows you to plug a MicroSD card in directly, without using any adapters. 
• Reinforced the MicroUSB port soldering 

Common Use cases :

• Make read-only Raspberry Pi SD cards
• Make virus-resistant LiveCDs (or, rather, LiveSDs) for all your computer maintenance needs
• Distribute SD cards with promotional materials
• Forensic research and data recovery (reading from the SD card while preventing all write operations)
• Test your SD-card-powered products for unexpected behavior (an SD card becoming read-only is a popular failure mode and tends to happen when the card controller detects severe data corruption).

Feature Set of the SD Card Locker

How does it work?

Larger SD cards have a mechanical "write protect" slide switch on the side. However, that switch is useless :

1. not all readers support it 
2. the OS can choose to ignore it 
3. it's not available on  MicroSD cards 
4. the switch tends to slide accidentally (or fall out of the SD card altogether) when you have no intention of enabling write protection.

The controller chips inside the SD cards (of all sizes, whether full-size or MicroSD) are required by the SD card standard to support a low-level command that locks the card into a read-only mode, preventing any changes - either temporarily (can be switched back to read-write) or even permanently (without a way to ever restore the write capability).

How to order ? 

You can order it from Tindie for only 12USD

Hints

• Look into zRAM (Virtual Swap Compressed in RAM,) to move your swap into RAM Memory, this way you can still swap effectively and even use RAM more efficiently.
• Use fstab to create directories (Like /etc/log) that only exist in RAM

This is a living post, that will be updated as I release Advisories.

Updates:

• 02.01.2020 - Added Initial List of Advisories
• 09.01.2020 - Added Bitdefender and Kaspersky Advisories
• 12.01.2020 - Added Bitdefender Advisories
• 13.02.2020 - Added TZO-011/012 ESET and AVIRA Advisories
• 14.02.2020 - Added TZO-015 F-Secure Advisory
• 17.02.2020 - Released TZO-017 Kaspersky
• 18.02.2020 - Released TZO-018 Bitdefender
• 20.02.2020 - Released TZO-019 Avira CVE-2020-9320
• 24.02.2020 - Released TZO-016 F-SECURE CVE-2020-9342
• 28.02.2020 - Released TZO-023 Avast Generic Bypass
• 02.03.2020 - Released TZO-020 Quickheal bypass

List of advisories: 

• [TZO-001-2020] - AVIRA Generic Bypass (ISO)
• [TZO-002-2020] - Kaspersky Generic Bypass (ZIP)
• [TZO-003-2020] - ESET Generic Bypass (ZIP) - CVE-2020-9264
• [TZO-004-2020] - Bitdefender Generic Archive Bypass (GZ2)
• [TZO-005-2020] - Kaspersky Generic Bypass II (ZIP)
• [TZO-007-2020] - Bitdefender Generic Archive Bypass (ZIP)
• [TZO-008-2020] - Bitdefender Generic Archive Bypass (ZIP II)
• [TZO-009-2020] - Bitdefender Generic Archive Bypass (RAR I)
• [TZO-010-2020] - Bitdefender Generic Archive Bypass (RAR II)
• [TZO-011-2020] - ESET Generic Bypass (GZIP) - CVE-2020-10180
• [TZO-012-2020] - ESET Generic Bypass (RAR)
• [TZO-013-2020] - AVIRA Generic AV Bypass (ZIP GPFLAG) -  No Patch 
• [TZO-015-2020] - F-SECURE Generic Malformed Container bypass (RAR)
• [TZO-016-2020] - F-SECURE Generic Malformed Container bypass (GZIP) - CVE-2020-9342
• [TZO-017-2020] - Kaspersky Generic Archive Bypass (ZIP FLNMLEN) 
• [TZO-018-2020] - Bitdefender Malformed Archive bypass (GZIP)
• [TZO-019-2020] - AVIRA Generic AV Bypass (ISO Container) - CVE-2020-9320
• [TZO-020-2020] - Quickheal Generic AV Bypass (ZIP GPFLAG) - CVE-2020-9362
• [TZO-021-2020] - Sophos Generic AV Bypass (ZIP GPFLAG) -  CVE-2020-9363
• [TZO-023-2020] - AVAST Generic AV bypass (ZIP) - CVE-2020-9399

Where can I find more information about this bug class ?

I wrote a post about this bug class in 2009 and in essence, it still holds true. The threat landscape has shifted and so has the technical capabilities : 

https://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

Why now ?

10 years ago I took a look at ways to evade AV/DLP Engine detection by using various techniques and released a metric ton of Advisories. 10 years later after multiple CISO type roles, I wanted to deep dive again and see how far (or not) the AV  industry has reacted to this class of vulnerabilities. [1,2]

These types of evasions are now actively being used in offensive operations [3]. To my surprise with a few exceptions most AV Vendors haven't appropriately reacted and in some cases I even found the very same vulnerabilities that were patched and disclosed years ago.

Worse than that is the fact that some vendors that were very collaborative in 2008/2009 have now started to ignore submissions (until I threaten disclosure) or are trying to argue that generically evading AV detection is not a vulnerability although they patched and released advisories before. Go figure.

I had a lot of back and forth on this matter, for instance, one vendor argued that this could not be called a vulnerability because it would not impact Integrity,  Availability or Confidentiality. Another Vendor argued that this cannot pose a "risk" to their customers because of XYZ (assumptions).

Well, I am reporting vulnerabilities within products, not risks. Furthermore, the impact on the customer is highly dependant on how the customer contextually uses the product. Something the vendor has rarely any insight into. Trying to calculate the expected loss for a hundred thousand customers is something we shouldn't be doing when handling vulnerability notifications, however, a shocking amount of vendors are unable to understand the difference between a vulnerability and a risk.

Even more bothersome to me is how the bug bounty platforms have created a distorted Reporter/Vendor relationship and mostly are executed to the detriment of the customers. I am collecting my experiences and plan to write a blog post about this phenomenon in the future.

I am hoping that I can finally help to eradicate this bug class and I don't have to come back to this 10 years from now.

[1] Our presentation at Hack.lu and CansecWest entitled "The Death of AV Defence in Depth?"

[2] It didn't go unnoticed - Past Press Coverage: Washington Post, Infoworld, Heise, Security Focus ... etc.

[3] https://www.bleepingcomputer.com/news/security/specially-crafted-zip-files-used-to-bypass-secure-email-gateways/ | https://www.techradar.com/news/zip-files-are-being-used-to-bypass-security-gateways