The Infosec Thread: Yes, time to move off Entrust

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off Entrust

«‹›509 »

Double Punctuation: Dec 30, 2009; Ships were made for sinking;
Whiskey made for drinking;
If we were made of cellophane
We'd all get stinking drunk much faster!

I won�t say what it was, but it was hilariously, mind-boggingly incompetent. Like, using ROT-13 twice levels of incompetence.

# ? Apr 11, 2020 02:28

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 03:11

CommieGIR: Aug 22, 2006; The blue glow is a feature, not a bug; Pillbug

Double Punctuation posted:

I won�t say what it was, but it was hilariously, mind-boggingly incompetent. Like, using ROT-13 twice levels of incompetence.

Oh good god.

# ? Apr 11, 2020 02:33

Sir Bobert Fishbone: Jan 16, 2006; Beebort

https://web.archive.org/web/20200409164556/https://medium.com/@s3c/how-i-hacked-worldwide-zoom-users-eafdff94077d

# ? Apr 11, 2020 03:10

SlowBloke: Aug 14, 2017

Sir Bobert Fishbone posted:

https://web.archive.org/web/20200409164556/https://medium.com/@s3c/how-i-hacked-worldwide-zoom-users-eafdff94077d

Without the images, it loses part of the shitpost charm

# ? Apr 11, 2020 08:44

whose tuggin: Nov 6, 2009; by Hand Knit

Anyone recommend privoxy? Does it offer anything that noscript + ublock origin + privacy badger + DuckDuckGo Privacy Essentials wouldn't give me?
(yes I need to get rid of some of these extensions, and yes they break poo poo all the time)

# ? Apr 11, 2020 21:38

BlankSystemDaemon: Mar 13, 2009

If there's anyone who doesn't already know about it, uBlock Origin can do double-duty and act like NoScript - here's the stuff I posted about it elsewhere:

D. Ebdrup posted:

If you enable advanced user functionality in ublock origin, you can enable dynamic filtering which lets you have noscript-like functionality, and if you then set the "Relax blocking mode" to ctrl+alt+b, you can turn it off for individual pages with one or maybe two presses of that key combination.

EDIT: The basic ruleset I'm using might even be better than the default-deny ruleset above:
pre:
* * 3p block
* * 3p-frame block
* * 3p-script block
behind-the-scene * 1p-script noop
behind-the-scene * 3p noop
behind-the-scene * 3p-frame noop
behind-the-scene * 3p-script noop
behind-the-scene * image noop
behind-the-scene * inline-script noop
no-large-media: behind-the-scene false
no-scripting: behind-the-scene false

# ? Apr 11, 2020 22:26

Sirotan: Oct 17, 2006; Sirotan is a seal.

Zoom building their security team by hiring any rando that finds a vuln on Twitter now I guess??

https://twitter.com/BillDemirkapi/status/1248909505234075649

# ? Apr 12, 2020 00:31

Absurd Alhazred: Mar 27, 2010; by Athanatos

Sirotan posted:

Zoom building their security team by hiring any rando that finds a vuln on Twitter now I guess??

https://twitter.com/BillDemirkapi/status/1248909505234075649

And for an internship, no less.

# ? Apr 12, 2020 00:41

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Sirotan posted:

Zoom building their security team by hiring any rando that finds a vuln on Twitter now I guess??

https://twitter.com/BillDemirkapi/status/1248909505234075649

If a high school kid is reversing this well already, am internship is a no brainier.

# ? Apr 12, 2020 00:52

Ynglaur: Oct 9, 2013; The Malta Conference, anyone?

That's legit cool for the kid.

# ? Apr 12, 2020 02:13

whose tuggin: Nov 6, 2009; by Hand Knit

https://twitter.com/0xfraq/status/1248434287713456130

# ? Apr 12, 2020 04:20

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Volmarias posted:

If a high school kid is reversing this well already, am internship is a no brainier.

yeah, this is a solid get

# ? Apr 12, 2020 04:25

Qwan: Jan 3, 2020

Is it though? Sure, Zoom has a lot of name recognition right now, but as a tech shop (that oursources most of their development overseas) theyre not really prestigious. For crying out loud they used loving ECB mode. The intern will proably be the most qualified infosec persoin on the floor by virtue of not being pants on head retarded.

(USER WAS PUT ON PROBATION FOR THIS POST)

# ? Apr 12, 2020 23:23

some kinda jackal: Feb 25, 2003; �
�

Not prestigious, but imagine the resume at the end of his internship

"Literally reworked Zoom's entire security posture"

