Is this a code injection attack via my website?

akalinin · 03-14-2016, 04:40 PM

Hello,
I run a small, simple website on Slackware 14.1 & apache 2.4. I wrote it with Vim, and there is no PHP or other dynamic content.

Since making the web site accessable to the public a week ago, I'm getting the following attacks when checking my access_log. What on earth is this?

202.109.143.16 - - [14/Mar/2016:07:07:20 -0400] "POST /cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6 F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%6 4%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69% 72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69 %6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E %72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 210

202.109.143.16 - - [14/Mar/2016:07:07:21 -0400] "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6 D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64 +%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64% 69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F %69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69 %2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 213

202.109.143.16 - - [14/Mar/2016:07:07:22 -0400] "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F %64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64 %69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%7 2%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69% 6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E% 72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 213

202.109.143.16 - - [14/Mar/2016:07:07:22 -0400] "POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F %64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64 %69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%7 2%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69% 6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E% 72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 209

202.109.143.16 - - [14/Mar/2016:07:07:23 -0400] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6 F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%6 4%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69% 72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69 %6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E %72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 210

Habitual · 03-14-2016, 04:48 PM

China hacking.

smallpond · 03-14-2016, 05:14 PM

Looks like this common scan for a vulnerability

http://security.stackexchange.com/qu...exploit-attack

sundialsvcs · 03-14-2016, 05:47 PM

The attacker is hoping that you have a PHP interpreter within a directory that can be accessed by the alias "/cgi-bin/" on your website, and is attempting to "stuff PHP source code" into it while concealing (superficially ...) what he is up to. The "%xx" symbols correspond to ASCII characters.

akalinin · 03-14-2016, 07:52 PM

Quote:

Originally Posted by sundialsvcs

The attacker is hoping that you have a PHP interpreter within a directory that can be accessed by the alias "/cgi-bin/" on your website, and is attempting to "stuff PHP source code" into it while concealing (superficially ...) what he is up to. The "%xx" symbols correspond to ASCII characters.

I take it (by the 404 error code returned to each attempt) that this was unsuccessful. Thanks to all the respondents, I now understand what is going on here.

sundialsvcs · 03-14-2016, 09:15 PM

Indeed, the attacker is hoping that you are ... shall we say ... "unaware."

That your Apache configuration had an Alias '/cgi-bin/' ... directive with not the slightest knowledge of its implications, nor of what it might be pointing to.

How do I say it politely? ... "If you do not know what you are doing, nor what you have done, then: 'I have a script for that.'"

dugan · 03-14-2016, 09:55 PM

This is my attempt to decode the URLs:

Code:

/cgi-bin/php5?-d+allow_url_include=on+-d+safe_m%6 Fde=off+-d+suhosin.simulation=on+-d+%6 4isable_functions=""+-d+open_basedi% 72=none+-d+auto_prepend_file=php://i nput+-d+cgi.force_redirect=0+-d+cgi. redirect_status_env=0+-n

/cgi-bin/php.cgi?-d+allow_url_include=on+-d+safe_%6 Dode=off+-d+suhosin.simulation=on+-d +disable_functions=""+-d+open_based% 69r=none+-d+auto_prepend_file=php:// input+-d+cgi.force_redirect=0+-d+cgi .redirect_status_env=0+-n

/cgi-bin/php-cgi?-d+allow_url_include=on+-d+safe_mo de=off+-d+suhosin.simulation=on+-d+d isable_functions=""+-d+open_basedi%7 2=none+-d+auto_prepend_file=php://i% 6Eput+-d+cgi.force_redirect=0+-d+cgi.% 72edirect_status_env=0+-n

/cgi-bin/php?-d+allow_url_include=on+-d+safe_mo de=off+-d+suhosin.simulation=on+-d+d isable_functions=""+-d+open_basedi%7 2=none+-d+auto_prepend_file=php://i% 6Eput+-d+cgi.force_redirect=0+-d+cgi.% 72edirect_status_env=0+-n

/cgi-bin/php4?-d+allow_url_include=on+-d+safe_m%6 Fde=off+-d+suhosin.simulation=on+-d+%6 4isable_functions=""+-d+open_basedi% 72=none+-d+auto_prepend_file=php://i nput+-d+cgi.force_redirect=0+-d+cgi. redirect_status_env=0+-n

Which is consistent with smallpond's information.

akalinin · 03-14-2016, 10:21 PM

Quote:

Originally Posted by sundialsvcs

Indeed, the attacker is hoping that you are ... shall we say ... "unaware."

That your Apache configuration had an Alias '/cgi-bin/' ... directive with not the slightest knowledge of its implications, nor of what it might be pointing to.

How do I say it politely? ... "If you do not know what you are doing, nor what you have done, then: 'I have a script for that.'"

My httpd.conf does contain 'ScriptAlias /cgi-bin/ "/srv/httpd/cgi-bin/"'. I'll comment that out since I have nothing of value in the cgi-bin directory anyway. Thanks for the advice!

