Security Fuckup Megathread - v17.1a - motherfuckers act like they forgot about jre

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Security Fuckup Megathread - v17.1a - motherfuckers act like they forgot about jre

«‹›2 »

apseudonym: Feb 25, 2011

Ground floor, are computers good yet?

# ¿ Dec 26, 2018 22:50

Adbot: ADBOT LOVES YOU

# ¿ May 8, 2024 15:38

apseudonym: Feb 25, 2011

Optimus_Rhyme posted:

Remember when that company got hacked and released all our information and turbo hosed us all? 2019 will be different, for sure.

2019 will be the year of secure companies and good fishmech posting.

Maybe.

# ¿ Dec 27, 2018 07:08

apseudonym: Feb 25, 2011

Is the point that it being unsecured without credentials is worse for state level actors than WPA? That's... Not how network attacking works.

If they're dumb enough (and they probably are) to believe that being on a network gives security properties then sure it's a fuckup, but thinking that link encryption makes a network safe is even more of a secfuck than a guest network

# ¿ Dec 31, 2018 22:40

apseudonym: Feb 25, 2011

I welcome our regulation overlords

# ¿ Jan 1, 2019 11:17

apseudonym: Feb 25, 2011

BangersInMyKnickers posted:

okay welcome to the loving dumbest pki implementation I have ever seen:

wwww.disa.mil exp 11/18/19
DOD ID SW CA-38 exp 9/23/21
DoD Root CA 3 exp 2/17/19 <-- lol
DoD Interop Root CA 2 exp 8/15/19 <-- lol�
Federal Bridge CA 2016 exp 5/15/20
TSCO SHA256 Bridge CA exp 2/19/19 <-- who the gently caress is this?
Alexion Pharmaceuticals Issue 2 CA exp 8/2/27 <-- WHO THE gently caress IS THIS??

Why the gently caress doesn't this stop at DoD Root CA 3 is beyond me but even that they hosed up your root should always have the last expiration date

Most likely answer: They've cross signed the CA (as everyone does) but due to wacky devices and whatever old CAs they trusted had to cross sign it to something dumb.

Do that for each CA and you see something like that.

# ¿ Jan 9, 2019 01:46

apseudonym: Feb 25, 2011

CmdrRiker posted:

Does that mean that this list is unordered once past the first few levels (DoD Root CA 3 exp 2/17/19) and since the CAs are cross signed the "wwww.disa.mil exp 11/18/19 < Alexion Pharmaceuticals Issue 2 CA exp 8/2/27 && wwww.disa.mil exp 11/18/19 > DoD Root CA 3 exp 2/17/19" dates can still be valid?

The bag of certs in a TLS connection is unordered (except that the first one is the server cert), so if you have something like:

Server -> Intermediate -> Root where Root is also Cross signed by Old the bag of certs might be Server, Intermediate, Root_crosssigned

For devices that have Root in their trust store they will build Server -> Intermediate -> Root (Root_crosssigned is ignored) and on old devices you'd build Server -> Intermediate -> Root_crossigned -> Old, you might do this for multiple levels if you have a CA that is itself cross signed by something newish, correct clients prefer trust anchors in path building so it works nicely.

However, the server is just returning the leaf and not any other certificates and that's the actual issue. The certificate paths you're seeing in SSLlabs are just possible paths given their set of known certificates so yeah with cross signing you can see a bunch of weird ones but that doesnt mean that's what is actually used and its just SSLLabs trying to find valid paths by following every possible bridge it knows about.

# ¿ Jan 9, 2019 04:32

apseudonym: Feb 25, 2011

CmdrRiker posted:

Thanks for taking the time to explain more. It helped.

I have implemented enough trust management that I like to post about it.

If you want to know why most attempts to do certificate pinning using Java's standard Trust Management APIs is wrong I can talk about that too

# ¿ Jan 10, 2019 06:48

apseudonym: Feb 25, 2011

Vesi posted:

I'd like to know about this

Volmarias posted:

Alright, posting time. I'm not going to compile the code I write here so if its slightly off :effort:

Pinning is about protecting yourself from a CA that is trusted by your device but is actually evil, so we assume the attacker owns a CA.

For the sake of naming, we've got the follow common certificates:

code:

