Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hidden Messages in Emojis and Hacking the US Treasury

slamdunksoftware.substack.com

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Hidden Messages in Emojis and Hacking the US Treasury

#21

Post by 0xbadcafebee »

cogman10 wrote: post #7

> Now, all of this might have been fine had Beyond Trust not written a feature which allowed users to directly, programmatically interact with psql (the postgres command line interface). That's the buried lede. Yes, there was a vulnerability in psql... but that's so much less a problem than the huge gaping hole of allowing users to directly interact with psql. No DB can be safe if you are turning untrusted user comma…

The only reason BeyondTrust implemented that was it wasn't untrusted user commands. They sanitized the data, so it should have been fine. The unfortunate problem was that the sanitizer didn't sanitize.

Systems are built on a set of expectations. Undermine the expectations and you undermine the system.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#22

Post by nkrisc »

jfengel wrote: post #19
xmprt wrote: post #5

I learned about the breach a few days ago but I didn't know that you could "adopt" an emoji: https://aac.unicode.org/sponsors That's a neat tidbit.

Does "adopting an emoji" mean something other than "appearing on that page"? From the adoption page: Each adoption comes with a digital badge and certificate that you can proudly display.

It’s a fun way to donate.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#23

Post by kevinsync »

Fun fact: MySQL (and I'm sure many other databases?) lets you pass in values directly as hexadecimal strings.

I've avoided SQL injection since ancient times not by escaping strings, but by transforming any given input via "0x" + bin2hex(value) and plopping that into the query.

No quotes needed, no code buried deep in included libraries needed, handles any kind of data possible, and also no funny business sneaking in based on how you may have mangled the input.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#24

Post by defen »

netsharc wrote: post #15

Geez, any summary of this article that tells it like the reader isn't five years old?

UTF-8 encodes a unicode codepoint into 1, 2, 3, or 4 bytes. Assuming that you have a valid UTF-8 encoding of a codepoint, then the first byte tells you how many bytes are in the encoding. 0-127 inclusive means one byte, 192-223 means 2, 224-239 means 3, and 240-247 means 4. If the first byte is 0xC0 (192), then the sequence is two bytes long. However, not every 2-byte sequence that starts with 0xC0 is valid UTF-8. The uppermost bits of the second byte must be `10` in a valid 2-byte UTF-8 sequence. 0x27 does not meet that criteria, so `0xC0 0x27` is not valid UTF-8. If your escape function operates at the level of unicode codepoints but doesn't actually verify that they're valid, you end up copying a single quote into your "escaped" buffer that downstream parts of the code will hit.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#25

Post by gowld »

0xbadcafebee wrote: post #18
netsharc wrote: post #15

Geez, any summary of this article that tells it like the reader isn't five years old?

A PHP app called a Postgres library function to "escape strings" for use in Postgres, and that called a function to get a utf8 string length, but the function was bullshit: > The PQescapeStringInternal method doesn’t actually validate that the string it is parsing with pg_utf_mblen is valid Unicode. So, instead, it just takes the length of 2, and grabs the next byte. So the bug was a shitty function in a generic open…

* Custom Unicode parsing code in the middle of an "escape" function

* No static type-checking for Unicode data

Re: Hidden Messages in Emojis and Hacking the US Treasury

#26

Post by gowld »

cogman10 wrote: post #7

> Now, all of this might have been fine had Beyond Trust not written a feature which allowed users to directly, programmatically interact with psql (the postgres command line interface). That's the buried lede. Yes, there was a vulnerability in psql... but that's so much less a problem than the huge gaping hole of allowing users to directly interact with psql. No DB can be safe if you are turning untrusted user comma…

Let's be clear: Beyond Trust is not a company that wrote a database-backed web app and made the all-too-common mistake of writing insecure code that tickled a bug in the database that allowed privilege escalation. Beyond Trust's is a company whose entire contribution is adding a security layer to prevent privilege escalation, and their solution here was to bypass Postgres's standard functionality and use this weird `psql` hack instead.

They had one job, and they failed at it. This amateur-level mistake should sink the entire company.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#27

Post by nix0n »

pavel_lishin wrote: post #9
giancarlostoro wrote: post #3

Earlier quoted context omitted.

I havent deep dived unicode enough to know, and probably someone somewhere already made it, but I often wonder if we can do compression more efficiently by abusing unicode somehow, especially regarding plain text.

I swear qntm has written something about this.

https://qntm.org/unicodings

Re: Hidden Messages in Emojis and Hacking the US Treasury

#28

Post by cogman10 »

0xbadcafebee wrote: post #21
cogman10 wrote: post #7

> Now, all of this might have been fine had Beyond Trust not written a feature which allowed users to directly, programmatically interact with psql (the postgres command line interface). That's the buried lede. Yes, there was a vulnerability in psql... but that's so much less a problem than the huge gaping hole of allowing users to directly interact with psql. No DB can be safe if you are turning untrusted user comma…

The only reason BeyondTrust implemented that was it wasn't untrusted user commands . They sanitized the data, so it should have been fine. The unfortunate problem was that the sanitizer didn't sanitize. Systems are built on a set of expectations. Undermine the expectations and you undermine the system.

> They sanitized the data, so it should have been fine.

This is a 101 rookie level approach to SQL or injection defense.

It's dumb for exactly the same reason why this is dumb

    "SELECT * FROM foo WHERE bar=" + sanitize(userInput)
The correct way to do something like this will always be parameterized input which looks something like this

    "SELECT * FROM foo WHERE bar=?"
    bindParameter(1, userInput);
Why? Because that the postgres protocol splits out the command and the data for the command in a way that can't be injected. Something that should be viewed as impossible to do when data and command are merged into 1 String.

IF this company wanted to build dynamic queries, then the only correct way to do that is to limit input to only valid variables. IE "isValidColumnName(userInput)" before sending the request. And even then, you'd not use psql to do that.

You simply can't use a generalized sanitizer and expect good results.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#29

Post by rapind »

benmmurphy wrote: post #10
mtrovo wrote: post #4

So many questions: - why a no side-effects function on a database can be used to get lateral access to the whole database instance - why do you need to validate strings on the database itself and not on the client anyway, heck why are there no type safe way of doing it - why would you want to execute shell commands from the database itself - Even if there's a real use case for executing commands like that why is it e…

They mentioned PAM module so maybe the sql injection just allowed bypassing the authorization of a system that was using the PAM module. Like it’s in the realm of possibility that a PAM module that wanted to validate a user against credentials stored in a pg database might shell out to the psql command to do this. Though, the whole thing is very questionable.

Yeah we’re missing some info.

What account were they authenticating with when attaching to psql?

If you have the connection string why does psql even matter, couldn’t you use any client? Or is this a case of your input being forwarded to a running, already authenticated, psql instance?

And finally, why do we need unicode support for schema? I assume it’s because the schema is itself data?

Re: Hidden Messages in Emojis and Hacking the US Treasury

#30

Post by rapind »

hnlmorg wrote: post #2

As someone who’s done a fair amount with parsing of Unicode strings lately, I’m not at all surprised by this bug. Unicode is a surprisingly elegant system but also an open invitation for all kinds of abuse.

> Unicode is a surprisingly elegant system…

s/elegant/clever

What could go wrong? I bet unicode is how AGI escapes and enslaves humanity.

Post reply on HN