# ? Apr 13, 2020 14:43

AlternateAccount: Apr 25, 2005; FYGM

Qwan posted:

Is it though? Sure, Zoom has a lot of name recognition right now, but as a tech shop (that oursources most of their development overseas) theyre not really prestigious. For crying out loud they used loving ECB mode. The intern will proably be the most qualified infosec persoin on the floor by virtue of not being pants on head retarded.

Youre gonna get tagged for that word.

# ? Apr 13, 2020 20:13

RFC2324: Jun 7, 2012; http 418

Martytoof posted:

Not prestigious, but imagine the resume at the end of his internship

"Literally reworked Zoom's entire security posture"

Given that Zoom is HIPAA compliant, he can make it WAY fancier than that.

# ? Apr 14, 2020 01:18

KennyTheFish: Jan 13, 2004

RFC2324 posted:

Given that Zoom is HIPAA compliant, he can make it WAY fancier than that.

Did they just say it was, or is there some audit firm that attests to it? because if the second, I have questions.

# ? Apr 14, 2020 02:48

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

KennyTheFish posted:

Did they just say it was, or is there some audit firm that attests to it? because if the second, I have questions.

HIPAA isn't the same as "provably secure", just that they have audit controls and have made a reasonable effort.

# ? Apr 14, 2020 02:55

Proteus Jones: Feb 28, 2013

Volmarias posted:

HIPAA isn't the same as "provably secure", just that they have audit controls and have made a reasonable effort.

Yeah, it's the same with PCI. It's not that you're an invincible fortress, it's that you've made best effort to meet the requirements and have the documentation, processes and log data to back that assertion up.

# ? Apr 14, 2020 06:17

Impotence: Nov 8, 2010; Lipstick Apathy

The Scientist posted:

Anyone recommend privoxy? Does it offer anything that noscript + ublock origin + privacy badger + DuckDuckGo Privacy Essentials wouldn't give me?
(yes I need to get rid of some of these extensions, and yes they break poo poo all the time)

Privoxy is to be used as an additional part of the toolkit - it is not totally useful by itself, especially in this day and age.

You can somewhat-easily block things like "googleadservices.com" through privoxy, but you will have difficulty blocking intentionally evasive poo poo (like malicious fingerprinting scripts that randomize hostnames nonstop, but can be matched by a ublock regex+cname filter)

# ? Apr 14, 2020 07:53

BangersInMyKnickers: Nov 3, 2004; I have a thing for courageous dongles

Qwan posted:

Is it though? Sure, Zoom has a lot of name recognition right now, but as a tech shop (that oursources most of their development overseas) theyre not really prestigious. For crying out loud they used loving ECB mode. The intern will proably be the most qualified infosec persoin on the floor by virtue of not being pants on head retarded.

ECB makes a lot of sense for this kind of application. CBC means chained block cipher i.e. the encryption of the current block is dependent on the one prior. This isn't exactly great for a real-time protocol being used on home networks and dodgy wifi which is a real design consideration. If you drop a packet, CBC would force you to wait for the retransmit before resuming the stream which is not just worthless in Zoom's use case but actively harmful. If I was doing this today I'd probably be looking at DTLS instead, but that brings is own host of problems since DTLS 1.0 support was only added with Win7 and its functionally equivalent to TLS 1.1 which isn't exactly great. MS didn't add DTLS 1.2 support until 2016 Win10, so when supporting older clients you're picking a poison between a less secure DTLS 1.0 stream or TLS 1.2 in AES-ECB mode.

# ? Apr 14, 2020 13:41

Qwan: Jan 3, 2020

But you dont need to use CBC. Isnt CTR the obvious mode for an *ahem* streaming *ahem* application? No need to get the previous package there and the offset from the initial counter is public info anyways and can just be sent along plain, so resistance to packet drops is there. Couldn't you even make the argument CTR is more efficient than ECB because you can do the expensive block cipher operations in advance instead of only after knowing what youre gonna send? (Not that it is a real speedup..)

# ? Apr 14, 2020 14:28

Potato Salad: Oct 23, 2014; nobody cares

RFC2324 posted:

Given that Zoom is HIPAA compliant, he can make it WAY fancier than that.

*Supposedly HIPAA compliant

# ? Apr 14, 2020 14:50

BangersInMyKnickers: Nov 3, 2004; I have a thing for courageous dongles

Qwan posted:

