Category Archives: Various

Remote File Inclusion in Google Cloud – nurhayati satu

Every know the Cloud security problematic, and the associated issues how are more and more visible. In July 2008 Outblaze and Spamhaus blocked Amazon EC2 Public IP ranges due to distribution of spam and malware. In April 2009 Arbor Networks reported that a malicious Google AppEngine was used as botnet CnC. In April 2010, VoIP Tech Chat has reported some Amazon EC2 SIP brute force attacks, until abuse report to Amazon EC2 the attacks have still continue in May, etc.

In March 2009, our Honey Net reported us a malicious Remote File Inclusion code hosted on a Google Sites, how was invoked in few events. The Google Sites was called “nurhayati satu“, an Indonesian surname and first name. The invoked malicious script was “http://sites.google.com/site/nurhayatisatu/1.txt???“.

[TABLE=10]

Between March 2009 and May 2010, no more sign of life of this Google Sites. But since May the number of events have increase and we could distinguish the apparition of the “Cloud” phenomena. “nurhayati satu” Google Sites has now around 16 IP addresses associated as hosting server and all these IP addresses are owned by Google Inc. The involved CIDR’s are 209.85.128.0/17 and 74.125.0.0/16.

It is interesting to visualize the interactions of the attackers source IPs (in blue) with the Google Sites Cloud destination IPs (in green).

Google Sites Cloud RFI
Google Sites Cloud RFI

You can see that the attackers source IPs are not dedicated to one hosting server IP, but are also invoking the “Cloud” IPs.

Between the search engine of the “nurhayati satu” Google Sites you can find other hosted classical scripts, scanners, tcl, etc.

Every one of you know the Google results labelled ‘This site may harm your computer‘.

It will be funny if Google Sites themselves will be labelled, but more seriously should we declare Google Sites to Dshield, Abuse.ch or Emerging Threats ? Should we block Google, cause Google is delivering some malwares between his Cloud infrastructure, and no one care 🙂

Local File Inclusion attempts on the rise

They’re is no new day without a Joomla Local File Inclusion (LFI) vulnerability. Just take a look at Exploit-DB, Inj3ct0r or Hack0wn and you will find thousands of Joomla components vulnerable to this vulnerability.

Since many years, security researcher have write studies on this vulnerability, and describe the different way to exploit them. You can find some good papers about LFI exploitations on Exploit-DB. But since 2010, LFI are coming back in force.

LFI vulnerability doesn’t look like to be dangerous in a first manner, but maybe we have to make a quick recap on the potential impacts to be vulnerable :

  • Exposure of sensitive informations (clear or hashed password, source code, documents leakage, etc.)
  • Exposure of system informations (system informations, users list, runtime informations, etc.)
  • Security bypass (normally inaccessible informations could be acceded…)
  • System access (malicious users could gain access to the system and compromise him)
  • Be involved in a botnet without knowing it
  • etc.

Why Local File Inclusion (LFI) attemps are on the rise ? The answer is very simple, cause Remote File Inclusion (RFI) are stagnating or even declining. Just do a simple research on Exploit-DB for RFI, you will directly see the difference with the LFI search. RFI vulnerabilities are very simple to exploit unlike LFI vulnerabilities. To argument, I propose you to visit our one year RFI HoneyNet statistics, you will see the increasing activity of RFI botnets. But the number of RFI exploits are decreasing continuously since the hype of 2006 and 2007. Compromised hosts by LFI are integrated into RFI botnets.

Despite LFI exploitation fail in 90% of cases (due to the OS, web server or PHP default hardening), if you scan 1000 hosts you can finally compromise 100 of them. LFI compromised hosts are compensating the decrease of RFI compromised hosts by RFI exploits. In such manner, we can see since 2010 apparition of dedicated Joomla LFI dork lists and mutation of traditional RFI scanners to LFI/RFI scanners (LRFI). The 2010 mutation of all traditional RFI scanner is also now to integrate XML RPC and SQL injection scanners, with nice updated dork lists.

We provide you a list of all unique LFI attempts on our HoneyNet for the latest 24 hours. This list will be updated daily and will permit you to follow the new vulnerable web applications.

So just a final word, take care on your /proc/self/environ, and special dedication to Indonesia 🙂 If you are curious, take a look to the Indonesian scene.

Increasing SSH Brute Force Attempts

