WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents • Hacker News Board

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#241

Post by libertymcateer » Wed, Mar 08, 2017, 1:27 PM UTC

awinter-py wrote: post #69

libertymcateer wrote: post #3

Edit: deleted, for very valid criticism. Next time I won't post in a rush during work hours.

careful with claims that android is 'owned'. You want to distinguish between: - remote takeover (like stagefright vuln) - ability to take control of the device from within an app sandbox - ability to unlock a device in your physical possession (FBI was able to do this on prev V of ios)

I spent a fair amount of time reading up on the wikileaks last night. While the released info does appear to not be beyond KitKat, the array of listed hacks is staggering. Have you had a chance to look? I understand that there are very fine levels of distinction between these types of hacks, but it seems to me that there were multiple root compromises.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#242

Post by sleepychu » Wed, Mar 08, 2017, 3:35 PM UTC

libertymcateer wrote: post #240

md_ wrote: post #237

Earlier quoted context omitted.

Sorry. I went to bed. I'll frame the basic argument for Chrome and then show how it expands to other systems. Chrome: ======= Someone who can access chrome://settings/password is presumed to have physical access to your powered-on, unlocked machine. E.g. someone who sits at your keyboard when you get up for coffee. And that person can just as easily install a Chrome extension that sniffs your passwords or steal your…

So, tell me what I am misunderstanding here: * On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database https://www.howtogeek.com/70146/how-secure-are-your-saved-ch... , which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has…

If the malicious script can execute arbitrary code as you then you're owned, essentially you always allow unsupervised use of your computer which as discussed is not part of the threat model.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#243

Post by crowbahr » Wed, Mar 08, 2017, 8:03 PM UTC

md_ wrote: post #236

crowbahr wrote: post #225

Earlier quoted context omitted.

Totally agree with you. I like my Nexus 5x a lot. I figure that usually it's the highest levels of government who are actually willing to pay a sum like that though. I doubt the local PD is willing to dedicate 1mil to cracking a phone if you get arrested for possession of a controlled substance or something. And it's kinda an unspoken goal of mine to, ya know, not end up on a CIA watch list. Now I know some of the co…

> And it's kinda an unspoken goal of mine to, ya know, not end up on a CIA watch list. First rule of not being on the watch list is not to admit you don't want to be on the watch list. What, do you have something to hide? Huh?

I invoke my 5th amendment right.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#244

Post by md_ » Thu, Mar 09, 2017, 10:40 AM UTC

sleepychu wrote: post #242

libertymcateer wrote: post #240

Earlier quoted context omitted.

So, tell me what I am misunderstanding here: * On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database https://www.howtogeek.com/70146/how-secure-are-your-saved-ch... , which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has…

If the malicious script can execute arbitrary code as you then you're owned, essentially you always allow unsupervised use of your computer which as discussed is not part of the threat model.

To expand on this (correct answer) very slightly, what you say (libertymcateer) is true but misses the other vector:

A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any other process at the same or lower security level; in OSX, at a quick Google, it looks to me like http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_c... may do the same.

So the attack that this opens up is to basically wait until Safari is running and loads the credentials into its memory--which it has to do to prefill the password field in a page--and then just read that memory from your code running in the same process in a different thread (which shares the address space). And if you don't want to wait, you can simply request the credentials directly from the Keychain API; Keychain doesn't know you're not "Safari" (since you're running in the same process) and will happily give you the credentials!

Now, there's still a small advantage to the DPAPI/Keychain approach, namely that it allows the OS to show approvals to the user ("Unlock the keychain?" dialogs or whatever), ensuring that the malware can only steal credentials while the user is present. There are some circumstances where a credential API is nonetheless useful. Offhand:

1. Cases where there's a test-of-presence ("Do you want to unlock the Keychain?") conducted by the higher-privilege process, and where approval is not routine (so that the user is not going to just click "OK"). Browser password autofill is not such a case, however.

2. Cases where there's a test-of-presence and the user assent is transactional (i.e. they see what they're approving and the approval is only good for that one action--as with Windows UAC).

3. Cases where the credential granted is a signature and not a bearer-token, and we find some advantage in the token itself being bound to the device. (IOW, the down-level process can steal a signature, but it can only use the signature for some limited use, and cannot steal the signing secrets, which never leave the privileged domain.)

So to get this right requires a lot of thought about things like broker processes, transactional approval, etc. I'm far from an expert in this, but hopefully the above makes some sense.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#245

Post by libertymcateer » Thu, Mar 09, 2017, 2:37 PM UTC

md_ wrote: post #130

libertymcateer wrote: post #116

Earlier quoted context omitted.

Yes - worms or browsers that scan local data files without accessing the runtime of the parent application.

So your threat model is "malware which has access to memory containing plaintext but is written by idiots"? 0_o

Dunno if you are still checking this thread, but I had a followup to this question.

It seems to me that certain cryptoviruses function in the following way (e.g. certain variants of ransom_vxlock - I will see if I can find a specific example):

* The virus functions like other cryptoviruses, encrypting local data and holding it for ransom

* However, in addition to holding your local data ransom, it archives certain files that are likely to hold passwords (e.g., the chrome password store), and then emails them to the C&C server