But you dont need to use CBC. Isnt CTR the obvious mode for an *ahem* streaming *ahem* application? No need to get the previous package there and the offset from the initial counter is public info anyways and can just be sent along plain, so resistance to packet drops is there. Couldn't you even make the argument CTR is more efficient than ECB because you can do the expensive block cipher operations in advance instead of only after knowing what youre gonna send? (Not that it is a real speedup..)

ECB allows you do observe the effective bitrate of the audio and video streams without having access to the plaintext itself, which lets you pull off some bandwidth saving trickery when it comes to detecting idle sessions and not propagating unneeded data through a conference call. There was a similar design issue in either SIPS or SRTP (can't remember which) where you couldn't actually break the audio stream but you could use the observable cadence to figure out what words were being said through statistical analysis. It's a legit design consideration for the use case, especially 10 years ago when this stuff was first created and bandwidth was more scarce.

# ? Apr 14, 2020 15:11

Qwan: Jan 3, 2020

I'm not sure what you are trying to get at? It sounds like you are talking about something like this: http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf But that is entirely an issue of "compressing then encrypting" which is independent of the block cipher mode of operation.

# ? Apr 14, 2020 17:34

Wiggly Wayne DDS: Sep 11, 2010

11 days, longer than i expected

Wiggly Wayne DDS posted:

eh i'd put it down to incompetence, a mildly competent job wouldn't raise an eyebrow compared to claiming AES 256, but doing 128 ECB in practice. the regions the servers are physically located is p irrelevant beyond legal jurisdiction/clickbait. end of the day you should always be adapting your communication based on how much you can trust a medium, not the party on the other end.

there's been a lot of leaping at zoom for what are p typical fuckups for companies as everyone's bored this pandemic with a lack of distracting news and it suddenly got popular, but there hasn't been anything especially egregious popping up so far. this'll be the next p typical fuckup that hits the newscycle if anyone bothers digging as everyone who tries to be clever with low latency voip falls in the trap:
https://twitter.com/colmmacc/status/1246160773379796994
for those who aren't familiar if you send voice packets with a variable length and no padding/timing element to them then a person on the line can just figure out the syllables you were speaking and reconstruct the words. encryption on them is irrelevant unless its padded to a fixed size - the metadata of size and time can show enough information to reconstruct

# ? Apr 14, 2020 18:33

BangersInMyKnickers: Nov 3, 2004; I have a thing for courageous dongles

ding ding ding

# ? Apr 15, 2020 14:02

Qwan: Jan 3, 2020

Again, if they do "compressing then encrypting" it is an issue. But it is completely unrelated to the block cipher mode of operation.

# ? Apr 15, 2020 16:25

BlankSystemDaemon: Mar 13, 2009

Qwan posted:

if they do "compressing then encrypting" it is an issue.

Gonna need to see some published and peer-reviewed papers on this, because if it's true then all forms of enterprise SANs, a lot of HTTPS communication, and even most disk encryption for Linux, FreeBSD, and so on is "an issue" too.

# ? Apr 15, 2020 18:23

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

D. Ebdrup posted:

Gonna need to see some published and peer-reviewed papers on this, because if it's true then all forms of enterprise SANs, a lot of HTTPS communication, and even most disk encryption for Linux, FreeBSD, and so on is "an issue" too.

...

# ? Apr 15, 2020 18:41

Qwan: Jan 3, 2020

D. Ebdrup posted:

Gonna need to see some published and peer-reviewed papers on this, because if it's true then all forms of enterprise SANs, a lot of HTTPS communication, and even most disk encryption for Linux, FreeBSD, and so on is "an issue" too.

Ehm, the paper I linked above is a paper by UNC researchers published in the 2011 IEEE Symposium on Security and Privacy. And that you can get in all kinds of hot water by "compressing then encrypting" is kinda well known, e.g. the CRIME and BREACH attacks.

# ? Apr 15, 2020 19:13

wolrah: May 8, 2006; what?

Qwan posted:

Ehm, the paper I linked above is a paper by UNC researchers published in the 2011 IEEE Symposium on Security and Privacy. And that you can get in all kinds of hot water by "compressing then encrypting" is kinda well known, e.g. the CRIME and BREACH attacks.

Saying it's about "compressing then encrypting" is way overbroad, because how else do you propose to compress anything? Lossless compression works on patterns that good encryption will eliminate and lossy compression requires knowledge of the plaintext. Either way it doesn't work to do it after encryption.

---

I'm not really familiar with the details of the CRIME/BREACH stuff but I am intimately familiar with VoIP and related topics. The problem discussed in the UNC paper is not a problem caused by "compressing then encrypting" it's purely choosing the wrong codec for the job. A real-time stream with a variable bit rate inherently leaks information about its content through packet sizes, and encrypting them doesn't change a thing about that.

As noted in the mitigation section of the paper, using a constant bitrate codec without silence suppression eliminates the problem entirely. You're still compressing before encrypting, you're just using the right compression for the job. Padding the data also works but defeats the purpose of using the VBR codec so it doesn't make sense in most cases.

# ? Apr 15, 2020 21:27

BlankSystemDaemon: Mar 13, 2009

Qwan posted:

Ehm, the paper I linked above is a paper by UNC researchers published in the 2011 IEEE Symposium on Security and Privacy. And that you can get in all kinds of hot water by "compressing then encrypting" is kinda well known, e.g. the CRIME and BREACH attacks.

drat, I'm sorry to say I completely loving whiffed on reading your post. Scrolled right past it.

BREACH requires three components, ie, RFC3749 with DEFLATE and querystring or HTTP POST to contain user-data, and part of the secret to be in the HTTP response body if I recall correctly? Which to me makes it sound like a weakness in RFC3749 in particular, and not a fault with the general idea of encrypting data after it's been compressed.
For example, does it apply to TLS1.3 with HTTP Live Streaming or Dynamic Adaptive Streaming over HTTP? Both are compressed video streams, and are used to push a pretty significant chunk of the internets traffic from Youtube and Netflix, including WebRTC and similar stuff used for Zoom, Jitsi, Google Meet/Hangouts, and other similar services.

That paper is a loving rad bit of science - there's something almost cyberpunk about using computational linguistics and speech analysis on phonemes - I'll have to take some time to read it though, since my brain's fried today.
EDIT: The only thing I've gotten from it so far is that it looks to be more about de-anonymizing the person rather than actually decrypting what's being said.
Does it even go into what crypto primitives are being used for the systems?

BlankSystemDaemon fucked around with this message at 21:39 on Apr 15, 2020

# ? Apr 15, 2020 21:32

Wiggly Wayne DDS: Sep 11, 2010

D. Ebdrup posted:

Does it even go into what crypto primitives are being used for the systems?

it is beyond irrelevant and you seem to be going out of the way to not get the point

# ? Apr 15, 2020 22:11

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

wolrah posted:

Saying it's about "compressing then encrypting" is way overbroad, because how else do you propose to compress anything? Lossless compression works on patterns that good encryption will eliminate and lossy compression requires knowledge of the plaintext. Either way it doesn't work to do it after encryption.

---

I'm not really familiar with the details of the CRIME/BREACH stuff but I am intimately familiar with VoIP and related topics. The problem discussed in the UNC paper is not a problem caused by "compressing then encrypting" it's purely choosing the wrong codec for the job. A real-time stream with a variable bit rate inherently leaks information about its content through packet sizes, and encrypting them doesn't change a thing about that.

As noted in the mitigation section of the paper, using a constant bitrate codec without silence suppression eliminates the problem entirely. You're still compressing before encrypting, you're just using the right compression for the job. Padding the data also works but defeats the purpose of using the VBR codec so it doesn't make sense in most cases.

The general problem with compress-then-encrypt is that compression turns your data, even if it was originally of a fixed size that would be totally opaque when encrypted, into something that is of variable size depending on the content - thus leaking information about the content in the size of the ciphertext.

A constant bitrate encoding is not really what people think of when you say "compression" - but it does avoid this particular issue, at the cost of wasting tons of bandwidth when you're not doing anything and making you sound like a robot when it is your turn to start talking.

# ? Apr 16, 2020 02:43

wolrah: May 8, 2006; what?

Jabor posted:

The general problem with compress-then-encrypt is that compression turns your data, even if it was originally of a fixed size that would be totally opaque when encrypted, into something that is of variable size depending on the content - thus leaking information about the content in the size of the ciphertext.

We agree about this part, I guess my problem is with the semantics of saying "compression before encryption" is the problem. That implies that the encryption is a factor, which it isn't, or that changing the order would fix it, which it won't. The use of a variable bitrate codec on a real-time stream does all the leaking of information, encrypting that stream has no inherent impact one way or another. As noted in the paper using a block cipher with large blocks can reduce the resolution of the data the attacker is able to gather, but that comes with a cost of latency so it has practical limitations in the context of a two-way communication platform.

quote:

A constant bitrate encoding is not really what people think of when you say "compression" - but it does avoid this particular issue, at the cost of wasting tons of bandwidth when you're not doing anything and making you sound like a robot when it is your turn to start talking.

I disagree on all counts. No one thinks of CBR MP3s as uncompressed. VBR of course delivers better quality in the same average bitrate or lower bitrate with the same quality, but it's not like it's a huge difference in the grand scheme of things.

PSTN-interconnected VoIP systems are using CBR codecs all the time, G.711 is literally the standard in telecom and the most popular wideband audio "HD voice" codec G.722 is designed to fit right in to the same 64 kbit/sec stream.

If you're legitimately concerned about an attacker analyzing the bitrate of your encrypted voice streams to reverse engineer your conversations, there are very few situations where 64 kbit/sec of "wasted" bandwidth per participant is going to make a meaningful difference.

I have no idea what you're talking about with the making you sound like a robot part. If that happens you have some connectivity issues or some really idiotic codec is in use.

# ? Apr 16, 2020 15:23

droll: Jan 9, 2020; by Azathoth

My boss was saying that our VPN service doesn't work correctly in China when our employees fly there for business trips, even with a 'full tunnel' because the protocols being used are still detectable and the Chinese will block certain types of traffic running over our VPN. Does that make sense? I don't know how to google/what to read to understand this better. I envisaged an encrypted tunnel meant everything in it was just garbage to someone trying to listen.

# ? Apr 16, 2020 18:05

BlankSystemDaemon: Mar 13, 2009

V0LTpwn: Attacking x86 Processor Integrity from Software (PDF) posted:

Fault-injection attacks have been proven in the past tobe a reliable way of bypassing hardware-based security measures, such as cryptographic hashes, privilege and access permission enforcement, and trusted execution environments. However, traditional fault-injection attacks require physical presence, and hence, were often considered out of scope in many real-world adversary settings.
In this paper we show this assumption may no longer be justified on x86. We present V0LTpwn, a novel hardware-oriented but software-controlled attack that affects the integrity of computation in virtually any execution mode on modern x86 processors. To the best of our knowledge, this represents the first attack on the integrity of the x86 platform from software. The key idea behind our attack is to undervolt a physical core to force non-recoverable hardware faults. Under a V0LTpwn attack, CPU instructions will continue to execute with erroneous results and without crashes, al-lowing for exploitation. In contrast to recently presented side-channel attacks that leverage vulnerable speculative execution, V0LTpwn is not limited to information dis-closure, but allows adversaries to affect execution, and hence, effectively breaks the integrity goals of modern x86 platforms. In our detailed evaluation we success-fully launch software-based attacks against Intel SGX enclaves from a privileged process to demonstrate that a V0LTpwn attack can successfully change the results of computations within enclave execution across multiple CPU revisions.

# ? Apr 16, 2020 20:32

evil_bunnY: Apr 2, 2003

droll posted:

My boss was saying that our VPN service doesn't work correctly in China when our employees fly there for business trips, even with a 'full tunnel' because the protocols being used are still detectable and the Chinese will block certain types of traffic running over our VPN. Does that make sense? I don't know how to google/what to read to understand this better. I envisaged an encrypted tunnel meant everything in it was just garbage to someone trying to listen.

If you can't establish the tunnel in the first place, yer hosed.

# ? Apr 16, 2020 21:22

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 03:11

Powered Descent: Jul 13, 2008; We haven't had that spirit here since 1969.

droll posted:

My boss was saying that our VPN service doesn't work correctly in China when our employees fly there for business trips, even with a 'full tunnel' because the protocols being used are still detectable and the Chinese will block certain types of traffic running over our VPN. Does that make sense? I don't know how to google/what to read to understand this better. I envisaged an encrypted tunnel meant everything in it was just garbage to someone trying to listen.

They might, with some effort, be able to determine something about the traffic based on the timing and size of the back-and-forth, even without being able to read the actual data. For example, see the discussion about VOIP calls happening in this very thread: if the audio algorithm changes its bitrate from moment to moment based on when the people are talking, then an eavesdropper can make some surprisingly good guesses about the words that are actually being said.

Similarly, they might be able to suss out, for example, that you're typing something in an interactive session (ssh'ed into a server?), or watching a video stream (Netflix tends to send out data chunks in this pattern, Youtube is more like that pattern), or anything else leaving a distinctive enough trail. (Running multiple things at once over the tunnel would make this sort of analysis more difficult, of course.) They just might, in theory, decide to cut off your tunnel when they see traffic that looks like [whatever-your-boss-meant].

In practice, I expect they don't care nearly enough to do that to a random visiting western businessperson connecting to the company server at home. But if they really wanted to, they could certainly try.

# ? Apr 16, 2020 23:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off Entrust

«‹›509 »