[JENKINS-34490] Jenkins credential change should require reauthentication

[timja]

Submitting as delegate for a Cisco pen-testing team
This is a vulnerability which could allow an attacker to change a logged in users credential without confirming that they are the user in question.

Headline: Jenkins credential change should require reauthentication
Platforms:Jenkins
Versions: 1.622
CWE Tags: CWE-620

Jenkins allows users to authenticate using multiple credentials including
passwords, API tokens, and SSH keys. End-users administer each of these
credentials via the user configuration page (e.g. /user/

{username}

/configure),
but this page does not require the user to reauthenticate before making a
change.

All applications must routinely accept changes to application state; however,
credential changes must be handled with the utmost care. Unlike other changes,
an insecure credential change process can allow an attacker to completely take
over a user account. For example, if an attacker temporarily gains unauthorized
access to an authenticated session, he can alter one, or more, of the user's
credentials thus allowing the attacker to access the account later. He can also
use this capability to lock the legitimate user out of the account.

Best practices dictate that applications require users to reauthenticate before
making a credential change. For example, many applications have long required
users to enter their old password and new password in order to make a password
change. To defend against the extreme consequences of such an attack, Jenkins
must also require all users to reauthenticate before accepting any credential
change.

Finally, one should note that this isn't just a theoretical security issue.
Adherence to this best practice would have fully mitigated the critical
exposure resulting from Jenkins SECURITY-180/CVE-2015-1814(forced API token
change).

References:
http://cwe.mitre.org/data/definitions/620.html

---

Originally reported by smarlowe, imported from: Jenkins credential change should require reauthentication

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

danielbeck:

Adherence to this best practice would have fully mitigated the critical
exposure resulting from Jenkins SECURITY-180/CVE-2015-1814 (forced API token
change).

SECURITY-180 was unauthenticated, I'm not sure how åny of this would have prevented that.

[timja]

crlorent:

In response to Daniel Beck's comment, Direct from the original pen tester

The suggestion is that there should essentially be 2 forms of
authentication for any credential change. First, the user should
have a valid session, and secondly the user must also supply a
valid credential (e.g. password) as a parameter to the credential
change request.

The problem with SECURITY-180 was that the session token wasn't
being verified properly, thus allowing anonymous/unauthenticated
attackers to issue the request. The change token API call takes
no parameters, but consider instead that this API might require
the user's password as a parameter. Even if the session wasn't
checked, this wouldn't be exploitable. Yes, an
anonymous/unauthenticated attacker could still call the change
token API, but it would result in an error because the attacker
couldn't supply the correct password as a parameter to the call.

The reason that the vulnerability existed, SECURTY-180, is that this type of best practice was not being followed.

[timja]

crlorent:

As per danielbeck, This is my request to have this defect marked as submitted by Steve Marlowe , the original discoverer, so that he can see them and be directly engaged.

[timja]

danielbeck:

Changed the reporter to smarlowe.

[timja]

danielbeck:

As per the Security team meeting of 2016-03-30, we do not consider this to be a vulnerability, as the credential change requires a user to be logged in to begin with.

Unless a case is made by others in the team or smarlowe, I will move this over to JENKINS.

[timja]

smarlowe:

I can definitely understand the reasoning why you might not want to call this a
vulnerability. There's not an "exploit" in the traditional sense that an
attacker can leverage. The real risk here is that an attacker who gains
temporary access to a valid user session can escalate this to permanent access
by changing the user's credential and potentially locking the valid user out of
his account. Or the attacker might chose to be sneaky and add a credential
(e.g. an SSH key) while leaving the valid user's access in tact.

The typical scenario that's usually discussed is a user who walks away from his
computer (e.g. to get coffee). While he's gone the attacker walks up to the
computer, navigates to the user profile page, and adds/changes the user's
credential. Of course, there are analogs to this scenario that don't require
physical access to the victim's computer--this is just the most straightforward
scenario to explain and understand.

At Cisco our defect tracker doesn't attempt to distinguish between
vulnerabilities and non-vulnerabilities in this way. Our closest categorization
equivalent is that of a security defect versus an enhancement/feature request.
Again, I can understand how one might consider this an enhancement in the sense
that a security protection is in place (a valid session is required) and the
issue is pointing out a way to strengthen it. Nevertheless, this would
definitely not be considered an enhancement at Cisco. It's 100% a defect, and
the reason is that it is a direct violation of Cisco security requirements
imposed by our secure development lifecycle. (And it's also a violation of
security best practices, but more on that later).

In fact, all Cisco products must force the user to provide his old password as
part of the password change process. The reason is exactly as I described in
the initial write-up. Although the attack is unlikely to occur, the impact of
this attack is enormous, so we take extra efforts to defend against it.
Furthermore the fix of requiring the user to authenticate for credential changes
is trivial to implement and is frankly expected by security-conscious users. We
certainly don't want our users to think we take security lightly because they
notice they can change their password without entering the old one.

Lastly, I'd reiterate what I stated in the original write-up that this behavior
goes against the grain of widely-accepted security best practices. I've just
verified that Hotmail/Outlook.com, GMail, Facebook, LinkedIn, and my bank all
require me to enter my old password before allowing me to update my credential.
Also, OWASP mentions this in their "Broken Authentication and Session
Management" guide (see [1] "Password Change Controls" section), and it's in the
OWASP testing guide as something that needs to be verified by penetration
testers (see [2]). Although, it's a bit buried and this CWE is meant to cover
additional scenarios, reauthentication at credential change also is explicitly
listed in the CWE-620 description (see [3]).

At the end of the day, yall can label this issue however you'd like. My primary
point is to urge you to not just blow this off and put it on a backlog of things
you might get to someday. I filed this because I think it's an important
protection that you're currently missing. I hope you agree and prioritize it
accordingly.

[1] https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management#How_to_Protect_Yourself
[2] https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_%28OTG-AUTHN-009%29#Test_Password_Change
[3] http://cwe.mitre.org/data/definitions/620.html#Potential_Mitigations

[timja]

danielbeck:

smarlowe Thanks for your response! While this is certainly lower priority than fixing actual vulnerabilities, but I wouldn't consider it to be low. The idea isn't to dump somewhere to never be seen again, just to distinguish between what needs private tracking (i.e. vulnerabilities that can put users at risk) and what can be tracked publicly (everything else). The limited visibility here is in some ways an impediment to actually getting it fixed because of the small group of people with access.

[timja]

teilo:

Just to point out that if a user does not lock their machine and goes for a coffee - a malicious person can walk up and install a browser plugin or change the users proxy settings so they can get all of the traffic to any site including non-jenkins passwords (and cookies), so requiring a password change will not help if in the end users let random people utilize their machines.

But yes - this would be a good thing to do in general.