Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

twitter.com

Post reply on HN
Print view View original

351–360 of 476 posts

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#351

Post by weinzierl »

crazypython wrote: post #56
johnklos wrote: post #42

Earlier quoted context omitted.

You can't download from mega.nz unless you have their "downloader" app or an account, or if you have Firefox or Safari. It's useless. The torrent works.

A web app that only works in non-Chromium browsers isn't useless.

I think johnklos meant it only works in Chrome and not in Firefox or Safari. You can download the whole archive as zip with Chrome - no problem. Firefox, on the other hand, doesn't allow you to store that much data locally in the browser, so it doesn't work out of the box. You can download the two top level directories separately though and this works even in Firefox.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#353

Post by wingerlang »

privacyonsec wrote: post #346

Intel leaked sources contain "backdoor" keyword https://twitter.com/deletescape/status/1291419918685147149?s...

I’ve only seen people writing “backdoor!” without actually saying what kind of, for who, to what and so on. Seem pretty disingenuous to me. Could easily be something trivial.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#355

Post by ponker »

skissane wrote: post #135
orisho wrote: post #11

At a previous workplace we had a few places in the code which used the word backdoor. It was not an actual backdoor though, but merely a debugging server that could be enabled and allowed you to inspect internal state during runtime. At some point I removed the word backdoor, fearing it would get to a customer or during an audit someone would misunderstand. :|

Once I got a complaint from a security auditor that some code was using MD5. It wasn’t being used for any security purpose, just to check whether an autogenerated file had been manually edited. We decided it was easier to do what they wanted than argue with them, so we replaced it with CRC32C. That would have been faster than MD5, but nobody cares about saving a few milliseconds off reading a configuration file at st…

When you're trying to keep a company of 100,000 employees secure, you can't have an approach that says "let's figure out where we need to remove MD5 and remove it." You have to set an easy to understand, consistent guideline -- "tear out the MD5" -- so that there won't be any doubt as to whether it's done, some teams won't complain that they shouldn't have to change it because some other team didn't have to change it, etc. And then every time they do a security audit the same thing will come up and cause more pointless discussion.

In isolation it looks like wasted work but in terms of organizational behavior it is actually the easiest way.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#356

Post by skissane »

souprock wrote: post #332
jasonladuke0311 wrote: post #302

Earlier quoted context omitted.

https://certbot.eff.org/

How could that work? For security, an internal site lacks a connection to the internet.

Are you talking about a fully internal site, with not even indirect Internet access? For those kinds of airgapped applications, you should maintain your own CA infrastructure, and update all clients/browsers to trust its certificates.

For the more common scenario of internal sites/services which are not accessible from the public Internet, but not fully isolated from it either:

You don't need the internal site exposed to the Internet. If you use DNS-01 ACME challenge, you just need to be able to inject TXT records into your DNS. Some DNS providers have a REST API which can make this easier.

Another option – to use HTTP-01 ACME challenge, you do need the internal host name to be publicly accessible over HTTP, but that doesn't mean the real internal service has to be. You could simply have your load balancer/DNS set up so external traffic to STAR.internal.example.com:80 gets sent to certservice.example.com which serves up the HTTP-01 challenge for that name. Whereas, internal users going to STAR.internal.mycompany.com talk to the real internal service. (There are various ways to implement this – split horizon DNS, some places have separate external and internal load balancers that can be configured differently, etc)

Yet another option is to use ACME with wildcard certs (which needs DNS-01 challenge). Get a cert via ACME for STAR.internal.medallia.com and then all internal services use that. That is potentially less secure, in that lots of internal services may all end up using the same private key. One approach is that the public wildcard cert is on a load balancer, and then that load balancer talks to internal services – end-to-end TLS can be provided by an internal CA, and you have to put the internal CA cert in the trust store of your various components, but at least you don't have the added hassle of having to put it in your internal user's browser/OS trust stores.

(In above, for STAR read an asterisk – HN wants to interpret asterisks as formatting and I don't know how to escape them.)

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#357

Post by sarakayakomzin »

souprock wrote: post #334
searchableguy wrote: post #312

Earlier quoted context omitted.

I am confused. Isn't that easily automated?

It's not easily automated. Somehow, you have to safely get a certificate across the air gap to the internal network. So I guess an internet-connected system grabs the certificates, then they get burned to DVD-R, then... a robot moves the DVD-R to the internal network? It's not easy. It's all much worse if the networks aren't physically adjacent. One could be behind a bunch of armed guards and interlocking doors.

>you have to safely get a certificate across the air gap to the internal network.

you can't trust a server on the internal network as root certificate trust? sounds like a scary situation.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#358

Post by skissane »

souprock wrote: post #334
searchableguy wrote: post #312

Earlier quoted context omitted.

I am confused. Isn't that easily automated?

It's not easily automated. Somehow, you have to safely get a certificate across the air gap to the internal network. So I guess an internet-connected system grabs the certificates, then they get burned to DVD-R, then... a robot moves the DVD-R to the internal network? It's not easy. It's all much worse if the networks aren't physically adjacent. One could be behind a bunch of armed guards and interlocking doors.

An airgapped network can include its own internal CA, and all the airgapped clients can have that internal CA's certificate injected into their trust stores, and all the services on the airgapped network can automatically request certificates from the internal CA – which can even be done using the same protocol which Let's Encrypt uses, ACME, just running it over a private airgapped network instead of over the public Internet.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#360

Post by fit2rule »

close04 wrote: post #161
fit2rule wrote: post #109

Earlier quoted context omitted.

Was it a backdoor, or a hidden door, or .. a utility panel? The difference, in my opinion, is in the documentation and frequency of use. Is it overt? Does the customer really know its there, and what its for? Perfectly fine to have an access panel that gives you access to the buss .. if the pilot knows you're doing it. But if its some random entrance in the back of an alley, only 2 or 3 users in the universe know wha…

Imagine the reaction if the same thing was coming from China. Nobody would ask the question.

Nationality has nothing to do with it. I also don't trust Americans with such devices.
Post reply on HN