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

A Hacker Has Wiped a Spyware Company’s Servers

motherboard.vice.com

Post reply on HN
Print view View original

81–90 of 120 posts

Re: A Hacker Has Wiped a Spyware Company’s Servers

#81

Post by megy »

twohlix_ wrote: post #31
stryk wrote: post #3

> " Friday morning, after the hacker told us he had deleted much of Retina-X’s data, the company again said it had not been hacked. " I have to admit that, despite all the seriousness of the actual SPYware this obviously terrible company sells, that one sentence brightened up my normal depressing morning experience of reading the weekday morning news on the Internet. That's just funny.

I think this is a great example of the saying "There are two types of companies: those who have been hacked, and those who know they've been hacked"

And those who will lie about it no matter what happens.

Re: A Hacker Has Wiped a Spyware Company’s Servers

#82

Post by megy »

jim_dow_jones wrote: post #23
larrik wrote: post #12

Earlier quoted context omitted.

They also store extensive sensitive data and media about/from/with children with piss poor security. Is that not unambiguously bad?

Their security was bad, no doubt. I don't see how that justifies deleting their data, though.

Ok. Then what does that justify in your mind?

Re: A Hacker Has Wiped a Spyware Company’s Servers

#83

Post by jessaustin »

jim_dow_jones wrote: post #23
larrik wrote: post #12

Earlier quoted context omitted.

They also store extensive sensitive data and media about/from/with children with piss poor security. Is that not unambiguously bad?

Their security was bad, no doubt. I don't see how that justifies deleting their data, though.

As TFA describes it, the first deletion last year by the heroic hacker actually interrupted another hacker's access to the data. Why hadn't that other hacker deleted it? Maybe he enjoyed having access to private pictures and communications of children, teens, and adults... Does that sound like a good situation?

Re: A Hacker Has Wiped a Spyware Company’s Servers

#84

Post by shkkmo »

cat199 wrote: post #56
bshacklett wrote: post #45

Earlier quoted context omitted.

It should be mentioned that none of that should ever make its way into a Git repo in the first place. If a secret is committed to Git, it's compromised, period. Suck it up and generate a new secret.

only if your git is published.. I assume this is what you mean - that said: separate integration repo containing encrypted keys + separate, manual managment/configuration of the decryption process is fine for most cases. but yes, bare and in mainline and published, I will agree this is terrible. see also: http://docs.ansible.com/ansible/2.4/vault.html

No, you should never commit your secrets, not even to a private github repo, and not even to a privately hosted git server. Doing so increases your attack surface, sometimes in surprising ways.

Now, if your secrets are encrypted before being committed (using something like ansible vault) and the encryption key is not stored in the repo, that may be ok. However, you still need to be aware that any time you rotate that key, you also should to rotate every secret hidden behind that key.

Re: A Hacker Has Wiped a Spyware Company’s Servers

#85

Post by spookthesunset »

HarryHirsch wrote: post #34
greglindahl wrote: post #18

Earlier quoted context omitted.

A better question is how can we give the owner a say without the typical owner getting pwned roughly 100% of the time? Which is what's happening on Android at the moment.

Someone invoking "personal responsibility" usually means that they try to drop their responsibilities on someone else, but for car maintenance it actually works. People know they should change tires when they are getting bald and leave brake maintenance to their mechanic unless they really know what they are doing. Anyone who gives a game access to their contacts really had it coming to them. (Disclaimer: don't own a…

Just waving the whole issue away by saying "make it the user's problem" isn't very helpful. It completely ignores the very real problem that most people don't know what is good for them and worse, even the people who do know what is best have a million better things to do with their time than personally scrutinize each and every app they install. Perhaps, the actual solution is to delegate that responsibility to somebody who does have the time, knowledge and incentive to make sure you are secure.

I own an iPhone instead of an Android precisely because I don't want to be burdened with the task of determining if what I'm installing is or isn't going to backdoor its way into my phone. I trust that Apple will in most cases do the right thing. Maybe they won't every time, but the risk of that is less than the cost of time & energy required to play "deep dive into every fucking app I install on my phone".

Re: A Hacker Has Wiped a Spyware Company’s Servers

#86

Post by andymal »

nitrogen wrote: post #63
nodesocket wrote: post #4

How is this even possible that a 3rd party application can intercept all text messages, call history, and photos and still get published to the Android Play Store? Ins't Google supposed to be reviewing the apps?

As a regular Android user, I'll say that Android's permission model is simply awful. There's no way (in stock) to return blank data, so apps will simply shut down or silently malfunction if you refuse permissions. The grouping of permissions lumps "can portscan your network" and "run hidden in the background when your phone boots" under "Other", which you can't disable. J2ME had a more refined security model back in…

APK devs should be checking to see if they have been granted permissions instead of crashing. https://developer.android.com/reference/android/support/v4/c..., java.lang.String)

If an application won't work after I've turned off all the permissions that it shouldn't need, it simply gets uninstalled.

Re: A Hacker Has Wiped a Spyware Company’s Servers

#87

Post by tachion »

figgis wrote: post #48
sowbug wrote: post #40

Earlier quoted context omitted.

It's all the more pathetic that they responded to the first hack by "obfuscating" the client-side secret, as if that could even theoretically stop any attacker with a budget of more than about an hour. Future service designers: if your client is talking directly to AWS, then your attacker will, too. Take the week to write a CRUD frontend server that enforces the policy you want.

Do you have a recommended security checklist for something like this? I remember seeing an old github repo with a bunch of good information but I cannot seem to find it and my search results are... unhelpful at best.

You wont like it, but... How would you feel being asked for a checklist for 'good software development' or something similar by a cooking chef? Hire skilled and dedicated DevOps/SRE/SysAdmin/hype-of-the-week person. ;)

Re: A Hacker Has Wiped a Spyware Company’s Servers

#89

Post by willstrafach »

smoyer wrote: post #74
andrewflnr wrote: post #5

They stored the master key to their entire data store in a publicly distributed app? > ...we have been taking steps to enhance our data security measures. Sharing details of security measures could only serve to potentially compromise those efforts. Maybe they used ROT13 on the API key twice this time!

I can publish my public key all day long for encryption into a back-end ... and later I can only read it with my private key. So they may not have used ROT13 but it certainly looks like they used something symmetrical.

This is not actually about an encryption key. Better to think about it as a password to access the server.

Re: A Hacker Has Wiped a Spyware Company’s Servers

#90

Post by mschuster91 »

kuschku wrote: post #37
andrewflnr wrote: post #5

They stored the master key to their entire data store in a publicly distributed app? > ...we have been taking steps to enhance our data security measures. Sharing details of security measures could only serve to potentially compromise those efforts. Maybe they used ROT13 on the API key twice this time!

This is a common issue, and many apps do this mistake. Another common mistake is having /.git/ available on the domain itself, often with PHP sites or backend-less SPAs this is common, giving full access to the source, including those API keys. Even major sites do this – The Hill until recently had their git repo, including API tokens and access keys for everything, publicly available.

> Another common mistake is having /.git/ available on the domain itself, often with PHP sites or backend-less SPAs this is common

Yeah and same for .svn and .cvs (which may happen to include your VCS credentials in that directory, too).

Post reply on HN