Hi Folks, Hope all good on your side of terminal. My terminal is overflowed with full of commands here 🙂
This post will unearth the technical aspects behind my research on Jenkins Automation Server and Detailed description of Meta Character Injection which lead me to believe that i can pose as other users and can do the significant damage on the admin side.
Before going a head just will discuss about why we use jenkins. A simple Open Source tool written in Java which can automate the testing and informing us about the isolated changes done in large code in real time. Superb isn’t it. This is the reason i’ve choosen this product to perform the testing.
Apart from automation jenkins provides lot of features like managing users and roles etc. Which is where i started testing exactly. Jenkins provides registration of users as an optional feature. But there are checks for SQL injections and some other Hudson API related attacks on registration.
Started with registration and based on Jenkins documentation we can see they have nice Matrix based authorization scheme where no more privilege escalation possible via normal registration process. After looking around i was just trying on overwriting the user but there are strong checks on existing user validation.
I was so keen that i can do something in this validation part. I’ve below checklist in my mind for any registration which ask us to choose an Username.
- Can we register with username as robots.txt (or any filename that we can overwrite)
- Can we register with username as LFI payloads (such as ../../etc/passwd may be after we can see file content)
- Can we register with username as some existing folder name on server (by guessing folder name)
- Can we register with username as some ID which may belong to other user (which may end up in Race Conditions)
- Can we register with username containing hardware characters (Ex: %00, %0a, %90, %09, %0C and %0d etc which definitely do some interruption in web application behavior)
Before performing all test cases blindly it’s a very good habit to just look at the existing CVE ID’s for the Jenkins which may cover some of listed attack vectors.
Yes it was true. Some of my attack vectors are already discovered by Researcher (Darren Zhao) identified that he can do following attacks.
- User names consisting of a single forward slash would have their user record stored in the parent directory; deleting this user deleted all user records.
- User names containing character sequences such as
..could be used to clobber other configuration files in Jenkins.
- User names could consist of reserved names such as
Amazing work by Darren Zhao isn’t it. Here you can see full explanation ( CVE-2017-1000391)
What else left for me from my checklist ? Playing with some Meta/Control Characters all i left with right. Did the same. Basically i can register as existing user by appending Meta/Control Characters.
So here you can see the duplication in action. There are so many duplicated accounts. But what is the actual impact here..?
Yes there is an impact at admin end. If administrator wanna assign some job or schedule some job to a user then how he will identify the exact user (User Impersonation).
What else we gonna do with this issue ? I’ve checked by logging in as admin quickly and identified admin can’t able to delete or modify the user from front end. Which is very bad (Denial of Services/Actions). Also if that particular user allocated to any job then there are some implications again.
Root Cause Analysis:
SecurityRealm that performs authentication by looking up User.
Hudson.security.HudsonPrivateSecurityRealm.SignupInfo Core API class is responsible for handling the Registration flow and Storing the user data in Jenkins User Database Security Realm.
HudsonPrivateSecurityRealm.Details class is handling the UserDetails view of the user object. Our injected meta characters are affecting the HudsonPrivateSecurityRealm.Details class where view of the user object got corrupted and not able to display the data to the front end user.
Jenkins team fixed the issue by implementing the user input validation in HudsonPrivateSecurityRealm e.g. #validateAccountCreationForm
You can see full attack here in action.
Reported to Jenkins Team via https://issues.jenkins-ci.org. Below was their Timeline.
2018-03-31 10:29 – Reported Issue
2018-03-31 16:14 – First Response from Team
2018-04-15 12:13 – Planned about the Patch
2018-05-08 14:46 – Fix staged
2018-05-09 09:53 – Fixed on Production and Marked as Resolved
2018-05-21 06:08 – Team requested for CVE
2018-06-13 04:40 – Assigned CVE-2018-1000193