sundialsvcs · 03-16-2016, 03:30 PM

Yes, you should always remove from the configuration anything that's "there by default." If you don't have CGI programs in a site, then there's zero reason for it to have any CGI-enabled locations. (And if you do, why call it something as obvious as "cgi-bin?" Why not call it, say, "footballs?")

Pay particular attention to the default <VirtualHost> !!

JJJCR · 03-17-2016, 12:39 AM

In any input text box or other forms, to prevent injection attack. Perform keys filtering on those input boxes that only letters and numbers are allowed. No matter how the inject like the one you posted above which has back slash, percent and plus sign those will be rejected.

sundialsvcs · 03-17-2016, 07:18 AM

Futhermore, when issuing SQL queries, use bound parameters! (Early PHP's could not do this, but "mysqli" can.)

Instead of textually constructing an SQL query string such as "SELECT * FROM PRODUCTS WHERE PRODUCT_ID = 'foo'; DROP TABLE PRODUCTS;" ...

... code the query a "SELECT * FROM PRODUCTS WHERE PRODUCT_ID = ?" (notice that the question-mark is not quoted ...). Then, bind the user's input to the first parameter, and execute the query.

SQL will promptly realize that "'foo;' DROP TABLE PRODUCTS;" is not a valid product-id.

It now becomes impossible to "inject SQL," because the SQL strings that are to be executed are now fixed, and the user's inputs are used only as parameters to them. Furthermore, such a query can be "prepared" one time and then re-executed multiple times with different sets of parameters.

JJJCR · 03-21-2016, 05:04 AM

Quote:

Originally Posted by sundialsvcs

Futhermore, when issuing SQL queries, use bound parameters! (Early PHP's could not do this, but "mysqli" can.)

Instead of textually constructing an SQL query string such as "SELECT * FROM PRODUCTS WHERE PRODUCT_ID = 'foo'; DROP TABLE PRODUCTS;" ...

... code the query a "SELECT * FROM PRODUCTS WHERE PRODUCT_ID = ?" (notice that the question-mark is not quoted ...). Then, bind the user's input to the first parameter, and execute the query.

SQL will promptly realize that "'foo;' DROP TABLE PRODUCTS;" is not a valid product-id.

It now becomes impossible to "inject SQL," because the SQL strings that are to be executed are now fixed, and the user's inputs are used only as parameters to them. Furthermore, such a query can be "prepared" one time and then re-executed multiple times with different sets of parameters.

Hi sundialsvcs, found your post quite interesting.

So this one is a valid query: "SELECT * FROM PRODUCTS WHERE PRODUCT_ID = ?"

But how to bind the query to that statement, to replace "?".

Sorry but i'm not familiar with this thing but you have an excellent idea.

sundialsvcs · 03-21-2016, 07:32 AM

If you look at the API calls for PHP's "mysqli" interface, you'll find functions to "bind parameters," as well as to bind outputs.

http://php.net/manual/en/mysqli-stmt.bind-param.php

http://php.net/manual/en/mysqli-stmt.bind-result.php

Other languages have had this concept for a very long time, and make it very easy to do. (For instance, Perl's "DBI" interface unit allows you to supply an array of parameter values in the "usual" call for making a query.)

Basically, what happens is that when SQL "prepares" the query, to create a so-called "execution plan," the plan says that the query is to have certain parameters which must be supplied (separately ...) each time the query runs. These parameters are not part of the SQL text. Different parameter-sets can be supplied as the same prepared statement-handle is executed an arbitrary number of times.

JJJCR · 03-21-2016, 08:13 PM

Thanks for the link.

$stmt = mysqli_prepare($link, "INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)");

mysqli_stmt_bind_param($stmt, 'sssd', $code, $language, $official, $percent);

so basically, if there is an injection and it doesn't match the string type which is the 'sssd' and doesn't match also the prepared parameters. Injection will not be possible since the parameters bind are fixed.

Hope I understand it correctly, Thank you, Sundialsvcs.

sundialsvcs · 03-22-2016, 08:16 AM

Exactly so. "The SQL statement that is to be executed" is found only in supplied string, which does not have any user-provided content. This statement, in the example above, has four input-parameters which must be supplied with values each time the prepared statement-handle ($stmt ...) is executed. Different parameter values may be provided each time $stmt is executed: there is no need to re-prepare the handle. Even if the parameter values "look like SQL," they are interpreted only as character-strings (or whatever data-type you said they were ...). In other words, they are input data to the query; never a part of the query itself.

This is not only more secure, but also more efficient. The SQL engine parses the SQL and prepares the "execution plan," as represented by the statement-handle, only one time. And, if you happen to be executing a statement millions of times, that does make a measurable difference.

It utterly baffles me why PHP did not provide easy access to this facility from the very start. (And why, when they finally did add it, they did not make it "easy.") It has always been available.