In this article, I will be discussing the security vulnerabilities that could be found using images. Furthermore, I will be demonstrating how an attacker can steal confidential images/data and may gain access to the host machine.
What are the initial things that a hacker look for when trying to hack a website? Some goes after forms to get X.S.S
Some try to inject the GET parameter whenever they see anything like
while some goes directly for login pages and try to bypass the authentication using SQL injectors like
admin' or '1'='1
admin' or '1'='1'--
admin' or '1'='1'#
admin' or '1'='1'/*
admin'or 1=1 or ''='
and almost everyone try the username and password as ‘admin’ XD but nobody pays much attention to the images present on the website. Images are important part of any website but people (hackers and developers) often underestimate the security vulnerabilities that images could create.
I am not talking about uploading shell scripts with or instead of images but a whole another dark stuff I call as ‘CHIRA Attack Vector’. Which is not an exploit but a technique or procedure to discover security vulnerabilities. The prevalence is medium to rare but its key to the treasure when found. Easy to exploit, All you need is a Web browser in most of the cases. and the impact is from informational to Harmful.
Lets start messing up with images, I must categorize the images into two categories first.
- Static Images:
Images like logo, background. Which forms the UI and doesn’t change. Publicly accessible and of no use to us.
- Dynamic Images:
Images like Profile pictures, supporting documents, fingerprints, signature. Which are different for different users.
We will focus on the dynamic images only and assuming the website requires you to login. You must have guessed that such kind of images are mostly found on registration form for examinations or Govt. Websites. Bingo, you are damn right!
Determining the Image Serve Method:
The next step will be determining how the images is given to us and how it is stored on the server. The website can serve the image directly by giving source to image directory . (You can run the examples yourself, Check the GitHub Repository) More Details Below.
or the server may serve the image using a controller to hide original image directory.
Take the first type where website serves the image by giving source to image directory. There is two things to check:
- Whether the directory has index file or not.
- If the file name are in sequence or something like username that can be guessed or some random hashing or something.
If the target directory doesn’t have any index file and server allows, You can see all the images/files present in the directory. The files may not be confidential one but it’s a hint that the admin doesn’t bother about security and the same loophole maybe left open with confidential information too. And it also allow us to discover the uploaded files easily (In case you were able to upload a shell, basic stuff).
If the target directory have any index file then we will check the file name whether that can be guessed or not. if it anything like “user01.jpeg” or “01.jpeg” we can guess the next file will be “user02.jpeg” or “02.jpeg” respectively. We can get the images/file by manually checking each filename.
Good practice is to use a index file and configure the server to prevent any index generation of directories if index file not present. And use random file like SHA hashes or something. The Best practice is too keep confidential information away from direct access. In a directory that only a controller can access, the controller will always check the authenticity of the user first.
This leads us to the second type where image is served using a controller to hide original image directory.
Inspecting The Image Controller:
You will usually find image controller or say scripts which serves the image. They are used to hide the original image directory from the public access and hence restricting the images to authenticated users only.
Software developer have deadlines to deliver a project so often they did not pay much attention to this part and leave security vulnerabilities at this part.
for example: taking arguments from user.
the arguments can be in GET (URL), or even header and cookies. which can be easily tempered. You can keep changing the arguments to fetch other user data. This is most common mistake developers make because from their point of view all the users are known and verified and can be tracked by in case of data leak. i.e exam portals require you to make fee payment and identity verification before you can access the dashboard. and hence its very easy to track from where the data is compromised but its not just about the images. The user given arguments can lead to a SQL injection and I know it’s bingo for hackers. You have now access to the DB not just images. The hackers will then try to get the admin credentials and login and will also try every attack vector to gain root access. and if successful, the hacker can delete/tamper the logs and make it difficult for the admin to track back the culprit.
The best approach is to use the user authentication to fetch images instead of taking any arguments from the user. For example: Each authenticated user have a session ID, and session data is stored on server side. its best practice to store user data in sessions like user id, E.T.C. and then use these server side arguments to fetch and serve image.
The above cases are represented in a simple demo (Github Repo). Just download the files or clone the repo. The script is written in PHP so you will need a PHP webserver like WAMP/XAMPP. No Database required.
The Demo has 3 scenarios:
1)When the profile and cover images are served directly. You can see the page source and open the image directory.
2)When the images are served by an image controller and arguments are taken from user. Only works if logged in.
3)Image controller without any user arguments. Securest way.
[Update 6th Jan 2019: At the time of writing I was not aware this is called as Insecure Direct Object References (IDOR) ]