If this is the case, would local encryption of the chrome password store be a protection, or would the decryption of this store be trivial the the virus author? Again, assuming that the virus author is a script kiddy.

So, basically, I am asking that if the characterization of the virus described is accurate, doesn't that mean that the threat model I describe also actually occurs in the wild? I'm not trying to be facetious here - I am trying to get to the bottom of this.

I will try to find links to support the above.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#246

Post by libertymcateer » Thu, Mar 09, 2017, 2:38 PM UTC

sleepychu wrote: post #242

libertymcateer wrote: post #240

Earlier quoted context omitted.

So, tell me what I am misunderstanding here: * On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database https://www.howtogeek.com/70146/how-secure-are-your-saved-ch... , which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has…

If the malicious script can execute arbitrary code as you then you're owned, essentially you always allow unsupervised use of your computer which as discussed is not part of the threat model.

Right, but I believe I have seen the threat model I describe actually functioning in the wild - cryptoviruses that archive files on your local drive that are likely to contain passwords and then mail them to the C&C server.

Would local encryption of these password stores be a (potentially) effective protection against this?

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#247

Post by libertymcateer » Thu, Mar 09, 2017, 2:43 PM UTC

md_ wrote: post #244

sleepychu wrote: post #242

Earlier quoted context omitted.

If the malicious script can execute arbitrary code as you then you're owned, essentially you always allow unsupervised use of your computer which as discussed is not part of the threat model.

To expand on this (correct answer) very slightly, what you say (libertymcateer) is true but misses the other vector: A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any oth…

Right - you are describing a very well written worm up at the top of your comment.

However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on this.

In other words, what I am saying is that you are describing a very nasty theoretical worm - I am, however, describing to you a family of worms that is currently out in the wild and causing a hell of a lot of damage, and, as far as I know, actually does function in the way I describe. Filecryptor viruses can be made / purchased by any script kiddy jerk these days, and it seems to me that they do not function in this very sophisticated way you describe, but instead may actually be stymied by local encryption of files with passwords in them. (Or, rather, the distribution of your passwords to the virus owner would be stymied.)

I would very much like to know if is accurate or not. I understand that the devil is in the details, but if it is true, then I stand by my point that it seems unwise (borderline indefensible) not to encrypt local password stores - as there is a known valid threat. If it is not true, then I stand corrected - which happens all the time.

Either way, I am deeply interested to know.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#248

Post by libertymcateer » Thu, Mar 09, 2017, 2:58 PM UTC

vetinari wrote: post #224

libertymcateer wrote: post #82

Earlier quoted context omitted.

I am not talking about ChromeOS - I am talking about the Chrome browser. Localstorage, last I checked, which was recently, is plaintext. > ChromeOS and Android both implement FDE Which is irrelevant if the runtime is compromised, which appears to be the case.

And it does not matter - it is in Chrome's homedir, no other app can access it. Wrt. physical store, it is on FDE anyway.

Good sn.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#249

Post by md_ » Thu, Mar 09, 2017, 5:02 PM UTC

libertymcateer wrote: post #247

md_ wrote: post #244

Earlier quoted context omitted.

To expand on this (correct answer) very slightly, what you say (libertymcateer) is true but misses the other vector: A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any oth…

Right - you are describing a very well written worm up at the top of your comment. However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on thi…

I don't have a huge amount of exposure to current malware trends, to be honest--it's not the area I work in at the moment. So tl;dr I can only guess.

You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"--they're refusing to implement an ambiguously useful security feature because its bypass would not represent a bug.

Whether such a feature is nonetheless valuable for the user is unanswered by that discussion, however; as you say, it may have value in some circumstances.

However, remember that by volume most exploitation is (as best as I can tell) economic--people who do it for business. And people doing it for business can buy whatever malware is on the market. If stealing in-memory secrets is reliably accomplished (which it is), malware vendors have a strong incentive to implement this and sell it as well.

So I think you have the right idea, but answering the question is nontrivial. If Chrome implemented file encryption (or, more likely, used the platform APIs where available), would the engineering cost (and complexity--e.g. different behavior on different platforms) be counterbalanced by the increased cost imposed on malware authors? Or would one or two malware authors quickly adapt and malware prices/effectiveness would remain fairly static?

You get the point.

Re: WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents

#250

Post by libertymcateer » Fri, Mar 10, 2017, 5:54 PM UTC

md_ wrote: post #249

libertymcateer wrote: post #247

Earlier quoted context omitted.

Right - you are describing a very well written worm up at the top of your comment. However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on thi…

I don't have a huge amount of exposure to current malware trends, to be honest--it's not the area I work in at the moment. So tl;dr I can only guess. You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"--they're refusing to imple…

Found it: the worm is called Dynacrypt.

Check it out and let me know what you think.

Edit: from the top google result on Dynacrypt:

>While the ransomware portion of DynA-Crypt, as described in the next section, is a pain, the real problem is the amount of data and information this program steals from a computer. While running, DynA-Crypt will take screenshots of your active desktop, record system sounds from your computer, log commands you type on the keyboard, and steal data from numerous installed programs.

>The programs and data that DynACrypt steals includes:

>Screenshots

>Skype

>Steam

>Chrome

>Thunderbird

>Minecraft

>TeamSpeak

>Firefox

>Recordings of system audio