SSRF with blacklist-based input filter

TL;DR

Same routine as the first SSRF labs, vulnerable stockApi to exploit on articles.

Exploitation gives us a gentle 400 bad request informing us of a security rule enforced (don’t expect verbose output for these in real life scenario)

Use double URL encoding to bypass the security checks and replicate the usual SSRF actions to solve the lab.

Learning material

---

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using the following techniques:

• Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
• Register your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.
• Obfuscate blocked strings using URL encoding or case variation.
• Provide a URL that you control, which redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filters.

Lab

---

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed two weak anti-SSRF defenses that you will need to bypass.

Write-up

---

The challenge attack vector is identical to previous labs basic ssrf against the local server and basic ssrf against another back-end system, though in this case you’re greeted with a 400 bad request

After playing a bit with requests, the website seems to black-list 127.0.0.1 and admin exclusively. For example, inserting %31 instead of 1 in http://%3127.0.0.1/ still triggers the security rules. However, URL encoding anything in the middle or even the last 1 bypass the check.

stockApi=http%3a%2f%2f1%25327.0.0.1%2f%2561dmin

Same principle applies to admin key word. Thus, URL encoding the complete payload (it ends up being double encoded in your request) completely voids the security rules :

Basically if you already did the previous lab this one is nothing but an URL double-encoding challenge. Once you got it right, repeat the step with the deletion request.

Resources

---

URL-encoding from %00 to %8f

ASCII Value	URL-encode	ASCII Value	URL-encode	ASCII Value	URL-encode
�	%00	0	%30	`	%60
	%01	1	%31	a	%61
	%02	2	%32	b	%62
	%03	3	%33	c	%63
	%04	4	%34	d	%64
	%05	5	%35	e	%65
	%06	6	%36	f	%66
	%07	7	%37	g	%67
backspace	%08	8	%38	h	%68
tab	%09	9	%39	i	%69
linefeed	%0a	:	%3a	j	%6a
	%0b	;	%3b	k	%6b
	%0c	<	%3c	l	%6c
c return	%0d	=	%3d	m	%6d
	%0e	>	%3e	n	%6e
	%0f	?	%3f	o	%6f
	%10	@	%40	p	%70
	%11	A	%41	q	%71
	%12	B	%42	r	%72
	%13	C	%43	s	%73
	%14	D	%44	t	%74
	%15	E	%45	u	%75
	%16	F	%46	v	%76
	%17	G	%47	w	%77
	%18	H	%48	x	%78
	%19	I	%49	y	%79
	%1a	J	%4a	z	%7a
	%1b	K	%4b	{	%7b
	%1c	L	%4c	|	%7c
	%1d	M	%4d	}	%7d
	%1e	N	%4e	~	%7e
	%1f	O	%4f		%7f
space	%20	P	%50	€	%80
!	%21	Q	%51		%81
”	%22	R	%52	‚	%82
#	%23	S	%53	ƒ	%83
$	%24	T	%54	„	%84
%	%25	U	%55	…	%85
&	%26	V	%56	†	%86
’	%27	W	%57	‡	%87
(	%28	X	%58	ˆ	%88
)	%29	Y	%59	‰	%89
*	%2a	Z	%5a	Š	%8a
+	%2b	[	%5b	‹	%8b
,	%2c	|%5c	Œ	%8c
-	%2d	]	%5d		%8d
.	%2e	^	%5e	Ž	%8e
/	%2f	_	%5f		%8f