lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <06DA44B99382B2428AD8DBFEE6CD209FAFDC8B@APOLLO.il.corp.radware.com>
Date: Mon, 6 Jul 2009 15:18:41 +0300
From: "Shaked  Vax" <ShakedV@...ware.com>
To: <3APA3A@...URITY.NNOV.RU>
Cc: full-disclosure@...ts.grok.org.uk
Subject: FW: Re[2]: Radware AppWall Web Application
	Firewall: Source code disclosure on management interface

Hello Vladimir

Let's clarify what is the .inc vulnerability all about:
In order to take advantage of this vulnerability one needs to:
1. Have access to internal AppWall management URL
2. Have credentials (user and password) of the AppWall Web Interface. Without the credentials one cannot access the  /Management/ folder at all !

Once you have access to the .inc file you can retrieve the server's source code. In most applications it is not "a good practice" (to say the least) to expose your source code even your authenticated users.

In AppWall's case there is nothing interesting to hide in the inc files, since if you have credentials, and you are looking to cause harm to the system, you can simply shutdown the AppWall service, change its IP address etc'. PHP source code is not interesting in this case.

This is not a critical issue and should be taken in relevant proportions.

Regards,
Shaked Vax

-----Original Message-----
From: Vladimir '3APA3A' Dubrovin [mailto:3APA3A@...URITY.NNOV.RU] 
Sent: Friday, July 03, 2009 15:58 PM
To: Shaked Vax
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re[2]: [Full-disclosure] radware AppWall Web Application Firewall: Source code disclosure on management interface

Dear Shaked  Vax,

 Are  you  sure  Radware  Team have analysed reflected attack via user's
 browser  (AppWall  administrator visits malcrafted page, page redirects
 his request to AppWall) before excluding remote vector?

--Thursday, July 2, 2009, 3:23:16 PM, you wrote to full-disclosure@...ts.grok.org.uk:

SV> Radware team has completed analysis of the reported issue, concluding
SV> that no AppWall customer using the product  according to Radware
SV> deployment recommendations would be exposed to vulnerability as a result
SV> of this issue. This is due to the facts that this issue exists only on
SV> the management interface that is recommended to be connection to
SV> internal LAN only, and that it does not allow performing any actions
SV> that would influence machine functionality.
SV>  Nevertheless, in order to enforce our commitment to deliver top
SV> security solution to our customers, Radware will supply a fix for this
SV> issue within its upcoming AppWall release.

SV> Shaked Vax
SV> AppWall Product Manager 
SV> ShakedV@...ware.com 
 

SV> _______________________________________________
SV> Full-Disclosure - We believe in it.
SV> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
SV> Hosted and sponsored by Secunia - http://secunia.com/


-- 
Skype: Vladimir.Dubrovin
~/ZARAZA http://securityvulns.com/
Но Гарри... я безусловно отдаю предпочтение ему, за
высокую питательность и какое-то особенно нежное мясо. (Твен)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