`;
180 |
181 | for(i=0; i < botsData.length; i++) { // [4]
182 | if (sBots.includes(botsData[i].name)) {
183 | botsHTML += `
184 |
185 |

186 |
`;
187 | }
188 | }
189 |
190 | botsHTML += `
`;
191 |
192 | $('.exp-container').html(botsHTML);
193 | }
194 | ```
195 |
196 | [4] botsData is decalred inside this file http://localhost:1337/static/js/global.js
197 |
198 | ```js
199 | window.botsData = [
200 | {
201 | "name":"DisBot",
202 | "src":"/static/images/bots/jake-parker-discord.png"
203 | }
204 | ```
205 |
206 | As the source is directly used in the jquery html sink we thought if we can clobber `window.botsData` we could get xss.But we couldn't find any injection point.
207 |
208 | Meanwhile my friend pointed out that the `/debug` endpoint has Werkzeug console exposed (as the application is running in debug mode), but we don't know the pin.
209 |
210 | This is where we came up with a plan how to solve this challenge by chaining all the pieces we already have.
211 |
212 |
213 |
214 | Searching on google we found this blog https://www.daehee.com/werkzeug-console-pin-exploit/, which explains how you can genrate the PIN if you have a path traversal bug.By following this we should be able to get the PIN
215 |
216 |
217 | Here's how the attack will look:
218 | Consider the xss endpoint to be `/xssendpoint`
219 |
220 |
221 | In the report endpoint, modify the id parameter in the request to `../go?to=/xssendpoint` . This will redirect the bot to the page where we have xss.Using the xss bug make a request to the `/api/ipc_download?file=../../../../etc/passwd` endpoint and get the response and sent it to our controlled server. (we will fetch the necessary information needed to generate the pin)
222 |
223 | -------------
224 |
225 | # XSS
226 |
227 | We are still misisng an important piece to prove our attack , xss. At this point we were clueless then my friend pointed our that the challenge name relates *web desync* maybe we need to exploit this to get xss.
228 | At that time we both remembered about seeing a new research by @kevin_mizu on *Abusing Client-Side Desync on Werkzeug* as we were dealing Werkzeug this looked very promising.
229 |
230 | https://mizu.re/post/abusing-client-side-desync-on-werkzeug
231 |
232 | Oxbla confirmed that it is ineeded vulnerable to desync attack. I was reading the research blog at that time as I am not good with this attack, the version mentioned in that blog was same as what was used in the challenge
233 |
234 | requirements.txt
235 | ```
236 | Flask==2.1.0
237 | Werkzeug==2.1.0
238 | ```
239 |
240 | https://nvd.nist.gov/vuln/detail/cve-2022-29361
241 |
242 |
243 | Mizu really went deep into his research and even undercover an interesting open redirect to demonstrate how this bug could could be chained together which will lead to account takeover.
244 |
245 | I won't go into the details as Mizu already explained everything very well in simple terms so make sure to read his research before continuing
246 |
247 |
248 | This is the open redirect which I am talking about :
249 |
250 | ```
251 | GET http://google.com HTTP/1.1
252 | Host: localhost:1337
253 | Accept-Encoding: gzip, deflate
254 | Accept: */*
255 | Accept-Language: en-US;q=0.9,en;q=0.8
256 | User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.138 Safari/537.36
257 |
258 |
259 | ```
260 |
261 | Response:
262 |
263 | ```
264 | HTTP/1.1 308 PERMANENT REDIRECT
265 | Server: Werkzeug/2.1.0 Python/3.11.4
266 | Date: Mon, 17 Jul 2023 15:18:31 GMT
267 | Content-Type: text/html; charset=utf-8
268 | Content-Length: 262
269 | Location: http://google.com/?
270 | ```
271 |
272 | Again check the research blog if you want to know the root cause of this.
273 |
274 |
275 | By using a form such as this:
276 |
277 | ```html
278 |