[HN Gopher] AES Finder - the utility to find AES keys in running...
___________________________________________________________________
AES Finder - the utility to find AES keys in running process memory
Author : based2
Score : 123 points
Date : 2020-09-06 12:25 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mabbo wrote:
| I remember many years ago, as I was thinking about going into
| technology as a career, I was chatting with a family friend who
| worked in computer security. I was asking him what he did. He
| said "If I have physical access to a computer, it's almost
| certain I will be able to get whatever data is on it. Especially
| if it's still running and logged in." (or something to that
| effect).
|
| Stuff like this always reminds me of that guy (haven't seen him
| in decades, sadly). Oh, you used AES encryption? That's lovely,
| but your computer knows the key and I can trick it into telling
| me it.
|
| Truecrypt likely changed the game on some of the claims he made,
| but that conversations predated it's existence.
|
| Today the angle of attack seems to be around OTP + Password with
| a timeout on the credentials generated. It narrows the window,
| but doesn't completely block it.
| hinkley wrote:
| I had a brief moment of technological joy when I worked at a
| place that had strict rules about leaving your computer
| unlocked, which I always struggled with.
|
| I had this new Symbian phone with Bluetooth (2?) and there was
| an app you could get for OS X that would lock your machine when
| it lost BT signal.
|
| Sub in a larger battery (still one of my favorite mini hacks,
| removing a little plastic so the 30% bigger Ngage battery would
| fit) and I was good to go, until the app stopped working.
|
| Big part of why I bought an Apple Watch (and then keep
| forgetting to set it up)
| dtech wrote:
| Truecrypt doesn't change that if the user has the volume open.
| When computers still had Firewire if they had a warrant for
| child porn they would use FW and DMA to pull a complete copy of
| the memory if it was on and get any encryption keys to the
| Truecrypt volume. They would actually announce that they were
| coming in on suspicion of child porn because people had a
| tendency to boot the computer and open Truecrypt to delete all
| their files.
|
| I suspect similar techniques are still used today, like we see
| with this tool. If you can get a dump of the computer active
| memory you can ultimately get the decryption keys on consumer
| hardware.
| srtjstjsj wrote:
| It seems unlikely that
|
| (a) FBI understood truecrypt
|
| (b) the target understood truecrypt
|
| (c) the target misunderstood the entire purpose of truecrypt,
| and they would misuse it to expose themselves
|
| and (d) the FBI expected this and intentionally blew their
| cover, leaving the target a chance to destroy the drive.
| enedil wrote:
| It's likely though that they knew that AES keys are
| somewhere in the memory.
| Drip33 wrote:
| >If you can get a dump of the computer active memory you can
| ultimately get the decryption keys on consumer hardware
|
| What methods are available to get a memory dump if Firewire
| is disabled? Feds couldn't break my encryption after ~1.5
| years but my devices were all off when they showed up.
| Ironically the one device they did get into was a cell phone
| powered on but it had little evidentiary value and in one
| funny way was partly exculpatory.
| koolba wrote:
| You can freeze the computer, remove the DIMMs, and then pop
| them into a different machine to read them: https://electro
| nics.stackexchange.com/questions/32189/freezi...
| Drip33 wrote:
| I thought that wasn't possible since DDR3 or 4?
| ATsch wrote:
| Smaller capacitors will keep their charge less long,
| which makes this more difficult, but I understand that
| there are no fundamental mitigations.
| Avamander wrote:
| There's (T)SME.
| TACIXAT wrote:
| You can do it via PCIe as well. [1]
|
| 1. https://github.com/ufrisk/pcileech
| benlivengood wrote:
| There was a neat patch to store the AES key in debug
| registers and do round key setup for each block. It was
| even faster than the normal routine. https://www.usenix.org
| /event/sec11/tech/full_papers/Muller.p...
| IncRnd wrote:
| It's a DMA attack, not necessarily a FW attack. DMA is
| direct memory access, which is how the attacks worked.
| dtech wrote:
| USB-C+Thunderbolt or eSATA with a vulnerable controller. I
| know modern OSes have protection against driveby-DMA, but
| don't know if they protect against memory dump if the
| "user" - or attacker who gained access to a logged in
| system - consents.
|
| All these attacks target decryption keys in memory, so they
| don't work on devices which are turned off.
| Drip33 wrote:
| I'm assuming the computer is "locked" but online, and no
| users consent to logging in to run anything. Will any of
| these methods still work if Firewire drivers are
| disabled?
| wongarsu wrote:
| In that case USB-C/Thunderbolt won't work, in the default
| config you need to trust the device and cable before
| anything too interesting can happen. This can be turned
| off via bios setting though, so there's room for
| misconfiguration.
|
| E-SATA or PCIe hotplug might still work. However the
| former is getting less common, and the latter is uncommon
| in consumer mainboards.
| based2 wrote:
| https://github.com/susam/aes.vbs
| alcover wrote:
| The TRESOR[1] kernel patch was proposed to prevent these attacks.
|
| It stores keys in privileged registers.
|
| [1]https://en.wikipedia.org/wiki/TRESOR
| hn_throwaway_99 wrote:
| Can someone explain how this works? I thought AES keys were just
| random bytes, but obviously there must be more to them if this
| tool is able to detect them.
| saagarjha wrote:
| The parent repository has a decent answer:
| https://github.com/mmozeiko/aes-finder/issues/12#issuecommen...
| cperciva wrote:
| Looks to me like it's searching for _expanded_ keys, i.e. the
| sequence of round keys, not just raw AES keys.
| EE84M3i wrote:
| I took a skim of the source[1] -- I think that it's looking for
| an expanded set of round keys[2] using their expected layout in
| memory (accounting for endian flips, forward/reverse ordering,
| 128/192/256 bit variants, and enc/dec). If a matching region of
| memory is found, the first round key is the main key.
|
| [1]: https://github.com/MantechUser/aes-finder/blob/master/aes-
| fi... [2]: https://en.wikipedia.org/wiki/AES_key_schedule
| makomk wrote:
| Yeah, it's a trick that's been around for a while. The thing
| that makes it a little fiddly is that the various ways to
| store a key schedule, especially for decryption - it could be
| in either order, and there's some optimization to do with
| whether InvMixColumn is pre-applied to the values that I
| can't remember the details of. I actually had a fork of the
| classic aeskeyfind that added some of these tricks, though
| apparently it's broken at higher compiler optimizations now
| and I probably need to look into that:
| https://github.com/makomk/aeskeyfind Could just have used
| this instead if I'd known about it.
| dunham wrote:
| Also sqlite3's encryption seems to be a byte swapped AES.
|
| E.g. look for a byte swapped AES key schedule in dropbox
| process memory and you should find its sqlite3 encryption
| key.
| hinkley wrote:
| Shouldn't there be a way to relocate the bits so that the L1
| and L2 caches are still happy but the data structures aren't
| contiguous? Is the main problem that they are all malloced
| sequentially?
| EE84M3i wrote:
| What do you mean by "problem"? Are you talking about
| obfuscation?
| hinkley wrote:
| > looking for an expanded set of round keys[2] using
| their expected layout in memory
|
| The problem is predictability of the layout, right? The
| layout is chosen for throughput, but CPU caches can cope
| well with some nonlinear layouts.
| EE84M3i wrote:
| Keys having an expected layout in memory is not a
| problem, nor is being able to dump encryption keys from
| process memory if you have access to it. That's the
| security model these processes operate in.
|
| Processes could conceivably put keys in memory in a non-
| standard way that is more difficult to write a tool to
| scan for, but the fact that they don't is not a problem,
| and even if they did it would not make it impossible to
| write a tool.
| panpanna wrote:
| The point is that if we could move the pieces of key
| schedule around freely it would increase the complexity
| of the tool significantly since it will have to match
| each potential block against a number of other potential
| blocks.
| natch wrote:
| Sort of feel like such posts should link directly to the original
| repo the repo was forked from, if any.
|
| https://github.com/mmozeiko/aes-finder
|
| Unless there's some newsworthy aspect to the child repo being a
| special different fork.
| muststopmyths wrote:
| This fork has a "memdump" tool to dump the memory of a process
| and a "-f" option to search for keys in a file, which I assume
| is the dump from step 1.
|
| <shrug emoji>
| jonstewart wrote:
| This source file provides a better history for looking for AES
| keys. It looks like Sam Trenholme developed the technique
| originally but I know of it because of Jesse Kornblum's
| subsequent work. Simson Garfinkel then embedded relevant code
| inside of bulk_extractor. The technique is over a decade old:
|
| https://github.com/simsong/bulk_extractor/blob/master/src/sc...
| makomk wrote:
| It looks like this particular fork of this code has a few
| nice features that aren't in older versions, such as support
| for dumping memory and actually knowing about the other
| common formats of AES key schedule that are commonly found in
| the wild. It's really annoying to run a search over a dump
| that you suspect contains an AES key schedule and coming up
| with nothing because the encryption library used a slightly
| different way of storing it than the one expected by the
| tool.
| Popcorn_Butter wrote:
| The pull request https://github.com/mmozeiko/aes-finder/pull/11
|
| Says "Improved cross platform capability, key dumping, memory
| dump search." but it's not even new code so nm comment on it.
| Popcorn_Butter wrote:
| The pull request https://github.com/mmozeiko/aes-finder/pull/11
|
| Says "Improved cross platform capability, key dumping, memory
| dump search." but it's not even new code so nm to comment on
| it.
| onigiri69 wrote:
| Someone please run this on matlab...
| knorker wrote:
| Also see this from 2007:
| http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87....
|
| I believe I also saw that talk at a CCC camp back then.
|
| Edit: ah yes, here it is:
| https://media.ccc.de/v/cccamp07-en-2002-Cryptographic_key_re...
| heavenlyblue wrote:
| There were also tools about 15 years ago to find the entry point
| to encryption routines by finding the SBox constants.
| tptacek wrote:
| There's lots of those, and they're _much_ easier to write,
| since you 're literally just grepping memory for a fixed
| string.
___________________________________________________________________
(page generated 2020-09-06 23:00 UTC)