/g/ - Technology

install openbsd

[Make a Post]
[X]





Nanonymous No.1494 [D][U][F][S][L][A][C] >>1495
File: 1da74ce52d24f4b6f2b828016556cdc5a653696b129bad3dfe8ce20d148471fb.png (dl) (12.15 KiB)

Using SD cards for secure "air-gapped" file transfer
Using USB sticks to transfer files across multiple computers is certainly not secure since the USB bus allows for Direct Memory Access and an USB device can pretend to be anything by changing its firmware/software.

Now, SD cards are far more limited as to what they are allowed to access on the host computer and offer only an SPI interface to write to and read files from it. Now, what do you think is it reasonably secure using an SD card to transfer files or not?

<Just use CD/DVDs
That's an option though it is quite bulky and quite wasteful (for write-once CD/DVDs)

Nanonymous No.1495 [D] >>1497 >>1565

>>1494
USB does not allow DMA though. At least not to the extent that a plugged-in USB device can read or write main memory. It is, however, a concern that a USB device can emulate e.g. a keyboard and start typing random commands.
SD cards are ok if you access them through SPI, but they also have a (((proprietary protocol))) for access which I wouldn't use out of principle, although it still doesn't allow for data theft. Most card readers use the (((proprietary protocol))) because it's faster.

Nanonymous No.1497 [D] >>1498

>>1495
>USB does not allow DMA though
Hm, I thought the USB protocol could be exploited to allow for DMA access ... but I can't find much on it besides this:
https://github.com/ufrisk/pcileech

Nanonymous No.1498 [D]

>>1497
Nevermind
>This is achieved by using DMA over PCIe.
I got confused by "USB3380" ...

Nanonymous No.1499 [D] >>4729

>Direct Memory Access
Only if you find a vulnerable driver (which probably exists).

And yes, use SD Cards for transferring to and from an airgapped machine.

Nanonymous No.1514 [D] >>1517 >>1805

There is a video from CCC on how to exploit SD cards microcontrollers. It's quite hard when you don't have access to the source code, but cianiggers probably have it.
From the microcontroller they can exploit SD card reader firmware, which is a USB device, so theoretically sdcards can be used to pwn the system. It must be a sophisticated malware like stuxnet tho.

Nanonymous No.1517 [D] >>1565

>>1514
>exploit SD cards microcontrollers
That's only a problem when you, for example, re-use the same USB SD card reader on multiple computers.

Nanonymous No.1565 [D] >>1578 >>4729

>>1495
>Proprietary Protocol
I don't think this is happening in Linux though. I think the protocol is 'windows-based' - please correct me if I am wrong.
>>1517
>use SD card on multiple computers
yeah, but wasn't that OP's point?

Nanonymous No.1569 [D] >>1578

>DMA and
what now. if a USB device can do DMA nothing else matters, it has access to all your RAM
>can pretend to be anything by changing its firmware/software.
>muh changing
no, it can simply be malicious by design, what kind of retarded thinking process do you have

Nanonymous No.1578 [D]

OP here
>>1565
Re-using (USB) SD card readers is problematic not re-using SD cards.
>>1569
Although USB doesn't have Direct-Memory Access the USB protocol does allow any particular USB device to have the capabilities of any other USB device by changing its firmware/software.

Nanonymous No.1805 [D][U][F]
File: 50a3fc3b9298ec52f4ed50f91cd2201c1e27640ce69658f36e154281784a009b.pdf (dl) (1.25 MiB)

>>1514
You're right ... I can't read and thought you were only talking about the (USB/internal) SD card readers, but yes, SD card firmware can be attacked as well:

>Attack scenarios:
> – Eavesdropping
> ● Report smaller than actual capacity
> ● Data is sequestered to hidden sectors that are uneraseable
> – ToC/ToU
> ● Present one version of file for verification, another for execution
> ● Bootloader manipulation, etc.
> – Selective-modify
> ● Scan for assets of interest, e.g. security keys, binaries, and replace with insecure versions

(quote from PDF attached, and I'm OP)

Nanonymous No.1806 [D] >>1807

>can be attacked as well
Or be malicious in the first place. Which is very, very likely... is there any storage medium (for a Sneakernet) that isn't as susceptible to attack?
(still OP)

Nanonymous No.1807 [D] >>1808

>>1806
Floppy disks

Nanonymous No.1808 [D] >>1810

>>1807
Tape drives?

Nanonymous No.1809 [D]

>Never underestimate the bandwidth of a station wagon filled with backup tapes

Nanonymous No.1810 [D]

>>1808
yeah tapes probably better than floppies for a sneakernet because you don't need any random access

Nanonymous No.4456 [D]

While not air-gapped, couldn't you do something like:
[connected x86]->RS232(A)->[C64]->RS232(B)->[x86]
Then have record-only hardware on both the RS232 lines so you can compare the signals to see if there's anything different. C64 (or other 8-bit machine) is used to review the data in binary-mode and re-transmit to second x86 machine. RS232 lines are optocoupled isolated, to prevent analog signals from moving over the lines.

Probably beats moving a microcontroller back and forth between computers...

Nanonymous No.4460 [D] >>4729

>USB bus allows for Direct Memory Access
It doesn't.
>is it reasonably secure using an SD card to transfer files or not?
http://www.bunniestudios.com/blog/?p=3554
https://wookey-project.github.io/target.html

Nanonymous No.4729 [D] >>4731

>>1499
>Only if you find a vulnerable driver (which probably exists).
That's still not DMA though because drivers run on the CPU. Direct Memory Access means peripherals read/write memory without the CPU knowing or being able to stop them.

>>1565
>That's only a problem when you, for example, re-use the same USB SD card reader on multiple computers.
Anon means the microcontroller inside the sdcard itself. Not a reader.

>>4460
>http://www.bunniestudios.com/blog/?p=3554
It seems to me that as long as you use encryption like dmcrypt then it's fine. The issue here is that if you try to run /sdcard/bin/myapp from an sdcard then malicious firmware can give you the correct bytes when you try to verify it but then when you try to execute it give you the bytes for /sdcard/bin/backdoor instead. This trick has been used to jailbreak locked down platforms like Android tv. If you use encryption though then the sdcard firmware can't make meaningful changes to the data. The only issue left is that malicious firmware can trigger bugs in the relevant kernel drivers but that will be true for most hardware.

Nanonymous No.4731 [D]

>>4729
Dropping some related links you and others might be interested.

Exploits:
https://github.com/ortegaalfredo/kscope
http://spritesmods.com/?art=hddhack
https://opensource.srlabs.de/projects/badusb
https://github.com/brandonlw/Psychson
https://github.com/scanlime/coastermelt/
http://www.bunniestudios.com/blog/?p=3554

Projects:
http://www.openssd.io/index.html
https://github.com/openssd/openssd
http://www.fadu.io/
https://wiki.odroid.com/accessory/emmc/reference_chart
https://wookey-project.github.io