Update (2020-04-29): Twitter has fixed their oversight.

{ "errors": [{ "code": 356, "message": "preferences.gender_preferences.gender_override: Must provide a non-empty custom value 30 characters or less in length." }]}

Anyone who set their custom gender to a long volume of text, should still have it set to a long volume of text.

The original article follows after the separator.

I was recently made aware of a change to Twitter, which exposes a new Gender field. If you’ve never specified your gender before, they guessed what it was (which is a really shitty thing to do, especially towards trans folks!).

https://twitter.com/leemandelo/status/1254179716451438592

Slightly annoyed, I went to go see what Twitter thinks my gender is.

Curses! They know I’m a guy. This won’t do at all.

But what’s this? An “Add your gender” option?

That’s at least, something, I guess? Defaulting to [whatever the algorithm guesses] is sucky, but at least nonbinary folks can still self-identify however they want.

But 30 characters isn’t a lot. What if I want to drop in, say, 68 characters? Do I need to do some crazy Unicode fuckery to pull that off?

Nope, Inspect Element + set maxlength="255" and now Twitter thinks my gender is the EICAR test file. Wonderful!

Which means: If someone downloads my Twitter data without my consent onto a workstation running antivirus software, the file will delete itself and all will be right in the marketing world.

https://twitter.com/SoatokDhole/status/1254635753319079937

(Okay but seriously, a lot of downstream systemic failures would have to exist for any damage to occur from me deciding to self-identify to marketers this way.)

Lessons to Learn

Twitter enforced a maxlength of 30 in the HTML element of the “Add your gender” text input, but they didn’t enforce this requirement server-side. The takeaway here is pretty obvious.

Also, don’t try to automatically[b] guess people’s gender at scale[/b]. It’s insulting when you get it wrong, and it’s creepy when you get it right.

(This sticker is tongue-in-cheek.)

What’s the Upper Limit for the Field?

I don’t know, but this indicates it has a larger upper bound than a tweet.

https://twitter.com/txlon5/status/1254648412261228545

If anyone has success dropping an entire thesis on gender identity and culture in the Gender field, let me know.

Update: The Best Genders

Everyone is having a lot of fun with the Gender field. Here’s some of the best tweets I’ve seen since publishing this stupid bug.

https://twitter.com/TecraFox/status/1254653500887310337

https://twitter.com/everlasting1der/status/1254652388713082880

https://twitter.com/hedgehog_emoji/status/1254650551473594368

https://twitter.com/Neybulot/status/1254659048886210563

A fox in Furry Technologists suggested building genderfs, which is a lot like redditfs but hoists the entire filesystem into the Gender field.

While I have your attention, trans rights are human rights and biology disagrees with the simple notion of “two sexes”. Thank you and good night.

https://soatok.blog/2020/04/27/why-server-side-input-validation-matters/

#furry #infosec #inputValidation #LGBTQIA_ #security #softwareDevelopment #Twitter

Dhole Moments

2020-04-27 05:22:30

Update (2020-04-29): Twitter has fixed their oversight.

{ "errors": [{ "code": 356, "message": "preferences.gender_preferences.gender_override: Must provide a non-empty custom value 30 characters or less in length." }]}

Anyone who set their custom gender to a long volume of text, should still have it set to a long volume of text.

The original article follows after the separator.

---

I was recently made aware of a change to Twitter, which exposes a new Gender field. If you’ve never specified your gender before, they guessed what it was (which is a really shitty thing to do, especially towards trans folks!).

https://twitter.com/leemandelo/status/1254179716451438592

Slightly annoyed, I went to go see what Twitter thinks my gender is.

Curses! They know I’m a guy. This won’t do at all.

But what’s this? An “Add your gender” option?

That’s at least, something, I guess? Defaulting to [whatever the algorithm guesses] is sucky, but at least nonbinary folks can still self-identify however they want.

But 30 characters isn’t a lot. What if I want to drop in, say, 68 characters? Do I need to do some crazy Unicode fuckery to pull that off?

Nope, Inspect Element + set maxlength="255" and now Twitter thinks my gender is the EICAR test file. Wonderful!

Which means: If someone downloads my Twitter data without my consent onto a workstation running antivirus software, the file will delete itself and all will be right in the marketing world.

https://twitter.com/SoatokDhole/status/1254635753319079937

