Re: seamless bait-and-switch
2011/12/8 Michal Zalewski : > What part? The change of a URL that is not associated with the > repainting of window contents? I believe that they are very unlikely > to catch this after initially examining the URL, in absence of other > indicators (change in URL length, page repainting, throbber activity). And even if so - someone who's typing in his password will not notice/react to a page reload for at least a few keystrokes. A javascript could send those to the server immediately, and if it's a semanic password, you might be able to guess the rest.
the week of silly PoCs continues: data://www.mybank.com/
Just another short note... this is a somewhat compelling and entirely unnecessary phishing opportunity - and a tiny symptom of the mess with URL handling. Firefox and Opera allow you to omit MIME type in data: URLs, possibly put random garbage into that section, and still get a valid HTML document. This is a natural extension of how the Content-Type header is handled in HTTP, but probably makes little or no sense here. With the use of Unicode homographs, you can create fairly believable URLs especially in Firefox: http://lcamtuf.coredump.cx/switch/index2.html The appearance may vary depending on your font selection; see http://lcamtuf.coredump.cx/switch/reference.jpg for a sample capture. If you know the special role of "data:", this won't fool you. But most browser users don't, even if they grasp the basics of URL syntax to begin with (of course, that part itself is not true in all too many cases). PS. It is probably better known that a less convincing variant of this can be achieved with javascript: URLs in MSIE and some other browsers. /mz
*CLOSING IN 5 DAYS * Re: AppSec DC 2012 - Call for Trainers
ALL, Just a reminder that the call for trainers closes on December 15th. We welcome all proposals at varying levels of technical content as well as non web-specific training. Submit proposals to http://training.appsecdc.org/ Regards, The AppSec DC Program Committee On Mon, Oct 24, 2011 at 2:27 PM, AppSec DC wrote: > Colleagues, > > OWASP is currently soliciting training providers for the OWASP AppSec DC > 2012 regional conference that will take place at the Walter E. Washington > Convention Center (801 Mount Vernon Place NW Washington, DC 20001) on April > 2nd through 5th of 2012. The theme for this year's conference is "OWASP - > Not just webapps anymore" to reflect the new and revised scope of OWASP to > include all application security issues instead of focusing just on web > application security. There will be training courses on April 2nd and 3rd > followed by plenary sessions on the 4th and 5th. There are a total of six > classrooms over two days or 12 training days available at the conference. > Three classrooms hold 30 students and the other three have a capacity of 24 > students. > > The following conditions apply for people or organizations that want to > provide training at the conference: > > * Training provider should provide class syllabus / training materials. > * Proceeds will be split 60/40 (OWASP/Trainer) for the training class. > * OWASP will provide the Venue, Marketing with Conference materials, > Registration and basic AV > * Trainers will cover travel and accommodations for the instructor(s) > and all course materials for students > * OWASP will reserve up to 2 training slots at no cost and the trainer > may reserve up to one slot at no cost > * Price per attendee: 2-Day Class $1500/ 1-Day Class $750. > * Trainers can brand training materials to increase their exposure > * Classes are to be focused around Application Security but are in no > way limited to web application security. > > Submit proposals to http://training.appsecdc.org/ before December 15th 2011 > to be considered. All trainers will be required to submit a Training > Instructor Agreement > (https://www.owasp.org/images/0/0f/AppSecDC_2012_Training_Instructor_Agreement.pdf) > in order to have their classed scheduled. Additional information can be > found at http://www.appsecdc.org > > Please forward to all interested practitioners and colleagues. > > Regards, > > The AppSec DC Program Committee
[SignalSEC Labs]: HTC Touch2 T3333 Video Player Memory Corruption
Affected Software: HTCVideoPlayer.exe
Tested on: HTC Touch2 T - Windows Mobile 6.5
Vulnerability: Memory Corruption
Details:
HTCVideoPlayer is the default media player of HTC Windows Mobile devices. This
media player is prone to a memory corruption vulnerability while parsing stbl
atom of 3g2 video format.
20:420> r
r0=2b7ea77c r1=2b7f15bb r2=0004 r3=0080 r4=4141413d r5=2b7ea7d4
r6=0004 r7=2b7ea77c r8= r9= r10=000209f0 r11=2b7efdec
r12=03f9e594 sp=2b7ea74c lr=01323c7c pc=03f9e8e4 psr=6010 -ZC-- ARM
20:420> u
coredll_3f4a000+0x548e4:
03f9e8e4 0130d1e4 ldrbr3, [r1], #1 --> memcpy() // like rep movs
03f9e8e8 042042e2 sub r2, r2, #4
03f9e8ec 0140d1e4 ldrbr4, [r1], #1
03f9e8f0 0150d1e4 ldrbr5, [r1], #1
03f9e8f4 01e0d1e4 ldrblr, [r1], #1
03f9e8f8 0130c0e4 strbr3, [r0], #1
vomp4fr+0x3c7c:
.text:10003C6CLDMHIFD SP!, {R4-R7,PC}
.text:10003C70MOV R2, R6; size_t
.text:10003C74MOV R0, R7; void *
.text:10003C78BLmemcpy
.text:10003C7CLDR R3, [R5,#0x14]
Proof of Concept:
www.signalsec.com/publications/htcvideo.3g2
Credits:
Vulnerability was discovered by Celil UNUVER from SignalSEC Labs
About SignalSEC:
SignalSEC is a company located in Turkey which provides vulnerability , cyber
threat intelligence and penetration testing services.
www.signalsec.com
CA20111208-01: Security Notice for CA SiteMinder
CA20111208-01: Security Notice for CA SiteMinder
Issued: December 08, 2011
CA Technologies Support is alerting customers to a potential risk in
CA SiteMinder. A vulnerability exists that can allow a malicious user
to execute a reflected cross site scripting (XSS) attack. CA
Technologies has issued patches to address the vulnerability.
The vulnerability, CVE-2011-4054, occurs due to insufficient
validation of postpreservationdata parameter input utilized in the
login.fcc form. A malicious user can submit a specially crafted
request to effectively hijack a victim’s browser.
Risk Rating
Medium
Platform
All
Affected Products
CA SiteMinder R6 SP6 CR7 and earlier
CA SiteMinder R12 SP3 CR8 and earlier
Non-Affected Products
CA SiteMinder R6 SP6 CR8
CA SiteMinder R12 SP3 CR9
How to determine if the installation is affected
Check the Web Agent log or Installation log to obtain the installed
release version. Note that the "webagent.log" file name is
configurable by the SiteMinder administrator.
Solution
CA is issuing patches to address the vulnerability.
CA SiteMinder R6:
Upgrade to R6 SP6 CR8 or later (Expected Availability: January 2012)
CA SiteMinder R12:
Upgrade to R12 SP3 CR9 or later
CR releases can be found on the CA SiteMinder
Hotfix/Cumulative Release page:
https://support.ca.com/irj/portal/anonymous/phpsupcontent?contentID={5AE61E29-C3DE-405E-9151-9EEA72D965CE}.
Workaround
None
References
CVE-2011-4054 - CA SiteMinder login.fcc XSS
Acknowledgement
CVE-2011-4054 - Jon Passki of Aspect Security, via CERT
Change History
Version 1.0: Initial Release
If additional information is required, please contact CA
Technologies Support at https://support.ca.com.
If you discover a vulnerability in CA Technologies products, please
report your findings to the CA Technologies Product Vulnerability
Response Team.
support.ca.com/irj/portal/anonymous/phpsupcontent?contentID=177782
Thanks and regards,
Ken Williams, Director
CA Technologies Product Vulnerability Response Team
CA Technologies Business Unit Operations
wilj...@ca.com
AST-2011-014: Remote crash possibility with SIP and the “automon” feature enabled
Asterisk Project Security Advisory - AST-2011-014 ProductAsterisk SummaryRemote crash possibility with SIP and the "automon" feature enabled Nature of Advisory Remote crash vulnerability in a feature that is disabled by default SusceptibilityRemote unauthenticated sessions Severity Moderate Exploits KnownYes Reported On November 2, 2011 Reported By Kristijan Vrban Posted On 2011-11-03 Last Updated OnDecember 7, 2011 Advisory Contact Terry Wilson CVE Name Description When the "automon" feature is enabled in features.conf, it is possible to send a sequence of SIP requests that cause Asterisk to dereference a NULL pointer and crash. Resolution Applying the referenced patches that check that the pointer is not NULL before accessing it will resolve the issue. The "automon" feature can be disabled in features.conf as a workaround. Affected Versions Product Release Series Asterisk Open Source 1.6.2.x All versions Asterisk Open Source1.8.x All versions Corrected In Product Release Asterisk Open Source 1.6.2.21, 1.8.7.2 Patches Download URLRevision http://downloads.asterisk.org/pub/security/AST-2011-014-1.6.2.diff 1.6.2.20 http://downloads.asterisk.org/pub/security/AST-2011-014-1.8.diff 1.8.7.1 Links Asterisk Project Security Advisories are posted at http://www.asterisk.org/security This document may be superseded by later versions; if so, the latest version will be posted at http://downloads.digium.com/pub/security/AST-2011-014.pdf and http://downloads.digium.com/pub/security/AST-2011-014.html Revision History Date Editor Revisions Made Asterisk Project Security Advisory - AST-2011-014 Copyright (c) 2011 Digium, Inc. All Rights Reserved. Permission is hereby granted to distribute and publish this advisory in its original, unaltered form.
AST-2011-013: Possible remote enumeration of SIP endpoints with differing NAT settings
Asterisk Project Security Advisory - AST-2011-013 ProductAsterisk SummaryPossible remote enumeration of SIP endpoints with differing NAT settings Nature of Advisory Unauthorized data disclosure SusceptibilityRemote unauthenticated sessions Severity Minor Exploits KnownYes Reported On 2011-07-18 Reported By Ben Williams Posted On Last Updated OnDecember 7, 2011 Advisory Contact Terry Wilson CVE Name Description It is possible to enumerate SIP usernames when the general and user/peer NAT settings differ in whether to respond to the port a request is sent from or the port listed for responses in the Via header. In 1.4 and 1.6.2, this would mean if one setting was nat=yes or nat=route and the other was either nat=no or nat=never. In 1.8 and 10, this would mean when one was nat=force_rport or nat=yes and the other was nat=no or nat=comedia. Resolution Handling NAT for SIP over UDP requires the differing behavior introduced by these options. To lessen the frequency of unintended username disclosure, the default NAT setting was changed to always respond to the port from which we received the request-the most commonly used option. Warnings were added on startup to inform administrators of the risks of having a SIP peer configured with a different setting than that of the general setting. The documentation now strongly suggests that peers are no longer configured for NAT individually, but through the global setting in the "general" context. Affected Versions Product Release Series Asterisk Open Source AllAll versions Corrected In As this is more of an issue with SIP over UDP in general, there is no fix supplied other than documentation on how to avoid the problem. The default NAT setting has been changed to what we believe the most commonly used setting for the respective version in Asterisk 1.4.43, 1.6.2.21, and 1.8.7.2. Links Asterisk Project Security Advisories are posted at http://www.asterisk.org/security This document may be superseded by later versions; if so, the latest version will be posted at http://downloads.digium.com/pub/security/AST-2011-013.pdf and http://downloads.digium.com/pub/security/AST-2011-013.html Revision History Date Editor Revisions Made Asterisk Project Security Advisory - AST-2011-013 Copyright (c) 2011 Digium, Inc. All Rights Reserved. Permission is hereby granted to distribute and publish this advisory in its original, unaltered form.
DC4420 - London DEFCON - 13 December 2011
OMG, it's Christmas again!! But happily this year we don't have to lurk in the corner of a dingy pub trying to look like we're having fun amongst the estate agents, bankers and stock borkers annual do's, as we have our very own cosy well stocked *private* bar and meeting space as per normal... Yes, our new home has not only put up with us for the whole year but have even invited us back for Christmas! Sweet! To celebrate, you are going to come and entertain us. Yes, that means YOU... This month we are doing lightning talks, so if you've got a 5-10 minute presentation, with or without slides/hardware/pyrotechnics/hadron colliders/pixies then bring your game face and share it with us... Also... There will be: Beer. (Small but cool) prizes for the best talks... More beer. Your last chance to buy the few remaining original DC4420 t-shirts! Even more beer. Your last chance (this year) to buy me a beer. Where: *** DOWNSTAIRS *** The Phoenix 37 Cavendish Square London W1G 0PP http://www.phoenixcavendishsquare.co.uk/ 2 minutes walk from Oxford Circus tube. When: Tuesday 13th December 2011 Room is ours from 17:30, talks kick off at 19:30 See you next week! cheers, MM -- "In DEFCON, we have no names..." errr... well, we do... but silly ones...
Re: seamless bait-and-switch
> And you don't believe that people would think that's suspicious? What part? The change of a URL that is not associated with the repainting of window contents? I believe that they are very unlikely to catch this after initially examining the URL, in absence of other indicators (change in URL length, page repainting, throbber activity). /mz
