Old Unwanted Internet Accounts are a Pain

[pbuk]

You referred to "evidence for the second part of that sentence", which was "keyloggers that log every key you enter are more and more common" − it was not regarding the first part of @harborsparrow 's sentence, which made reference to JavaScript libraries as a source of keyloggers, that I was responding; it was regarding only the second part.

There seems to be a misunderstanding and I am sorry for my part in this. The context of @harborsparrow 's sentence, was javascript running in browsers when users visit web pages, and all of my posts in this thread have assumed the same context.

I think that this qualifies as a "dependency compromise" − from https://snyk.io/vuln/SNYK-JS-JQUERY-565129:

No, a dependency compromise is specifically the injection of malicious code into the dependency chain, not simply a vulnerabilty of another kind (in this case an XSS vulnerability) in a dependency. See https://attack.mitre.org/techniques/T1195/001/

 

[pbuk]

... jQuery 2.0, which is provably a compromised dependency

In general usage the word 'compromised' can be synonymous with 'flawed' however in computer security 'compromised' means 'made vulnerable by unauthorized access' and so this statement is not true in the conxtext of computer security.

 

[BillTre]

Do keyloggers only pick-up data coming from the keyboard?
Would they pick up automated entries or voice recognized words turned into text?

 

[pbuk]

Do keyloggers only pick-up data coming from the keyboard?
Would they pick up automated entries or voice recognized words turned into text?

Are we still talking about web sites? If someone can inject has injected JavaScript into a site, or use has used typosquatting and/or phishing to create a malicious site which wraps or mimics a target site then it is basically 'game over' for the security of any data that is entered by any method or provided in any form on that site by anyone using it.

It would be good if we could get away from discussing keyloggers on web sites, they are not really a problem.

 

[sysprog]

... jQuery 2.0, which is provably a compromised dependency

In general usage the word 'compromised' can be synonymous with 'flawed' however in computer security 'compromised' means 'made vulnerable by unauthorized access' and so this statement is not true in the conxtext of computer security.

That looks to me like a false dichotomy $-$ jQuery 2.0 is 'compromised', in that it is known that it can be used for purpose of facilition of XSS attacks. I didn't use 'compromised' to mean 'flawed'; I used it to mean 'demonstrated to be untrustworthy'. Your definition, while it appears to me to be not incorrect, is not the only meaning that the term has, including when it is used within a context of data security.

For example, from https://auth0.com/blog/sha-1-collision-attack/:

SHA-1 Has Been Compromised In Practice​

$\cdots$​

Additionally, since the published attack vector has only been proven with PDF files, the team created a website, shattered.io, which allows you to test your PDF files and see if they could have been compromised.​

​

From http://www.redbooks.ibm.com/redbooks/pdfs/sg248100.pdf:

Exploitation might also be because of the usage of a function within a system in an unintended way that compromises the system or underlying data.​

And, from https://www.tomshardware.com/news/researchers-reveal-new-sha-1-attack:

New 'Shambles' Attack Against SHA-1 Shows It’s Finally Time to Ditch It​

​

A new collision attack against the SHA-1 hash function shows that SHA-1 attacks are getting significantly cheaper with each passing year and that it should no longer be used for software security. The new attack puts PGP and other software that uses SHA-1 in their authentication schemes at risk of being compromised.​

Apparently, including in a context of data security, 'compromised' can mean something like 'demonstrated to be untrustworthy'.

If someone can inject JavaScript into a site, or use typosquatting and/or phishing to create a malicious site which wraps or mimics a target site then it is basically 'game over' for the security of any data that is entered by any method or provided in any form on that site by anyone using it.

I think that this is an oversimplified, overly absolutist, and possibly rather defeatist position $-$ the fact that some exploits succeed should not deter us from persisting in our data security mission.

It would be good if we could get away from discussing keyloggers on web sites, they are not really a problem.

Sometimes keyloggers are a critical part of a comprehensive attack strategy.

 

[BillTre]

Thanks for answering my simple question @pbuk, it was most helpful.

 

[pbuk]

That looks to me like a false dichotomy

...

Apparently, including in a context of data security, 'compromised' can mean something like 'demonstrated to be untrustworthy'.

No, the fallacy is yours. 'Compromised' (= C) is a subset of 'demonstrated to be untrustworthy' (= D). The statements you quote are of the form 'x∈C' and so we can infer in each case x∈D however this does not mean that C = D.

I think that this is an oversimplified, overly absolutist, and possibly rather defeatist position

The post to which you referred was not as clear as it could have been: I have corrected it.

The fact that some exploits succeed should not deter us from persisting in our data security mission.

Absolutely!

Sometimes keyloggers are a critical part of a comprehensive attack strategy.

Maybe, but often they are not. In order to improve security you need to focus on the attack vector, not the payload.

 

[sysprog]

No, the fallacy is yours. 'Compromised' (= C) is a subset of 'demonstrated to be untrustworthy' (= D). The statements you quote are of the form 'x∈C' and so we can infer in each case x∈D however this does not mean that C = D.

I said that 'demonstrated to be untrustworthy' was one of the meanings of 'compromised' $-$ that would make C a superset of D; not a subset.

You contended that although outside of a data security context,
'compromised' could mean 'flawed', within such a context, it means 'made vulnerable by unauthorized access', and if you meant by that contention to hold that to be the only meaing of 'compromised' in such a context, then that is in my view a false dichotomy.

I think that that, for example, 'demonstrated to be untrustworthy is another legitimate meaning for 'compromised', including within a data security context.

 

[berkeman]

Thread closed temporarily for Moderation...

 

[berkeman]

After a Mentor discussion, the thread will remain closed. Thanks everybody for an interesting thread.