CA_g --  a good CA that the real website uses
I -- intermediate issued by CA_g that issued the real certificate for the website, this is the certificate pinned  to.
CA_b -- evil CA we want pinning to protect us from
Evil -- Evil certificate for the website we want to MiTM that uses pinning

Also keep in mind that certificates form a graph which may have multiple possible paths between the leaf and a trusted issuer, path building is a straight up graph traversal problem, and this is important later.

The basic naive Java pinning is:

code:

public void checkPin(SSLSocket s) throws CertificateException {
	for (X509Certificate c : s.getSession().getPeerCertificates()) {
		if (PINS.contains(sha256(cert.getPublicKey().getEncoded())) {
			// Pin found!
			return;
		}
		throw new CertificateException("Pinning check failed!");
	}

Not having read the documentation involved this looks correct but its trivial to bypass because SSLSession.getPeerCertificates does not return the verified path but instead returns the bag of certificates provided by the server. The bag of certs is an arbitrary set of certificates which may or not be used in path building. The evil server just sends down {Evil, CA_b, I, CA_a}, the TrustManager will use the path [Evil, CA_b] which is valid and the pinning check will pass because I in included.

Ah, so you just need an API to get the actual path from the SSLSession, then its easy! Except Java doesn't give you such an API :smithicide:

. So instead a number of people decided to try and do their own path building before they check pins. I could add a bunch of code here but :effort:

, so let's just use an already existing implementation like this one. Its vulnerable and still not fixed but its publicly documented vulnerable on the issues page since 2017 so....

Now, this only works if you always build exactly the same certificate chain as the default TrustManager did, if you ever build a different one there's a problem. That's a terrible idea because a real path building is taking in account things like certificate usage, basic constraints, expiration, etc etc, whereas 'chain cleaners' only build the first possible path based on subject/issuer. In order to bypass this we would need to create a bag of certificates for our evil certificate wherethe real trust manager builds a valid chain to our evil CA but the path returned from the chain cleaner includes our pinned intermediate. With our evil CA this is pretty easy.

First we're going to get a valid leaf certificate from CA_g issued by I for a website under our control, call it notevil.com, since CA_g is in the business of issuing leaf certs for websites this is easy. Then we also issue an intermediate CA from CA_b with the same subject and key as our notevil.com leaf certificate and sign Evil with that.

The bag of certs we provide is then {Evil, notevil.com_leaf, notevil.com_intermediate, I, CA_g, CA_b}. There are two potential paths in this

code:

Path 1 -- [Evil, notevil.com_leaf, I, CA_g]
Path 2 -- [Evil, notevil.com_intermediate, CA_b]

Path 1 is not a trusted path since notevil.com_leaf will have the CA bit set in the basic constraints to false, but path 2 is a perfectly trusted path chaining to our evil CA. A trust manager that does everything in rfc4158 will try the first chain, reject it, and then try the second chain and see its valid. Chain cleaning however will build path 1 which will pass the pinning check.

Generally speaking anything that relies on two different implementations of the same spec behaving the exact same way is horribly broken in fun ways, but that's another topic for another post.

So you need to do one of: add an API that gives you the chain to make this trivial, write your own X509TrustManager that does pinning checks during chain validation, or figure out how to do it using the JCA APIs which if you can figure out correctly without losing your mind you're a better person than I am.

PS: Never pin to leafs and always include a backup SPKI hash if you really want to do pinning.

E: Also if you don't follow the cert chains I can make some actual certs as an example, but that's a lot of :effort:

apseudonym fucked around with this message at 03:33 on Jan 11, 2019

# ¿ Jan 11, 2019 03:28

apseudonym: Feb 25, 2011

Jabor posted:

Wait, so the validation APIs don't give you any way to tell "hey, here's the trust chain the platform used to determine that this certificate is valid"?

Are there any examples from whoever designed that api showing you how it's supposed to be used? Are you just supposed to do 100% of the certificate validation yourself and not rely on the platform doing anything?

Yeah... about that.

Realistically you use some extensions/have the OS provide you abstractions so you never have to touch this because also you shouldn't try and write your own X509TrustManager please I beg you let us do it you will do it wrong.

# ¿ Jan 11, 2019 03:54

apseudonym: Feb 25, 2011

Jabor posted:

Though thinking about it, in common use cases (you're using certificate pinning to ensure you're talking to a server you control), wouldn't it be easy enough to fail validation if the certificate bag contains more certs than you expect?

Like, you expect it to contain the leaf cert, your pinned intermediate, and that intermediate's root cert, and absolutely nothing else.

Good news your CA has changed their infrastructure and the intermediate is now no longer directly issuing certificates but is instead using another intermediate cert in between.

SPKI Pinning has lead to far more "welp guess all your clients can't connect anymore sorry pal" than it has prevented evil CA attacks.

CmdrRiker posted:

I hope everyone knows that they should never roll their own encryption.

Might want to check the author of the pinning library I linked

apseudonym fucked around with this message at 04:36 on Jan 11, 2019

# ¿ Jan 11, 2019 04:15

apseudonym: Feb 25, 2011

pseudorandom name posted:

it�s weird how the Hollywood portrayal of hacking started out absurdly wrong and then the entire industry raced to make the fictional real

The security industry doesn't make money from making things secure they make money from being flashy and Hollywood is flashy

# ¿ Jan 12, 2019 23:25

apseudonym: Feb 25, 2011

Lain Iwakura posted:

i ended up ranting in a thread about my dislike of infosec yesterday

https://twitter.com/KateLibc/status/1084506853042733056

someone decided that a klout-like website for infosec persons (really just men who are "thought leaders" with a few token women) would be a grand idea. it's everything i hate about infosec in one website

They dont even have natashenka on there, nice.

# ¿ Jan 15, 2019 03:23

apseudonym: Feb 25, 2011

Lain Iwakura posted:

why would they put a girl on there who is only known for having tamagotchis?

she is one of the nicest people in infosec i bet

I am always surprised the number of people who know her just for the tamagotchis.

she's one of the best offensive folks I know and a cool person

# ¿ Jan 15, 2019 04:46

apseudonym: Feb 25, 2011

Do people actually say there's no issues with the culture in infosec?

I'm not surprised, just sad. I swore a long time ago I'd never be a part of the community or industry and haven't regretted it in the slightest.

# ¿ Jan 16, 2019 00:17

apseudonym: Feb 25, 2011

Diva Cupcake posted:

are there project management Twitter rockstars?

Yes they are all about synergizing holistic learnings about user journeys and providing hero moments and oh god please end my pain

# ¿ Jan 16, 2019 00:34

apseudonym: Feb 25, 2011

Diva Cupcake posted:

well. end everything.

This for thread title

# ¿ Jan 16, 2019 00:41

apseudonym: Feb 25, 2011

CmdrRiker posted:

It's not specifically infosec. It happens a lot in industries that have diversity issues.

And the issues come in all sorts of shapes and sizes: A) people who act hostile towards others challenging their comfortable and secure notions about the world ("Prove sexism/racism exists!"), B) people who want to be inclusive but refuse to be aware of their subconscious biases ("I always treat men and women the same!"), or C) people that are completely indifferent or ignore diversity issues ("It doesn't affect me so why should I care?").

