[Full-disclosure] Open Letter to the International Information Security Community - Help Brazilian Security Researchers
ctions are not restricted to our nations, but have effect in a global scale. A cybercrime law passed in Brazil might harm colleagues in China or France, fr instance. In fact a similar law passed in Germany has done exactly that (http://www.theregister.co.uk/2009/06/07/germany_hacker_tool_law/). There are no boundaries anymore. The security industry is a whole, every body is a target, everybody is an actor, everybody helps everybody. If you are not worried about a tool you might write because you are not physically in Brazil, at least Imagine the amount of contributions to world's computer security that will be blocked in Brazil. Imagine if this kind of legislation gains strength and starts serving as a whole model so other countries start adopting it. We must stop it right now. I urge you Information Security Community Member to help Brazil and yourself on this matter by exposing it as publicly as possible. It is incredible when the complaints in Brazil against this law proposal started to be heard by politicians when Brazilian press gave minimum attention (http://www1.folha.uol.com.br/tec/1092515-lei-de-crimes-ciberneticos-pode-punir-inocentes-se-aprovada-dizem-especialistas.shtml ). If this PRESSure continues and happens internationally I am positive Brazilian Congress will respond appropriately and change will come. The proposal is scheduled to be voted definitely next November 6th 2012 (http://www2.camara.leg.br/agencia/noticias/POLITICA/429234-CAMARA-PODE-VOTAR-ROYALTIES,-FIM-DA-TAXA-DE-TELEFONIA-E-MARCO-CIVIL-DA-INTERNET.html ). It is little time until there, and a lot of work. I am also listing in the end of the letter the names and email addresses of all the politicians that will vote the proposal. Feel free to drop them an email with your opinion, they understand English or have people that do. Best Wishes, Pablo Ximenes Information Security Researcher and Internet Freedom Activist Information Securty Research Team (http://insert.uece.br) Ceara State Government Security Analyst (http://ww.etice.ce.gov.br) Security Blogger (http://ximen.es) pa...@ximen.es pa...@etice.ce.gov.br pa...@insert.uece.br VOTING POLITICIANS "DEPUTADO(A) ABELARDO CAMARINHA - PSB - SP" , "DEPUTADO(A) ABELARDO LUPION - DEM - PR" , "DEPUTADO(A) ACELINO POPO - PRB - BA" , "DEPUTADO(A) ADEMIR CAMILO - PSD - MG" , "DEPUTADO(A) ADRIAN - PMDB - RJ" , "DEPUTADO(A) AELTON FREITAS - PR - MG" , "DEPUTADO(A) AFONSO FLORENCE - PT - BA" , "DEPUTADO(A) AFONSO HAMM - PP - RS" , "DEPUTADO(A) ALBERTO FILHO - PMDB - MA" , "DEPUTADO(A) ALBERTO MOURAO - PSDB - SP" , "DEPUTADO(A) ALCEU MOREIRA - PMDB - RS" , "DEPUTADO(A) ALESSANDRO MOLON - PT - RJ" , "DEPUTADO(A) ALEX CANZIANI - PTB - PR" , "DEPUTADO(A) ALEXANDRE CARDOSO - PSB - RJ" , "DEPUTADO(A) ALEXANDRE LEITE - DEM - SP" , "DEPUTADO(A) ALEXANDRE ROSO - PSB - RS" , "DEPUTADO(A) ALEXANDRE SANTOS - PMDB - RJ" , "DEPUTADO(A) ALFREDO KAEFER - PSDB - PR" , "DEPUTADO(A) ALFREDO SIRKIS - PV - RJ" , "DEPUTADO(A) ALICE PORTUGAL - PCdoB - BA" , "DEPUTADO(A) ALINE CORREA - PP - SP" , "DEPUTADO(A) ALMEIDA LIMA - PPS - SE" , "DEPUTADO(A) AMAURI TEIXEIRA - PT - BA" , "DEPUTADO(A) ANDERSON FERREIRA - PR - PE" , "DEPUTADO(A) ANDRE FIGUEIREDO - PDT - CE" , "DEPUTADO(A) ANDRE MOURA - PSC - SE" , "DEPUTADO(A) ANDRE VARGAS - PT - PR" , "DEPUTADO(A) ANDRE ZACHAROW - PMDB - PR" , "DEPUTADO(A) ANDREIA ZITO - PSDB - RJ" , "DEPUTADO(A) ANGELO AGNOLIN - PDT - TO" , "DEPUTADO(A) ANGELO VANHONI - PT - PR" , "DEPUTADO(A) ANIBAL GOMES - PMDB - CE" , "DEPUTADO(A) ANTHONY GAROTINHO - PR - RJ" , "DEPUTADO(A) ANTONIA LUCIA - PSC - AC" , "DEPUTADO(A) ANTONIO ANDRADE - PMDB - MG" , "DEPUTADO(A) ANTONIO BALHMANN - PSB - CE" , "DEPUTADO(A) ANTONIO BRITO - PTB - BA" , "DEPUTADO(A) ANTONIO BULHOES - PRB - SP" , "DEPUTADO(A) ANTONIO CARLOS MAGALHAES NETO - DEM - BA" , "DEPUTADO(A) ANTONIO CARLOS MENDES THAME - PSDB - SP" , "DEPUTADO(A) ANTONIO IMBASSAHY - PSDB - BA" , "DEPUTADO(A) ANTONIO ROBERTO - PV - MG" , "DEPUTADO(A) ARACELY DE PAULA - PR - MG" , "DEPUTADO(A) ARIOSTO HOLANDA - PSB - CE" , "DEPUTADO(A) ARLINDO CHINAGLIA - PT - SP" , "DEPUTADO(A) ARMANDO ABILIO - PTB - PB" , "DEPUTADO(A) ARMANDO VERGILIO - PSD - GO" , "DEPUTADO(A) ARNALDO FARIA DE SA - PTB - SP" , "DEPUTADO(A) ARNALDO JARDIM - PPS - SP" , "DEPUTADO(A) ARNALDO JORDY - PPS - PA" , "DEPUTADO(A) ARNON BEZERRA - PTB - CE" , "DEPUTADO(A) AROLDE DE OLIVEIRA - PSD - RJ" , "DEPUTADO(A) ARTHUR LIRA - PP - AL" , "DEPUTADO(A) ARTHUR OL
Re: [Full-disclosure] Security Problem with Google’s 2-Step Authentication
Hi, On Mon, Jul 30, 2012 at 1:46 PM, andfarm wrote: > > Invalidating the entire window would make you unable to authenticate > using OTP more than once every 10 minutes. You´re right, it would have a hard impact on usability. Maybe just invalidating closeby tokens would do, like the 2 or 3 next ones. > In any case, I'm having a hard time imagining what sort of threat model > which make this necessary -- if you can somehow predict a user's OTP code > for some point in the future, you could go ahead and predict one that's > even further in the future (outside the window of invalidated keys), and > use it when that time arrives. > I don´t know if it answers your question, but have you got the chance to examine my PoC? http://ximen.es/gmail It´s a phishing verion of accounts.google.com that steals two OTP passwords and gets you authenticated with one of them while it "saves" the other in a usable state (it issues an error message in order to trick the user into entering the code again). This way, the user is lead to think all the 2 codes entered were invalidated because of the successful login, which is obviously not the case in the PoC. If the "invalidate the next X tokens" approach were in place, this threat wouldn´t be possible. Regards, Pablo ___ 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] sandboxed browsing
Christian´s tip on wget is a good alternative. Why not do some protocol level inspection? I mean wget, netcat, curl, etc... Sometimes I even hide my network with tor. Of course, sometimes you gonna need some actual end user experience to better analyze the attack, but I think most suspicious URLs can be cracked right away with just that. Regards, Pablo Ximenes On Wed, Aug 1, 2012 at 7:45 AM, Christian Sciberras wrote: > I use Internet Explorer 6 on Windows XP, obviously! > > > On a more serious note, I doubt there's a safer alternative, > except maybe not going there in the first place (or just wget-ing it > instead). > > > > > > > > On Wed, Aug 1, 2012 at 1:38 AM, Kyle Creyts wrote: > >> Who uses something other than a browser in a virtual machine to follow >> suspicious/possibly malicious links? >> >> If you do, what do you use, and how did you choose it? >> >> ___ >> 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 - http://secunia.com/
[Full-disclosure] Security Problem with Google’s 2-Step Authentication
Hi Folks, I'd like to share with you one of my findings that failed to get Google's Security Reward. Although Google doesn't consider it a security problem, some might find it at least amusing if not interesting. Check it out: http://ximen.es/?p=653 Sorry for typos, cross posting, and lack of accuracy. Regards, Pablo Ximenes ___ 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] Publication References on Criminalisation of Hacking Tools Needed
Hi Folks, I was wondering if any of you could point out any good references (academic preferebly) on the consequences of the Criminalisation of sales, distribution, advertisement, and cretation of Hacking Tools (those that can be used to facilitate a computer breach, especially software). I have find a few and would very much apreciate any contribution. Thank you. Regards, Pablo Ximenes ___ 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] Google open redirect
I was assuming web vulns found in Google´s Infrastructure, and not vulnerabilities in general as I imagine Google wouldn´t condone selling vulns on their systems to the highest bidder. As far as crimes commited during the process of discovering the vuln itself, Google expressly authorizes security testing in the program: http://www.google.com/about/corporate/company/rewardprogram.html But for vulns in general, I totally agree with you. 2011/12/8 > On Thu, 08 Dec 2011 14:24:21 -0300, Pablo Ximenes said: > > 2011/12/8 Michal Zalewski > > > If you don't like it, let us know how to improve it. You also always > > > have the option of not researching vulnerabilities in these platforms; > > > going with the full-disclosure approach; or selling the flaws to a > > > willing third party. > > > Well, selling flaws to third parties might be considered a crime in some > > places, so I would be cautious with that approach. > > I suspect a large portion of the people who are selling flaws to third > parties > are not at all concerned about whether selling the flaw is a crime, as > often the > bigger question is how many crimes were committed in the discovery > process... > ___ 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] Google open redirect
2011/12/8 Michal Zalewski > > If you don't like it, let us know how to improve it. You also always > have the option of not researching vulnerabilities in these platforms; > going with the full-disclosure approach; or selling the flaws to a > willing third party. > > Well, selling flaws to third parties might be considered a crime in some places, so I would be cautious with that approach. ___ 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] Google open redirect
I think the reward is intended as a symbolic token of appreciation, and not as compensation. That's why they give you the option to donate your cash reward instead of keeping the money. I think what really drives researchers into Google's program is recognition and not compensation, IMHO. 2011/12/8 Charles Morris > Michal/Google, > > IMHO, 500$ is an incredibly minute amount to give even for a error > message information disclosure/an open redirect, > researchers with bills can't make a living like that.. although it > might? be okay for students. > > How many Google vulnerabilities per month are there expected to be? > Granted there are other avenues to pursue for a fledgling researcher, > > What is the cost to Google's business if an open redirect causes their > image to be tarnished > by some arbitrary amount in the eyes of some percentage of consumers? > > Considering Google grossed 30 billion dollars in 2010, (ridiculous) I > would expect that the numbers > we are talking about perhaps are so massive that 500$ is nothing in > comparison. > > We live in an age that pays 5k, or 30k, or 100k for a root level > compromise, > in a common package with a reliable and solid exploit. At least that's > what I hear. > > Even if everyone else's opinion says "500$ is too much for a redirect", > doesn't Google want to promote the industry by sharing a little of the > wealth to people with good intentions and ability? > > It's time to raise the bar a little here, and I'm not just talking about > bounty. > > Why would Google ever suffer from these issues to begin with? > Can't Google, in it's infinite wisdom and 30 billion dollars, come up with > a better solution for whatever random problem they are trying to solve > with an open redirect? > > > n.b. I have never sold a vulnerability, even when non-pittance sums are > offered > > /rant > > On Thu, Dec 8, 2011 at 12:15 AM, Michal Zalewski > wrote: > >> _Open_ URL redirectors are trivially prevented by any vaguely sentient > >> web developer as URL redirectors have NO legitimate use from outside > >> one's own site so should ALWAYS be implemented with Referer checking > > > > There are decent solutions to lock down some classes of open > > redirectors (and replace others with direct linking), but "Referer" > > checking isn't one of them. It has several subtle problems that render > > it largely useless in real-world apps. > > > ... > > We have a vulnerability reward program, and it's just about not paying > > $500 for reports of that vulnerability - along with not paying for > > many other minimal-risk problems such as path disclosure. > > > > /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/ > ___ 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] Google open redirect
Well, I usually support adopting business models into processes that help society, so I would agree with you on the "monetary philosophy". But the strategy here isn't (as I understand) driving pro's into the program, but getting rid of unilateral vuln disclosures that happen mostly without direct monetary compensation. So, I thing Google's program is directed to those that already are willing to gain no money for their work in disclosing vulns. Again, this is just my point of view. 2011/12/8 Charles Morris > Granted, but I know that vulnerability research can take a huge chunk > of time out of a person's life, > and without getting in to "monetary philosophy", I feel that in our > current system, a person should > be compensated for their time if they've done something useful for society. > That's sort of the point of the way we use money. > > On Thu, Dec 8, 2011 at 10:03 AM, Pablo Ximenes wrote: > > I think the reward is intended as a symbolic token of appreciation, and > not > > as compensation. That's why they give you the option to donate your cash > > reward instead of keeping the money. I think what really drives > researchers > > into Google's program is recognition and not compensation, IMHO. > > > ___ 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] OMIGOD CIQ HACKING THE WORLD.
Alright, let´s stop assuming things then. Anyhow, congrats for the great work. Nice chat, btw. Att, Pablo Ximenes 2011/12/7 Dan Rosenberg > On Wed, Dec 7, 2011 at 10:02 AM, Pablo Ximenes wrote: > > Hi, > > > > 2011/12/7 Dan Rosenberg > >> > >> On Wed, Dec 7, 2011 at 9:09 AM, Pablo Ximenes wrote: > >> > >> > >> > >> That's a good question. As you've mentioned, the URL falls within the > >> HTTP request, the entirety of which is protected by SSL. So I would > >> argue that the URL is content that should remain secret in an SSL > >> session. I haven't made up my mind whether the same applies to > >> non-HTTPS URLs. The issue is further complicated by the fact that > >> perhaps the domain (without query parameters) that's being requested > >> shouldn't be considered secret since this is readily available by > >> looking at DNS. > >> > > > > Well, let´s take a look at a simple HTTP request: > > > > POST /login.php HTTP/1.1 > > Host: www.example.com > > User-Agent: Mozilla/5.0 (Windows;pt-BR; rv:1.8.0.11) Gecko/20070312 > > Firefox/1.5.0.11 > > Accept: text/xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > > Accept-Language: en-gb,en;q=0.5 > > Accept-Encoding: gzip,deflate > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > Keep-Alive: 300 > > Connection: keep-alive > > Referer: http://www.example.com/ > > Content-Type: application/x-www-form-urlencoded > > Content-Length: 22 > > > > username=jdoe&pass=god > > > > > > > > In this case, the URL being visited is http://www.example.com/login.php > > > > In order to capture this URL, the eavesdropping software would have to > open > > up the contents of the HTTP payload, get information from the method line > > (1st line, POST), then get information from the "Host:" line, Merge them > > together and then assemble the original URL. Bottom line is that the > > eavesdropping software has to look at the contents in order to assemble > this > > seemingly "header" information. I would say this info is content and not > > header, even for non-HTTPS requests, don´t you think? > > > > Even though DNS leaks some info, as you mentioned it´s never the full > URL. > > Also, there´s the DNS cache, URL domain names get resolved once in a > while, > > and chache is used quite often. > > > > And that´s only for URLs, I wonder how deep they would have to digg into > > HTTP payloads in order to get other metrics that they might be > collecting. > > As you already said the samgung model has direct indication of > collection of > > "Request type" (GET, POST, etc), "content length" (port of the request´s > > payload), and "status code" (part of the reply´s payload!), all of which > > would need deep inspection of HTTP payload request contents as I > mentioned. > > > > This is more of a semantic argument of what is meant by "content" and > "header". At the application layer, the URL is considered a header. > At the transport or network layer, the entire HTTP payload is > considered content. I don't know how the law interprets this. > > Regardless, you're correct that they are "digging into" HTTP payloads > to get this information: their instrumentation is in Webkit, where > they have easy access to this information. They never touch POST > parameters or response bodies, but they do collect the information I > described. > > > > >> > >> Please note that I'm not a lawyer, so I don't know the wording of any > >> laws related to this sort of thing. Also remember that it remains to > >> be seen whether URL data is/was being collected at all, which is > >> obviously a key piece of information with regards to the legal issues > >> at hand. > >> > > > > Assuming those metrics were intended mostly for debugging purposes, It > is a > > fair assumption that they were indeed colleting this info, since it´s > very a > > important piece of data for debugging their data network in terms of > > application level. > > > > I don't think either of us in a position to make a guess here. The > profiles I looked at included almost exclusively radio and telephony > related data and did not include URLs. Other profiles might include > application data like this. So, like I said, it's definitely possible > that URLs were being collected, but neither
Re: [Full-disclosure] OMIGOD CIQ HACKING THE WORLD.
Hi, 2011/12/7 Dan Rosenberg > On Wed, Dec 7, 2011 at 9:09 AM, Pablo Ximenes wrote: > > > That's a good question. As you've mentioned, the URL falls within the > HTTP request, the entirety of which is protected by SSL. So I would > argue that the URL is content that should remain secret in an SSL > session. I haven't made up my mind whether the same applies to > non-HTTPS URLs. The issue is further complicated by the fact that > perhaps the domain (without query parameters) that's being requested > shouldn't be considered secret since this is readily available by > looking at DNS. > > Well, let´s take a look at a simple HTTP request: POST /login.php HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows;pt-BR; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11 Accept: text/xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com/ Content-Type: application/x-www-form-urlencoded Content-Length: 22 username=jdoe&pass=god In this case, the URL being visited is http://www.example.com/login.php In order to capture this URL, the eavesdropping software would have to open up the contents of the HTTP payload, get information from the method line (1st line, POST), then get information from the "Host:" line, Merge them together and then assemble the original URL. Bottom line is that the eavesdropping software has to look at the contents in order to assemble this seemingly "header" information. I would say this info is content and not header, even for non-HTTPS requests, don´t you think? Even though DNS leaks some info, as you mentioned it´s never the full URL. Also, there´s the DNS cache, URL domain names get resolved once in a while, and chache is used quite often. And that´s only for URLs, I wonder how deep they would have to digg into HTTP payloads in order to get other metrics that they might be collecting. As you already said the samgung model has direct indication of collection of "Request type" (GET, POST, etc), "content length" (port of the request´s payload), and "status code" (part of the reply´s payload!), all of which would need deep inspection of HTTP payload request contents as I mentioned. > Please note that I'm not a lawyer, so I don't know the wording of any > laws related to this sort of thing. Also remember that it remains to > be seen whether URL data is/was being collected at all, which is > obviously a key piece of information with regards to the legal issues > at hand. > > Assuming those metrics were intended mostly for debugging purposes, It is a fair assumption that they were indeed colleting this info, since it´s very a important piece of data for debugging their data network in terms of application level. -Dan > > > Att, Pablo Ximes > > > >> Regards, > >> Dan > >> > > > > > > Regards, > > > > Pablo Ximenes > > > >> > >> > > >> > Regards, > >> > > >> > Pablo Ximenes > >> > > >> > 2011/12/6 Christian Sciberras > >> >> > >> >> Or not... > >> >> > >> >> http://vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/ > >> >> > >> >> On the other hand, where that l33t hacker Drew (aka xD 0x41)? > >> >> Thought he'd enlighten us with more of his awesome hacking powers on > >> >> this > >> >> issue. > >> >> > >> >> ___ > >> >> 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 - http://secunia.com/
Re: [Full-disclosure] OMIGOD CIQ HACKING THE WORLD.
Hi, 2011/12/7 Dan Rosenberg > And I was really hoping I wouldn't get dragged into another discussion > on this... > Well, if it serves of any consolation, discussions are good for making things more clear, I´d assume. Sorry, though. > On Wed, Dec 7, 2011 at 7:55 AM, Pablo Ximenes wrote: > > Hi All, > > > > Based on what I read from the post, basically Rosenberg recognises he > has no > > clue about what happens with the rest of affected phone models: > > > > "One important thing to note is that this represents the metrics that are > > submitted to the CarrierIQ application by the code written by Samsung. > The > > list of available metrics are carrier specific, but will remain constant > on > > a given handset model. The subset of this data that is actually recorded > and > > collected is at the discretion of the carrier, and is based on the > profile > > installed on the device." (Dan Rosenberg) > > > > > > So the eavesdropped data with respect to the rest of affected phones > could > > be anything for all he knows, including contents of SMS's and visited > pages. > > > > This is not accurate. I have not enumerated the locations on every > phone where OEMs have modified the Android framework to submit metrics > to the CarrierIQ agent running on the phone. This means I don't know > what subset of metrics that CIQ supports is actually being submitted > to the agent on every phone. However, I have reverse engineered the > actual CarrierIQ binaries on a wide variety of phones (the agent code > is actually fairly similar across the board), so I have a very good > idea of the total set of supported metrics (regardless of what's > actually being submitted) looks like. And surprise, there is no > metric that contains fields for SMS bodies or web page contents. > > Glad you made yourself more clear this time. :) Suggestion: why don´t you publish the full set of metrics found on your investigation? That would make your research report even more complete. > Food for thought: why would a carrier double their bandwidth > utilization for SMS in order to violate federal wiretapping law and > get a second copy of the text message *that they already have*? > > Good point! But that´s not the case for encrypted HTTP data, though. > > And about collecting every URL (even https ones) that is visited. Forget > > about the legality, let's go directly to the privacy implications. > > For instance, if you do that for a simple Facebook session, there's a > huge > > amount of very private information being collected (fixed URLS that > reveal > > photos, etc; ajax URLs that reveal juicy IDs, among other things). > Also, I > > don't think anybody would want to have their complete web history in the > > hands of anyone without their express consent. > > > > Agreed. It will be interesting to see whether or not this information > is actually being collected, since I've only shown that it's > *possible* for it to be collected, not that it actually is. > > > Going back to the legality, even if the URL is just the begining of an > HTTP > > negotiation process, it doesn't mean that URLs are not payloads legally. > In > > many countries only layers 4 (transport) and bellow (TCP info, IP data, > etc) > > would be considered header information and all the rest would be > considered > > payload, incluing the URL. If what Rosenberg claims is that a URL is not > > considered payload to the law, I thing he might have to review his > concepts. > > In Brazil, for instance, capturing the URL alone in this scenario would > > constitute a crime of illegal wiretapping. > > > > I never made this claim. I explicitly state that the legality of this > needs to be investigated, since to my knowledge, it's an open legal > question in the United States. > > Well, it wasn´t clear to me, that´s why I used a "IF" when questioning your claims. Maybe I should have made it Bigger. :) Since we are on that, there´s one question I think you could answer. Are URLs content or header information in your opinion? (kind of the main point I was raising doubts about) Regards, > Dan > > Regards, Pablo Ximenes > > > > Regards, > > > > Pablo Ximenes > > > > 2011/12/6 Christian Sciberras > >> > >> Or not... > >> > >> http://vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/ > >> > >> On the other hand, where that l33t hacker Drew (aka xD 0x41)? > >> Thought he'd enlighten us with more of his awesome hacking powers o
Re: [Full-disclosure] OMIGOD CIQ HACKING THE WORLD.
Hi All, Based on what I read from the post, basically Rosenberg recognises he has no clue about what happens with the rest of affected phone models: * "One important thing to note is that this represents the metrics that are submitted to the CarrierIQ application by the code written by Samsung. The list of available metrics are carrier specific, but will remain constant on a given handset model. The subset of this data that is actually recorded and collected is at the discretion of the carrier, and is based on the profile installed on the device.**"* (Dan Rosenberg) So the eavesdropped data with respect to the rest of affected phones could be anything for all he knows, including contents of SMS's and visited pages. And about collecting every URL (even https ones) that is visited. Forget about the legality, let's go directly to the privacy implications. For instance, if you do that for a simple Facebook session, there's a huge amount of very private information being collected (fixed URLS that reveal photos, etc; ajax URLs that reveal juicy IDs, among other things). Also, I don't think anybody would want to have their complete web history in the hands of anyone without their express consent. Going back to the legality, even if the URL is just the begining of an HTTP negotiation process, it doesn't mean that URLs are not payloads legally. In many countries only layers 4 (transport) and bellow (TCP info, IP data, etc) would be considered header information and all the rest would be considered payload, incluing the URL. If what Rosenberg claims is that a URL is not considered payload to the law, I thing he might have to review his concepts. In Brazil, for instance, capturing the URL alone in this scenario would constitute a crime of illegal wiretapping. Regards, Pablo Ximenes 2011/12/6 Christian Sciberras > Or not... > > http://vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/ > > On the other hand, where that l33t hacker Drew (aka xD 0x41)? > Thought he'd enlighten us with more of his awesome hacking powers on this > issue. > > ___ > 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] Facebook Attach EXE Vulnerability
I see. I have seen this kinda behavior from vendors too often. I supose the reason for this is the flood of false positives. I think they need a better way to sift the wheat from the chaff. Congrats for your work! 2011/10/28 Nathan Power > I was basically told that Facebook didn't see it as an issue and I was > puzzled by that. Ends up the Facebook security team had issues reproducing > my work and that's why they initially disgarded it. After publishing, the > Facebook security team re-examined the issue and by working with me they > seem to have been able to reproduce the bug. > > > Nathan Power > www.securitypentest.com > > > On Fri, Oct 28, 2011 at 11:18 AM, Pablo Ximenes wrote: > >> Not fixed yet. At least not yesterday when I checked. >> >> Nathan, didn't Facebook ask for some time to fix this bug after they have >> acknowledged it? >> >> >> Pablo Ximenes >> <http://ximen.es/>http://ximen.es/ >> <http://twitter.com/pabloximenes>http://twitter.com/pabloximenes >> >> Em 27/10/2011, às 19:29, Joshua Thomas < >> rappercra...@gmail.com> escreveu: >> >> can't believe such was on FB wahahaha !!! lol rofl ... >> >> When was this discovered and fixed ? >> >> >> On Thu, Oct 27, 2011 at 1:02 AM, Nathan Power < >> >> n...@securitypentest.com> wrote: >> >>> >>> - >>> 1. Summary: >>> >>> When using the Facebook 'Messages' tab, there is a feature to attach a >>> file. >>> Using this feature normally, the site won't allow a user to attach an >>> executable file. >>> A bug was discovered to subvert this security mechanisms. Note, you do >>> NOT have >>> to be friends with the user to send them a message with an attachment. >>> >>> >>> - >>> >>> Read the rest of this advisory here: >>> >>> <http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html><http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html> >>> http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html >>> >>> >>> Enjoy :) >>> >>> >>> Nathan Power >>> <http://www.securitypentest.com> <http://www.securitypentest.com> >>> www.securitypentest.com >>> >>> ___ >>> Full-Disclosure - We believe in it. >>> Charter: >>> <http://lists.grok.org.uk/full-disclosure-charter.html><http://lists.grok.org.uk/full-disclosure-charter.html> >>> http://lists.grok.org.uk/full-disclosure-charter.html >>> Hosted and sponsored by Secunia - <http://secunia.com/><http://secunia.com/> >>> http://secunia.com/ >>> >> >> ___ >> Full-Disclosure - We believe in it. >> Charter: >> <http://lists.grok.org.uk/full-disclosure-charter.html><http://lists.grok.org.uk/full-disclosure-charter.html> >> http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - <http://secunia.com/><http://secunia.com/> >> 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] Facebook Attach EXE Vulnerability
Agreed. What I'm asking is whether Facebook did ask him to wait. Did it? If it did it's a whole different ball game. Pablo Ximenes http://ximen.es/ http://twitter.com/pabloximenes Em 28/10/2011, às 13:01, Peter Dawson escreveu: I dont think that he waited for vendor to confirm fix in production and I dont see a reason that he needs to wait . If FB did not ask him to refrain from disclosure.. y shld he ? 09/30/2011 Reported Vulnerability to the Vendor 10/26/2011 Vendor Acknowledged Vulnerability 10/27/2011 Publicly Disclosed On Fri, Oct 28, 2011 at 11:18 AM, Pablo Ximenes wrote: > Not fixed yet. At least not yesterday when I checked. > > Nathan, didn't Facebook ask for some time to fix this bug after they have > acknowledged it? > > > Pablo Ximenes > <http://ximen.es/>http://ximen.es/ > <http://twitter.com/pabloximenes>http://twitter.com/pabloximenes > > Em 27/10/2011, às 19:29, Joshua Thomas < > rappercra...@gmail.com> escreveu: > >can't believe such was on FB wahahaha !!! lol rofl ... > > When was this discovered and fixed ? > > > On Thu, Oct 27, 2011 at 1:02 AM, Nathan Power < > > n...@securitypentest.com> wrote: > >> >> - >> 1. Summary: >> >> When using the Facebook 'Messages' tab, there is a feature to attach a >> file. >> Using this feature normally, the site won't allow a user to attach an >> executable file. >> A bug was discovered to subvert this security mechanisms. Note, you do NOT >> have >> to be friends with the user to send them a message with an attachment. >> >> >> - >> >> Read the rest of this advisory here: >> <http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html><http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html> >> http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html >> >> >> Enjoy :) >> >> >> Nathan Power >> <http://www.securitypentest.com/> <http://www.securitypentest.com/> >> www.securitypentest.com >> >> ___ >> Full-Disclosure - We believe in it. >> Charter: >> <http://lists.grok.org.uk/full-disclosure-charter.html><http://lists.grok.org.uk/full-disclosure-charter.html> >> http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - <http://secunia.com/><http://secunia.com/> >> http://secunia.com/ >> > > ___ > Full-Disclosure - We believe in it. > Charter: > <http://lists.grok.org.uk/full-disclosure-charter.html><http://lists.grok.org.uk/full-disclosure-charter.html> > http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - <http://secunia.com/><http://secunia.com/> > 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 - 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] Facebook Attach EXE Vulnerability
Not fixed yet. At least not yesterday when I checked. Nathan, didn't Facebook ask for some time to fix this bug after they have acknowledged it? Pablo Ximenes http://ximen.es/ http://twitter.com/pabloximenes Em 27/10/2011, às 19:29, Joshua Thomas escreveu: can't believe such was on FB wahahaha !!! lol rofl ... When was this discovered and fixed ? On Thu, Oct 27, 2011 at 1:02 AM, Nathan Power < n...@securitypentest.com> wrote: > > - > 1. Summary: > > When using the Facebook 'Messages' tab, there is a feature to attach a > file. > Using this feature normally, the site won't allow a user to attach an > executable file. > A bug was discovered to subvert this security mechanisms. Note, you do NOT > have > to be friends with the user to send them a message with an attachment. > > > - > > Read the rest of this advisory here: > > <http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html> > http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html > > > Enjoy :) > > > Nathan Power > <http://www.securitypentest.com>www.securitypentest.com > > ___ > Full-Disclosure - We believe in it. > Charter: <http://lists.grok.org.uk/full-disclosure-charter.html> > http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - <http://secunia.com/>http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: <http://lists.grok.org.uk/full-disclosure-charter.html> http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - <http://secunia.com/>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] Twitter URL spoofing still exploitable
Aparently twitter is back to normal, t.co isn't showing in place of every URL anymore. This was indeed temporary while they were fixing things as mentioned. Att, Pablo Ximenes http://ximen.es/ http://twitter.com/pabloximenes 2011/9/27 Benji : > If you hover over the t.co links the alt= tag holds the real url. > > On Tue, Sep 27, 2011 at 4:11 PM, dave bl wrote: >> >> On 28 September 2011 01:00, Mario Vilas wrote: >> > On Tue, Sep 27, 2011 at 3:26 PM, Dan Kaminsky wrote: >> >>> >> >>> Ok, now nobody can spoof a URL, but how come a user will tell good >> >>> URLs and bad ones apart? Oh boy! >> >>> >> >> >> >> Wherever did you get the idea that users can do this? >> > >> > Jokes apart, I do find it annoying that URLs aren't expanded >> > automatically >> > anymore. But I don't expect this situation to be permanent. >> >> Agreed. >> >> ___ >> 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 - http://secunia.com/
[Full-disclosure] Twitter URL spoofing still exploitable
Some of you might consider this blog post of value: http://ximen.es/?p=534 Thanks, Pablo Ximenes http://ximen.es/ http://twitter.com/pabloximenes ___ 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] Vulnerabilities in *McAfee.com
FIY
http://it.slashdot.org/story/11/03/28/209230/McAfees-Website-Full-of-Security-Holes
Pablo Ximenes
http://ximen.es/
http://twitter.com/pabloximenes
2011/3/28 Pablo Ximenes :
> blog post about this: http://ximen.es/?p=469
>
> Please, don't throw stones at me.
>
> []'s
>
>
> Pablo Ximenes
> http://ximen.es/
> http://twitter.com/pabloximenes
>
>
>
> 2011/3/27 YGN Ethical Hacker Group
>>
>> Vulnerabilities in *McAfee.com
>>
>>
>> 1. VULNERABILITY DESCRIPTION
>>
>> -> Cross Site Scripting
>>
>> http://download.mcafee.com/products/webhelp/4/1033/#javascript:top.location.replace('attacker.in')
>>
>> -> Information Disclosure > Internal Hostname:
>> http://www.mcafee.com/js/omniture/omniture_profile.js
>>
>> ($ ruby host-extract.rb -a
>> http://www.mcafee.com/js/omniture/omniture_profile.js)
>>
>> -> Information Disclosure > Source Code Disclosure:
>>
>>
>> view-source:http://download.mcafee.com/clinic/includes/commoninc/cookiecommon.asp
>>
>> view-source:http://download.mcafee.com/clinic/includes/commoninc/appcommon.asp
>>
>> view-source:http://download.mcafee.com/clinic/includes/commoninc/partnerCodesLibrary.asp
>> view-source:http://download.mcafee.com/clinic/Includes/common.asp
>> view-source:http://download.mcafee.com/updates/upgrade_patches.asp
>>
>> view-source:http://download.mcafee.com/updates/common/dat_common.asp
>> view-source:http://download.mcafee.com/updates/updates.asp
>> view-source:http://download.mcafee.com/updates/superDat.asp
>> view-source:http://download.mcafee.com/eval/evaluate2.asp
>> view-source:http://download.mcafee.com/common/ssi/conditionals.asp
>>
>> view-source:http://download.mcafee.com/common/ssi/errHandler_soft.asp
>> view-source:http://download.mcafee.com/common/ssi/variables.asp
>>
>> view-source:http://download.mcafee.com/common/ssi/standard/oem/oem_controls.asp
>> view-source:http://download.mcafee.com/common/ssi/errHandler.asp
>> view-source:http://download.mcafee.com/common/ssi/common_subs.asp
>>
>> view-source:http://download.mcafee.com/us/upgradeCenter/productComparison_top.asp
>> view-source:http://download.mcafee.com/us/bannerAd.asp
>>
>> view-source:http://download.mcafee.com/common/ssi/standard/global_foot_us.asp
>>
>>
>> 2. RECOMMENDATION
>>
>> - Fully utilize Mcafee FoundStone Experts
>> - Use outbound monitoring of traffic to detect potential information
>> leakage
>>
>>
>> 3. VENDOR
>>
>> McAfee Inc
>> http://www.mcafee.com
>>
>>
>> 4. DISCLOSURE TIME-LINE
>>
>> 2011-02-10: reported vendor
>> 2011-02-12: vendor replied "we are working to resolve the issue as
>> quickly as possible"
>> 2011-03-27: vulnerability found to be unfixed completely
>> 2011-03-27: vulnerability disclosed
>>
>>
>> 5. REFERENCES
>>
>> Original Advisory URL:
>>
>> http://yehg.net/lab/pr0js/advisories/sites/mcafee.com/[mcafee]_xss_infoleak
>> Former Disclosure, 2008:
>> http://www.theregister.co.uk/2008/06/13/security_giants_xssed/
>> Former Disclosure, 2009:
>>
>> http://news.softpedia.com/news/McAfee-Websites-Vulnerable-to-Attacks-110667.shtml
>> Former Disclosure, 2010:
>>
>> http://security-sh3ll.blogspot.com/2010/04/mcafee-communities-xss-defacement.html
>> host-extract: http://code.google.com/p/host-extract/
>> Demo: http://yehg.net/lab/pr0js/training/view/misc/XSSing_McAfee_Secured/
>> xssed: http://www.xssed.com/search?key=mcafee.com
>> Lessont Learn:
>> http://blogs.mcafee.com/mcafee-labs/from-xss-to-root-lessons-learned-from-a-security-breach
>>
>> #yehg [2011-03-27]
>>
>> ___
>> 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] Vulnerabilities in *McAfee.com
blog post about this: http://ximen.es/?p=469
Please, don't throw stones at me.
[]'s
Pablo Ximenes
http://ximen.es/
http://twitter.com/pabloximenes
2011/3/27 YGN Ethical Hacker Group
> Vulnerabilities in *McAfee.com
>
>
> 1. VULNERABILITY DESCRIPTION
>
> -> Cross Site Scripting
>
> http://download.mcafee.com/products/webhelp/4/1033/#javascript:top.location.replace('attacker.in
> ')
>
> -> Information Disclosure > Internal Hostname:
>http://www.mcafee.com/js/omniture/omniture_profile.js
>
>($ ruby host-extract.rb -a
> http://www.mcafee.com/js/omniture/omniture_profile.js)
>
> -> Information Disclosure > Source Code Disclosure:
>
>view-source:
> http://download.mcafee.com/clinic/includes/commoninc/cookiecommon.asp
>view-source:
> http://download.mcafee.com/clinic/includes/commoninc/appcommon.asp
>view-source:
> http://download.mcafee.com/clinic/includes/commoninc/partnerCodesLibrary.asp
>view-source:http://download.mcafee.com/clinic/Includes/common.asp
>view-source:http://download.mcafee.com/updates/upgrade_patches.asp
>view-source:
> http://download.mcafee.com/updates/common/dat_common.asp
>view-source:http://download.mcafee.com/updates/updates.asp
>view-source:http://download.mcafee.com/updates/superDat.asp
>view-source:http://download.mcafee.com/eval/evaluate2.asp
>view-source:http://download.mcafee.com/common/ssi/conditionals.asp
>view-source:
> http://download.mcafee.com/common/ssi/errHandler_soft.asp
>view-source:http://download.mcafee.com/common/ssi/variables.asp
>view-source:
> http://download.mcafee.com/common/ssi/standard/oem/oem_controls.asp
>view-source:http://download.mcafee.com/common/ssi/errHandler.asp
>view-source:http://download.mcafee.com/common/ssi/common_subs.asp
>view-source:
> http://download.mcafee.com/us/upgradeCenter/productComparison_top.asp
>view-source:http://download.mcafee.com/us/bannerAd.asp
>view-source:
> http://download.mcafee.com/common/ssi/standard/global_foot_us.asp
>
>
> 2. RECOMMENDATION
>
> - Fully utilize Mcafee FoundStone Experts
> - Use outbound monitoring of traffic to detect potential information
> leakage
>
>
> 3. VENDOR
>
> McAfee Inc
> http://www.mcafee.com
>
>
> 4. DISCLOSURE TIME-LINE
>
> 2011-02-10: reported vendor
> 2011-02-12: vendor replied "we are working to resolve the issue as
> quickly as possible"
> 2011-03-27: vulnerability found to be unfixed completely
> 2011-03-27: vulnerability disclosed
>
>
> 5. REFERENCES
>
> Original Advisory URL:
> http://yehg.net/lab/pr0js/advisories/sites/mcafee.com/[mcafee]_xss_infoleak
> Former Disclosure, 2008:
> http://www.theregister.co.uk/2008/06/13/security_giants_xssed/
> Former Disclosure, 2009:
>
> http://news.softpedia.com/news/McAfee-Websites-Vulnerable-to-Attacks-110667.shtml
> Former Disclosure, 2010:
>
> http://security-sh3ll.blogspot.com/2010/04/mcafee-communities-xss-defacement.html
> host-extract: http://code.google.com/p/host-extract/
> Demo: http://yehg.net/lab/pr0js/training/view/misc/XSSing_McAfee_Secured/
> xssed: http://www.xssed.com/search?key=mcafee.com
> Lessont Learn:
> http://blogs.mcafee.com/mcafee-labs/from-xss-to-root-lessons-learned-from-a-security-breach
>
> #yehg [2011-03-27]
>
> ___
> 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] Other recommended lists?
I ask: Might calling someone a troll in an unsubstantiated fashion be considered trolling? Pablo Ximenes http://ximen.es/ http://twitter.com/pabloximenes 2011/2/21 Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> > But you've not proven anything. All you've done is said "I rest my case". > > I refer you also to: > http://www.urbandictionary.com/define.php?term=trolling > > > On Mon, Feb 21, 2011 at 7:12 PM, Paul Schmehl wrote: > >> I rest my case. >> >> >> --On February 21, 2011 7:04:33 PM + "Cal Leeming [Simplicity Media >> Ltd]" wrote: >> >> And why is that, Paul? >>> >>> >>> On Mon, Feb 21, 2011 at 7:03 PM, Paul Schmehl >>> wrote: >>> >>> >>> >>> >>> --On February 21, 2011 6:15:07 PM + "Cal Leeming [Simplicity Media >>> Ltd]" wrote: >>> >>> >>> Can anyone recommend any decent lists, preferably that are moderated >>> against douchebaggery and trolls (but allow swearing and insults etc), >>> and allows for general security/tech related discussion? >>> >>> >>> Seriously? I think it's safe to assume you don't understand irony. >>> >> >> >> >> -- >> Paul Schmehl, Senior Infosec Analyst >> As if it wasn't already obvious, my opinions >> are my own and not those of my employer. >> *** >> "It is as useless to argue with those who have >> renounced the use of reason as to administer >> medication to the dead." Thomas Jefferson >> "There are some ideas so wrong that only a very >> intelligent person could believe in them." George Orwell >> >> > > ___ > 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] On the iPhone PDF and kernel exploit
I believe Jailbreakme.com is just REsurfacing,as it used to be used back in the days of the first gen iPhone also for jailbreaking. So, it's not excatly the first time this is happening. []'s Pablo Ximenes (aka brasuco) 2010/8/4 Marcello Barnaba (void) > For the first time in my life, a 0-day exploiting remote code execution, > sandbox escaping and privilege escalation has been packaged for general > user consumption via a web site ( http://jailbreakme.com ). The actual > pdf exploit can be downloaded here: http://jailbreakme.com/_/. > > What puzzles me is.. no notices here on FD, no info on Bugtraq, no CVE, > no press release by the CERT, as of now. > > The cat & mouse game played by the iPhone dev team and Apple is done to > liberate our devices from useless restrictions, but the whole point for > them to exist is because said devices live in a walled garden, that is > really useful only to the company behind it. > > I've posted more thougths and the few technical details I was able to > gather (from a tweet!) here: > > http://sindro.me/2010/8/4/on-the-iphone-pdf-and-kernel-exploit > > What do you think? Did someone reverse engineer the exploit? > > ~Marcello > -- > ~ marcello.barn...@gmail.com > ~ http://www.linkedin.com/in/marcellobarnaba > ~ http://sindro.me/ > > > > > ___ > 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] DoS vulnerability in Internet Explorer
Crhome isn't vulnerable!
:P
2010/6/1 PsychoBilly
> This had already been published
> http://www.pewy.fr/hamster.html
>
> Cluster #[[ Laurent Gaffie ]] possibly
> emitted, @Time [[ 01/06/2010 16:00 ]] The Following #String
> **
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Sorry Mustlive,
> > i understand you need to see this in clear text finaly.
> > I guess ascii is the best to communicate with you;
> >
> >
> > Hello Full-Disclosure!
> >
> > I want to warn you about a Denial of Service in every browser finaly !!!
> >
> > It actually affect every browser with a javascript engine build in !!!
> >
> > Adobe may be vulnerable to
> >
> > PoC :
> >
> >
> > 0n0z
> >
> >
> > for (i=0;i<65535;i++) {
> > alert('0n0z mustlive got you, now you're fucked, the only solution is
> > to restart your browser or be faster than JS !!!');
> > }
> >
> >
> >
> >
> >
> > Greetz to mustl...@oswap.com.ua
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQIcBAEBAgAGBQJMBRJkAAoJEEESJ0AJ05HwJpYQAI84bDG8fNbq4lYjomqD3+Wf
> > 29VzhaQt39FF2ERwh7sDYkc5wdw/DWfAC5SpwdVtr/0wDW0dyZV36RfJyUixysce
> > weKx5wztjjwzk4yQF61v8DXz7MEWLhuYv9fTGcw9LKpnDm9/Z0YZ6ObKp8dE9A11
> > 1E4xzAByLYpEdTQyxosMsJ336oJgTc3NrjDiPJGoxOb65epLlc07aEaP7ZA7jE/J
> > i+M0ukNl8CKAryGs8DhDf+5fkJf1wcqOUoxK4mJ4nPe0IhhoQ+FUizB04E7MpK8P
> > OisvgW8I6tdGurJTfux14Jj6NZXBuL0ww65e3vfgOrm8WRtKPrbwiRd1nk8NqsCC
> > Nz5UBxEr32YhEUdgoXPj8ZleBbvLL0z0PVoRtbBSyKABih8OUwPMUpa0WkpMno+x
> > gcG7vmO/bIr5wEjRGlK9NglCMqKNWzRk2f03KGIM2MMetB7KLvR/Kir3rL2n8a4k
> > nLj/EYRm4orHzIDtR/Fr8LixJPr1wwpi53OOPJEcpjDvud4sOKcfUPSb7cckc7wQ
> > vBPCNjPZ1D8V3GzJhE7+NHVVl8wUDwKodu0ejDmzJ2K7L1nLDiI9GStA8Xof98ne
> > 4ZBLA3lCRsbcYDdE0cvqwMa+xyx7KUcMy5M8vimyTGpIhnFF2+ScdFgFzrDIEtNH
> > g+1w9Kvgr12i+aEmD2Me
> > =v3oL
> > -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 - http://secunia.com/
