Forum Moderators: open

Message Too Old, No Replies

asp translation

         

lucy24

9:59 pm on Mar 8, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I don't speak asp, I'm pretty sure my server doesn't either, and the request was in any case blocked six ways from Sunday. Just curious: What were they trying to achieve?

With added line breaks and decoded percents, but otherwise verbatim:

107.150.33.138 - - [06/Mar/2015:01:41:06 -0800] "POST /upload.asp?action=save&type=IMAGE&style=style=standard'
and 1=3 union select
S_ID,S_Name,S_Dir,S_CSS,S_UploadDir,S_Width,S_Height,S_Memo,S_IsSys,S_FileExt,S_FlashExt, [S_ImageExt]+'|cer|aspx|cdx|asp|asaspp',S_MediaExt,S_FileSize,S_FlashSize,S_ImageSize,S_MediaSize,
S_StateFlag,S_DetectFromWord,S_InitMode,S_BaseUrl from ewebeditor_style where s_name='standard' and 'a'='a HTTP/1.1" 403 3250 "-" "Mozilla/5.0 (Auto Shell Spider)"

107.150.33.138 - - [06/Mar/2015:01:41:07 -0800] "POST /upload.asp?action=save&type=IMAGE&style=standard'
and 1=2 union select
S_ID,S_Name,S_Dir,S_EditorHeader,S_Body,S_Width,S_Height,S_Memo,S_IsSys,S_FileExt,S_FlashExt, [S_ImageExt]+'|cer|aspx|cdx|asp|asaspp',S_MediaExt,S_FileSize,S_FlashSize,S_ImageSize,S_MediaSize,
S_StateFlag,S_DetectFromWord from ewebeditor_style where s_name='standard' and'a'='a HTTP/1.1" 403 3250 "-" "Mozilla/5.0 (Auto Shell Spider)"


(StateFlag?! Huh what?)

wilderness

8:13 am on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



lucy,
FWIW, I've seen a few of these as well.
The POST catches a 403, as well as the UA.

I'm also curious as to what the encoding means?

keyplyr

8:35 am on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Looks like an injection attempt using the file (image) upload feature contained in POST. Almost anything can be wrapped up as an image file (the parameters: _FileSize, etc) The rest looks like detection, assuming this stuff works on an M$ server.

lucy24

9:02 am on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I'm also curious as to what the encoding means?

Which encoding? In the request as received, all non-alphanumerics were percent-encoded because they're part of a query string. It looked like this
:: shuffling papers ::
action=save&type=IMAGE&style=style=standard'%20%20and%201=3%20union%20select

and
%20%5BS_ImageExt%5D%2b'%7Ccer%7Caspx%7Ccdx%7Casp%7Casaspp'

and so on.

Is upload.asp part of some ubiquitous CMS package, in the same way that there are /wp-admin/ directories all over the place?

Almost anything can be wrapped up as an image file.

Eeuw, nasty. I did wonder if they ran out of room at the end with
S_DetectFromWord from ewebeditor_style where s_name='standard' and'a'='a

... or possibly the person who wrote the script hit Enter too soon.

keyplyr

9:10 am on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month




A web search for "Mozilla/5.0 (Auto Shell Spider)" does nor return anything so possibly this UA is spoofed.


Is upload.asp part of some ubiquitous CMS package, in the same way that there are /wp-admin/ directories all over the place?

I'm not a M$ guy, maybe dstiles could answer. I'm guessing that a default install of a CMS or Forum build for IIS (or other M$ server) would enable POST & PUT so members could upload files and post comments in discussions.

...wonder if they ran out of room at the end

Yeah, looks that way with the missing single quote at the end... but then again, I'm not a M$ guy so...

Aside: POST & PUT have always seemed like a huge security risk for M$, UNIX or otherwise. I have always stayed away from having a Forum or interactive Blog because of this; that and the time it would take to police it for SPAM & bad behavior.