I know it's not unique to security, nor is it even close to my only gripe about the industry and community.

If all the bigotry went away in a day I'd still avoid it. There's too many creepy people and people selling bullshit solutions to things that aren't even a problem. I wish security stopped trying to be 'cool' and instead focused on actually helping people not have bad things happen to them because computers.

The number of times I've had people be confused when my response to them going on about the personal websites employees at their company visit is "you're my adversary and a creep" is enraging.

This thread is fun though and a good place to rant. Y'all ok.

# ¿ Jan 16, 2019 02:04

apseudonym: Feb 25, 2011

Shifty Pony posted:

https://twitter.com/chronic/status/1090399087827083264

if that's right this probably merits termination of Facebook's iOS development accounts. dunno if that's a fight Tim Cook will want to pick but if it is Facebook is really going to regret the bonfire of public goodwill they've been having for the past year.

Its that time of the sec fuckup thread where I say:

A modern OS should not support MiTM CAs and this is why. I'm still surprised iOS hasn't followed Android here.

# ¿ Jan 30, 2019 06:04

apseudonym: Feb 25, 2011

fisting by many posted:

at least not without enabling developer mode first and having a warning that actually explains what it is

I don't use iOS but android's permissions dialog really pisses me off because they make absolutely no distinction between permissions that are intrusive but plausibly required by the app (eg. Camera), permissions that really have no good reason to be granted (eg. device info), and permissions that are harmless (eg. "allow game to manage its own data?")

