Juice Shop is a purposely-vulnerable web platform created by Björn Kimminich and the Open Web Application Security Project (OWASP) that provides users with a legal way to hack a website. I recently completed the challenges in Juice Shop, and one of my favorite ones was a higher level challenge called Leaked Access Logs. It includes some of my favorite things: OSINT, password spraying, and a dash of SQL injection. It was also a challenge I was able to complete on my own.

Here was the initial question:

Dumpster dive the Internet for a leaked password and log in to the original user account it belongs to. (Creating a new account with the same password does not qualify as a solution.)

That’s not a lot to go on, so I looked at the extended description:

As the challenge name implies, your task is to find some leaked access logs which happen to have a fairly common format. A very popular help platform for developers might contain breadcrumbs towards solving this challenge. The actual log file was copied & paste onto a platform often used to share data quickly with externals or even just internal peers. Once you found and harvested the important piece of information from the log, you could employ a technique called Password Spraying to solve this challenge.

The first thing that stuck out to me was the developer help site part. That had to be stackoverflow.com. And the copy and paste platform? I’d be willing to bet that’s probably pastebin.com.

What are some common log formats? JSON? XML? Something else? And I was looking for a leaked password?

With all that information, I began some Google searches using the Google dorks “site:stackoverflow.com” and “site:pastebin.com”. I searched for a variety of terms, alone and together, including “log,” “access,” “juice,”, “juice shop,” and “access log.” I found some interesting results, but none of them really pointed to what I was looking for. And then I thought I’d see if Juice Shop creator Björn Kimminich had an account on Stack Overflow.

Turns out he does have an account, and he’s asked some questions, and one of those questions does indeed have a link to an entry on Pastebin:

Bjorn’s StackOverflow Page

Bjorn’s StackOverflow Question

I searched for the string “password” in the log data and found this entry:

161.194.17.103 - - [27/Jan/2019:11:18:35 +0000] "GET /rest/user/change-password?current=0Y8rMnww$*9VFYE%C2%A759-!Fg1L6t&6lB&new=sjss22%@%E2%82%AC55jaJasj!.k&repeat=sjss22%@%E2%82%AC55jaJasj!.k8 HTTP/1.1" 401 39 "http://localhost:3000/" "Mozilla/5.0  

So it looks like the current password was 0Y8rMnww$*9VFYE%C2%A759-!Fg1L6t&6lB and the user was attempting to change it to either sjss22%@%E2%82%AC55jaJasj!.k or sjss22%@%E2%82%AC55jaJasj!.k8.

One thing I noticed immediately was that the passwords looked encoded, and since I wasn’t sure what type of input could be used when doing password spraying I came up with 4 options for the password:

sjss22%@%E2%82%AC55jaJasj!.k
sjss22%@€55jaJasj!.k
sjss22%@%E2%82%AC55jaJasj!.k8
sjss22%@€55jaJasj!.k8

Now there was the matter of the user. I searched through the log, but there was nothing given to indicate which user the password belonged to. This is where the spraying part will likely come in. But before that I needed to get a list of all the Juice Shop users.

Prior to this challenge, there was another challenge where I used SQL injection to exfiltrate the database schema of the site via the site’s search feature. (The website is running SQLite.) I modified the request that was used to get the schema to get info from the Users table. I used Burp Suite Community Edition to do this.

I requested usernames, emails, and password hashes from the Users table.

Requesting Users table

The results of the injection request

Now I had the emails for all of the users of the site, so I could start spraying. But before I did that I was curious about those hashes. What kind were they? If I could convert the passwords I had into hashes and match any of those with the user’s hash then I’d have my answer and wouldn’t even have to bother spraying.

According to a hash analyzer, the hashes were likely MD5 with no salting. So I took the passwords I had and converted them into MD5 hashes. Unfortunately, after searching the user hashes not one of them matched! I knew that wasn’t a good sign, but maybe the hash analyzer was wrong and there was some salting after all.

So I decided to begin spraying. I started up Burp Intruder and pasted the user emails in as a list. I also used Grep - Match to flag responses with “Invalid email or password,” which was the response I would get if the password was incorrect.

list in Burp intruder

using grep with burp

I tried the 4 password options and nothing. There really wasn’t a user with one of those passwords.

I tried 0Y8rMnww$*9VFYE%C2%A759-!Fg1L6t&6lB and its decoded counterpart 0Y8rMnww$*9VFYE§59-!Fg1L6t&6lB in Intruder and I still wasn’t getting any results. Then I realized those two passwords were too long to be used in Intruder, and I wasn’t going to be able to spray with them.

password too long

So what now, was I going to have to do all of this manually? Yeah, it looked like I was.

I started with the first email in the database, J12934@juice-sh.op, and thankfully the password 0Y8rMnww$*9VFYE§59-!Fg1L6t&6lB worked and I was in! Because the user’s request to change their password included 2 different strings in the new and repeat fields the password change didn’t actually happen and the current password remained the same.

challenge solved

And when I took the password 0Y8rMnww$*9VFYE§59-!Fg1L6t&6lB and converted it into a hash, it did match the hash for the user J12934@juice-sh.op.

making a hash

the hashes match