lucy24

6:23 pm on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



POST & PUT have always seemed like a huge security risk

I think my host has something built-in about PUT, because I see the occasional request getting a 405. But it only kicks in when the request doesn't get an independent 403 from me. (Don't know if this means that the host-level rule executes after mine, or that a 403 trumps other 400-class responses.) Notably the "nyet.gif" botnet's PUT / GET pattern will get either a 403:403 or a 405:404.

I've personally blocked all POST requests except for the one or two specific pages (like contact form) that are meant to support POST.

Searching logs for PUT reveals a few clusters of
Microsoft Data Access Internet Publishing Provider DAV 1.1

from unrelated IPs. They were all 403, so I never noticed them before.

dstiles

10:04 pm on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I have no idea what upload.asp actually is - it could be an arbitrary page designed by anyone for any purpose - but my guess would be that it's a wrapper for something like Persits' file uploader.

Some sites use a standard upload package (there are a few available for MS, such as Persits) and that this is the common interface to it as copied from the package's documentation. Or it could be part of a CMS.

The reported "attack" could be someone trying out an intrusion based on an MS bug - which is fair, as I keep getting php attacks. I think it's easier to just attack everyone with everything rather than work out what type of OS and web server the site is running under. Botnets are cheap.

I offered an upload facility a few years ago on a couple of sites and a 3rd party uploader was essential as MS was (and maybe still is) sadly broken in that region.

PUT - I think any web site that allows that is either very confident or very misguided. I allow POST on my sites for contact and ordering type forms but with safeguards where possible (ie I always parse the input before allowing it anywhere near a database). PUT can be blocked at the server level, as can any verb. I generally permit only GET,POST,HEAD.

MS DAV should be blocked unless the site specifically allows user control - eg an internal web site. Well, that's my view. :)

keyplyr

11:34 pm on Mar 11, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month





I've personally blocked all POST requests except for the one or two specific pages (like contact form) that are meant to support POST.

My contact (and similar) forms all use the .php file extension & confined in a specific directory, then I block POST on all other files site-wide. This relates to an earlier discussion about the benefit (or not) of using .php page extensions. Likewise my server blocks PUT.

lucy24

12:24 am on Mar 20, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



:: bump ::

They came by again. That is, the identical UA and request pattern, unrelated IP. The new one is
103.27.124.0/22
(Hong Kong) which I saw no harm in blocking. The current batch totaled 110 requests, all for different URLs but-- this is the interesting part-- only two different query strings. Didn't check whether either one was identical to what I posted above, but clearly very similar. I recognized the StateFlag at once! Of those 110, 15 got blocked by mod_security; the others got a 404. (Why not 403? Because my POST-blocking is constrained to extensions that actually occur on my site, and the IP wasn't previously blocked.)

I thought it worthwhile to pull error logs and see why mod_security objected to only 15 of 110 requests (er, if it's an Apache server, shouldn't all requests for .asp be suspect?)
ModSecurity: Multipart parsing error: Multipart: Final boundary missing.

Unfortunately this leaves me no wiser, because what does "Final boundary" mean? It sounds like a description of the query string-- ending in
name = 'standard'_and'a' = 'a

-- but that would have applied to all requests.

In the course of looking this up, I also found that in the interval between the 110-request visit and my IP lockout, they came back with a further 206 requests. Blehh.

keyplyr

1:02 am on Mar 20, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Another reason I block China with prejudice :)

Pfui

3:20 am on Mar 20, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Ditto. And nowadays, even more so: Hong Kong's sunnyvision.com, ditto Taiwan's hinet.net, are seemingly chockablock with fckeditor attackers (...assaults from which include loads of upload.asp, upload.aspx and upload.php hits in the typical 70-plus HEAD 'sets').

keyplyr

6:36 am on Mar 20, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I even found it necessary to block all Korean ranges. I really didn't want to but I kept getting hit by the same bad actors from China.