So people just click OK without understanding that they might actually be doing something very bad, because they have to click OK on every app they install.

There is no permission to "manage it's own data"?

apseudonym fucked around with this message at 16:03 on Jan 30, 2019

# ¿ Jan 30, 2019 15:59

apseudonym: Feb 25, 2011

fisting by many posted:

it's a google play games thing rather than an android thing but it's a similar prompt

there's just no reason to even ask yet it's given exactly as much weight as "allow app to rootkit your phone"

We also don't present an option to allow apps to rootkit your phone?

# ¿ Jan 30, 2019 16:43

apseudonym: Feb 25, 2011

Trabisnikof posted:

Well they have an android version of their VPN app so how does that one work?

You don't need to mitm TLS to do the kinds of "competitive intelligence" (gently caress that phrase) they at least used to be doing, you use things like unencrypted DNS and SNI. Hell you can even use packet sizes and timings to get a good guess.

As far as them losing all their internal apps due to this: "play stupid games win stupid prizes"

Lutha Mahtin posted:

google has gotten slightly better about this over the years but yes, they are still extremely bad about it. one example: apps are able to download updated files into a sandboxed area of the filesystem that belongs only to this app, but apps routinely lie to users that "oh we actually need full read/write access to you entire user data partition, it's totally required our app can't work without it" and i don't think i've ever heard of google yanking the apps from some chinese waifu game because the in-app permission explanation was kind of dishones

There is little correlation to what you read online about what's happening with security and reality.

# ¿ Jan 30, 2019 22:07

apseudonym: Feb 25, 2011

CmdrRiker posted:

I didn't know the difference between "competitive intelligence" and "economic espionage" so I went to wiki.

Welp.

Competitive intelligence is supposed to sound less bad than economic espionage, or something

# ¿ Jan 31, 2019 03:21

apseudonym: Feb 25, 2011

my bitter bi rival posted:

https://twitter.com/alexstamos/status/1091099413366403072
Ah,

He's not wrong that people ignore Apple's flaws, FB still bad tho

# ¿ Feb 1, 2019 02:54

apseudonym: Feb 25, 2011

Plank Walker posted:

yeah i wouldn't say apple is perfect, but don't create this false equivalency with two companies whose entire revenue streams are based on collecting and monetizing as much personal info as they can glean from you

Never said they were the same? It takes a lot of effort to live up to Facebooks current behavior

# ¿ Feb 1, 2019 04:38

apseudonym: Feb 25, 2011

Optimus_Rhyme posted:

Shirt answer: no

https://twitter.com/alexstamos/status/1091108382000451585?s=19

Haha gently caress that's not true at all

'We MiTM'd to learn details of things like "how many messages are people sending in this app" to decide who to buy that's totally what OS vendors are doing, right guys? guys? guys?'

apseudonym fucked around with this message at 06:16 on Feb 1, 2019

# ¿ Feb 1, 2019 06:14

apseudonym: Feb 25, 2011

Optimus_Rhyme posted:

It just gets worse. He then pivots to trying to say Apple is worse cause they sell their phone in china. Thankfully gets mocked.

I know he's trying to deflect from FB and all, but I hate the China stuff and we shouldn't give them a pass for it. Apple does deserve a ton of flak for China and what they did with encrypted backups, it is probably their worst privacy move and they basically got away with it.

The things US companies do to try and get into a market under the false belief the Chinese government wont just gently caress them is somewhere between embarrassing and enraging, not even Apple is immune to selling their soul to try and enter that market.

apseudonym fucked around with this message at 17:28 on Feb 1, 2019

# ¿ Feb 1, 2019 17:19

apseudonym: Feb 25, 2011

https://bugzilla.mozilla.org/show_bug.cgi?id=1450784

Yay Firefox is on the gently caress MiTMs train too

# ¿ Feb 1, 2019 19:12

apseudonym: Feb 25, 2011

salted hash browns posted:

