Blind SSRF bugs are difficult to exploit. Just because you have a Server-Side Request Forgery bug, doesn't mean that the data is being returned back to you properly. The article explains a technique that the author used to turn a Invalid JSON exception with no data to get the full response data. Notably, they wanted to get the AWS metadata information.
They tested a lot of the handling of responses in the application by sending the request to their website via the SSRF and seeing how it reacted to different things. 300s, 400s, 500s, etc. They noticed that a 500 error returned all of the data. Of course, making a request to the AWS cloud metadata service will respond with a 200 so this wouldn't work for returning the data. Their goal was to trigger a 500 error but get the response from the server.
Since this was black box, they had no idea what to do next. The application was following redirects for 3xx status codes so they were curious what would happen if they reached the maximum amount of redirects. This led to a NetworkException and wasn't very useful. So, they decided to do some fuzzing around the types of 3xx status codes and their handling.
Their fuzzing was simply using each 3xx status code once and incrementing to the next one. To their surprise, on the application returned the full chain of redirects and the entire response to the metadata request from the final redirect. But, wait, why!?
They made some guesses on why this may have worked. The application was happy to follow a few redirects. However, if it followed more than 5 redirects not handled by libcurl then their was another error state. Surprisingly, this technique has worked in several situations for the author of the post.
I'm always amazed by how successful people are with this blackbox fuzzing to understand applications. For every instance of a blog post like this, there are likely several hundred cases that were not exploitable though. Interesting read!