Strange UA

[wilderness]

looking for CGI vulnerabilities.

"() { :;}; echo 'H0m3l4b1t: YES'"

[dstiles]

Looks like an attempt at the linux bash bug, which anyone with any gumption should have updated months ago. Linux is easy to maintain and, unlike windows, does not usually require a reboot. :)

Oddly, given that, many linux web servers remain unpatched because their "owners" just load them up and let them go. :(

[lucy24]

Is that the actual, literal UA string?! I once met one that began with a literal equals sign. (Manual type-in from posted robot code? Oops, wrong thread.) And that's why our htaccess files get fatter and fatter. We add strange UAs when we see them, and never get around to checking whether it ever came back.

You may remember an earlier thread where we were trying to consolidate rules for a whole clutch of weird UA configurations. They all came down to "something hinky about the punctuation" ... but try reducing that to a Regular Expression!

[wilderness]

213.180.72.zz - - [21/Nov/2014:07:38:36 -0700] "GET /cgi-bin/test.cgi HTTP/1.1" 403 605 "-" "() { :;}; echo 'H0m3l4b1t: YES'"

[wilderness]

They all came down to "something hinky about the punctuation" ... but try reducing that to a Regular Expression!

Sheesh lucy,
You've gone and busted the pedestal ;)

How about YES$
or 'contains' echo
or 'contains \(\)

[lucy24]

Yes, I think \(\) was part of the generic rule the previous time around. But that's what I meant: You can't just tell the server "If the punctuation is weird, throw a 403 at 'em".

Edit: Come to think of it, I can probably extract some useful patterns from the tests I used to run while checking for typos or scannos in ebooks. Buncha stuff involving duplicate punctuation, or missing space after punctuation, or extraneous space before punctuation, or....

[roshaoar]

Had the same a couple of days ago, I went for the echo option
74.208.209.zz - - [19/Nov/2014:18:15:44 +0000] "GET /cgi-sys/entropysearch.cgi HTTP/1.0" 404 30339 "-" "() { :;}; echo 'H0m3l4b1t: YES'"

[keyplyr]

Requests containing that UA string produce a response code of 418 at my server config without me having to take any action.

[lucy24]

a response code of 418 at my server config

Are we on the same host? ;) A while back, mine changed their mod_security response to return a 418. This makes it very easy to identify the source of a lockout: 403 is me, 418 is the host.

[keyplyr]

Are we on the same host?

Yes, the site I'm commenting about is hosted where yours are. Can I borrow a cup of sugar?

This makes it very easy to identify the source of a lockout: 403 is me, 418 is the host.

Well not in this case, at least not from testing this particular UA.

Blocking "\(\)" or "echo" via mod_rewrite still produces a 418. So the server is doing this prior to implementing my htaccess directives. That's a good thing IMO.

[dstiles]

The very last traps in my system are:

^[a-zA-Z0-9 ,\./]

and

^[0-9]|[ $%^;/_\+\-\(\)\*]+

(add any other symbols you like).

These are tested AFTER legit browsers and bots have been approved, especially necessary for the first one which would otherwise reject Mozilla. :)

[lucy24]

The very last traps in my system are:

I can't figure out what would not be caught by these two rules :) Are they both applied to the User-Agent?

You could look for
^[MO]
^M[^o]
^Mo[^bz]
and then do supplementary tests for the ones that do claim to be Mozilla, Opera or MobileSafari.

[ $%^;/_\+\-\(\)\*]+

What comes after the plus sign? (Incidentally, most of that stuff doesn't need to be escaped inside grouping brackets unless you've got a very strange RegEx engine. I assume this is happening somewhere other than Apache.)

[dstiles]

As I said, the rules are applied way after anything legit has passed through. I stop testing when a legit or known bad UA or other condition is found and approved or reviled.

I occasionally get stuff trapped on the first rule (alpha-numeric UAs such as php/2.5) but almost never on the second. The final rule is more a panic trap. In practice the tests are usually abandoned before reaching it.

Yes, not apache. A very poor regex provided by MS's Classic ASP. The + extends the previous character (set) for as long as there is a match.

The expressions were written years ago and not visited since but now I look closer, the second rule's [0-9] has already been parsed. :(

[lucy24]

The + extends the previous character (set) for as long as there is a match.

Yes, that's why I wondered what comes after it. If there's nothing more, it wouldn't matter whether the match is one or many.

[dstiles]

Ah. I see what you're getting at. Difficult after all these years to know what I was thinking at that time. I do know I was relatively inexperienced in regex at the time. I think I need to revisit those! :)

[lucy24]

<topic drift>

Difficult after all these years to know what I was thinking at that time.

There are times I find it difficult to know what I was thinking after a few minutes.
</topic drift>