Old Unwanted Internet Accounts are a Pain

[sysprog]

Which government used a compromised dependency on many servers?

Presumably any and all that used jQuery, either directly or by using something that uses it, e.g. AJAX $-$ probably every national government, and in the US at least, all or almost all state, county, and city governments have had some exposure in this regard.

From
Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web
Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad, William Robertson, Christo Wilson and Engin Kirda Northeastern University {toby, 3abdou, arshad, wkr, cbw, ek}@ccs.neu.edu

Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author’s employer if the paper was prepared within the scope of employment. NDSS ’17, 26 February - 1 March 2017, San Diego, CA, USA Copyright 2017 Internet Society, ISBN 1-1891562-46-0 https://doi.org/10.14722/ndss.2017.23414​

[/size]
:​

Yes, it is the very nature of software dependencies that application programmers, er, depend on them.

That seems facetious to me. The term 'software dependencies', as you undoubtedly well know, refers to the dependencies of higher-level or same-level software on same-level or lower-level software performing requested functions $-$ the term is only extensionally referential to anything that programmers depend on $-$ sometimes programmers are prevailed upon to deliver functionalities on a scale and schedule that necessitates incurring sotware dependencies that the programmer is not well-positioned to adequately vet.

Each dependency ecosystem includes various mitigations against such vulnerabilities and anyone developing or deploying applications which deal with sensitive data should be aware of these mitigations and their limitations.

Clearly just being aware isn't enough $-$ when the authority, the ability, and the accountability are not co-located, a scenario such that a boss mandates something that the marketers have already promised, the programmer adjures regarding the risks, then at the insistence of the boss, implements it hastily, and when something goes wrong, everyone who is potentially on the hook looks around for someone to blame $-$ it's easy enough to blame e.g. jQuery, AJAX, modernizr, node.js, JSON, etc. $-$ everyone is using those libraries, the argument goes, so no individual may legitimately be regarded as the culprit when one of the libraries introduces a vulnerability.

 

[pbuk]

None of the attackers listed in #30 are javascript based - that is the wrong section of Mitre, you should be looking at https://attack.mitre.org/techniques/T1059/007/.

I have looked at some of the references on the T1059.007 page and all those I have looked at the attack vector is either XSS (cross-site scripting) or server compromise (for a more extensive list of javascript vulnerabilities you can search Mitre's CVE database). None I have looked at is dependency compromise: as I mentioned above the only javascript dependency compromise exploit I have seen reported is the event-stream/copay vulnerability listed on Mitre here and described in reasonable detail comprehensible to non-experts here. The product that was compromised was the mobile phone app Copay, not a web site, and the exploit was not a keylogger.

 

[pbuk]

Presumably any and all that used jQuery, either directly or by using something that uses it

Now you are talking about something else, jQuery has never been hijacked, and no version of jQuery has a vulnerability that can be exploited directly so any site using it is exposed.

 

[sysprog]

None of the attackers listed in #30 are javascript based - that is the wrong section of Mitre, you should be looking at https://attack.mitre.org/techniques/T1059/007/.

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.

I have looked at some of the references on the T1059.007 page and all those I have looked at the attack vector is either XSS (cross-site scripting) or server compromise (for a more extensive list of javascript vulnerabilities you can search Mitre's CVE database).

I agree with you there $-$ there have been numerous"XSS (cross-site scripting)'' attacks wherein the scripting language was JavaScript, especially when jQuery (subsequent to Release 1.0.3 $-$ October, 2006, and prior to Release 3.5.1 $-$ May 4, 2020) was in use.

None I have looked at is dependency compromise: as I mentioned above the only javascript dependency compromise exploit I have seen reported is the event-stream/copay vulnerability listed on Mitre here and described in reasonable detail comprehensible to non-experts here.

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

Cross-site Scripting (XSS)
Affecting jquery package, versions >=1.0.3 <3.5.0
Overview
jquery is a package that makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) Passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.​

The product that was compromised was the mobile phone app Copay, not a web site, and the exploit was not a keylogger.

Some jQuery vulnerabilities have been XSS-based, and have not been specifically keyloggers, although the 'untrusted code' introduced by XSS attacks could include keyloggers within a browser page $-$ from https://nvd.nist.gov/vuln/detail/CVE-2020-11023:

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.​

$-$ which didn't come out until May of last year $-$ the problem has existed since no later than October of 2006 $-$ so it was out there for over 2 decades and people just kept chuntering along all the while $\dots$

 

[sysprog]

Now you are talking about something else, jQuery has never been hijacked, and no version of jQuery has a vulnerability that can be exploited directly so any site using it is exposed.

You asked "Which government used a compromised dependency on many servers?" $-$ although something that is 'hijacked' is 'compromised', not everything that is 'compromised' is 'hijacked' $-$ I responded to the question that you asked; not "about something else".

no version of jQuery has a vulnerability that can be exploited directly so any site using it is exposed

Even if that's true, it's not the same thing as being a 'compromised dependency' $-$ a site using jQuery 2.0, which is provably a compromised dependency, doesn't necessarily thereby incur an exposure; however, a programmer who uses a compromised dependency, without knowing precisely how to avoid the associated vulnerability, and how to ensure that others who might modify the code are adequately unlikely to fail to also avoid it, and acting accordingly, may be taking excessive risk.

 

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