(Okay but seriously, a lot of downstream systemic failures would have to exist for any damage to occur from me deciding to self-identify to marketers this way.)

Lessons to Learn

Twitter enforced a maxlength of 30 in the HTML element of the “Add your gender” text input, but they didn’t enforce this requirement server-side. The takeaway here is pretty obvious.

Also, don’t try to automatically[b] guess people’s gender at scale[/b]. It’s insulting when you get it wrong, and it’s creepy when you get it right.

(This sticker is tongue-in-cheek.)

What’s the Upper Limit for the Field?

I don’t know, but this indicates it has a larger upper bound than a tweet.

https://twitter.com/txlon5/status/1254648412261228545

If anyone has success dropping an entire thesis on gender identity and culture in the Gender field, let me know.

Update: The Best Genders

Everyone is having a lot of fun with the Gender field. Here’s some of the best tweets I’ve seen since publishing this stupid bug.

https://twitter.com/TecraFox/status/1254653500887310337

https://twitter.com/everlasting1der/status/1254652388713082880

https://twitter.com/hedgehog_emoji/status/1254650551473594368

https://twitter.com/Neybulot/status/1254659048886210563

A fox in Furry Technologists suggested building genderfs, which is a lot like redditfs but hoists the entire filesystem into the Gender field.

While I have your attention, trans rights are human rights and biology disagrees with the simple notion of “two sexes”. Thank you and good night.

https://soatok.blog/2020/04/27/why-server-side-input-validation-matters/

#furry #infosec #inputValidation #LGBTQIA_ #security #softwareDevelopment #Twitter

Imagine you’re a software developer, and you need to authenticate users based on a username and password.

If you’re well-read on the industry standard best practices, you’ll probably elect to use something like bcrypt, scrypt, Argon2id, or PBKDF2. (If you thought to use something else, you’re almost certainly doing it wrong.)

Let’s say, due to technical constraints, that you’re forced to select PBKDF2 out of the above options, but you’re able to use a suitable hash function (i.e. SHA-256 or SHA-512, instead of SHA-1).

Every password is hashed with a unique 256-bit salt, generated from a secure random generator, and has an iteration count in excess of 80,000 (for SHA-512) or 100,000 (for SHA-256). So far, so good.

(Art by Khia.)

Let’s also say your users’ passwords are long, randomly-generated strings. This can mean either you’re building a community of password manager aficionados, or your users are actually software bots with API keys.

Every user’s password is, therefore, always a 256 character string of random hexadecimal characters.

Two sprints before your big launch, your boss calls you and says, “Due to arcane legal compliance reasons, we need to be able to detect duplicate passwords. It needs to be fast.”

You might might think, “That sounds like a hard problem to solve.”

Your boss insists, “The passwords are all too long and too high-entropy to reliably attacked, even when we’re using a fast hash, so we should be able to get by with a simple hash function for deduplication purposes.”

So you change your code to look like this:

