Trinity First Place Winner
* "When Trinity Hacked the IRS D-Base..."
===========================================
By Ed Skoudis ( edskoudis@yahoo.com)
************************************************
* SOLUTION BY "Raul Siles" *
************************************************
1) What type of attack had Trinity really launched against the IRS?
The attack launched by Trinity against the IRS D-Base is known as "SQL
Injection" (sometimes also called "SQL Insertion"), altough analyzing the
details of the attack we could consider she used a "Stored Procedure
Injection" in input set 1 and a "pure SQL Injection" in input set 2 and 3.
What is a SQL Injection Vulnerability?
- User Controlled Data is placed into a SQL query without being validated
for correct format or embedded escape strings.
- This situation is used by an attacker to inject its own SQL sentences to
be able to execute its own desired actions against the database server.
- Affects the majority of applications which use a database backend and
don't force variable types.
- At least 50% of the large e-commerce sites and about 75% of the medium to
small sites are vulnerable. Numerous security-oriented sites have also been
found to be vulnerable.
- Improper validation in CFML, ASP, JSP, and PHP are the most frequent
causes. ASPs is involved in this case.
First of all lets analyze all the three user input sets used during the
attack from a general point of view. We will make a deepest research later
to answer the other 3 questions.
All three data sets, are composed of 3 elements: prefix, SQL query and
suffix.
1. Prefix.
- Prefix is used to accomodate the expected results returned by the "real"
application SQL query to the attacker injected data, just not to interfere
with the action the attacker wants to run with its own SQL query.
We can find 2 types of prefix in the 3 user input sets:
- SET 1: ";" colon symbol is used to indicate the end of the SQL
sentence and to allow appending more sentences, in this case, the execution
of a store procedure.
Example.- "...username='test';+exec..."
- SET 2 and 3: "UNION" - the statement UNION is used to append the
results of 2 different SELECT queries (it will be explained later).
Example.- "...username='test'+UNION+SELECT..."
2. SQL query:
It contains the data the attacker want to be executed in the database.
3. Suffix.
Suffix should nullify the rest of the query, just not to disturb the results
expected by the attacker.
During the 3 input data sets, the "End Query + Comment" symbols are used:
";--" in MS SQL Server.
Before answering the three questions related with the three user input data
sets, we need to describe the environment where the attack took place, that
is, the infraestructure used by the IRS D-Base.
We can see attacker, Trinity, is accesing system through an ASP (Active
Server Page) application, probably running in a Web Server (I will say it´s
an IIS ;-)) acting as a FrontEnd system to display information stored in a
BackEnd system, a MS SQL server database.
As we mentioned before, the method used is called SQL Injection, and to
avoid it, the ASP programmers should include input validation code in the
application.
Just say that probably, MS SQL Server could be considered the easiest system
for SQL Insertion.
The ASP code exploited could be similar to the following one:
<%
' DB Initialization Code and Variable Declarations
SQL = "SELECT userid FROM tblusers WHERE user = '"
& Request.Form("username" & "' AND pass = '"
& Request.Form("password") & "' "
Set RS = Conn.Execute(SQL);
' Code to check and display rows returned
%>
The query we are trying to exploit could be similar to the one presented in
the ASP code, so after receiving the attacker data input sets, that is,
using the "SQL Injection" method, we will execute SQL sentences similar to
the following ones:
- SET 1:
select x from y where
'username=xxxx';
exec master..xp_cmdshell "ping ...";--
...
- SET 2:
select x from y where
'username=xxxx'
UNION
select name, ...
from irs_dbase.sysobjects
where xtype = 'U';--
...
- SET 3:
select x from y where
'username=xxxx'
UNION
select phone_number
from irs_dbase.account
where taxpayer_lastname = 'Anderson';--
...
2) What was the real purpose of the first set of user input, and how does it
function?
*************************
First set of user input:
*************************
"irsfile.asp?username='test';+exec+master..xp_cmdshell+'ping+209.171.43.28';
--"
Lets analyze one by one all the components of this user input:
First of all, the ASP page used to access the IRS database, belonging to the
Web application that allow this HTTP access to the IRS information is called
"irsfile.asp".
The "?" symbol is used to pass parameters to the application, the ASP code.
The code expects "username" as one of its parameters.
When using the "username='test'" sentence, probably the attacker is trying
to make sure that the first query, the one that the web application's
developer intended to be executed, returns no records, cause user "test"
doesn´t exists. This will allow the attacker not getting information that
could disturb its own injected sentence.
The colon sign (;) was used to separate 2 different SQL sentences, the one
associated to the user "test" and the "xp-cmdshell" execution.
The MicroSfot SQL Server database contains a extended (xp) stored procedure
to run external programs, called "xp_cmdshell". "xp_cmdshell" executes a
given command string as an operating-system command shell and returns any
output as rows of text [1].
- Example of usage to execute a directory listing:
EXEC master..xp_cmdshell 'dir *.*'
Extended stored procedures are essentially compiled Dynamic Link Libraries
(DLLs) that use a SQL Server specific calling convention to run exported
functions. They allow SQL Server applications to have access to the full
power of C/C++, and are an extremely useful feature. A number of extended
stored procedures are built in to SQL Server, and perform various functions
such as sending email and interacting with the registry.
We could say "master..xp_cmdshell" is the holy grail of stored procedures.
It takes a single argument, which is the command that you want to be
executed at SQL Server's user level.
This procedure resides in the "master" database, that is the reason why the
word "master" appears before the procedure name in the user input.
An out-of-the-box install of Microsoft SQL Server has over one thousand
stored procedures. If you can get SQL injection working on a web application
that uses SQL Server as it's backend, you can use these stored procedures to
pull off some remarkable feats.
The first thing you should know about stored procedure injection is that
there is a good chance that you will not see the stored procedure's output
in the same way you get values back with regular injection. Depending on
what you're
trying to accomplish, you may not need to get data back at all. You can find
other means of getting your data returned to you. This seems what Trinity
tried to do.
Lets say that due to the fact that the attacker interact with the IRS D-Base
through a Web aplication, all the input is introduced through the URL. For
this reason, attacker need to use the "+" symbol to represent a blank space.
This is the associated character for blank spaces used in URLs under the
HTTP protocol.
The stored procedure was invoked from the application URL and was used to
executed the "ping" command to verify the
availablity of a system: 209.171.43.28.
With the idea of seeing if the store procedure injection works, the attacker
can use its own IP address, so just running a sniffer in its system, can
verify if the ICMP echo request packets are arriving to it. If so, the ping
command has been executed successfully ;-). This check will only work if
having outbound network access in the databse server. Probably, that`s what
Trinity tried with this first user input.
- Additional information about the checked IP address:
Just to complement the explanation about this attack, I considered that some
additional information about the IP address used by Trinity will be
interesting.
The IP address can be translated to:
Name: ip28-43-171-209.toro1.na.psigh.com
Address: 209.171.43.28
and correspond to a domain name ("psigh.com") registered by France Telecom:
Domain Name: PSIGH.COM
Registrar: TRANSPAC
Whois Server: whois.oleane.net
Referral URL: http://www.oleane.net
Name Server: PRI3.DNS.PSINET.NL
Name Server: PRI2.DNS.PSINET.NL
Name Server: PRI1.DNS.PSINET.NL
Status: ACTIVE
Updated Date: 03-feb-2003
Creation Date: 04-feb-2000
Expiration Date: 04-feb-2004
The host belongs to the following company: PSIGH.COM. And here it is the
information associated to this domain in the WHOIS databases.
Date de creation : 04/02/2000
Date d'expiration : 04/02/2004
SOCIETE
Nom : PSINET NETHERLANDS
Adresse : Sirwisdreef 36
Ville : HOOFDDORF
Code Postal : 2132WT
Pays : FR
Contact Administratif : EH4-OLEANE, Emile HUSMANN
Contact Technique : EH4-OLEANE, Emile HUSMANN
Billing Contact : OH1-OLEANE
Nom des Serveurs : PRI1.DNS.PSINET.NL, PRI2.DNS.PSINET.NL,
pri3.dns.psinet.nl
CONTACT ADMINISTRATIF
NIC-Handle : EH4-OLEANE
Contact: Emile HUSMANN
Nom Société : PSINET NETHERLANDS
Adresse Société : Sirwisdreef 36
Ville : HOOFDDORF
Code Postal : 2132WT
Pays : FR
Téléphone : +31 235699877
Fax : +31 235699801
E-mail : husmanne@hc.psinet.nl
CONTACT TECHNIQUE
NIC-Handle : EH4-OLEANE
Contact: Emile HUSMANN
Nom Société : PSINET NETHERLANDS
Adresse Société : Sirwisdreef 36
Ville : HOOFDDORF
Code Postal : 2132WT
Pays : FR
Téléphone : +31 235699877
Fax : +31 235699801
E-mail : husmanne@hc.psinet.nl
LISTE DES SERVEURS DE NOMS
Serveur Primaire :
PRI1.DNS.PSINET.NL Adresse IP :
154.15.249.166
Serveur Secondaire :
PRI2.DNS.PSINET.NL Adresse IP :
154.15.249.170
Serveur Secondaire :
pri3.dns.psinet.nl Adresse IP :
154.15.249.174
Serveur Secondaire :
Adresse IP :
It seems the IP address belongs to an European ISP, probably the one that
Trinity used to launch the attack, or an intermediate system involved in the
attack.
--- Author comment: ----
Additionally, I will have a question about this IP address and the
information around it:
"Do this information belong to The Matrix or to the RealWorld? ;-)"
Before giving a response, take into account the date this domain was
registered (04-feb-2000) and the year when the movie "The Matrix" was
released: 1999 ;-)
------------------------
As mentioned previously, the "--" (double hyphen) comment indicator is used
to block out the rest of the intended SQL sentence. It is neccesary to do
so, cause sometimes may be additional SQL code, for example, WHERE
conditions that will de added to the query after your injection string if
"--" is not used.
Just to conclude with the first answer, lets analyze some elements involved
in the permissions used during the execution of the stored procedure:
By default, the "xp_cmdshell" store procedure can only be run by members of
the "sysadmin" group. So, it depends on the username used to run the queries
against the database from the Web application (ASPs). Sometimes "sa" is used
(the
System Administration account), which belongs to the "sysadmin" group.
When a login that's in the sysadmin role executes "xp_cmdshell", it runs
under the windows account that SQL Server is running under. When you grant
the right to run "xp_cmdshell" to a login that is not in the sysadmin role,
you must set the account that is used to run "xp_cmdshell" and any programs
that it invokes. This is done with the extended stored procedure
"xp_sqlagent_proxy_account" authorization for using this stored procedure
[2]. If the proxy account is not available, "xp_cmdshell" will fail.
By default, only members of the sysadmin fixed server role can execute this
extended stored procedure. However, permissions can be granted to other
users to execute stored procedures and extended stored procedures, using the
proxy account.
You can find out the current permissions by running 'sp_helprotect' stored
procedure, which will tell, who else, apart from members in sysadmin fixed
server role, has execute permission on this.
If an attacker can access the SQL server as a sysadmin, it can execute OS
commands with the security context of the
MS SQL Server service. Since SQL server is normally running as either the
local 'system' account, or a 'domain user' account, an attacker can do a
great deal of harm.
- NOTE:
--------
There was a time when SQL Server performed no permission checking on
temporary stored procedures. The reason for this being that temporary stored
procedures should only be accessible to the user that created it so of
course that user should have the permission to access it. This doesn't take
into account however the fact that the temporary stored procedure may be
accessing something the user doesn't have access to:
create proc #mycmd as
exec master..xp_cmdshell 'dir > c:\temp-stored-proc-results.txt'
Microsoft made published a patch for this issue. Please see both links for
more details:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
bulletin/MS00-048.asp
http://www.nextgenss.com/advisories/mssql-esppu.txt
3) What was the real purpose of the second user input, and how does it
function?
*******************
Second user input:
*******************
"irsfile.asp?username='test'+UNION+SELECT+name,1,'1',1,'1'+FROM+irs_dbase..s
ysobjects+WHERE+xtype+=+'U';--"
This second input command again uses the same ASP page, and the same technic
associated to the first SQL query prefix and suffix.
If Trinity receiveed the ping response, she had injection working, so she
had to decide what tables and fields she wants to retrieve information from.
In SQL Server, there are a number of tables which are usually readable by
all users which store basic information about the structure and contents of
the database. These tables are prefixed with 'sys' and exist both in the
master database, which has additional information about the data server, and
in each database.
With SQL Server, you can easily get all of the table and column names in the
database. The key is to be able to access the system tables that contain the
table and column names. In SQL Server, they are called 'sysobjects' and
'syscolumns', respectively.
Trinity referenced the "sysobjects" table defined in the IRS database,
"irs_dbase".
The SQL sentence injected, "select name from sysobjects where type = 'U'"
was used to get a list of user tables in SQL Server, regardless of access
level. So it provides the table name to be queried, that is, the table that
is used in the third set of user input to get the desired phone number [3].
This will return the names of all of the user-defined (that's what xtype =
'U' does) tables in the database. Once you find one that looks interesting
(Trinity found the "account" table, see next user input set), you can get
the names of the fields in that table with an injection query similar to the
one used in the third input set.
The UNION statement is used to be able to append data ripped form other SQL
sentences (the one defined in the ASP code).
The fields indicated in the SELECT sentence injected are:
- "name": This will allow the attacker to get the tables names that will be
used later, in the third set of user input.
- All the other fields: 1, '1' ... are used to match different fields
obtained from the first SELECT sentence, the one specified in the ASP code,
and they are needed to be able to run the UNION statement between two
SELECTs.
So, the UNION action will fill up the field obtained from the UNION
operation with the introduced values: 1 or '1'.
Based on the field type, you need to specify a number or a string, 1 or '1'.
To know the number of fields you need to add to your attacking query, you
need to find out how many columns are requested in the legitimate query.
This portion of the process is known as "column number mismatch and
guessing".
The legitimate SELECT and the injected UNION SELECT need to have an equal
number of columns in their WHERE clauses. In this case, they both need five.
Not only that, but their column types need to match as well. If first field
is a string, then the corresponding field in your injection string needs to
be a string as well.
Some servers, such as Oracle, are very strict about this. Others are more
lenient and allow you to use any data type that can do implicit conversion
to the correct data type. For example, in SQL Server, putting numeric data
in a varchar's place is okay, because numbers can be converted to strings
implicitly. Putting text in a smallint column,
however, is illegal because text cannot be converted to an integer. Because
numeric types often convert to strings easily but not vice versa, the usage
of numeric values by default is recommended.
A trial and error process is the key here to get the right number of
columns. The injection query was modified to fit whatever circumstances she
found herself in, adding the 1 and '1' fields.
4) What was the real purpose of the third user input, and how does it
function?
***********************************
Third and final set of user input:
***********************************
"irsfile.asp?username='Trinity'+UNION+SELECT+phone_number+FROM+irs_dbase..ac
count+WHERE+taxpayer_lastname+=+'Anderson';--"
So finally Trinity was interested in getting Mr. Thomas Anderson phone
number, that is, Neo phone number inside The Matrix as a computer programmer
;-). She tried to extract this information from the IRS D-Base, "Internal
Revenue Service" belonging to the Department of Threasury
(http://www.irs.gov/).
Again she used the prefix to accomodate the ASP SQL sentence to her own
injected SQL query, but this time she probably wanted to leave a signature
of her actions, so she substituted "test" by her own nickname, "Trinity"
(another non-existent user in the IRS database).
She used the same UNION process described before, but this time she was just
interested in querying the databse to be able to get specific information
she was interested in, Neo phone number.
Again she referenced the IRS database, "irs_dbase", but using the table name
learnt from its second input, the "account" table. Then, she just reduce the
search domain through the WHERE clause specifying the person she was looking
for, "Anderson", using to do it a field defined in the "account" table,
"taxpayer_lastname".
************************
- REFERENCED RESOURCES:
************************
- [1]: "xp_cmdshell" description:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_
xp_aa-sz_4jxo.asp
- [2]: "SQL Server 2000 SP3 and xp_cmdshell Woes" - stored procedure
permissions:
http://databasejournal.com/features/mssql/article.php/1580041
- [3]: "SQL Server 2000 Security From the Attacker's Perspective":
http://www.blackhat.com/presentations/bh-usa-01/ChipAndrews/bh-usa-01-Andrew
s-SQL.ppt
or
http://www.blackhat.com/presentations/win-usa-01/Andrews/win-01-andrews.ppt
***********************
- ADITIONAL RESOURCES:
***********************
- Threat Profiling Microsoft SQL Server:
http://www.nextgenss.com/papers/tp-SQL2000.pdf
- SQL Injection: (the one studied by Trinity before attacking IRS ;-))
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
- Attacking and defending MS SQL Server:
http://www.sqlsecurity.com/uploads/232_spop_12.doc
- SQL Injection Modes of Attack, Defense, and Why It Matters:
http://www.governmentsecurity.org/articles/SQLInjectionModesofAttackDefencea
ndWhyItMatters.php
http://www.sans.org/rr/appsec/SQL_injection.php
- Advanced SQL Injection:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
- SQL Insertion Techniques:
http://www.digitaloffense.net/confs/bootcamp02/sql.ppt
- Practical associated to GCIH v.2.0:
http://www.palecrow.com/content/GCIH/Matt_Borland_GCIH.html
*******************
- ADDITIONAL NOTE:
*******************
It is possible to use this technique taking advantage of any error message
that reveals information about the environment, or the database. A list of
the format strings for standard error messages can be obtained by
running the following SQL query:
"select * from master..sysmessages"
Examining this list will reveal some interesting messages that could be used
to select the proper SQL sentences.
----
Raúl Siles
===========================================
By Ed Skoudis ( edskoudis@yahoo.com)
************************************************
* SOLUTION BY "Raul Siles" *
************************************************
1) What type of attack had Trinity really launched against the IRS?
The attack launched by Trinity against the IRS D-Base is known as "SQL
Injection" (sometimes also called "SQL Insertion"), altough analyzing the
details of the attack we could consider she used a "Stored Procedure
Injection" in input set 1 and a "pure SQL Injection" in input set 2 and 3.
What is a SQL Injection Vulnerability?
- User Controlled Data is placed into a SQL query without being validated
for correct format or embedded escape strings.
- This situation is used by an attacker to inject its own SQL sentences to
be able to execute its own desired actions against the database server.
- Affects the majority of applications which use a database backend and
don't force variable types.
- At least 50% of the large e-commerce sites and about 75% of the medium to
small sites are vulnerable. Numerous security-oriented sites have also been
found to be vulnerable.
- Improper validation in CFML, ASP, JSP, and PHP are the most frequent
causes. ASPs is involved in this case.
First of all lets analyze all the three user input sets used during the
attack from a general point of view. We will make a deepest research later
to answer the other 3 questions.
All three data sets, are composed of 3 elements: prefix, SQL query and
suffix.
1. Prefix.
- Prefix is used to accomodate the expected results returned by the "real"
application SQL query to the attacker injected data, just not to interfere
with the action the attacker wants to run with its own SQL query.
We can find 2 types of prefix in the 3 user input sets:
- SET 1: ";" colon symbol is used to indicate the end of the SQL
sentence and to allow appending more sentences, in this case, the execution
of a store procedure.
Example.- "...username='test';+exec..."
- SET 2 and 3: "UNION" - the statement UNION is used to append the
results of 2 different SELECT queries (it will be explained later).
Example.- "...username='test'+UNION+SELECT..."
2. SQL query:
It contains the data the attacker want to be executed in the database.
3. Suffix.
Suffix should nullify the rest of the query, just not to disturb the results
expected by the attacker.
During the 3 input data sets, the "End Query + Comment" symbols are used:
";--" in MS SQL Server.
Before answering the three questions related with the three user input data
sets, we need to describe the environment where the attack took place, that
is, the infraestructure used by the IRS D-Base.
We can see attacker, Trinity, is accesing system through an ASP (Active
Server Page) application, probably running in a Web Server (I will say it´s
an IIS ;-)) acting as a FrontEnd system to display information stored in a
BackEnd system, a MS SQL server database.
As we mentioned before, the method used is called SQL Injection, and to
avoid it, the ASP programmers should include input validation code in the
application.
Just say that probably, MS SQL Server could be considered the easiest system
for SQL Insertion.
The ASP code exploited could be similar to the following one:
<%
' DB Initialization Code and Variable Declarations
SQL = "SELECT userid FROM tblusers WHERE user = '"
& Request.Form("username" & "' AND pass = '"
& Request.Form("password") & "' "
Set RS = Conn.Execute(SQL);
' Code to check and display rows returned
%>
The query we are trying to exploit could be similar to the one presented in
the ASP code, so after receiving the attacker data input sets, that is,
using the "SQL Injection" method, we will execute SQL sentences similar to
the following ones:
- SET 1:
select x from y where
'username=xxxx';
exec master..xp_cmdshell "ping ...";--
...
- SET 2:
select x from y where
'username=xxxx'
UNION
select name, ...
from irs_dbase.sysobjects
where xtype = 'U';--
...
- SET 3:
select x from y where
'username=xxxx'
UNION
select phone_number
from irs_dbase.account
where taxpayer_lastname = 'Anderson';--
...
2) What was the real purpose of the first set of user input, and how does it
function?
*************************
First set of user input:
*************************
"irsfile.asp?username='test';+exec+master..xp_cmdshell+'ping+209.171.43.28';
--"
Lets analyze one by one all the components of this user input:
First of all, the ASP page used to access the IRS database, belonging to the
Web application that allow this HTTP access to the IRS information is called
"irsfile.asp".
The "?" symbol is used to pass parameters to the application, the ASP code.
The code expects "username" as one of its parameters.
When using the "username='test'" sentence, probably the attacker is trying
to make sure that the first query, the one that the web application's
developer intended to be executed, returns no records, cause user "test"
doesn´t exists. This will allow the attacker not getting information that
could disturb its own injected sentence.
The colon sign (;) was used to separate 2 different SQL sentences, the one
associated to the user "test" and the "xp-cmdshell" execution.
The MicroSfot SQL Server database contains a extended (xp) stored procedure
to run external programs, called "xp_cmdshell". "xp_cmdshell" executes a
given command string as an operating-system command shell and returns any
output as rows of text [1].
- Example of usage to execute a directory listing:
EXEC master..xp_cmdshell 'dir *.*'
Extended stored procedures are essentially compiled Dynamic Link Libraries
(DLLs) that use a SQL Server specific calling convention to run exported
functions. They allow SQL Server applications to have access to the full
power of C/C++, and are an extremely useful feature. A number of extended
stored procedures are built in to SQL Server, and perform various functions
such as sending email and interacting with the registry.
We could say "master..xp_cmdshell" is the holy grail of stored procedures.
It takes a single argument, which is the command that you want to be
executed at SQL Server's user level.
This procedure resides in the "master" database, that is the reason why the
word "master" appears before the procedure name in the user input.
An out-of-the-box install of Microsoft SQL Server has over one thousand
stored procedures. If you can get SQL injection working on a web application
that uses SQL Server as it's backend, you can use these stored procedures to
pull off some remarkable feats.
The first thing you should know about stored procedure injection is that
there is a good chance that you will not see the stored procedure's output
in the same way you get values back with regular injection. Depending on
what you're
trying to accomplish, you may not need to get data back at all. You can find
other means of getting your data returned to you. This seems what Trinity
tried to do.
Lets say that due to the fact that the attacker interact with the IRS D-Base
through a Web aplication, all the input is introduced through the URL. For
this reason, attacker need to use the "+" symbol to represent a blank space.
This is the associated character for blank spaces used in URLs under the
HTTP protocol.
The stored procedure was invoked from the application URL and was used to
executed the "ping" command to verify the
availablity of a system: 209.171.43.28.
With the idea of seeing if the store procedure injection works, the attacker
can use its own IP address, so just running a sniffer in its system, can
verify if the ICMP echo request packets are arriving to it. If so, the ping
command has been executed successfully ;-). This check will only work if
having outbound network access in the databse server. Probably, that`s what
Trinity tried with this first user input.
- Additional information about the checked IP address:
Just to complement the explanation about this attack, I considered that some
additional information about the IP address used by Trinity will be
interesting.
The IP address can be translated to:
Name: ip28-43-171-209.toro1.na.psigh.com
Address: 209.171.43.28
and correspond to a domain name ("psigh.com") registered by France Telecom:
Domain Name: PSIGH.COM
Registrar: TRANSPAC
Whois Server: whois.oleane.net
Referral URL: http://www.oleane.net
Name Server: PRI3.DNS.PSINET.NL
Name Server: PRI2.DNS.PSINET.NL
Name Server: PRI1.DNS.PSINET.NL
Status: ACTIVE
Updated Date: 03-feb-2003
Creation Date: 04-feb-2000
Expiration Date: 04-feb-2004
The host belongs to the following company: PSIGH.COM. And here it is the
information associated to this domain in the WHOIS databases.
Date de creation : 04/02/2000
Date d'expiration : 04/02/2004
SOCIETE
Nom : PSINET NETHERLANDS
Adresse : Sirwisdreef 36
Ville : HOOFDDORF
Code Postal : 2132WT
Pays : FR
Contact Administratif : EH4-OLEANE, Emile HUSMANN
Contact Technique : EH4-OLEANE, Emile HUSMANN
Billing Contact : OH1-OLEANE
Nom des Serveurs : PRI1.DNS.PSINET.NL, PRI2.DNS.PSINET.NL,
pri3.dns.psinet.nl
CONTACT ADMINISTRATIF
NIC-Handle : EH4-OLEANE
Contact: Emile HUSMANN
Nom Société : PSINET NETHERLANDS
Adresse Société : Sirwisdreef 36
Ville : HOOFDDORF
Code Postal : 2132WT
Pays : FR
Téléphone : +31 235699877
Fax : +31 235699801
E-mail : husmanne@hc.psinet.nl
CONTACT TECHNIQUE
NIC-Handle : EH4-OLEANE
Contact: Emile HUSMANN
Nom Société : PSINET NETHERLANDS
Adresse Société : Sirwisdreef 36
Ville : HOOFDDORF
Code Postal : 2132WT
Pays : FR
Téléphone : +31 235699877
Fax : +31 235699801
E-mail : husmanne@hc.psinet.nl
LISTE DES SERVEURS DE NOMS
Serveur Primaire :
PRI1.DNS.PSINET.NL Adresse IP :
154.15.249.166
Serveur Secondaire :
PRI2.DNS.PSINET.NL Adresse IP :
154.15.249.170
Serveur Secondaire :
pri3.dns.psinet.nl Adresse IP :
154.15.249.174
Serveur Secondaire :
Adresse IP :
It seems the IP address belongs to an European ISP, probably the one that
Trinity used to launch the attack, or an intermediate system involved in the
attack.
--- Author comment: ----
Additionally, I will have a question about this IP address and the
information around it:
"Do this information belong to The Matrix or to the RealWorld? ;-)"
Before giving a response, take into account the date this domain was
registered (04-feb-2000) and the year when the movie "The Matrix" was
released: 1999 ;-)
------------------------
As mentioned previously, the "--" (double hyphen) comment indicator is used
to block out the rest of the intended SQL sentence. It is neccesary to do
so, cause sometimes may be additional SQL code, for example, WHERE
conditions that will de added to the query after your injection string if
"--" is not used.
Just to conclude with the first answer, lets analyze some elements involved
in the permissions used during the execution of the stored procedure:
By default, the "xp_cmdshell" store procedure can only be run by members of
the "sysadmin" group. So, it depends on the username used to run the queries
against the database from the Web application (ASPs). Sometimes "sa" is used
(the
System Administration account), which belongs to the "sysadmin" group.
When a login that's in the sysadmin role executes "xp_cmdshell", it runs
under the windows account that SQL Server is running under. When you grant
the right to run "xp_cmdshell" to a login that is not in the sysadmin role,
you must set the account that is used to run "xp_cmdshell" and any programs
that it invokes. This is done with the extended stored procedure
"xp_sqlagent_proxy_account" authorization for using this stored procedure
[2]. If the proxy account is not available, "xp_cmdshell" will fail.
By default, only members of the sysadmin fixed server role can execute this
extended stored procedure. However, permissions can be granted to other
users to execute stored procedures and extended stored procedures, using the
proxy account.
You can find out the current permissions by running 'sp_helprotect' stored
procedure, which will tell, who else, apart from members in sysadmin fixed
server role, has execute permission on this.
If an attacker can access the SQL server as a sysadmin, it can execute OS
commands with the security context of the
MS SQL Server service. Since SQL server is normally running as either the
local 'system' account, or a 'domain user' account, an attacker can do a
great deal of harm.
- NOTE:
--------
There was a time when SQL Server performed no permission checking on
temporary stored procedures. The reason for this being that temporary stored
procedures should only be accessible to the user that created it so of
course that user should have the permission to access it. This doesn't take
into account however the fact that the temporary stored procedure may be
accessing something the user doesn't have access to:
create proc #mycmd as
exec master..xp_cmdshell 'dir > c:\temp-stored-proc-results.txt'
Microsoft made published a patch for this issue. Please see both links for
more details:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
bulletin/MS00-048.asp
http://www.nextgenss.com/advisories/mssql-esppu.txt
3) What was the real purpose of the second user input, and how does it
function?
*******************
Second user input:
*******************
"irsfile.asp?username='test'+UNION+SELECT+name,1,'1',1,'1'+FROM+irs_dbase..s
ysobjects+WHERE+xtype+=+'U';--"
This second input command again uses the same ASP page, and the same technic
associated to the first SQL query prefix and suffix.
If Trinity receiveed the ping response, she had injection working, so she
had to decide what tables and fields she wants to retrieve information from.
In SQL Server, there are a number of tables which are usually readable by
all users which store basic information about the structure and contents of
the database. These tables are prefixed with 'sys' and exist both in the
master database, which has additional information about the data server, and
in each database.
With SQL Server, you can easily get all of the table and column names in the
database. The key is to be able to access the system tables that contain the
table and column names. In SQL Server, they are called 'sysobjects' and
'syscolumns', respectively.
Trinity referenced the "sysobjects" table defined in the IRS database,
"irs_dbase".
The SQL sentence injected, "select name from sysobjects where type = 'U'"
was used to get a list of user tables in SQL Server, regardless of access
level. So it provides the table name to be queried, that is, the table that
is used in the third set of user input to get the desired phone number [3].
This will return the names of all of the user-defined (that's what xtype =
'U' does) tables in the database. Once you find one that looks interesting
(Trinity found the "account" table, see next user input set), you can get
the names of the fields in that table with an injection query similar to the
one used in the third input set.
The UNION statement is used to be able to append data ripped form other SQL
sentences (the one defined in the ASP code).
The fields indicated in the SELECT sentence injected are:
- "name": This will allow the attacker to get the tables names that will be
used later, in the third set of user input.
- All the other fields: 1, '1' ... are used to match different fields
obtained from the first SELECT sentence, the one specified in the ASP code,
and they are needed to be able to run the UNION statement between two
SELECTs.
So, the UNION action will fill up the field obtained from the UNION
operation with the introduced values: 1 or '1'.
Based on the field type, you need to specify a number or a string, 1 or '1'.
To know the number of fields you need to add to your attacking query, you
need to find out how many columns are requested in the legitimate query.
This portion of the process is known as "column number mismatch and
guessing".
The legitimate SELECT and the injected UNION SELECT need to have an equal
number of columns in their WHERE clauses. In this case, they both need five.
Not only that, but their column types need to match as well. If first field
is a string, then the corresponding field in your injection string needs to
be a string as well.
Some servers, such as Oracle, are very strict about this. Others are more
lenient and allow you to use any data type that can do implicit conversion
to the correct data type. For example, in SQL Server, putting numeric data
in a varchar's place is okay, because numbers can be converted to strings
implicitly. Putting text in a smallint column,
however, is illegal because text cannot be converted to an integer. Because
numeric types often convert to strings easily but not vice versa, the usage
of numeric values by default is recommended.
A trial and error process is the key here to get the right number of
columns. The injection query was modified to fit whatever circumstances she
found herself in, adding the 1 and '1' fields.
4) What was the real purpose of the third user input, and how does it
function?
***********************************
Third and final set of user input:
***********************************
"irsfile.asp?username='Trinity'+UNION+SELECT+phone_number+FROM+irs_dbase..ac
count+WHERE+taxpayer_lastname+=+'Anderson';--"
So finally Trinity was interested in getting Mr. Thomas Anderson phone
number, that is, Neo phone number inside The Matrix as a computer programmer
;-). She tried to extract this information from the IRS D-Base, "Internal
Revenue Service" belonging to the Department of Threasury
(http://www.irs.gov/).
Again she used the prefix to accomodate the ASP SQL sentence to her own
injected SQL query, but this time she probably wanted to leave a signature
of her actions, so she substituted "test" by her own nickname, "Trinity"
(another non-existent user in the IRS database).
She used the same UNION process described before, but this time she was just
interested in querying the databse to be able to get specific information
she was interested in, Neo phone number.
Again she referenced the IRS database, "irs_dbase", but using the table name
learnt from its second input, the "account" table. Then, she just reduce the
search domain through the WHERE clause specifying the person she was looking
for, "Anderson", using to do it a field defined in the "account" table,
"taxpayer_lastname".
************************
- REFERENCED RESOURCES:
************************
- [1]: "xp_cmdshell" description:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_
xp_aa-sz_4jxo.asp
- [2]: "SQL Server 2000 SP3 and xp_cmdshell Woes" - stored procedure
permissions:
http://databasejournal.com/features/mssql/article.php/1580041
- [3]: "SQL Server 2000 Security From the Attacker's Perspective":
http://www.blackhat.com/presentations/bh-usa-01/ChipAndrews/bh-usa-01-Andrew
s-SQL.ppt
or
http://www.blackhat.com/presentations/win-usa-01/Andrews/win-01-andrews.ppt
***********************
- ADITIONAL RESOURCES:
***********************
- Threat Profiling Microsoft SQL Server:
http://www.nextgenss.com/papers/tp-SQL2000.pdf
- SQL Injection: (the one studied by Trinity before attacking IRS ;-))
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
- Attacking and defending MS SQL Server:
http://www.sqlsecurity.com/uploads/232_spop_12.doc
- SQL Injection Modes of Attack, Defense, and Why It Matters:
http://www.governmentsecurity.org/articles/SQLInjectionModesofAttackDefencea
ndWhyItMatters.php
http://www.sans.org/rr/appsec/SQL_injection.php
- Advanced SQL Injection:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
- SQL Insertion Techniques:
http://www.digitaloffense.net/confs/bootcamp02/sql.ppt
- Practical associated to GCIH v.2.0:
http://www.palecrow.com/content/GCIH/Matt_Borland_GCIH.html
*******************
- ADDITIONAL NOTE:
*******************
It is possible to use this technique taking advantage of any error message
that reveals information about the environment, or the database. A list of
the format strings for standard error messages can be obtained by
running the following SQL query:
"select * from master..sysmessages"
Examining this list will reveal some interesting messages that could be used
to select the proper SQL sentences.
----
Raúl Siles
111111111 X 111111111 = ;-)
