Old Unwanted Internet Accounts are a Pain

  • Thread starter anorlunda
  • Start date
  • #26
harborsparrow
Gold Member
611
154
Most web pages these days have Javascript which executes within the browser (and likely also communicates with the server). A keystroke logger would require that the server be compromised (which happens plenty).

Sometimes the Javascript is written by the webpage creator, but sometimes also it is library "packages" being sucked in.

I assumed you were talking about a third party "package" that has been compromised and then gets used on many servers--like recently happened to the government. That is one possibly vulnerability, as are UI Javascript library files, or even programmer created javascript files. All are potentially vulnerable, and I believe that the average programmer uses them with hardly a look at what they contain.
 
  • #27
1,961
1,209
pbuk said:
you referred to 'executable javascript library files' which is a phrase that doesn't mean anything to me
There are packages that fill that bill ##-## perhaps @harborsparrow had something like jquery or modernizr or maybe JSON in mind ##-##

from https://www.w3schools.com/js/js_json_intro.asp:

JSON - Introduction

JSON: JavaScript Object Notation.
JSON is a syntax for storing and exchanging data.
JSON is text, written with JavaScript object notation.

Exchanging Data
When exchanging data between a browser and a server, the data can only be text.

JSON is text, and we can convert any JavaScript object into JSON, and send JSON to the server.

We can also convert any JSON received from the server into JavaScript objects.

This way we can work with the data as JavaScript objects, with no complicated parsing and translations.​
 
  • Love
Likes harborsparrow
  • #28
1,961
1,209
harborsparrow said:
All are potentially vulnerable, and I believe that the average programmer uses them with hardly a look at what they contain.
🎯 🎯 🎯
 
  • #29
pbuk
Science Advisor
Gold Member
2,262
965
I assumed you were talking about a third party "package" that has been compromised and then gets used on many servers
Well I was trying to work out what you were talking about when you said...

Because executable javascript library files are so ubiquitous, keyloggers that log every key you enter are more and more common.

...because it wasn't clear, and you still haven't provided any evidence for the second part of that sentence.

--like recently happened to the government.
Which government used a compromised dependency on many servers?

That is one possibly vulnerability, as are UI Javascript library files, or even programmer created javascript files. All are potentially vulnerable, and I believe that the average programmer uses them with hardly a look at what they contain.
Yes, it is the very nature of software dependencies that application programmers, er, depend on them. 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.
 
  • #30
1,961
1,209
Well I was trying to work out what you were talking about when you said...
harborsparrow said:
Because executable javascript library files are so ubiquitous, keyloggers that log every key you enter are more and more common.
...because it wasn't clear, and you still haven't provided any evidence for the second part of that sentence.
That knowledge is so common among programmers that it might seem unnecessary to cite examples to a fellow programmer ##-## nevertheless, the following is from:

1613445537100.png

https://www.mitre.org/about/our-history#node-104
##\Updownarrow##
https://attack.mitre.org/techniques/T1056/001/

Procedure Examples

ADVSTORESHELL can perform keylogging.[3][4]

Agent Tesla can log keystrokes on the victim’s machine.[5][6][7][8]

APT28 has used tools to perform keylogging.[9][10]

APT3 has used a keylogging tool that records keystrokes in encrypted files.[11]

APT32 has abused the PasswordChangeNotify to monitor for and capture account password changes.[12]

APT38 used a Trojan called KEYLIME to capture keystrokes from the victim’s machine.[13]

APT39 has used tools for capturing keystrokes.[14]

APT41 used a keylogger called GEARSHIFT on a target system.[15]

Astaroth logs keystrokes from the victim's machine.[16]

One of Attor's plugins can collect user credentials via capturing keystrokes and can capture keystrokes pressed within the window of the injected process.[17]

BabyShark has a PowerShell-based remote administration ability that can implement a PowerShell or C# based keylogger.[18]

When it first starts, BADNEWS spawns a new thread to log keystrokes.[19][20][21]

BadPatch has a keylogging capability.[22]

Bandook contains keylogging capabilities[23]

BISCUIT can capture keystrokes.[24]

BlackEnergy has run a keylogger plug-in on a victim.[25]

Cadelspy has the ability to log keystrokes on the compromised host.[26]

Carbanak logs key strokes for configured processes and sends them back to the C2 server.[27][28]

Cardinal RAT can log keystrokes.[29]

Catchamas collects keystrokes from the victim’s machine.[30]

CHOPSTICK is capable of performing keylogging.[31][3][10]

Cobalt Strike can track key presses with a keylogger module.[32]

Cobian RAT has a feature to perform keylogging on the victim’s machine.[33]

CosmicDuke uses a keylogger.[34]

DarkComet has a keylogging capability.[35]

Darkhotel has used a keylogger.[36]

Daserf can log keystrokes.[37][38]

Derusbi is capable of logging keystrokes.[39]

DOGCALL is capable of logging keystrokes.[40][41]

Duqu can track key presses with a keylogger module.[42]

##\dots##


You can go to the https://attack.mitre.org/techniques/T1056/001/ link and see the whole list, complete with 130 references . . .

The https://attack.mitre.org site has a great set of resources.
 
  • #31
1,961
1,209
pbuk said:
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
:​
1613467756650.png

pbuk said:
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.
pbuk said:
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.
 
  • #32
pbuk
Science Advisor
Gold Member
2,262
965
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.
 
  • #33
pbuk
Science Advisor
Gold Member
2,262
965
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.
 
  • #34
1,961
1,209
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.
pbuk said:
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.​
pbuk said:
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##
 
  • #35
1,961
1,209
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".
pbuk said:
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.
 
  • #36
pbuk
Science Advisor
Gold Member
2,262
965
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/
 
  • #37
pbuk
Science Advisor
Gold Member
2,262
965
... 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.
 
  • #38
BillTre
Science Advisor
Gold Member
2020 Award
1,756
4,388
Do keyloggers only pick-up data coming from the keyboard?
Would they pick up automated entries or voice recognized words turned into text?
 
  • #39
pbuk
Science Advisor
Gold Member
2,262
965
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.
 
Last edited:
  • #40
1,961
1,209
pbuk said:
sysprog said:
... 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'.
pbuk said:
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.
pbuk said:
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.
 
Last edited:
  • #41
BillTre
Science Advisor
Gold Member
2020 Award
1,756
4,388
Thanks for answering my simple question @pbuk, it was most helpful. :bow:
 
  • Like
Likes sysprog
  • #42
pbuk
Science Advisor
Gold Member
2,262
965
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.
 
  • #43
1,961
1,209
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.
 
Last edited by a moderator:
  • #44
berkeman
Mentor
59,622
9,755
Thread closed temporarily for Moderation...
 
  • #45
berkeman
Mentor
59,622
9,755
After a Mentor discussion, the thread will remain closed. Thanks everybody for an interesting thread.
 

Related Threads on Old Unwanted Internet Accounts are a Pain

  • Last Post
Replies
9
Views
2K
  • Last Post
Replies
9
Views
3K
Replies
6
Views
3K
Replies
4
Views
2K
  • Last Post
Replies
6
Views
1K
  • Last Post
Replies
1
Views
5K
  • Last Post
Replies
3
Views
2K
  • Last Post
Replies
9
Views
2K
  • Last Post
Replies
7
Views
3K
  • Last Post
Replies
16
Views
4K
Top