<?phpuse ParagonIE\EasyDB\EasyDB;use MyApp\Security\PasswordHash;class Authentication { private EasyDB $db; public function __construct(EasyDB $db) { $this->db = $db; $this->pwhash = new PasswordHash('sha256'); } public function signUp(string $username, string $password) { // New: $hashed = hash('sha256', $password); if ($db->exists( "SELECT count(id) FROM users WHERE pw_dedupe = ?", $hashed )) { throw new Exception( "You cannot use the same username or password as another user." ); } // Original: if ($db->exists( "SELECT count(id) FROM users WHERE username = ?", $username )) { throw new Exception( "You cannot use the same username or password as another user." ); } $this->db->insert('users', [ 'username' => $username, 'pwhash' => $this->pwhash->hash($password), // Also new: 'pw_dedupe' => $hashed ]); } public function logIn(string $username, string $password): int { // This is unchanged: $user = $this->db->row("SELECT * FROM users WHERE username = ?", $username); if (empty($user)) { throw new Exception("Security Error: No user"); } if ($this->pwhash->verify($password, $user['pwhash'])) { throw new Exception("Security Error: Incorrect password"); } return (int) $user['id']; }}

Surely, this won’t completely undermine the security of the password hashing algorithm?

Is this a face that would mislead you? (Art by Khia.)

Three years later, a bored hacker discovers a read-only SQL injection vulnerability, and is immediately able to impersonate any user in your application.

What could have possibly gone wrong?

Cryptography Bugs Are Subtle

https://twitter.com/SwiftOnSecurity/status/832058185049579524

In order to understand what went wrong in our hypothetical scenario, you have to kinda know what’s under the hood in the monstrosity that our hypothetical developer slapped together.

PBKDF2

PBKDF2 stands for Password-Based Key Derivation Function #2. If you’re wondering where PBKDF1 went, I discussed its vulnerability in another blog post about the fun we can have with hash functions.

PBKDF2 is supposed to be instantiated with some kind of pseudo-random function, but it’s almost always HMAC with some hash function (SHA-1, SHA-256, and SHA-512 are common).

So let’s take a look at HMAC.

HMAC

HMAC is a Message Authentication Code algorithm based on Hash functions. Its definition looks like this:

Source: Wikipedia

For the purposes of this discussion, we only care about the definition of K’.

If your key (K) is larger than the block size of the hash function, it gets pre-hashed with that hash function. If it’s less than or equal to the block size of the hash function, it doesn’t.

So, what is PBKDF2 doing with K?

How PBKDF2 Uses HMAC

The RFCs that define PBKDF2 aren’t super helpful here, but one needs only look at a reference implementation to see what’s happening.

// first iteration$last = $xorsum = hash_hmac($algorithm, $last, $password, true);// perform the other $count - 1 iterationsfor ($j = 1; $j < $count; $j++) {$xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));}$output .= $xorsum;

If you aren’t fluent in PHP, it’s using the previous round’s output as the message (m in the HMAC definition) and the password as the key (K).

Which means if your password is larger than the block size of the hash function used by HMAC (which is used by PBKDF2 under the hood), it will be pre-hashed.

The Dumbest Exploit Code

Okay, with all of that in mind, here’s how you can bypass the authentication of the above login script.

$httpClient->loginAs( $user['username'], hex2bin($user['pw_dedupe']));

Since K’ = H(K) when Length(K) > BlockSize(H), you can just take the pre-calculated hash of the user’s password and use that as the password (although not hex-encoded), and it will validate. (Demo.)

This is probably how you feel right now, if you didn’t already know about this.
(Art by Khia.)

Above, when HMAC defined K’, it included a variant in its definition. Adding variants to hash function is a dumb way to introduce the risk of collisions. (See also: Trivial Collisions in IOTA’s Kerl hash function.)

Also, some PBKDF2 implementations that mishandle the pre-hashing of K, which can lead to denial-of-service attacks. Fun stuff, right?

Some Dumb Yet Effective Mitigations

Here are a few ways the hypothetical developer could have narrowly avoided this security risk:

• Use a different hash function for PBKDF2 and the deduplication check.
  
  • e.g. PBKDF2-SHA256 and SHA512 would be impervious

  
  

• Always pre-hashing the password before passing it to PBKDF2.
  
  • Our exploit attempt will effectively be double-hashed, and will not succeed.

  
  

• Use HMAC instead of a bare hash for the deduplication. With a hard-coded, constant key.
• Prefix the password with a distinct domain separation constant in each usage.
• Truncate the hash function, treating it as a Bloom filter.
• Some or all of the above.
• Push back on implementing this stupid feature to begin with.

Subtle problems often (but not always) call for subtle solutions.

Password Security Advice, Revisited

One dumb mitigation technique I didn’t include above is, “Using passwords shorter than the block size of the hash function.” The information security industry almost unanimously agrees that longer passwords are better than short ones (assuming both have the same distribution of possible characters at each position in the string, and are chosen randomly).

But here, we have a clear-cut example where having a longer password actually decreased security by allowing a trivial authentication bypass. Passwords with a length less than or equal to the block size of the hash function would not be vulnerable to the attack.

For reference, if you ever wanted to implement this control (assuming ASCII characters, where 1 character = 1 byte):

• 64-character passwords would be the upper limit for MD5, SHA-1, SHA-224, and SHA-256.
• 128-character passwords would be the upper limit for SHA-384 and SHA-512.
• (Since the above example used 256-character passwords, it always overflows.)

But really, one of the other mitigation techniques would be better. Limiting the input length is just a band-aid.

Another Non-Obvious Footgun

Converse to the block size of the hash function, the output size of the hash function also affects the security of PBKDF2, because each output is calculated sequentially. If you request more bytes out of a PBKDF2 function than the hash function outputs, it will have to work at least twice as hard.

This means that, while a legitimate user has to calculate the entire byte stream from PBKDF2, an attacker can just target the first N bytes (20 for SHA-1, 32 for SHA-256, 64 for SHA-512) of the raw hash output and attack that instead of doing all the work.

Is Cryptography Hard?

I’ve fielded a lot of questions in the past few weeks, and consequently overheard commentary from folks insisting that cryptography is a hard discipline and therefore only the smartest should study it. I disagree with that, but not for the reason that most will expect.

Many of the people reading this page will tell me, “This is such a dumb and obvious design flaw. Nobody would ship that code in production,” because they’re clever or informed enough to avoid disaster.

Yet, we still regularly hear about JWT alg=none vulnerabilities. And Johnny still still can’t encrypt. So cryptography surely can’t be easy.

Art by Riley.

Real-world cryptographic work is cognitively demanding. It becomes increasingly mathematically intensive the deeper you study, and nobody knows how to name things that non-cryptographers can understand. (Does anyone intuitively understand what a public key is outside of our field?)

In my opinion, cryptography is certainly challenging and widely misunderstood. There are a lot of subtle ways for secure building blocks to be stitched together insecurely. And today, it’s certainly a hard subject for most people to learn.

However, I don’t think its hardness is unavoidable.

Descending the Mohs Scale

There is a lot of gatekeeping in the information security community. (Maybe we should expect that to happen when people spend too many hours staring at firewall rules?)

“Don’t roll your own crypto” is something you hear a lot more often from software engineers and network security professionals than bona fide cryptographers.

Needless gatekeeping does the cryptographic community a severe disservice. I’m not the first to suggest that, either.

From what I’ve seen, far too many people feel discouraged from learning about cryptography, thinking they aren’t smart enough for it. It would seem A Mathematician’s Lament has an echo.

If it can be said that cryptography is hard today, then that has more to do with incomplete documentation and substandard education resources available for free online than some inherent mystical quality of our discipline that only the christened few can ever hope to master.

Cryptographers and security engineers that work in cryptography need more developers to play in our sandbox. We need more usability experts to discuss improvements to our designs and protocols to make them harder to misuse. We also need science communication experts and a legal strategy to stop idiotic politicians from trying to foolishly ban encryption.

So if you’re reading my blog, wondering, “Will I ever be smart enough to understand this crap?” the answer is probably “Yes!” It might not be easy, but with any luck, it’ll be easier than it was for the forerunners in our field.

If a random furry can grok these topics, what’s stopping you? This dhole believes in you.
(Art by Khia.)

I have one request, though: If you’re thinking of learning cryptography, please blog about your journey (even if you’re not a furry). You may end up filling in a pothole that would otherwise have tripped someone else up.

https://soatok.blog/2020/11/27/the-subtle-hazards-of-real-world-cryptography/

#computerSecurity #cryptographicHashFunction #cryptography #dumbExploit #HMAC #infosec #passwordHashing #PBKDF2 #SecurityGuidance

Dhole Moments

2020-05-05 12:00:22

There are several different methods for securely hashing a password server-side for storage and future authentication. The most common one (a.k.a. the one that FIPS allows you to use, if compliance matters for you) is called PBKDF2. It stands for Password-Based Key Derivation Function #2.

Why #2? It’s got nothing to do with pencils. There was, in fact, a PBKDF1! But PBKDF1 was fatally insecure in a way I find very interesting. This StackOverflow answer is a great explainer on the difference between the two.

Very Hand-Wavy Description of a Hash Function

Let’s defined a hash function as any one-way transformation of some arbitrary-length string () to a fixed-length, deterministic, pseudo-random output.

Note: When in doubt, I err on the side of being easily understood by non-experts over pedantic precision. (Art by Swizz)

For example, this is a dumb hash function (uses SipHash-2-4 with a constant key):

function dumb_hash(string $arbitrary, bool $raw_binary = false): string{ $h = sodium_crypto_shorthash($arbitrary, 'SoatokDreamseekr'); if ($raw_binary) { return $h; } return sodium_bin2hex($h);}

You can see the output of this function with some sample inputs here.

Properties of Hash Functions

A hash function is considered secure if it has the following properties:

1. Pre-image resistance. Given , it should be difficult to find .
2. Second pre-image resistance. Given , it should be difficult to find such that
3. Collision resistance. It should be difficult to find any arbitrary pair of messages () such that

That last property, collision resistance, is guaranteed up to the Birthday Bound of the hash function. For a hash function with a 256-bit output, you will expect to need on average trial messages to find a collision.

If you’re confused about the difference between collision resistance and second pre-image resistance:

Collision resistance is about finding any two messages that produce the same hash, but you don’t care what the hash is as long as two distinct but known messages produce it.

On the other paw, second pre-image resistance is about finding a second message that produces a given hash.

Exploring PBKDF1’s Insecurity

If you recall, hash functions map an arbitrary-length string to a fixed-length string. If your input size is larger than your output size, collisions are inevitable (albeit computationally infeasible for hash functions such as SHA-256).

But what if your input size is equal to your output size, because you’re taking the output of a hash function and feeding it directly back into the same hash function?

Then, as explained here, you get an depletion of the possible outputs with each successive iteration.

But what does that look like?

Without running the experiments on a given hash function, there are two possibilities that come to mind:

1. Convergence. This is when will, for two arbitrary messages and a sufficient number of iterations, converge on a single hash output.
2. Cycles. This is when for some integer .

The most interesting result would be a quine, which is a cycle where (that is to say, ).

The least interesting result would be for random inputs to converge into large cycles e.g. cycles of size for a 256-bit hash function.

I calculated this lazily as the birthday bound of the birthday bound (so basically the 4th root, which for is ).

Update: According to this 1960 paper, the average time to cycle is , and cycle length should be , which means for a 256-bit hash you should expect a cycle after about or about 128 bits, and the average cycle length will be about . Thanks Riastradh for the corrections.

Conjecture: I would expect secure cryptographic hash functions in use today (e.g. SHA-256) to lean towards the least interesting output.

An Experiment Design

Since I don’t have an immense amount of cheap cloud computing at my disposal to run this experiments on a real hash function, I’m going to cheat a little and use my constant-key SipHash code from earlier in this post. In future work, cryptographers may find studying real hash functions (e.g. SHA-256) worthwhile.

Given that SipHash is a keyed pseudo-random function with an output size of 64 bits, my dumb hash function can be treated as a 64-bit hash function.

This means that you should expect your first collision (with 50% probability) after only trial hashes. This is cheap enough to try on a typical laptop.

Here’s a simple experiment for convergence:

1. Generate two random strings .
2. Set .
3. Iterate until .

You can get the source code to run this trivial experiment here.

Clone the git repository, run composer install, and then php bin/experiment.php. Note that this may need to run for a very long time before you get a result.

If you get a result, you’ve found a convergence.

If the loop doesn’t terminate even after 2^64 iterations, you’ve definitely found a cycle. (Actually detecting a cycle and analyzing its length would require a lot of memory, and my simple PHP script isn’t suitable for this effort.)

“What do you mean I don’t have a petabyte of RAM at my disposal?”

What Does This Actually Tell Us?

The obvious lesson: Don’t design key derivation functions like PBKDF1.

But beyond that, unless you can find a hash function that reliably converges or produces short cycles (, for an n-bit hash function), not much. (This is just for fun, after all!)

Definitely fun to think about though! (Art by circuitslime)

If, however, a hash function is discovered to produce interesting results, this may indicate that the chosen hash function’s internal design is exploitable in some subtle ways that, upon further study, may lead to better cryptanalysis techniques. Especially if a hash quine is discovered.

(Header art by Khia)

https://soatok.blog/2020/05/05/putting-the-fun-in-hash-function/

#crypto #cryptography #hashFunction #SipHash

There are two news stories today. Unfortunately, some people have difficulty uncoupling the two.

1. The Team Fortress 2 Source Code has been leaked.
2. Hackers discovered a Remote Code Execution exploit.

The second point is something to be concerned about. RCE is game over. The existence of an unpatched RCE vulnerability, with public exploits, is sufficient reason to uninstall the game and wait for a fix to be released. Good on everyone for reporting that. You’re being responsible. (If it’s real, that is! See update at the bottom.)

The first point might explain why the second happened, which is fine for the sake of narrative… but by itself, a source code leak is a non-issue that nobody in their right mind should worry about from a security perspective.

Anyone who believes they’re less secure because the source code is public is either uninformed or misinformed.

I will explain.
Professor Dreamseeker is in the house. Twitch Emote by Swizz.

Why Source Code Leaks Don’t Matter for Security

You should know that, throughout my time online as a furry, I have been awarded thousand dollar bounties through public bounty programs.

How did you earn those bounties?
By finding zero-day vulnerabilities in those companies’ software.

But only some of those were for open source software projects. CreditKarma definitely does not share their Android app’s source code with security researchers.

How did you do it?
I simply reverse engineered their apps using off-the-shelf tools, and studied the decompiled source code.

Why are you making that sound trivial?
Because it is trivial!

If you don’t believe me, choose a random game from your Steam library.

Right click > Properties. Click on the Local Files tab, then click “Browse Local Files”. Now search for a binary.
Me, following these steps to locate the No Man’s Sky binary.
If your game is a typical C/C++ project, you’ll next want to install Ghidra.

Other platforms and their respective tools:

• Java games (.jar files): Luyten
• .NET games: ILSpy
• Android apps: dex2jar then Luyten (as per Java)

If you see a bunch of HTML and JS files, you can literally use beautifier.io to make the code readable.

Open your target binary in the appropriate reverse engineering software, and you can decompile the binary into C/C++ code.
Decompiled code from No Man’s Sky’s NMS.exe file on Windows.
Congratulations! If you’ve made it this far, you’re neck-and-neck with any attacker who has a leaked copy of the source code.

Every Information Security Expert Knows This

Almost literally everyone working in infosec knows that keeping a product’s source code a secret doesn’t actually improve the security of the product.

There’s a derisive term for this belief: Security Through Obscurity.

The only people whose job will be made more difficult with the source code leak are lawyers dealing with Intellectual Property (IP) disputes.

In Conclusion

Remote Code Execution is bad.

The Source Code being public? Yawn.
Pictured: Soatok trying to figure out why people are worried about source code disclosure when he publishes everything publicly on Github anyway (2020). Art by Riley.
Update: Shortly after I made this post, I was made aware of another news story worthy of everyone’s attention far more than FUD about source code leaks.

With the Source leaks happening today, I think everyone is missing the most important part: how much does Valve swear? I tallied up instances of these words in the leak*:

"fuck": 116
"shit": 63
"damn": 109

*There was some non-Valve stuff in the leak; I didn't count it

— @tj (@tjhorner) April 22, 2020

Well damn if that doesn’t capture my interest.
Now this is the kind of story that makes Twitter worthwhile!

Is the RCE Exploit Even Real?

Update 2: I’ve heard a lot of reports that the alleged RCE exploit is fake. I haven’t taken the time to look at Team Fortress 2 or CS:GO in any meaningful way, but the CS:GO team did have this to say about the leaks:

We have reviewed the leaked code and believe it to be a reposting of a limited CS:GO engine code depot released to partners in late 2017, and originally leaked in 2018. From this review, we have not found any reason for players to be alarmed or avoid the current builds.

— CS2 (@CounterStrike) April 22, 2020

Fake news and old news are strange (yet strangely common) bedfellows.

https://soatok.blog/2020/04/22/source-code-leak-is-effectively-meaningless-to-endpoint-security/

#commonSense #informationSecurity #infosec #misinformation #reverseEngineering #security #securityThroughObscurity #sourceCode

Dhole Moments

2020-04-22 22:13:34

There are two news stories today. Unfortunately, some people have difficulty uncoupling the two.

1. The Team Fortress 2 Source Code has been leaked.
2. Hackers discovered a Remote Code Execution exploit.

The second point is something to be concerned about. RCE is game over. The existence of an unpatched RCE vulnerability, with public exploits, is sufficient reason to uninstall the game and wait for a fix to be released. Good on everyone for reporting that. You’re being responsible. (If it’s real, that is! See update at the bottom.)

The first point might explain why the second happened, which is fine for the sake of narrative… but by itself, a source code leak is a non-issue that nobody in their right mind should worry about from a security perspective.

Anyone who believes they’re less secure because the source code is public is either uninformed or misinformed.

I will explain.
Professor Dreamseeker is in the house. Twitch Emote by Swizz.

Why Source Code Leaks Don’t Matter for Security

You should know that, throughout my time online as a furry, I have been awarded thousand dollar bounties through public bounty programs.

How did you earn those bounties?
By finding zero-day vulnerabilities in those companies’ software.

But only some of those were for open source software projects. CreditKarma definitely does not share their Android app’s source code with security researchers.

How did you do it?
I simply reverse engineered their apps using off-the-shelf tools, and studied the decompiled source code.

Why are you making that sound trivial?
Because it is trivial!

If you don’t believe me, choose a random game from your Steam library.

Right click > Properties. Click on the Local Files tab, then click “Browse Local Files”. Now search for a binary.
Me, following these steps to locate the No Man’s Sky binary.
If your game is a typical C/C++ project, you’ll next want to install Ghidra.

Other platforms and their respective tools:

• Java games (.jar files): Luyten
• .NET games: ILSpy
• Android apps: dex2jar then Luyten (as per Java)

If you see a bunch of HTML and JS files, you can literally use beautifier.io to make the code readable.

Open your target binary in the appropriate reverse engineering software, and you can decompile the binary into C/C++ code.
Decompiled code from No Man’s Sky’s NMS.exe file on Windows.
Congratulations! If you’ve made it this far, you’re neck-and-neck with any attacker who has a leaked copy of the source code.

Every Information Security Expert Knows This

Almost literally everyone working in infosec knows that keeping a product’s source code a secret doesn’t actually improve the security of the product.

There’s a derisive term for this belief: Security Through Obscurity.

The only people whose job will be made more difficult with the source code leak are lawyers dealing with Intellectual Property (IP) disputes.

In Conclusion

Remote Code Execution is bad.

The Source Code being public? Yawn.
Pictured: Soatok trying to figure out why people are worried about source code disclosure when he publishes everything publicly on Github anyway (2020). Art by Riley.
Update: Shortly after I made this post, I was made aware of another news story worthy of everyone’s attention far more than FUD about source code leaks.

With the Source leaks happening today, I think everyone is missing the most important part: how much does Valve swear? I tallied up instances of these words in the leak*:

"fuck": 116
"shit": 63
"damn": 109

*There was some non-Valve stuff in the leak; I didn't count it

— @tj (@tjhorner) April 22, 2020

Well damn if that doesn’t capture my interest.
Now this is the kind of story that makes Twitter worthwhile!

Is the RCE Exploit Even Real?

Update 2: I’ve heard a lot of reports that the alleged RCE exploit is fake. I haven’t taken the time to look at Team Fortress 2 or CS:GO in any meaningful way, but the CS:GO team did have this to say about the leaks:

We have reviewed the leaked code and believe it to be a reposting of a limited CS:GO engine code depot released to partners in late 2017, and originally leaked in 2018. From this review, we have not found any reason for players to be alarmed or avoid the current builds.

— CS2 (@CounterStrike) April 22, 2020

Fake news and old news are strange (yet strangely common) bedfellows.

https://soatok.blog/2020/04/22/source-code-leak-is-effectively-meaningless-to-endpoint-security/

#commonSense #informationSecurity #infosec #misinformation #reverseEngineering #security #securityThroughObscurity #sourceCode

That backdoor in sshd (via xz / liblzma) affects recent versions of Kali Linux:

Kali Linux announced that the impact of this vulnerability affected Kali between March 26th and March 29th. If you updated your Kali installation on or after March 26th, applying the latest updates today is crucial to address this issue. However, if you did not update your Kali installation before the 26th, you are not affected by this backdoor vulnerability.

More info here:
https://infosec.exchange/@kalilinux/112180505434870941

#infosec #hacking #cve20243094

Kali Linux

2024-03-29 18:57:49

As of the information we have currently, the following is true. Should more information come to light, we will continue to keep this situation updated.

The xz package, starting from versions 5.6.0 to 5.6.1, was found to contain a backdoor. This backdoor could potentially allow a malicious actor to compromise sshd authentication, granting unauthorized access to the entire system remotely. The impact of this vulnerability affected Kali between March 26th to March 29th. If you updated your Kali installation on or after March 26th, it is crucial to apply the latest updates today to address this issue. However, if you did not update your Kali installation before the 26th, you are not affected by this backdoor vulnerability.

More information can be found at https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/ and https://www.openwall.com/lists/oss-security/2024/03/29/4

Beware! Backdoor found in XZ utilities used by many Linux distros (CVE-2024-3094) - Help Net Security

A vulnerability (CVE-2024-3094) in XZ Utils may enable a malicious actor to gain unauthorized access to Linux systems remotely.

^{Zeljka Zorz (Help Net Security)}

Well this is fucking lovely....

Malicious code was discovered in the upstream tarballs of "xz" which then affects liblzma

Downstream there may be backdoors in various implementations of "sshd".

Versions Affected:

• Fedora 41
• Fedora Rawhide
• openSUSE Tumbleweed
• Debian testing, unstable, experimental distributions
• Kali updates between March 26th and March 29th

Original notice here:
https://www.openwall.com/lists/oss-security/2024/03/29/4

Red Hat CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-3094

Red Hat Security Blog Post: https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

Arch Linux Security Post: https://archlinux.org/news/the-xz-package-has-been-backdoored/

Debian Security Post: https://lists.debian.org/debian-security-announce/2024/msg00057.html

openSUSE Security Post: https://news.opensuse.org/2024/03/29/xz-backdoor/

Kali Linux announcement: https://infosec.exchange/@kalilinux/112180505434870941

CISA Advisory: https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094

Article here: https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/

#infosec #linux #foss #hacking #cve20243094 #cve

Kali Linux

2024-03-29 18:57:49

As of the information we have currently, the following is true. Should more information come to light, we will continue to keep this situation updated.

The xz package, starting from versions 5.6.0 to 5.6.1, was found to contain a backdoor. This backdoor could potentially allow a malicious actor to compromise sshd authentication, granting unauthorized access to the entire system remotely. The impact of this vulnerability affected Kali between March 26th to March 29th. If you updated your Kali installation on or after March 26th, it is crucial to apply the latest updates today to address this issue. However, if you did not update your Kali installation before the 26th, you are not affected by this backdoor vulnerability.

More information can be found at https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/ and https://www.openwall.com/lists/oss-security/2024/03/29/4

Beware! Backdoor found in XZ utilities used by many Linux distros (CVE-2024-3094) - Help Net Security

A vulnerability (CVE-2024-3094) in XZ Utils may enable a malicious actor to gain unauthorized access to Linux systems remotely.

^{Zeljka Zorz (Help Net Security)}

To prove the point that users will continue to click links, regardless of how obvious it is that they shouldn't, I worked with the person in charge of the monthly phishing trainings at $dayjob last month. Historically, they have used the hated ruses like fake gift cards, and I wanted to try to get away from that, especially during the holidays. We ended up using something to the effect of the following:

---
Hello <first name>,

Happy Holidays. This is the monthly phishing test. Yes, really. It's not a trick. Use the <phishing reporting function> to report this as phishing. If you do not know how to use <phishing reporting function>, feel free to ask a colleague. If you still have questions, search for <phishing reporting function> on <internal docs site>.

Do not click the following link as it is there for metrics and will cause you to be assigned phishing awareness training: <phishing training 'malicious' link>

Sincerely,
IT Security Team
---

I don't know how well it was received by users, but I do know that we still had more clicks than two other months in 2023, despite being explicitly told not to click the link. Users will always click links with their link-clicking machines. Relying on their discretion is either ignorant, or I expect in some cases, malicious in that there will always be a scapegoat to blame for the inevitable breach.

#phishing #infosec

Update: we seem to be unblocked. Thank you all!

—

Last night, the website of Reykjavík #Hackerspace, Hakkavélin, got flagged by Google's "Safe Browsing" as "deceptive":
https://mstdn.social/@rysiek/110166076666804008

The site is now unblocked. 🎉

But our #Yunohost login page is still blocked:
https://bob.hakkavelin.is/yunohost/sso/ 🤦‍♀️

We would really appreciate help with reporting this also as incorrect. You can do this here, and it takes less than a minute:
https://safebrowsing.google.com/safebrowsing/report_error/?tpl=mozilla&url=https%3A%2F%2Fbob.hakkavelin.is%2Fyunohost%2Fsso%2F

#FuckGoogle #Hackers #InfoSec

Michał "rysiek" Woźniak · 🇺🇦

2023-04-09 00:42:05

Edit: main site unblocked. #Yunohost login page still blocked.

—

Website of Reykjavík #Hackerspace, Hakkavélin, just got flagged by #Google Safe Browsing as "deceptive"; anyone who visits this site gets a scary red warning:
https://hakkavelin.is/

Thing is, I manage this site. It's literally a single static HTML file.

This is what we get for allowing shitty journalists to farm clicks by abusing the words "hacker" and "hack" to mean "cybercriminal" and "attack".

#FuckGoogle #Hackers #InfoSec

Hakkavélin

^{hakkavelin.is}