1 – the sqlis were damn easy to identify – discovering the resources affected, not so much. lots of recon (gau, google dorking, spidering, url guessing) on target. discovered a number of web services, however no vulns
SQL注入非常容易识别，发现受影响的资源不容易。大量的侦察(gau,google daring, spidering ， url guessing ) ，发现一些网络服务，但是不会有漏洞。
2 – kept URL guessing and found a zip file containing web.config – several creds leaked – more interesting was the URLs disclosed in there as they point to asmx web services – turns out 90% of these are on sites out of scope
3 – the paths of these web services were somehow similar to other folders and couple web services that existed on the main target, so I created several dictionaries to be used in an attack with permutations to see if the site had these endpoints just in different folders
4.- dict1 known folders on target. dict2, dict3 both had paths extracted from the urls in web.config, with some permutations based on names similarities I inferred; dict4 endpoints from web.config. ran ffuf cluster-bomb style out of 35k possibilities, found 10+
5.- 10+ web services that supposedly were on OOS sites, however available in different locations on target in scope. each web service had many endpoints (some even 30-40). moral of the story, these had more holes than swiss cheese. that’s were all sqlis were
6 – TLDR; would i have reported the web.config finding immediately, other people would have seen the URLs and perhaps locate these web services on the target; i didn’t report it and worked until i found their location and reported as many sqlis as i could.
7 – my take away and tip for the reader: don’t report a bug as soon as you find it, especially if it shows that it can be used to further own a target. keep the intel for yourself and hack. if after a while it doesn’t lead to anything, report the bug and move on.
2.I Built a TV That Plays All of Your Private YouTube Videos
3.Breaking GitHub Private Pages for $35k