Warning : The below content is for educational purposes only. Author is not responsible for any action performed based on this tutorial.
What is an OPAC ? :
Abbreviated as Online Public Access Catalogue, OPAC is a catalogue that is linked to a database in the back end. OPAC is owned mostly by libraries and it contains books and other infos. Public uses OPAC to search regarding the a book and author. So what are we going to gain by hacking OPAC ? Well, we can change each and every info of the books available in the database as well as we can deface the web page of OPAC once we gain enough information regarding the database credentials.
How to SQL inject into a Library OPAC :
As i have mentioned above, all the OPAC systems are connected to a database backend. It receives input from the end user and sends it back to the database. Mostly OPAC system doesn’t have any sanitizer to sanitize the inputs given by the end user. So, the queries sent back-end can be tampering with SQL queries. When SQL queries are sent to the database by any means of Input, either through URL or through other input means, the database reflects with the information requested by the attacker. Let me use my collage OPAC as an example for this attack.
Hacking into Library OPAC using SQL injection :
My collage ran OPAC on Local Network with a class C IP 172.16.23.15. Surfing through the OPAC, I found search option for searching books, authors, journals, ebook, videos etc. While searching for books related to ‘Hacking’, the URL of the OPAC system looked as below :
I had a thought of trying SQL injection into OPAC. Inorder to test, I added an apostrophe at the end of the URL so the URL looked as the below mentioned
Hitting enter and loading page reflected me with an Error. The error stated that OPAC uses Microsoft SQL server. Boom! Also I tried adding double quote at the end of the URL where the Web App doesn’t respond with an Error. If SQL error is triggered for both single and double quote, then you can conclude that the system is vulnerable to Integer based SQL injection. Now that I’ve got to know the system is vulnerable and it run on Microsoft SQL server, I tried to inject it using MSSQL Error Based Injection.
How to inject into Library OPAC database :
After knowing the type of SQL server, I tried to find the name of the database. So I manipulated the URL with db_name at the end and the server responded me with an error which included the database name in it. The manipulated URL will look like
Since I was exploiting on Library machine, I was not able to take any screenshots. Instead, I clicked some pictures with my Smartphone Camera. AutoLibSA is the database name of our Library OPAC. Now that we know our database name, we can try injecting into the database for tables and further informations. Before that, I tried to find the running version of the SQL server using the following URL.
It responded an SQL error stating
Microsoft OLE DB Provider for SQL server Error ‘80040e07’
Syntax error converting the nvarchar value ‘Microsoft SQL Server 2000 – 8.00.760 (Intel X86) Dec 17 2002 14.22.05 copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service pack 2)’ to a column of data type smallint.
/jnlissue_main.asp, line 46
That’s it. Now we have got the version of the SQL server on which the OPAC running.
How to dump entire data in database using MSSQL Error Based Injection :
Here we come to an end by dumping all the tables, columns and data present in them using stacked queries. Stacked queries in SQL are used for executing multiple statements in a single query. The query for dumping list of tables and columns in OPAC look as follows
http://172.16.23.15/jnlissue_main.asp?jnl_code=(select+table_name%2b’::’%2bcolumn_name as t+from+AutoLibSA.columns FOR XML PATH(”))–
This above manipulated URL will dump all the names of Tables and Columns in the AutoLibSA database of our Library OPAC. After dumping tables and columns, I tried to dump the data in all the available tables and columns. While searching for a apt injection query, I found the following query which worked like a charm leaking all the data in the database.
Query credits : Security Idiots
Alright, Now came to an end. Now we own the entire database. We can find the login panel by bruteforce and deface the entire OPAC web page. Also, we can edit, add, delete or modify the contents of each and every book in the OPAC database. Creating a database and OPAC doesn’t matter as all the scripts are available online. What matters the most is how secure we keep them from attackers. For every new coding, there’s a new bug awaiting to be acknowledged.