Skip to content

Commit 98b07d4

Browse files
UnknnownnnUnknnownnn
committed
Update writeup.md
1 parent 52a185e commit 98b07d4

File tree

1 file changed

+294
-1
lines changed

1 file changed

+294
-1
lines changed

‎website/writeups/Cyscom Juice Shop 2025/writeup.md‎

Lines changed: 294 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,4 +6,297 @@ categories: [web, ctf]
66
tags: [sql-injection, xss, ssti, idor, authentication]
77
---
88

9-
CLOSED
9+
![](imagedata/logo.png)
10+
11+
The CYSCOM JUICE SHOP, like OSWAP Juice Shop, includes a broad spectrum of vulnerabilities from simple input-based flaws to logic and design-level flaws. Understanding the rationale behind each exploit reinforces the importance of layered security, input validation, and robust authentication design.
12+
13+
This document provides a detailed analysis of each challenge presented in the CYSCOM Juice Shop Challenge. Each vulnerability is explained alongside its exploitation method and the flag retrieval steps.
14+
15+
## TASK 1: MAIN FLAGS
16+
17+
### Initial Login Page & SQL Injection
18+
<img src="./imagedata/Picture1.png">
19+
The login form is susceptible to SQL Injection, allowing attackers to bypass authentication without knowing valid credentials. This is due to improperly sanitized user inputs in SQL queries.
20+
21+
Examples of payloads:
22+
```
23+
admin' –
24+
admin';--
25+
admin' /*
26+
' UNION SELECT 1,2,3,1,'admin
27+
```
28+
29+
Entering these in the username followed by any password lets the user login as admin.
30+
31+
> [!NOTE]
32+
> OR-based injections are filtered, requiring alternative payloads.
33+
34+
<img src="./imagedata/Picture2.png"> <img src="./imagedata/Picture3.png">
35+
36+
<img src="./imagedata/Picture4.png">
37+
38+
<hr>
39+
40+
### Admin Panel Disclosure
41+
42+
The `/admi`n endpoint, typically hidden, becomes accessible post-SQL injection login. This panel leaks usernames and passwords of all registered users, indicating a <b>Sensitive Data Exposure</b> vulnerability.
43+
44+
<img src="./imagedata/Picture5.png">
45+
46+
<img src="./imagedata/Picture6.png">
47+
48+
<b>Flag Retrieval:</b> Visiting this hidden endpoint grant the user a flag.
49+
50+
<img src="./imagedata/Picture7.png" >
51+
52+
The leaked credentials can be used to authenticate normally to 'admin' user and retrieve the corresponding flag.
53+
54+
<img src="./imagedata/Picture8.png">
55+
56+
<hr>
57+
58+
### Documentation Panel - Token Access
59+
60+
This panel is visible only on admin login and shows some open endpoints that we can access.
61+
62+
<img src="./imagedata/Picture9.png">
63+
64+
<img src="./imagedata/Picture10.png">
65+
66+
<img src="./imagedata/Picture11.png">
67+
68+
This panel reveals hidden endpoints, accessible only via a Base64-encoded token in the format:
69+
70+
```
71+
base64("username:date")
72+
```
73+
74+
This mechanism mimics an insecure form of token-based access control and can be exploited for endpoint access.
75+
76+
77+
<b>Flag Retrieval: </b> Visiting `/api/v1/internal/users` endpoint:
78+
79+
<img src="./imagedata/Picture12.png">
80+
81+
<img src="./imagedata/Picture13.png">
82+
83+
<img src="./imagedata/Picture14.png">
84+
85+
Also visiting `/api/v1/backup?token=` with the correct token of format `(admin:time)` in base64 format, leads to:
86+
87+
Eg: `https://vul-webapp.onrender.com/api/v1/backup?token=YWRtaW46MjEzCg==`
88+
89+
<img src="./imagedata/Picture14.png">
90+
91+
<img src="./imagedata/Picture15.png">
92+
93+
<hr>
94+
95+
### IDOR (Insecure Direct Object Reference)
96+
97+
Users can add and view personal notes with titles and some body. These also supports HTML formatting. By modifying the note ID in the URL (e.g., /note/2 to /note/1), we can access notes belonging to other users.
98+
Vulnerability Impact: Lack of access control on object references allows unauthorized data exposure.
99+
100+
<img src="./imagedata/Picture16.png"> to <img src="./imagedata/Picture17.png">
101+
102+
<img src="./imagedata/Picture18.png">
103+
104+
<hr>
105+
106+
### Cross Site Scripting (XSS)
107+
108+
HTML input fields when not sanitized allow malicious scripts to be saved and executed in the browser of other users. This compromises session tokens or redirects victims.
109+
110+
Since the notes supports HTML formatting. We can inject code into these notes using basic HTML scripts.
111+
112+
<img src="./imagedata/Picture19.png">
113+
114+
<img src="./imagedata/Picture20.png">
115+
116+
<hr>
117+
118+
### Encoded Cross Site Scripting
119+
120+
Most websites sanitize the user inputs to prevent XSS vulnerabilities in their webpages by not allowing syntax or text for certain formats. We can bypass this using encoding text to their ascii values or decimal values and injecting the XSS. Browsers decode these before rendering, reactivating the payload.
121+
122+
Eg: `<script>&#97;&#108;&#101;&#114;&#116;(1)</script>`
123+
124+
<img src="./imagedata/Picture21.png">
125+
126+
<img src="./imagedata/Picture22.png">
127+
128+
<hr>
129+
130+
### Server-Side Template Injection (SSTI)
131+
132+
Unsensitized input can sometimes be passed into server-side template engines (like Jinja2). If expressions are interpreted, attackers can run arbitrary code.
133+
For example:
134+
```
135+
{{7*7}} => 49
136+
```
137+
This can lead to full server compromise if RCE is possible.
138+
139+
You can inject Server-side templates to the file search of option to reveal sensitive data. This happens when the user input is not sanitized.
140+
141+
<img src="./imagedata/Picture23.png">
142+
143+
<img src="./imagedata/Picture24.png">
144+
145+
<img src="./imagedata/Picture25.png">
146+
147+
<hr>
148+
149+
### Advanced SSTI
150+
Expanding SSTI beyond one field demonstrates lack of sanitization across the app, suggesting systemic weaknesses in input validation such as input to the title of user notes.
151+
152+
<img src="./imagedata/Picture26.png">
153+
154+
<img src="./imagedata/Picture27.png">
155+
156+
<hr>
157+
158+
### Event-Based Cross Site Scripting
159+
160+
Event handlers like onerror are triggered under certain browser events. Injecting them into inputs can cause malicious execution without direct user interaction
161+
162+
<img src="./imagedata/Picture28.png">
163+
164+
<img src="./imagedata/Picture29.png">
165+
166+
<img src="./imagedata/Picture30.png">
167+
168+
<hr>
169+
170+
### Broken Authentication - Token Forgery
171+
172+
The application allows password resets via a token which is easily found on the "/admin" endpoint. Lack of proper validation enables unauthorized access.
173+
174+
<img src="./imagedata/Picture31.png">
175+
176+
We need to make a base64 encode token of format:
177+
```
178+
username:date (eg: user:02, cabinet:21)
179+
```
180+
And convert it to `base64`.
181+
We can then use this token to reset password of the account.
182+
This gives us the broken authentication flag.
183+
184+
<img src="./imagedata/Picture32.png">
185+
186+
<img src="./imagedata/Picture33.png">
187+
188+
Only few accounts have the ability to reset password. Not all accounts can reset the password.
189+
190+
<hr>
191+
192+
### Lost User (OSINT Challenge)
193+
194+
This is an OSINT challenge that starts by logging in to the `cabinet` user. This user already has a note with a heading "remember the date" and a link to a webpage.
195+
196+
<img src="./imagedata/Picture34.png">
197+
198+
It also has another note that states that the official account `cyscom` is scheduled for deletion because the password was too easy to guess (a date).
199+
200+
On clicking the link to the webpage, we can scroll down to find a timeline to events.
201+
202+
<img src="./imagedata/Picture35.png">
203+
204+
Trying the date 15012022 (15 January 2022) as the password for `cyscom` user, we get access to the account that is to be removed.
205+
206+
<img src="./imagedata/Picture36.png">
207+
208+
Clicking the `view Flags` button, we are given the Lost User flag.
209+
210+
<img src="./imagedata/Picture37.png">
211+
212+
<hr>
213+
214+
### Type Juggling (PHP)
215+
216+
Type juggling or type casting refers to a PHP functionality. Since PHP does not require explicit type definition in variable declaration, a string can be assigned to a variable 'a' and later on an int can also be assigned to variable 'a'.
217+
```
218+
'0e12345' == '0e54321' // true in PHP
219+
```
220+
221+
If the computed hash only contains numbers after the first `0e`, PHP will treat the hash as a float. A password hash that begins with `0e` will always appear to match the strings, regardless of what they actually are.
222+
This can be used to bypass authentication in vulnerable PHP programs. We can emulate this in our webpage by sending a POST request as:
223+
```
224+
curl -X POST "https://SERVER_IP/api/v1/verify_backup" -H "Content-Type: application/json" -H "Cookie: session=YOUR_SESSION_COOKIE" -d "{\"id\":123,\"hash\":\"0e123456789\"}"
225+
```
226+
227+
<img src="./imagedata/Picture38.png">
228+
229+
This request sends a request with these parameters:
230+
```
231+
{
232+
"id": 123,
233+
"hash": "0e123456789"
234+
}
235+
```
236+
To the `/api/v1/verify_backup` endpoint, which bypasses the authentication with an hash starting with 0e.
237+
238+
> [!NOTE]
239+
> In the above request, replace SERVER\_IP with the website IP address & YOUR\_SESSION\_COOKIE with your session token. This can be found using inspect element. In Firefox, it can be found at:
240+
> <img src="./imagedata/Picture39.png">
241+
242+
<hr>
243+
244+
### Prototype Pollution (JavaScript)
245+
246+
Prototype pollution is a JavaScript vulnerability that enables an attacker to add arbitrary properties to global object prototypes, which might be inherited by user-defined objects. This vulnerability let's an attacker control property of objects that would otherwise be inaccessible.
247+
JavaScript objects inherit from Object.prototype. Injecting into `__proto__` alters default properties application-wide, potentially bypassing logic or introducing backdoors.
248+
249+
To emulate this, we can send a curl request to the server using this data:
250+
```
251+
{
252+
"__proto__": {
253+
"polluted": true
254+
}
255+
}
256+
```
257+
Example command:
258+
```
259+
curl -X POST "https://SERVER_IP/api/v1/user/preferences" \ -H "Content-Type: application/json" \ -H "Cookie: session=YOUR_SESSION_COOKIE" \ -d "{\"normal_key\": \"normal_value\", \"__proto__\": {\"polluted\": true}}"
260+
```
261+
262+
<img src="./imagedata/Picture40.png">
263+
264+
> [!NOTE]
265+
> In the above request, replace SERVER\_IP with the website IP address & YOUR\_SESSION\_COOKIE with your session token. This can be found using inspect element.
266+
267+
<hr>
268+
269+
## TASK 2: BONUS FLAGS
270+
271+
### Image Steganography
272+
Data is hidden within image files using LSB or metadata techniques. Tools like zsteg extract such hidden data.
273+
Logging into user `Unknown` gives us an image in the notes
274+
275+
<img src="./imagedata/Picture41.png">
276+
277+
We can download this image and try to run text extraction techniques on it such as steghide, zsteg, etc.
278+
279+
<img src="./imagedata/Picture42.png">
280+
281+
Using `zsteg`, we can see the flag hidden in the image.
282+
283+
<hr>
284+
285+
### Audio Steganography
286+
Logging into the user `user`, we can see that this user has a .wav file as a note. Downloading and running this through a spectrogram generator gives us the flag.
287+
288+
<img src="./imagedata/Picture43.png">
289+
290+
<hr>
291+
292+
### Hidden in plain sight
293+
A flag is revealed to the user in the documentation page of the webpage as the DEBUG\_KEY.
294+
295+
<img src="./imagedata/Picture44.png">
296+
297+
<hr>
298+
299+
### Discussions Tab
300+
<img src="./imagedata/Picture45.png">
301+
302+
Taking the first letter of every comment from 2nd to 3rd last gives CYSM, our flag format. The 2nd last comment give us the full flag `CYSM{dafweyif29ybvf23d}`

0 commit comments

Comments
 (0)