|
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 |
|
|
# ? May 26, 2024 05:28 |
|
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 |
|
https://web.archive.org/web/20200409164556/https://medium.com/@s3c/how-i-hacked-worldwide-zoom-users-eafdff94077d
|
# ? Apr 11, 2020 03:10 |
|
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 |
|
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 |
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.
|
|
# ? Apr 11, 2020 22:26 |
|
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 |
|
Sirotan posted:Zoom building their security team by hiring any rando that finds a vuln on Twitter now I guess?? And for an internship, no less.
|
# ? Apr 12, 2020 00:41 |
|
Sirotan posted:Zoom building their security team by hiring any rando that finds a vuln on Twitter now I guess?? If a high school kid is reversing this well already, am internship is a no brainier.
|
# ? Apr 12, 2020 00:52 |
|
That's legit cool for the kid.
|
# ? Apr 12, 2020 02:13 |
|
https://twitter.com/0xfraq/status/1248434287713456130
|
# ? Apr 12, 2020 04:20 |
|
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 |
|
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 |
|
Not prestigious, but imagine the resume at the end of his internship "Literally reworked Zoom's entire security posture"
|
# ? Apr 13, 2020 14:43 |
|
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 |
|
Martytoof posted:Not prestigious, but imagine the resume at the end of his internship Given that Zoom is HIPAA compliant, he can make it WAY fancier than that.
|
# ? Apr 14, 2020 01:18 |
|
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 |
|
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 |
|
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 |
|
The Scientist posted:Anyone recommend privoxy? Does it offer anything that noscript + ublock origin + privacy badger + DuckDuckGo Privacy Essentials wouldn't give me? 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 |
|
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 |
|
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 |
|
RFC2324 posted:Given that Zoom is HIPAA compliant, he can make it WAY fancier than that. *Supposedly HIPAA compliant
|
# ? Apr 14, 2020 14:50 |
|
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 |
|
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 |
|
11 days, longer than i expectedWiggly 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.
|
# ? Apr 14, 2020 18:33 |
|
ding ding ding
|
# ? Apr 15, 2020 14:02 |
|
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 |
Qwan posted:if they do "compressing then encrypting" it is an issue.
|
|
# ? Apr 15, 2020 18:23 |
|
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 |
|
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 |
|
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. --- 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 |
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. 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 |
|
D. Ebdrup posted:Does it even go into what crypto primitives are being used for the systems?
|
# ? Apr 15, 2020 22:11 |
|
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. 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 |
|
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. 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. 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 |
|
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 |
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.
|
|
# ? Apr 16, 2020 20:32 |
|
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.
|
# ? Apr 16, 2020 21:22 |
|
|
# ? May 26, 2024 05:28 |
|
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 |