Unpopular opinion: Apple giving away iCloud encryption keys in PRC is going to cause far more human harm than Facebook or Google will ever do.

Let's not challenge companies to one up that move. Tech companies are desperate for growth numbers.

I want to believe that people are just being willfully ignorant of Apple giving the keys to a Chinese government ran company, there's no greater sin for a privacy promising company than promising privacy and outright stabbing them in the back.

E: migraine posting is bad for grammar

apseudonym fucked around with this message at 04:01 on Feb 2, 2019

# ¿ Feb 2, 2019 03:30

apseudonym: Feb 25, 2011

cinci zoo sniper posted:

but sorry i do forget that companies are people and our friends. everyone please stop being mean to facebook and google, apple bad.

None of them are your friends

# ¿ Feb 2, 2019 07:39

apseudonym: Feb 25, 2011

Carbon dioxide posted:

Pls read up on your biology before you start DNA hacking.

me: Please I know Javascript and ML there's no reason I need to learn biology

Also me: Help its eating my skin how do I iterate

apseudonym fucked around with this message at 21:13 on Feb 3, 2019

# ¿ Feb 3, 2019 21:08

apseudonym: Feb 25, 2011

Security Fuckup Megathread - v17.1 - Validate your DNA inputs

# ¿ Feb 3, 2019 21:19

apseudonym: Feb 25, 2011

I regret this

# ¿ Feb 3, 2019 21:44

apseudonym: Feb 25, 2011

Partycat posted:

I will let someone with more InfoSec clout tell you to stop putting Apple on blast for operating in China following Chinese regulation and law I guess.

The "well its the local law" as argument for justifying actively supporting repressive regimes is disgusting, please don't make it.

sadus posted:

This thread could use a reeducation camp or two
RIP Uyghurs, Tibet, and Emagic GmbH

RIP

# ¿ Feb 6, 2019 01:51

apseudonym: Feb 25, 2011

simble posted:

how loving convenient

There's always bugs going on. The FaceTime thing was never going to be more a flash in the pan in the media anyways.

# ¿ Feb 6, 2019 08:45

apseudonym: Feb 25, 2011

Analytics are a loving privacy dumpster fire

# ¿ Feb 8, 2019 02:30

apseudonym: Feb 25, 2011

Truga posted:

this been posted yet? https://source.android.com/security/bulletin/2019-02-01.html
lmao

C/C++ should not be used for parsing things.

*20 years later*

It hurts please stop

# ¿ Feb 9, 2019 05:32

apseudonym: Feb 25, 2011

Chris Knight posted:

dyin
https://twitter.com/duniel_pls/status/1093566057833529347

you've gotta be making GBS threads me, _why_ do they even have access to the certs for the domains!?

apseudonym fucked around with this message at 06:30 on Feb 10, 2019

# ¿ Feb 10, 2019 06:28

apseudonym: Feb 25, 2011

Good Sphere posted:

i don't know if it warrants a class action lawsuit, but maybe this is the only motivating factor now that will make it change. also security questions - get rid of them

I give them flak for stuff but:

It's loving stupid.

It's a straight up suit that "omg this security improving thing makes my life slightly harder let's sue", that's awful.

Good secure UX is hard, suing because you have to hit a few more buttons is embarrassing and doesn't help.

If they won (which they won't) it would set one hell of a counter productive precedence.

# ¿ Feb 13, 2019 07:44

apseudonym: Feb 25, 2011

flakeloaf posted:

the security improvements to windows vista were necessary and it was just that kind of thinking made people reject them outright

My job is to make ordinary people act like they aren't trying to actively compromise their own security on an hourly basis. It's just not possible to make "a typical user" give a gently caress about security. A toddler in an abandoned amusement park has better survival instincts.

UAC is a case study in how not to do security UX

# ¿ Feb 13, 2019 21:13

Adbot: ADBOT LOVES YOU

# ¿ May 8, 2024 15:38

apseudonym: Feb 25, 2011

mystes posted:

Vista UAC was intentionally designed to suck because its purpose was to get developers to change their software.

That went well

# ¿ Feb 13, 2019 21:21

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Security Fuckup Megathread - v17.1a - motherfuckers act like they forgot about jre

«‹›2 »