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

381–390 of 476 posts

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

#381

Post by dcow »

zeroimpl wrote: post #279
dcow wrote: post #275

Earlier quoted context omitted.

Again, I don't believe it's accurate or honest to call this coercion. These files were obtained from a content delivery network by visiting a url in a browser. Nothing deceptive, cunning, crafty, or coercive about it. Let me ask you, what files am I allowed to access on a public network? Must I ask owners permission before visiting their websites? Must I be able to find it with a search engine? What constitutes a fil…

Were the files listed when going to http://server.com ? No, the user had to: 1. Find the server via nmap 2. Guess at some URLs until the server finally responded with some hidden data. While neither of those would require being an expert in the field, this is well beyond the realm of browsing public websites.

This is incorrect. Actually, yes, the files were in fact browseable and Akamai servers typically front with DNS names that presumably resolve to their any-cast addresses where they use SNI to select content bucket, so there would have been a "friendly" name involved. Going to https://server.com/folder displayed a list of folders and files all hyper-linked and connected as is common on the internet. The fact that the server was initially discovered by way of a crawler, a scan, is irrelevant (this is actually how search engines discover content, btw). The fact that a browser could browse these files suggests that it is not "well beyond the realm of browsing public websites".

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

#382

Post by dgellow »

Traster wrote: post #75

This is more embarrassing than harmful. Having worked at companies like intel, it's not really that damaging leaking some of this IP - the worst that happens is some open source project gets slightly better or you have a few more bugs (not that Intel are lacking in that area). The second we see internal marketing, pricing & road map slides- that's when you know they're in real trouble.

> the worst that happens is some open source project gets slightly better

If anyone is reading this is working on open source projects that would benefits from what has been leaked: stay far away from such a leak. The last thing you want is your open source project to be accused of copyright or patent infringement.

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

#383

Post by MaxBarraclough »

danudey wrote: post #228
tombert wrote: post #193

Earlier quoted context omitted.

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".

This was the sales pitch for iTunes and the iTunes store: "We approached it as 'Hey, we all love music.' Talk to the senior guys in the record companies and they all love music, too. … We love music, and there's a problem. And it's not just their problem. Stealing things is everybody's problem. We own a lot of intellectual property, and we don't like when people steal it. So people are stealing stuff and we're optimi…

Interesting that it depends so much on region.

Here in the UK, Sky offer a cheap 'over-the-top' streaming alternative to their satellite offerings, [0] so you could watch Game of Thrones for £8/month, provided you didn't mind the inferior video quality.

[0] https://en.wikipedia.org/wiki/Now_TV_(Sky)

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

#384

Post by jyriand »

ccurrens wrote: post #2

> 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…

Some people/companies think that if you are behind VPN you can use simple and obvious passwords.

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

#385

Post by ImaCake »

hnick wrote: post #238
ImaCake wrote: post #117

Earlier quoted context omitted.

This can't be real... are you serious? It sounds like one of those silly buisness parabels!

The older I get, the less I care if individual stories like this are true. The fact that they could be is concerning enough :) And they are educational nonetheless.

A good perspective! People find fiction novels to be enriching and filled with learning despite the fact they are just entertaining lies.

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

#386

Post by asddubs »

dyingkneepad wrote: post #206
therein wrote: post #186

Earlier quoted context omitted.

// We use MD5 to check if config files are changed. This is not used anywhere else. typedef DigestMD5 ConfigFileHasher;

Until someone repurposes that thing to do something that is security-sensitive and forgets to remove the comment, misleading the next auditors. I always assume that people from the future who are going to touch my code are really dumb people, so I try to have as few traps as possible for them.

i know for a fact the person who's gonna touch my code in the future is really dumb, because it's me

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

#387

Post by loktarogar »

reaperducer wrote: post #325
loktarogar wrote: post #7

Earlier quoted context omitted.

at my first job they used a similar password as their go-to "temporary" password for users etc. I found later when I got to work with the users that they rarely changed this password even when "forced" to, and in many cases had it up on post-its next to their monitor.

and in many cases had it up on post-its next to their monitor. These days a post it is probably the best way to secure your password. 99.9999999% of password hacks come over the wire now, from people in other cities, states, or nations. If someone is in your building, in front of the computer, even without the post-it, you're probably toast.

A post-it is not a good way to secure your office's generic temporary password.

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

#388

Post by lmilcin »

schmichael wrote: post #4
ccurrens wrote: post #2

> 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…

Password protection may have been used to bypass antivirus and other filters. While you should treat dumps like this with a lot of suspicion, treat password protected zips with a heaping dose of care as they may have been used to evade automated defenses.

I have left Intel couple of years ago, that's exactly what passwords were used for. It was pretty annoying to try to send files and putting them in encrypted archive wast the most convenient method.

It was not just for binaries but for scripts, html, etc.

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

#389

Post by Nursie »

MaxBarraclough wrote: post #383
danudey wrote: post #228

Earlier quoted context omitted.

This was the sales pitch for iTunes and the iTunes store: "We approached it as 'Hey, we all love music.' Talk to the senior guys in the record companies and they all love music, too. … We love music, and there's a problem. And it's not just their problem. Stealing things is everybody's problem. We own a lot of intellectual property, and we don't like when people steal it. So people are stealing stuff and we're optimi…

Interesting that it depends so much on region. Here in the UK, Sky offer a cheap 'over-the-top' streaming alternative to their satellite offerings, [0] so you could watch Game of Thrones for £8/month, provided you didn't mind the inferior video quality. [0] https://en.wikipedia.org/wiki/Now_TV_(Sky)

They have a "topup" now which allows you to get real, full-fat 1080p.

Woohoo!

I did actually add that to my subscription, and during lockdown have used it to re-watch Game of Thrones :)

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

#390

Post by rommel917 »

Polylactic_acid wrote: post #225
skissane wrote: post #207

Earlier quoted context omitted.

Sometimes customers demand security audits as part of sales contracts. If it is a high enough value deal, the company may decide it is in their business best interest to say yes. In that scenario, not listening to the security auditor is not a viable option. You need to keep them onside to keep the customer onside. Similarly, sometimes in order to sell products to government agencies you need to get security audits d…

I have a feeling that these auditor people just make up bullshit when they can't find something real. The last few we have got have come up with total non issues marked as severe because they are easy to "exploit". Meanwhile I have been finding and fixing real security issues regularly. To be fair it would be extremely difficult for an external person to find issues in the limited time they have so the audit comes do…

Some years ago I worked in $BIGBANK and auditor from $GOVERMENT told as to change street name property from textfield to dropdown (for all countries) to help them with fraud detection, and remove all diacritic characters from client names their new software don't like them.

I told my manager that they are idiots and I won't listen them, he was like 'OK, as I expected' never done anything about it, next auditors didn't mentioned it.

Post reply on HN