Intel went open source today.
20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
191–200 of 476 posts
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#192> If you find password protected zips in the release the password is probably either "Intel123" or "intel123". This was not set by me or my source, this is how it was aquired from Intel. Can't say I'm surprised, people are lazy. Another large tech company I used to work for commonly used an only-slightly more complex password. But it was never changed, so people who had left the team still could have access to things…
I was an admin for a medium sized company and handled their websites. Almost all of them (about a dozen or so) were hosted on Go Daddy. Plus they had about two dozen reserved domains they were sitting on like www.yourcompanysucks.com and others. I left the company 5 years ago. Just checked the login to see if it still worked. Yeap. Any disgruntled employee could change the password, lock them out of all of their site…
I wonder if a malware should just grep for "pw:" or "password:" and then try the string it finds against anything encrypted. Or forward it to the control center.
Also the contents of files like password[s].txt
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#193Earlier quoted context omitted.
I've heard it put this way: If you force users to trade convenience for security, they will find a way to obtain convenience at the expense of security.
If you make it harder for people to do the right thing than the wrong thing, they will choose the wrong thing. This has been brought up a million times in the context of DRM, but it is true in the general case as well.
I could be mistaken on this, but wasn't this basically the sales pitch for Spotify? Basically saying "you'll never get rid of piracy, but you can compete with it".
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#194Earlier quoted context omitted.
That doesn't sound very safe.
What sounds unsafe about having a locally bound port inside a container that only binds with an env variable getting set?
For example that someone finds out about that backdoor and activate it to spy on users. Forwarding a port in Docker is not magic…
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#195Earlier quoted context omitted.
It was disabled by default, and could only be enabled using environment variables. Even when enabled, the whole thing ran in Docker and the socket was bound to loopback, so you could only connect to it from within the container. When the intention is a debugging server, making it exposed to the world is a mistake and a security vulnerability. At that point it is effectively a backdoor, but the difference between a hi…
That doesn't sound very safe.
If you're already running another process in the container, you could do whatever you want anyway.
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#196Earlier quoted context omitted.
What sounds unsafe about having a locally bound port inside a container that only binds with an env variable getting set?
For example that someone finds out about that backdoor and activate it to spy on users. Forwarding a port in Docker is not magic…
Sure, it's simple. But you would have to be able to modify the container settings anyway. For all practical uses, and certainly in my case, you could just make it run a different image at that point. Or copy another executable into the container and run it. You're already privileged. Requiring you to be privileged to access the debug server means it's secure.
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#197This kid has been posting these for fame (it's the same guy that posted the Daimler leak). I guess it's all fun and games until he finds himself in prison
That is indeed often the case with young narcissists (I don't know if it applies to this person, don't know him/her).
That said, I remember the shocking arrogance and total disregard (for anything but their own ego) of a few young privileged "hackers", who were involved in DDOS services for hire, and also for some very nasty IoT bot net (if I recall correctly).
Krebs wrote about them quite a bit. I think they even got caught because of that, but not sure. They did loads of real damage, that much is certain. But instead of going to jail, they got community service. Apparently with intervention of the US government, for which they now work. Go figure.
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#198Is releasing this legal? It seems like this person isn't really disguising their identity or concerned about breaking the law. In their profile they even seem to brag about leaking company's code.
Of course it's not legal. This is exfiltrated intellectual property being shared without license.
I don't believe this is accurate or in any way obvious even if this is the stance the courts would ultimately take. These files were downloaded from a publicly available CDN server discovered while browsing the internet. No authorization mechanisms were bypassed, no computer systems were hacked. These files are the result of a GET request to an Akamai server that happened to be hosting the files. Despite how this will be spun in pop culture, Intel did not secure access to these files. I'm not sure how you would prosecute someone for re-sharing a file they were given, under no legal contract, when they asked for it.
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#199Binaries unique to SpaceX, maybe related to a server or contract with SpaceX?
Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions
#200Earlier quoted context omitted.
Makes perfect sense. Defense in depth, if you can grep the source code and not find any references to md5, then you have quickly verified that the code probably doesn't use md5. This you can easily verify again later, you can even make a test for it :) Even if in practice this had no impact, removing md5 usage, will make it harder to accidentally introduce it in the future.
The issue is not md5. The issue one wants to detect is weak hash functions used in cases where they're not appropriate. The fact that crc32 passed means that any obscure hash function would have passed too, even if it had been used in a context were it isn't appropriate. All it means that the audit is superficial and doesn't catch the error category, just famous examples within that category. That kind of superficial…
Both perspectives are somewhat correct, I feel; the requirement to remove any usage of md5 is beneficial, but the fact that crc32 passed means the audit shows the motivation was misplaced.
The resulting situation might of course not be a net benefit though :/