As mentioned in my Tweet post, the 16 Jun, our HoneyNet has reveal increasing SSH Brute Force Attempts. These scans have been confirmed by Internet Storm Center (ISC), the 18 Jun from other sources. These scans made me remember last year and the incredible SSH 0Day rumor, and also the Zero For Owneds, Summer of Hax, also knows as ZF05. Maybe another try to own security experts infrastructures before DefCon & BlackHat ?

We have a clear difference with ISC alert around the increasing SSH Brute Force Attempts. On our HoneyNet all the source IP addresses have only focus on the root user and really try to password brute force the root account.

You follow the SSH Brute Force Attempts in our Use Case SUC015 with real time life data’s.

When an old Tier RFI mutate into a RFI botnet

Every one of you know Remote File Inclusion vulnerability, how permit to include a remote file usually through a PHP script on the Web application. This remote file contain some code how will be executed in the context of the server and permit for example to gather informations, execute code and compromise the Web server.

An typical RFI attack is to target Web applications how are vulnerable to an RFI. For example the actual most targeted RFI vulnerability is “MODx CMS snippet.reflect.php reflect_base CVE-2008-5938“.

Same as Metalica, bad guys are seeking and then destroying. But before destroying, bad guys seeking potential targets with search engines (Google, Yahoo, Live, Ask, etc.) and if some results are matching, they then try to see if the Web application URL is vulnerable or not. Same as a submarine active sonar, the remotely included code will ping the potential vulnerable URL, and if this URL is vulnerable the Web application will do an code echo reply. PS : Special dedicated to :

echo("FeeL"."CoMz");

Now the bad guys knowing that the Web application URL is vulnerable, they will gather more informations about the Web application and server environment. Following the responses to the informations gathering, the bad guys will decide which kind of infections they could apply and how depth the infections would be. The critical informations that the bad guys will look are for example :

  • Is PHP safe mode set to “on” ?
  • What is the OS hosting the vulnerable application ?
  • Version of the kernel, if applicable ?
  • What is the user running the web application, most of time httpd or apache.
  • What are the permissions of the Web application directories, read only, writable ?

If PHP safe mode is set to “on”, the bad guys will only use the vulnerable Web application and server as repository for some scripts, most of time the “ping code” and the “informations gathering code“.

If PHP safe mode is set to “off”, then the bad guys will begin to remote upload, on the server, more scripts. Mainly RFI viral packs containing these capabilities :

  • IRC Command & Control bot module
  • Search engines targets seeker module
  • RFI code ping scan script
  • RFI code echo reply listener module
  • Informations gathering script
  • IRC channels & words spying module
  • DOS & DDOS module
  • Portscanner module
  • Fake speaking & answering IRC bots module
  • Google bypasser module
  • PHP shells script

What is really important to understand is that every parts of these RFI viral packs could be decentralized on other compromised servers, and controlled by different IRC Command & Control servers . And now, longer the first initial Web application and server is compromised, longer this infected host will participate to increase the size of the RFI botnet.

We will use a example, a very old friend of our HoneyNet, lunched in February 2009. We will call our old friend “RFI n°4” (Nooo, I’m not an number….) and provide you his ID card.

  • RFI ID : 4
  • RFI IP : 213.158.72.68
  • RFI FQDN : virtual.interfree.it
  • RFI Country : Italy
  • RFI Vhost : brej.interfree.it
  • RFI URL : http://brej.interfree.it/id.jpg??
  • Number of events generated by n°4 : 1935
  • Number of source IPs how are calling the RFI URL : 112
  • RFI first seen : 2009-02-15 20:54:58
  • RFI last seen : 2010-05-26 21:48:09
  • RFI life time : 465 day’s

Hu, 465 days old … my n°4 friend is very old and has a lot of friends how are visiting him (112 source IPs). The number of events is quiet relative, cause 465 day’s for only generating 1935 events, my n°4 friend you could do better, maybe your master is a lazy guy. All you friends are trying different attacks, with your help, against our HoneyNet.

RFI n°4 as red, and all his friends in green with the related SIG attempts
RFI n°4 as red, and all his friends in green with the related SIG attempts

What is interesting n°4, is that some of your friends are also RFI infected, and all together you create a big family linked together (RFI botnet).

RFi n°4 centralized in red, and all his friend
RFi n°4 centralized in red, and all his friend

Another possible visualization is to see month by month the activities turning around our n°4 RFI friend. RFI n°4 is indicated in green colors, source IPs how are not also RFI are indicated in orange colors and source IPs how are also RFI are indicated in red flame colors.
[nggallery id=4]