i need help cuz i kinda reach a dead end regarding an image upload exploitation, for now i can upload test.aspx.png, and furthermore i know its location, i can call the image from the server by url
i tried to inject a string in the image after the magic number (cuz off course there is a control in the server side that filter images from other file types)
the problem is that there is some kind of library that almost change completely the image hex of the image, i know that because i compared the hex of both original image and uploaded image and they are completely different but they are similar in appearance,
i wonder how i can overcome this issue, is there anyway to send some crafted image that is designed specifically to bypass any sort of filtering libraries or any known vulnerabilities of asp image libraries …?
i thought that resizing the original image to fit the same size after upload [400/222] would help preventing that function or whatever manipulate the image and change its hex but no, i still have the same problem
@Surviver the other solution is write your own backdoor in python and and convert that payload to executable.
While making *.pt to *.exe you can embbed the payload in image using pydot(a python package to convert *.py to *.exe)
@Surviver these are long shots, but what I would probably do:
upload a normal image or file. One you’re sure that’s allowed and untampered. Keep a copy of the original. Let’s call this
download that file after it was uploaded. That’s
upload that downloaded image again, so upload
download it again. Call it
What would especially interest me is if and would differ from each other.
So basically: if an image underwent whatever the server is doing to it. Does it do it again if you send over a file already that meets the exact specifications the server is trying to achieve?
You’ll end up with two paths:
either there is no difference between and . Then use that to build your payload, see what happens and adjust from there
if there is a difference, then:
I’d want to know what changes exactly between the three files.
somehow it has to be a valid image of it displays, so it has to be a known file type (for your browser to interpret it)
once you know what differs, you may be able to anticipate the difference. Depending on it’s complexity.
Another possible path is:
Is the service known to you? Is it open-source, or do you know the name and version numbers?
If so, try to get your hands on the source code and see what actually happens. Maybe you can reverse the process and send a file that comes out the way you want it.
Other ways are:
Investigate a completely different path. Sometimes you’re just at a dead end, no matter how close you are. But in your case, you still have options.
Hope this brought you some hope. Let me know how you finally went about it. Good luck!
i wonder how i can overcome this issue, is there anyway to send some crafted image that is designed specifically to bypass any sort of filtering libraries or any known vulnerabilities of asp image libraries …?
There are no guarantees and no magic to make sure your attacks will bypass every control. It is an arms race to some extent.
That said, there are some good resources and, with patience, you can get there through trial and error.