Direito - Unip - DNA 2,03/08

Direito Unip - DNA 2,3/08 · às 8/22/2020

In the last article Learning Web Pentesting With DVWA Part 1: Installation, you were given a glimpse of SQL injection when we installed the DVWA app. In this article we will explain what we did at the end of that article and much more.

Lets start by defining what SQL injection is, OWASP defines it as: "A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands."

Which basically means that we can use a simple (vulnerable) input field in our web application to get information from the database of the server which hosts the web application. We can command and control (at certain times) the database of the web application or even the server.

In this article we are going to perform SQL injection attack on DVWA, so let's jump in. On the DVWA welcome page click on SQL Injection navigation link. We are presented with a page with an input field for User ID.

Now lets try to input a value like 1 in the input field. We can see a response from server telling us the firstname and surname of the user associated with User ID 1.

If we try to enter a user id which doesn't exist, we get no data back from the server. To determine whether an input field is vulnerable to SQL injection, we first start by sending a single quote (') as input. Which returns an SQL error.

We saw this in the previous article and we also talked about injection point in it. Before diving deeper into how this vulnerability can be exploited lets try to understand how this error might have occurred. Lets try to build the SQL query that the server might be trying to execute. Say the query looks something like this:

SELECT first_name, sur_name FROM users WHERE user_id = '1';

The 1 in this query is the value supplied by the user in the User ID input field. When we input a single quote in the User ID input field, the query looks like this:

SELECT first_name, sur_name FROM users WHERE user_id = ''';

The quotes around the input provided in the User ID input field are from the server side application code. The error is due to the extra single quote present in the query. Now if we specify a comment after the single quote like this:
'-- -
or
'#
we should get no error. Now our crafted query looks like this:

SELECT first_name, sur_name FROM users WHERE user_id = ''-- -';

or

SELECT first_name, sur_name FROM users WHERE user_id = ''#';

since everything after the # or -- - are commented out, the query will ignore the extra single quote added by the server side app and whatever comes after it and will not generate any error. However the query returns nothing because we specified nothing ('') as the user_id.

After knowing how things might be working on the server side, we will start to attack the application.
First of all we will try to determine the number of columns that the query outputs because if we try a query which will output the number of columns greater or smaller than what the original query outputs then our query is going to get an error. So we will first figure out the exact number of columns that the query outputs and we will do that with the help of order by sql statement like this:

' order by 1-- -

This MySQL server might execute the query as:

SELECT first_name, sur_name FROM users WHERE user_id = '' order by 1-- -';

you get the idea now.
if we don't get any error message, we will increase the number to 2 like this:

' order by 2-- -

still no error message, lets add another:

' order by 3-- -

and there we go we have an error message. Which tells us the number of columns that the server query selects is 2 because it erred out at 3.

Now lets use the union select SQL statement to get information about the database itself.

' union select null, version()-- -

You should first understand what a union select statement does and only then can you understand what we are doing here. You can read about it here.
We have used null as one column since we need to match the number of columns from the server query which is two. null will act as a dummy column here which will give no output and the second column which in our case here is the version() command will output the database version. Notice the output from the application, nothing is shown for First name since we specified null for it and the maria db version will be displayed in Surname.
Now lets check who the database user is using the user() function of mariadb:

' union select null, user()-- -

After clicking the submit button you should be able to see the user of the database in surname.

Now lets get some information about the databases in the database.
Lets determine the names of databases from INFORMATION_SCHEMA.SCHEMATA by entering following input in the User ID field:

' union select null, SCHEMA_NAME from INFORMATION_SCHEMA.SCHEMATA-- -

This lists two databases dvwa and information_schema. information_schema is the built in database. Lets look at the dvwa database.
Get table names for dvwa database from INFORMATION_SCHEMA.TABLES

' union select null, TABLE_NAME from INFORMATION_SCHEMA.TABLES-- -

It gives a huge number of tables that are present in dvwa database. But what we are really interested in is the users table as it is most likely to contain user passwords. But first we need to determine columns of that table and we will do that by querying INFORMATION_SCHEMA.COLUMNS like this:

' union select null, COLUMN_NAME from INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'users'-- -

We can see the password column in the output now lets get those passwords:

' union select user, password from users-- -

Of-course those are the hashes and not plain text passwords. You need to crack them.
Hope you learned something about SQL injection in this article. See you next time.

References:

1. SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
2. MySQL UNION: https://www.mysqltutorial.org/sql-union-mysql.aspx
3. Chapter 25 INFORMATION_SCHEMA Tables: https://dev.mysql.com/doc/refman/8.0/en/information-schema.html

More information

Direito Unip - DNA 2,3/08 · às 8/22/2020

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:

Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
Launch denial of Service attacks of various kinds:
- PostScript based infinite loops
- PostScript showpage redefinition
- Disable jobmedia with proprietary PJL
- Set the device to offline mode with PJL

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:

Web attacker:
- A malicious website that uses XSP
Network access:
- Via Jetdirect (port 9100/tcp)
- Via LPD (port 515/tcp)
- Via IPP (port 631/tcp)
Wireless access:
- Apple Air Print (enabled by default)
Cloud access:
- Google Cloud Print (disabled by default)
Physical access:
- Printing via USB cable or USB drive
- Potentially NFC printing (haven't tested)

Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…

Continue reading

Direito Unip - DNA 2,3/08 · às 8/22/2020

The OWASP Foundation would like to thank the OWASP Las Vegas Chapter Volunteers for taking the time out of their busy schedule to give back and volunteer to work the booth at BlackHat 2019. It was great meeting our Las Vegas OWASP members and working with Jorge, Carmi, Dave, and Nancy.
Also, take a moment to thank Global Board Members Martin Knobloch, Owen Pendlebury, and Gary Robinson for also working the booth and speaking with individuals and groups to answer questions on projects and suggestions on the use of our tools to address their work problems.
OWASP can not exist without support from our members.

Direito - Unip - DNA 2,03/08

sábado, 22 de agosto de 2020

Learning Web Pentesting With DVWA Part 2: SQL Injection

References:

More information

New Printers Vulnerable To Old Languages

35 year old bugs features

Now exploitable from the web

Conclusion: Christian Slater is right

Continue reading

Thank You To Volunteers And Board Members That Worked BlackHat Booth 2019

Related links

Arquivo do blog

direito - unip

Qual o melhor prof desse semestre