Re: [Full-disclosure] Vulnerability in Zombie Processes
you have too much time on your hands, but this is hilarious stuff =)
It's true though, most people don't even know what a zombie process is :(
On Tue, Jun 12, 2012 at 11:34 AM, Григорий Братислава
musntl...@gmail.com wrote:
Hello is Full Disclosure!! !! !!
Is like to warn you about is Zombie apocalypse. Is only on OpenBSD is
exist zombie process. Is can be seen like how:
ps -xua | awk '$8 == Z'
Is musntlive develop process 25 years ago is stop
/*
*
* зомби.c
* musntLive is musnt give away is LUA
* Flamer Kaspersky creation secrets
*
*/
void getMessage(lua_State* L, int idx, void* ptr)
{
*(const char**)ptr = lua_tostring(L, idx);
}
...
lua_CFunction fct;
const char* msg;
lua_genpcall(L, return print, 'z0mb!3S',
%c %k, fct, getMessage, msg);
lua_pushstring(L, msg);
fct(L);
Is more information on Zombies
A Pennsylvania woman driving a car with the license plate ZOMBIE is
accused of hitting two pedestrians with her car and then zapping
another man with a stun gun:
http://content.usatoday.com/communities/ondeadline/post/2012/06/zombie-attack-leads-to-arrest-in-pennsylvania/1#.T9dYyrXh-So)
Special ammunition optimised for fighting zombies is selling like hot
cakes in the USA, according to reports, following sensational media
coverage of incidents involving flesh-eating and similar undead-esque
behaviour. http://www.theregister.co.uk/2012/06/11/zombie_bullets/
'Miami zombie' attack autopsy: Ronald Poppo's flesh not found in Rudy
Eugene's stomach
http://www.wptv.com/dpp/news/news_archives/miami-zombie-attack-autopsy-ronald-poppos-flesh-not-found-in-rudy-eugenes-stomach#ixzz1xamf8d9l
Cranberries http://www.youtube.com/watch?v=6Ejga4kJUts
___
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] Obama Order Sped Up Wave of Cyberattacks Against Iran
I know for a fact HBGary was working with the NSA in regards to stuxnet. I've never been all that good at spelling... but am I wrong that HBGary is an anagram for posturing charlatan ? Alternatively: if this is true then we are even worse off than I thought. ___ 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] Obama Order Sped Up Wave of Cyberattacks Against Iran
On Wed, Jun 6, 2012 at 12:13 PM, Laurelai laure...@oneechan.org wrote: On 6/6/12 11:50 AM, Charles Morris wrote: I know for a fact HBGary was working with the NSA in regards to stuxnet. I've never been all that good at spelling... but am I wrong that HBGary is an anagram for posturing charlatan ? Alternatively: if this is true then we are even worse off than I thought. It was in the leaked HBgary emails, communications with the NSA regarding stuxnet. Why am i the only one who remembers this? I don't agree, disagree, or comment in any other way than my surprise, as I want to have respect for the NSA- but I suppose there are bad decisions made in any organization. ___ 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] things you can do with downloads
Let's just ditch browsers already. =) On Wed, May 30, 2012 at 4:35 PM, Michal Zalewski lcam...@coredump.cx wrote: Another moderately interesting tidbit, I guess... ___ 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] FW: Curso online - Profesional pentesting - Promocion ( 25% de descuento )
I request your permission to test any and all of your facilities in any way I deem appropriate including (by not limited to) your personal machines, the machines of your coworkers and family, and any other device I deem within scope of my testing. Further, I request you to grant full, unlimited access and authorization for me to test these devices in any way I see fit with full unadulterated impunity. stop flexing ___ 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] Vulnerability in is Dopewars
You should have went to a CERT with this, shouldn't vendor coordination be of urgency here? On Thu, May 17, 2012 at 12:35 PM, Григорий Братислава musntl...@gmail.com wrote: Hello Full-Disclosure!! !! !! Is like to warn you about is vulnerability in Dopewars. I'm is discover vulnerability perhaps 10 years ago but is posting now. Is problem exist when carry more than is 50 cocaines and is Officer Hardass (pitifully armed) is kill 2 of is your bitches. Is when this happen player is obviously targeted! Is exploit will happen only when player is in is Brooklyn (not Queens) and is has identity given to Officer Hardass! Proof exist in code: 8056370: 85 c0 test %eax,%eax 8056372: 7f dc jg 8056350 gtk_clist_select_row@plt+0x7da0 8056374: eb b9 jmp 805632f gtk_clist_select_row@plt+0x7d7f 8056376: 8d 76 00 lea 0x0(%esi),%esi 8056379: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi 8056380: 55 push %ebp 8056381: 89 e5 mov %esp,%ebp 8056383: 53 push %ebx 8056384: 83 ec 14 sub $0x14,%esp 8056387: 8b 5d 0c mov 0xc(%ebp),%ebx 805638a: c7 44 24 04 00 00 00 movl $0x46256595(%eip) // -- Is hardcoded proof perl -e 'printf Barrett your is bed is ready @ . 0x . %02xx4.\n,70,37,101,149' Is MusntLive not contact Dopewars developer this year but next when is I release new advisory! (NO IS HAMSTER IS HURT DURING IS MAKING OF IS POST AND IS NO LUMBERJACKS IS HARMED ISEVER SEKTIEWHOARE IS EXPOSED) ___ 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] We're now paying up to $20, 000 for web vulns in our services
On Tue, Apr 24, 2012 at 11:13 AM, Michal Zalewski lcam...@coredump.cx wrote: IMHO, anyone who willingly, knowingly places customer data at risk by inviting attacks on their production systems is playing a very dangerous game. There is no guarantee that a vuln discovered by a truly honest researcher couldn't become a weapon for the dishonest researcher through secondary discovery I'm not sure I follow. Are you saying that the dishonest researcher will not try to find vulnerabilities if there is no reward program for the honest ones? /mz I'm not sure what he means either, however I know that many organizations treat security patches to the same lifecycle as features, which means sometimes upwards of a year of testing- thus giving a huge window for secondary discovery; whereas a vuln exploited in-the-wild generally has a much faster patch. Still I'm not sure how this fact is relevant, if it is at all. Perhaps if the adversary sees the vuln in unencrypted email between researcher and organization and then uses it silently making sure not to alert anyone? Not sure, but I digress. I don't know who believes that they are owed anything in this manner, and I agree with you, Jim, on that point. However, my main complaint is that businesses should either not pay anything at all (perhaps 1$ as a token of gratitude, some swag or some such), or at least make a real effort. Finding a code execution vuln in google's whatever app-of-the-day is non-trivial task that requires researchers to learn a completely new landscape. I would expect Google, of all people, to pay 10x to 100x this amount for this sort of thing.. A you-only-get-it-when-successful 20,000$ budget from Google is insulting, considering the perhaps massive time investment from the researcher. There is zero ability to make an argument that such businesses can't realistically outcompete all buyers of weaponized exploits as Michal has done [ :'( ]. The huge amount of damage that a badguy code executing on google wallet would cost far more than 2M in damages, repair work, lost business, and penalties; and yet they only pay a nice researcher 20 grand? You can't even live on that. Researchers aren't just kids with no responsibilities, they have mortgages and families. Increase the payouts and you not only get good guys doing good things but you also get bad guys doing good things (even if for the wrong reasons). n.b. The fact that badguys take risk when doing their badguy activities, including selling exploits, makes it even easier to outcompete the buyers. Still, this is a huge improvement on what it was if memory serves. A million thanks to Michal ! ___ 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] Hacking AutoUpdate by Injecting Fake Updates
Welcome to 2002 On Tue, Apr 3, 2012 at 10:01 AM, Adam Behnke a...@infosecinstitute.com wrote: We all know that hackers are constantly trying to steal private information by getting into the victim's system, either by exploiting the software installed in the system or by some other means. By performing routine updates for their software, consumers can protect themselves, patching known vulnerabilities and therefore greatly reducing the chance of getting hacked. Commonly used software, such as MS Office, Adobe Flash and PDF reader (as well as the browsers themselves) are the major targets for exploits if left unpatched. In the past, fake patches for Firefox, IE, etc. displayed messages informing users that updated versions for a plugin or the browser were available, prompting the user to update their software. For example, the page will tell the user that updating their Flash version is critical. Once the user clicks the fake update, it will download malicious content (like, for example, the Zeus Trojan) to the victim's computer, as well as perhaps a rogue anti-virus, asking the user to pay in order to remove the infections. Similar attacks have been done in the past for various browsers, too. When you think about it, how many people are really cautious about the updates, the type of update or the link from where they are downloading and installing the update? Obviously, there are very few people that are really cautious and vigilant about updates, therefore making the success rates for those exploiting the users high. Read more about how to perform a few different AutoUpdate man-in-the-middle attacks that work against Java, AppleUpdate, Google Analytics, Skype, Blackberry and more: http://www.ethicalhacking.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] when did piracy/theft become expression of freedom
Dear Valdis and whoever else; The really ridiculous points are the following: A) Every time you execute/install/download a program you are committing evil data theft by not only copying secret or illegal information into RAM/Disk/Registers/Buffers/Busses/photons coming off the screen/human memory/history of the universe but potentially not just your physical property but on hundreds of routers and deduplication boxen around the earth. B) You can't copyright or own a number, all digital representations are numbers, due to the boolean nature (no fuzzy data), etc. C) Any data is a form of any other data given a specific transform, e.g. manifold / encryption key + algo, something as trivial as XOR D) You guys already know these points so why do we even care anymore about what these people say? Why even have these conversations. They will never stop. It's about greed and shortsightedness, not about what is moral or logical. Just try to ignore them or change the subject when the parrots start talking. And to preempt the flames from the blind, Yes I feel artists should be compensated for their contribution. It's 5am- bye. On Sat, Jan 28, 2012 at 5:26 PM, valdis.kletni...@vt.edu wrote: On Fri, 27 Jan 2012 19:02:09 PST, Zach C. said: If you buy an album used, the seller generally loses possession of it, you gain possession of it at a reduced cost, and the original purchase still gave the original seller and producer value. Note that if I shoplift a CD that sucks and isn't worth the $14.99 sticker price, I have deprived the producer of the ability to sell it to somebody else. That's the crucial point that underlies our social concept of theft - if I take it from you, you don't have it anymore. If I copy an album that isn't worth the sticker price, and which I would not have purchased at that price, two things of note happen: 1) As much as the labels wish it were so, they can't count that as lost revenue because it wouldn't have acccrued to them anyhow, any more than a car dealership can legitimately call it lost revenue if I walk onto their lot, tell the salescritter they're crazy if they think I'll pay $28K for a given car, and walk off the lot. (Now, if they want to count the Damn, we lost the $4.99 that guy *would* have paid if we charged that instead of $14.99, they're welcome to that. :) 2) More importantly, they still have the original bits and are free to look for other suckers who *will* pay $14.99. For the record, all my media is legitimately acquired, though a large portion *was* obtained used and if the producers don't like that, they're welcome to go re-read first sale doctrine ;) Just trying to make people actually engage their neurons - this stuff is *not* easy to sort out, because intellectual property and digital information do *not* behave the same as cars and cows in the physical world, and unintended consequences of policy decisions are all *over* the place. (DMCA anti-circumvention clause prohibiting me from fair-use accessing my own media, I'm looking at you. :) ___ 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] OT: Firefox question / poll
I'm curious what everyone's opinion is on the following question... esp. to any FF dev people on list: Do you think that the Firefox warning: unresponsive script is meant as a security feature or a usability feature? ___ 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
Just quickly I digress; this is a massive problem in the mindset of many. They won't ever learn about something if they aren't ever made aware of it. Say, by fixing the problem... I have seen the most users don't understand X anyway as an argument against fixing X in the browser several times before, and I think that's wrong; but I'm not sure this is applicable here. /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/
Re: [Full-disclosure] Minimum Syslog Level Needed for Court Trial
Okay.. I'd be happy to help you, but could you rephrase the question? So, whos going to offer REAL DAMN ONLINE SEC HELP HERE , SIMPLE On Fri, Dec 9, 2011 at 5:27 AM, xD 0x41 sec...@gmail.com wrote: Oh wow anothwer fucking genius! Upir actually know him, why arent you a nice guy who thimks theyre top shit..but again, as alwys, offering VERY little helpf for *gordon* are you...dickhead thats what makes me angry about thsi list..look at whats been done, to the no.1 pentestin app EVERY1 of u has used in some form...and, you cannot even figure out, hwo to help the guy like, ive seeen yo0u make more of a fucking fuss. over some bs topic that meant nothing but trolling and abuse... yet when it is time to REALLY help, only few remain... lamers...and believe me, i dont need FD to tell me shit, and prosec, your fucking over... stupid gay faggots... you and your arsehole mates at GNAA are gonna regret being the arseholes you are today... i know, my friend there at fibertel, is definately.. but, dont worry, this troll will come running now from gnaa ,the gay Nigger Association of America ? right... wel, thts what the ezxines say... :P So, whos going to offer REAL DAMN ONLINE SEC HELP HERE , SIMPLE DONT POINT ANY FINGERS, NOR CHANGE THE DARN TIC, IF YOU BELIEVE IN SOMETHING, AND SOMEONE WHO IS HELPING YOU THEN GET THE FUCK UP OFF YOUR ASS, AND ATLEAST, HELP HIM MAYBE SIGN A NICE BIGARSE LIST OF COMPLAINEES WHO *USE TYHE SOFTWAFRE* AND, ALSO, SOME WHO HAVE EXPERINCED THE BAD INSTALLER... NOW, WHEN YOU MAYBE, DO SOMETHIN USEFUL, ON THE LIST HERE, LIKE, THIS IS BEING IGNORED... ANDF, I SEE THAT FYODOR, AND, I DUN CARE WHAT OR WHO THE FK HE IS, GOT ME ? IT IS ABOUT ONLINE SECURITY, AND WHERE OUR BVOICES ARE HEARD... IS THIS GOING TO NOW TUIRN INTO A BS JOKE , OR, IS PEOPLE GOING TO MAYBE, ACTUALLY MAKE THE VOICE AM ASKING YOU TO MAKE, BUT, MAKE THE NOISE, ABOUT WHATS HAPPENED TO NMAP,, AND, I HOPE THAT GORDON, OR WHOEVER THE FK HE IS, CAN ATLEAST SPELL THE DAQMN LAWYERS NAME COZ, SOFAR, HE IS RELYING ON online HELP FOR AN offline MATTER...SORRY BUT, IT STARTED ONLINE, but THEY BREACHED CONTRACT, BRINGING IT BACK, TO CIVIL, THEN CRIMINAL...SO, GO TELL ME SSOMETHING I DONT KNOW, AND MAYBE WE WILL SEE SOME HELP, FOR REAL HERE... SERIOUSLY, THINK ABOUT IT, IF THIS WAS YOUR DAMN TOOL, YOU HAD HELPED 'HAX0RS' USE, FOR 10YRS OR WHAT, AND, YOU GET NOTHING BUT, TRIED TO BE HIDDEN AWAY AND, TOLD TO DO THIS AND THAT, BUT, NOTHING ONLINE, WILL HELP..SIMPLE... SO, I DUN CARE WHO TAKES MY ADVICE, I WAS, AND, DID, ALOT FO TIME..SOP, KNOW ATLEAST MY RIGHTS..AND THE RIGHTS OF THE GORDON...WICH, WAS BREACHED. HE COULD SUE HARD, IF HE WAS SMART, AND DID NOT LISTEN TO FAGGOTS ONLINE TELLING HIM GOD KNOWS WHATTODO BUT, NOT TELLING HIM, TO GET LEGAL AID FIORST...AND, THIS IS THE PRIME THING, ANYIONE DOES IN ANY CASE, REQUEST A LAWYER, HEY, WATCH SOME LA CRIME SHOWS, YOU MAY EVEN LEARN, FROM HOW FKD UP USA IS,... AND HOW THE COURT SYSTEM IS, AND, THIS WOULD STILL, EVEN IF TAKENM TO COURT, PROBABLY BE A HEADLINE, AS IT HAS NOT HAPPENED B4... IF, PEOPLE TREATE THIS SERIOUSLY... IT DOES NOT MATTER, ABOUT WHO OR WHAT GORDON IS..IT MATTERS, ABOUT WHO THE VOICE IS, WICH WE HAVE..AND, IF YOU WANNA BAG ME, GO RIGHT AHEAD BUT, DONT TELL ME, I AM WRONG.. MATE AND, IF YOU DOWELL, I WOULD SAY, ,LOOKUP THE DIFFERENCES, BETWEEN A REPUBLIC, AND A DEMOCRACY, AND, A PRESIDENTIAL STATE...AND, THE SYSTEMS, WICH RULE THE ACTS,W ICH FORM THE BIL;LS, WICH GET PASSED IN PARLIAMENT... THIS CANNOT BE DONE, ON AN ONLINE FORM! WAKE THE FUCK UP, AND SERIOUSLY, LOOK AROUND YOUR NOT GUILTY OF ANYTHING RIGHT ? SO, WHWHY NOT TRY HELP, OR, OFFER SOME ADVICE THATS ATLEAST WORTHY... YOU CAN NOW RESUME ANY BAGGING, BUT REMEMBER IT IS AT THE EXPENSE AND TIME, THAT NMAP HAS...AND BELIEVE ME CNET IS WATCHING THIS INTENTLY... BECAUSE THEYRE WAITING FO THE 'OFFER' TO SETTLE ;) WHEN IM WRONG, THEN SLAP ME, UNTIL THEN STFU. On 9 December 2011 20:39, tc toughcr...@gmail.com wrote: I bet Gordon was glad to get that email. On Fri, Dec 9, 2011 at 5:13 PM, xD 0x41 sec...@gmail.com wrote: As i told Fy0d0r ___ 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] Google open redirect
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 lcam...@coredump.cx 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/
Re: [Full-disclosure] Google open redirect
Don't be strange, was I not specific enough? I think people should be encouraged to do the work, if they are good enough to find something that nobody else has noticed yet- and all of these cash for bugs programs have me a bit annoyed. Not offering the money for issues that they claim to offer for issues is not only dishonest but it is discouraging to beginning researchers. I've personally seen it happen. On Thu, Dec 8, 2011 at 9:57 AM, Benji m...@b3nji.com wrote: Sorry, you think people should be making a living off reporting open redirect disclosure? ___ 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
pretty much nearly almost implying and implying are very different things. On Thu, Dec 8, 2011 at 10:05 AM, Benji m...@b3nji.com wrote: 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. I wasn't being strange, you pretty much implied 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/
Re: [Full-disclosure] Google open redirect
I'm sure you are right about Google's intentions, it doesn't really make it any less palatable to me however. I'm just ranting really. haha On Thu, Dec 8, 2011 at 10:13 AM, Pablo Ximenes pa...@ximen.es wrote: 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 cmor...@cs.odu.edu 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 pa...@ximen.es 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] one of my servers has been compromized
Sorry paul, Gage is right here! Instead of silly maybe more like correct :( On Tue, Dec 6, 2011 at 2:42 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote: Don't be silly. You can run static binaries off a thumb drive without taking the system down. And that includes md5sum. You can put everything, including the script, on a thumb drive and be perfectly comfortable that the results are reliable, because statically compiled binaries don't use system libraries. As a quick check to see if system binaries have been altered, it's hard to beat. And I wasn't responding to the OP. I already did that the other day, when I told him he had a web app that got hacked and the scripts were run with perl, so noexec, nosuid for /tmp wouldn't have helped. I will agree with you that we don't typically see the old style hacks any more, but some hackers are still installing trojaned sshd binaries. Nowadays it's mostly app hacks and primarily (as it's always been) to Windows boxes. --On December 6, 2011 10:49:14 AM -0800 Gage Bystrom themadichi...@gmail.com wrote: But the problem with that is it is a mentality roughly a little more then a decade old. What you described is a userland rootkit detector. Problem is no one uses userland rootkits anymore! Sure there was some recent development in managed code rootkits but it really hasn't home anywhere and is Windows centric. Not to mention your plan is totally flawed. You assume md5sum is safe to begin with. Meaning that to be remotely safe with this you have to run the script for a livecd. Meaning you have to bring down the server everytime you suspect you MAY have been compromised. Completely unacceptable for anyone other than a home user. The only way to circumvent such issues is to recreate tripwire, in which you still have the same fundemental problems tripwire has always has. I know ya mean well, but your first block of advice isn't pratical or effective. The second one the OP already did so alls well for that. :) On Dec 6, 2011 10:19 AM, Paul Schmehl pschmehl_li...@tx.rr.com wrote: A poor man's root kit detector is to take md5sums of critical system binaries (you'd have to redo these after patching), and keep the list on an inaccessible media (such as a thumb drive). If you think the system is compromised, run md5sum against those files, and you will quickly know. You could even keep statically compiled copies on the thumb drive to use in an investigation. Start with things you use to check for problems; ls, ps, fstat, sockstat, netstat, wtmp, nc, sshd, etc. It would be fairly trivial to create a simple shell script that would compare the md5sums of system binaries to the saved copies and flag anomalies. And, of course, if you can take a system offline, there are a number of bootable security distros that allow you to do extensive analysis of systems. http://www.darknet.org.uk/2006/03/10-best-security-live-cd-distros-pen-t est-forensics-recovery/ In general, on Unix systems, look for oddly named directories in odd places (like /tmp, /dev, etc. and review logs that have been syslogged elsewhere for telltale signs of compromise. It's surprising how few times the shell history logs get wiped, but there are some kits out there that do that for you. Web apps and improper permissions (world writeable) are the two most frequent causes of compromises that I've seen on Unix systems. --On December 5, 2011 1:53:21 PM + Dan Ballance tzewang.do...@gmail.com wrote: Thanks for the heads-up on rkhunter Gage. Is there anything else out there atm that works as a reasonable root kit detector or is such a thing considered impossible now? I realise a skilled attack will be able to bury itself without a trace, but I'm thinking of something that can be used in less skilled breaches such as the one thought to have been identified in this thread. Sometimes something imperfect is still better than nothing I think. Also, am I correct to think that using something like tripwire is the best way to detect root kits properly, but that it obviously needs installing when the box is fresh and before it has been physically connected to a network? thanks to everyone for their valuable contributions here - much appreciated! dan :) On 5 December 2011 11:13, Gage Bystrom themadichi...@gmail.com wrote: If it was a rootkit then trying to run the outdated rkhunter would be a moot point. Whatever seizes the kernel first wins, hands down. Fortunately for him, since the bot was so easy to find in the first place and such a simple way of maintaining it, the box was clearly seized by someone who didn't give a rats ass about it. Probably a skiddie or an automated attack to begin with. As for plugging any security holes, check your httpd error logs. If you noted down the time of the bot files creation date you would look around the same time for suspicious log entries. If they were as careless in
Re: [Full-disclosure] one of my servers has been compromized
+1. Except instead of MD5 you want to use something that isn't garbage. On Tue, Dec 6, 2011 at 1:18 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote: A poor man's root kit detector is to take md5sums of critical system binaries (you'd have to redo these after patching), and keep the list on an inaccessible media (such as a thumb drive). If you think the system is compromised, run md5sum against those files, and you will quickly know. You could even keep statically compiled copies on the thumb drive to use in an investigation. ___ 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] Large password list
This is extremely depressing. On Fri, Dec 2, 2011 at 2:14 PM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:59 PM, Sanguinarious Rose sanguiner...@occultusterra.com wrote: I am at a lack of words for this, why pay $4.99 when you can just do some simple googling? You can even search pastebin and get a mass collection of password lists from dbases. Add a dash of awk and maybe a pinch of sed and viola! Why even spend the CPU cycles to process the password list? See Jon Callas' post on the Random Bits mailing list: No one bothers cracking the crypto (real life edition), http://lists.randombit.net/pipermail/cryptography/2011-December/001870.html. Interestingly (sadly?), googling the hash worked quite well for me on a number of test cases, including common words and proper names. Jeff ___ 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] Large password list
Valdis, (For real fun, consider that published and unpublished works are treated differently. And a password list almost always becomes a published work without the permission of the author(s) ;) Talking of currently implemented systems... One could argue that the author of lists resulting from cracked hashes is the cracker, as the cracker is simply computing one of the infinite collisions that each hash intrinsically has. Nobody can say if that collision was caused by the original password Now back to operational content... ___ 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] Large password list
Of course, you are quite right, it follows, and it's been many years since I've used anything less than 512 bits with strong internal state for anything relevant. Still... On Fri, Dec 2, 2011 at 2:30 PM, Gage Bystrom themadichi...@gmail.com wrote: I think it simply makes sense though. As more and more common passwords are cracked by the multitude of boxes out there dedicated to cracking hashes, the more and more likely that its gunna turn up in a list or a site somewhere. Add in that Google is really good at finding long strings and numbers if they exist on the net and the fact that the entire idea behind hashes is for them to be uniqueyeah. On Dec 2, 2011 11:17 AM, Charles Morris cmor...@cs.odu.edu wrote: This is extremely depressing. On Fri, Dec 2, 2011 at 2:14 PM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:59 PM, Sanguinarious Rose sanguiner...@occultusterra.com wrote: I am at a lack of words for this, why pay $4.99 when you can just do some simple googling? You can even search pastebin and get a mass collection of password lists from dbases. Add a dash of awk and maybe a pinch of sed and viola! Why even spend the CPU cycles to process the password list? See Jon Callas' post on the Random Bits mailing list: No one bothers cracking the crypto (real life edition), http://lists.randombit.net/pipermail/cryptography/2011-December/001870.html. Interestingly (sadly?), googling the hash worked quite well for me on a number of test cases, including common words and proper names. Jeff ___ 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 - 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] Ubuntu 11.10 now unsecure by default
nice try though On Fri, Nov 18, 2011 at 9:10 AM, Dan Kaminsky d...@doxpara.com wrote: On Fri, Nov 18, 2011 at 5:01 AM, valdis.kletni...@vt.edu wrote: On Thu, 17 Nov 2011 15:53:41 CST, C de-Avillez said: There is no guest account on an Ubuntu server, so at least there this is not a real/perceived risk. And nobody's *ever* installed the desktop version on a server because they didn't know any better, especially from Ubuntu's target audience. Gotcha. ;) OK, seriously. If you're sitting in front of a machine that's presenting you a login prompt, you've got enough privileges to insert a bootable USB/CD and pull all the data / make yourself an account (FDE/Bios PW notwithstanding). ___ 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
Nathan, It IS an issue, don't let their foolishness harsh your mellow. Although it's a completely ridiculous, backwards, and standards-relaxing security mechanism, the fact is they implemented it, and you subverted it. In my book that's Pentester 1 :: Fail Vendor 0 I've had large vendors (read:Microsoft) reply to issues with the same kind of garbage, where they take a situation where there wasn't a threat, create a security mechanism to counter the nonexistent threat, then implement it incorrectly, thus creating either a vulnerability in the system itself or a false sense of security for the user. Fail: Hello user, you can add attachments now! Look at our amazing 1997 web technology!! User: Oh neat, I can't wait to send my friend this random file (read: give up your rights and control of your random file to facebook) your through your excessive, unnecessary, inefficient, insecure, closed-source tool Fail: I am blocking exe attachments 'for your security' so feel free to just run attachments without a second thought, don't even bother to waste 100ns of your time to practice normal security User: Wait, what about .bat, .cmd, .vbs, .ws, .pif, .inx, .lnk etc etc? What about the extensions that I set up? Can I really just spam clicks all over the place? Fail: Oh those, well you shouldn't be clicking those. What, we can't be held responsible if you don't practice normal security!! P.S. You know when we said we were blocking .exe files? Well--- we aren't. Enjoy. /rant On Fri, Oct 28, 2011 at 1:38 PM, Nathan Power n...@securitypentest.com wrote: 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. ___ 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] What are some of the top ...
1) Fix CVSS from disastrously broken to slightly broken or better 2) eliteness = #CVE* avg CVSS /sec + coolpoints 3) eliteness *= (taking credit for other people's vulns and known issues) ? 0 : 1 On Fri, Jun 3, 2011 at 6:28 AM, Georgi Guninski gunin...@guninski.com wrote: On Thu, Jun 02, 2011 at 03:29:01PM -0700, t0hitsugu wrote: While I make no claims of being a security professional, the abolute best thing you can do is look into schools that will lead to the prestigious CEH certification, highly vaued in the infosec community, which will teach you to use complex tools like sqlmap, nmap, and if youre skilled enough, metasploit. i suppose the current measure for eliteness is #CVEs(R) per second :) -- joro ___ 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] Python ssl handling could be better...
On Fri, Mar 4, 2011 at 11:14 AM, bk cho...@gmail.com wrote: On Mar 4, 2011, at 7:53 AM, Michael Krymson wrote: The problem with this discussion is simply one of definition of security. For some, security is entirely black and white. I can't speak for others, but I don't see anything as black white. What I'm railing against is FALSE security. If it can be trivially broken, it shouldn't be labeled as security. Python has an incomplete implementation of SSL. The protocol was not designed to be used w/o authentication. It's lazy people who took it out. One cannot implement a lock without pins. If anyone can walk up and turn the plug, it has no value and if someone is selling that to you to make your house safe, they would be sued. You are quite right that false security is a serious and pervasive problem today. If there is a problem with Python's SSL implementation, which I assume there is, it should be fixed, regardless of breaking existing applications. Yes, the snake oil salesman has never had a better opportunity to make a buck than 1996 to today. If it's trivial for you to break asymmetric encryption you wouldn't be publicly making the claim that it was trivial for you to break asymmetric encryption. If we're talking about whether a certain key length would take 20 years vs. implementing more operations to make it last for 50 years, that's a discussion of acceptable levels of risk and it comes down to what's appropriate for the data you're protecting. If you're talking about whether it takes 5 minutes to download a sniffing program vs. taking 10 minutes to download and configure tools to MITM a connection, that's not shades of grey. It's freakin broken. Even that is shade of gray. True, the magnitude and growth of O is unchanged, but sorry friend, 5 does not equal 10. I also explained why it's not a comparison of 5 to 10. Especially if in that 5 you are caught and your attack stopped. Which, you would be, if you were on my network. These people probably tend to be those who've actually had jobs in general digital defense... LOL, really? Have you seen http://extendedsubset.com/?page_id=2 (Marsh Ray)? What about http://www.sentinelchicken.com/advisories/ (Tim). I've worked in security roles since 2000 and I'm credited in http://support.apple.com/kb/HT2009 . CVE-2008-2538 CVE-2007-4070 CVE-2006-4315 CVE-2005-4158 CVE-2005-1993 I suppose then, by your own standard, you should respect my argument and stop defending a broken position? No... I wouldn't expect you to. There's always someone with better credentials. Stay out of this Michal! ;D ___ 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] Python ssl handling could be better...
Ok great, but by comparing MitM with sniffing, we're already assuming the attacker has access to the traffic. Think about it. There aren't any networks in common use today which in their physical implementation make alteration of packets harder than observation of packets. This is why the big-Os are the same. Wrong. You can't just generalize all existing /common/ networks match my idea of what is. You have to back up your statement with some argument. I already gave examples as to why reading isn't the same as writing, not by far. And you know, even if you weren't wrong, big O isn't the end-all of metrics. It's a useful metric, no doubt, but implying that O(a) = O(b) = f(a) = f(b) where f is a function that has security impacts is just foolish. A does not equal B. 5 does not equal 10. Reading does not equal writing. O(attack execution) does not imply f(attack execution).. e.g. Risk to attacker of being discovered. Monitor port does not equal ??mysterious nebulous MitM attack?? And you two are the ones complaining about snake oil :/ I've had this conversation at many different times with different people over the years. snip If you tell a lie enough times. ___ 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] Python ssl handling could be better...
- ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION BTW there really isn't a security difference between encrypted-but-unauthenticated traffic and just plain unencrypted traffic. The only attacker you're defeating is a casual observer, Fail. I hear the blackhats cackle as you switch to telnet. There are a million and one attack scenarios where what you have is an observer, please remember that to execute a MITM you actually have to be in the middle of something. That's A LOT more difficult than configuring a SPAN port and running snort. Especially so when you have to be invisible... you can't just waltz around changing routing tables or physically sticking a server on top of a rack of switches and expect not to be noticed. Not to mention the fact that at any one time you may have N active sessions, an attacker has to begin his attack at a specific point in time, thereby only glimpsing (or MITM-ing) NEW sessions at that point in time, instead of probably being able to hijack the N active sessions as with an unencrypted protocol. NOT TO MENTION the fact that doing a live hijack of an encrypted protocol is severely extended in difficulty by the length of the session and not observing the beginning transaction (in general). One would have to crack the key, figure out what the protocol was and how to hijack it, and execute the attack- all before the session ended- which in itself is a computational feat that only an attacker with HUGE resources could accomplish (assuming a good algorithm choice, key length, and session length). Organized MITM by governments and backbone providers? A resounding YES this is an issue. MITM by disgruntled employee X or blackhat trudy? Not so much. Maybe it's even worse than pointless. It's the idiot user's fault if they don't understand the difference between authentication, encryption, and authentication + encryption. Even somebody who has near-zero computer experience should know the definitions of these words. It's the idiot application's fault if it does not explain the scenario to the user i.e. this connection is encrypted but unauthenticated. The solution is to EDUCATE users instead of putting silly annoying warning banners- that people just click through anyway- on my browser every time I try to use a self signed cert... There was a study a while back on how extended validation certificates do effectively nothing against a phishing site / MITM attacks. In short- Encryption without authentication is ALWAYS BETTER than no encryption Authentication without encryption is ALWAYS BETTER than no authentication Encryption with authentication is ALWAYS BETTER than either of the above two scenarios ___ 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] Python ssl handling could be better...
the same. Another way to look at it is O(MitM) = O(sniff). There may be some implementation details that make MitM harder, but it's within a constant factor. To illustrate this point, we merely need to search the web for MitM tools. At the network layer, we could achieve this in one of numerous ways, including: * DNS cache poisoning * ARP poisoning * routing protocol poisoning (many kinds) * ICMP router redirects * NETBIOS name poisoning * ... The list goes on, I'm sure. The list does go on. However, I completely disagree with your assertion that O(MitM) = O(sniff) Yes there are many vectors to MITM at many levels, but they are (perhaps not ALL) not only detectable but also preventable in many scenarios. * DNS cache poisoning =Don't fail at DNS * ARP poisoning = use static ARP tables (and before you say who on earth does that- I do) * routing protocol poisoning (many kinds) = (many solutions) * ICMP router redirects=Get filtered by firewall before they ever reach me * NETBIOS name poisoning=Don't ever use netbios for anything That should be fairly self-evident. Take wireless with some mid-level encryption for example, how easy is it to sniff wireless traffic and crack if after the fact; versus how easy is it to do a live MITM on said traffic? How easy is it to become a fake AP and grab new clients? What numerous protections can we make against that sort of attack? I think you and this rambling bk fellow misunderstand the nature of my disagreement with you. My statement is not that that we shouldn't be designing systems for the highest possible level of assurance, my statement is that, along with everything in my previous email, it's completely baseless and fundamentally damaging to make the statement that: 0) ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION 1) O(MITM) = O(sniffing) 2) RISK(MITM) = RISK(sniffing) 3) whateverelse(MITM) = whateverelse(sniffing) N.B. I am in complete agreement with the point of this thread; that python's handling should be fixed. ___ 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] Python ssl handling could be better...
It's hard to do if you're starting from zero and have to write your own tools. It's not hard to do when you can just download something off the Internet, which is the reality we're dealing with. Jay Beale released a tool to do this years ago at Toorcon. There are many others. Game over on that discussion. Oh no tols exist!?!?! Wow. We should be designing systems for a high level of assurance, not a little bit better than awful. Besides, with the speed at which technology moves and the innovativeness of users, products should be made robust so they can stand up to unanticipated usage. For example, if someone went out and wrote a Twitter client based on python-twitter and it became popular in North Africa, many people would falsely think their revolutionary conversations are secure because it uses SSL, but in fact the oppressive governments can trivially sniff all the traffic (and possibly impersonate trusted users?). An attacker who is motivated to cause harm will find the tools to do what they want, so MITM is not a high bar. There are available tools to do it that don't require expertise. As I said previously, the only attacker defeated by unauthenticated SSL is the one who wasn't going to cause much harm any way. Ahh yes, the chorus of nerds everywhere. Guess what, most people just do their job, that they're good at, and expect the technology to do the right thing. The assume computer professionals are as thoughtful about making things easy to use and safe as the designers of microwaves, lawn mowers, paper shredders, etc... With those things you have to try really hard to hurt yourself or cause damage. With unsafe SSL you're hurting yourself by default. That would be akin to a microwave melting your eyes if you were too stupid to wrap the appliance in protective shielding. The incorrect assumption of the masses isn't our fault and is only marginally our problem :( It's a sad thing, and I'm more than happy to work to educate them. And no, you aren't hurting yourself by default; and your microwave-blaming-the-operator example is incorrect, as I also specifically said that it's the application's (client's / microwave's) fault if it does not advise the user of the current security context. In short- Encryption without authentication is ALWAYS BETTER than no encryption It's not. Would you like to jump out of an airplane with a parachute that you THINK will work, but doesn't, or one that actually will work? You'd make a different choice if you knew the chute wouldn't open. It is. A parachute that works a nonzero % of the time (encryption without authentication) is infinitely better than one that you can BE SURE WILL NEVER WORK (plaintext) The application, or parachute, should warn of the danger involved so the user may make an educated choice. Authentication without encryption is ALWAYS BETTER than no authentication Not if it can be captured/replayed to impersonate you in the future. WTF are you smoking? It is. Authentication that resists a nonzero percentage of attackers (cleartext authentication) is ALWAYS BETTER than no authentication whatsoever. e.g. Turn off authentication on your in.telnetd, post your IP on FD, and tell me how that works out for you. Encryption with authentication is ALWAYS BETTER than either of the above two scenarios Even a broken clock... I think that means you agree with me, otherwise I have no idea what you mean.. so.. Burrito! ___ 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] What the f*** is going on?
mz
Disclosing how their epic story simply involved SQLi, well, what about the
guys discovering 0days in native code?
Totally. I have long postulated that perl -e '{print Ax1000}' is
considerably more l33t than scriptalert(1)/script or ' OR '1' ==
'1.
I don't understand the point you are getting at. I think that the more
interesting aspect of this story are the egregious practices revealed
in that write-up (and elsewhere):
/mz
Michal, your blog writeup does cut to the disheartening core of the
issue, but as we all know large non-savvy organizations just eat that
bravado and mystery up.
Also, I would say that even though randomly prodding exec arguments
with As isn't so elite, the space of the non-web is much more deep
and much more complex than the space of the web.. and the
vulnerabilities are generally more interesting, generally more
difficult to find, and generally more difficult to exploit. If we
examine the specialists in each area, I also think there is a general
trend that the web houses the less l33t, and the non-web houses
the more l33t. In general. I'm sure one can find the great and the
garbage in both arenas.
I also completely agree with your concern for the well being of both
our tax dollars, the health and safety of the internet, and our
physical persons as well. I don't want HBGary sending some thugs to
knock me with a blackjack if they see me on the wikileaks IRC
channel..
___
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 always felt purposefully antagonizing others and inciting general distress, fear, uncertainty, doubt, and frustration among as many people as possible, without letting others know it was your intention was a better description.. All in all it means you aren't a nice person and you have psychological problems :'( Are you a troll, Cal? I doubt :D Of course I'm one of the few who thinks Andrew isn't a troll either ... :/ ___ 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] Vulnerability in reCAPTCHA for Drupal
Michele, Granted I don't know or really care about drupal, and I'm not just trying to defend MustLive, who just seems to be a guy trying to get ahead in the world, even if he's a little misguided; but what really gets to me is when people dismiss issues like that. Not to mention you are assuming that the defaults are never changed. full path disclosure IS an information disclosure, unless the code is designed to disclose it's filesystem path. Any information gathered by unorthodox methods from an application that wasn't designed to do so, is an information disclosure. Information disclosure IS a vulnerability. Even if an attack vector isn't known, things like filesystem knowledge, internal varialbe names, error messages, username = id mapping, etc can still be used from a social engineering perspective. It is my personal belief that all vulnerabilities should be patched regardless of existence of a known attack vector or exploit. If an application does not behave exactly as it's intended in all circumstances: patch || gutmann() And, to MustLive; I hope that debugging option or whatever is turned on by default- otherwise the quoted issue is more of a misconfiguration and yes two days is a completely irrational acknowledgment duration cap ... :( ... I've had vendors take weeks to acknowledge an issue.. we have to gently hold the hand of vendors and teach them how computer work.. I personally suggest putting a proper disclosure policy on your website and then stick to it. On 2/17/11, Michele Orru antisnatc...@gmail.com wrote: If you thing that some statements from MustLive like the following: Full path disclosure (WASC-13): At POST request to the page with form with using of Cyrillic char in parameter op, the error message is showing, which consists the full path on the system. Vulnerabilities exist at pages:http://site/user/,http://site/user/1/edit, http://site/user/password,http://site/user/register,http://site/contact, http://site/user/1/contact. Other pages which have forms also can be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20Full%20path%20disclosure.html As noted Drupal developers, these vulnerabilities appear due to turned on debugging option in administrator panel. So for preventing of these and other FPD at the site it's needed to turn off this option. are not hilarious, then you're a really noob. I mean, every Drupal user knows that the default path to register a new user is user/register, or that the default admin account is reachable at user/1, or that the contact form is at the contact URI. These are not vulnerabilities, and this is one of the many reasons why almost no-one in FD read his advisories and flag his address as spam :) antisnatchor ... MustLive mailto:mustl...@websecurity.com.ua February 17, 2011 6:18 PM Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing reCaptcha for Drupal. - Affected products: - Vulnerable are all versions of reCAPTCHA plugin for Captcha module versions before 6.x-2.3 and 7.x-1.0. -- Details: -- Insufficient Anti-automation (WASC-21): In different forms in Drupal the vulnerable captcha-plugin reCAPTCHA is using. Drupal's Captcha module is vulnerable itself, so besides reCAPTCHA other captcha-plugins also can be vulnerable (at that this exploit is a little different from exploit for default Captcha module for Drupal). For bypassing of captcha it's needed to use correct value of captcha_sid, at that it's possible to not answer at captcha (captcha_response) or set any answer. This method of captcha bypass is described in my project Month of Bugs in Captchas (http://websecurity.com.ua/1498/). Attack is possible while this captcha_sid value is active. Vulnerabilities exist on pages with forms: http://site/contact, http://site/user/1/contact, http://site/user/password and http://site/user/register. Other forms where reCAPTCHA is using also will be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20reCAPTCHA%20bypass.html Timeline: 2010.12.11 - announced at my site. 2010.12.14 - informed reCAPTCHA developers. 2010.12.14 - informed Google (reCAPTCHA owner). 2011.02.16 - disclosed at my site. I mentioned about this vulnerability at my site (http://websecurity.com.ua/4752/). 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 -
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
It is my personal belief that all vulnerabilities should be patched regardless of existence of a known attack vector or exploit. Let me fix that for you: All vulnerabilities should be evaluated as to whether patching them makes sense. If it's a one-liner fix for a stupid logic error, yes it probably should be patched whether or not there's a known exploit. ... So yes, evaluation is needed. But patching it may not make any realistic sense, depending on the nature of the issue and who is potentially affected. I agree Valdis, and I personally used shatter when it was popularized.. resulting in tons of fun here at the university with my colleagues. However, I'm simply stating a belief in a more abstract sense, I agree beliefs are not always realistic, but personally I /do/ make that guarantee whenever I write a piece of code. I am very aware I must compromise this belief when working in the market, like most of my other beliefs and morals, and I do so daily. Then I go home and cry myself to sleep. Charles ___ 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] Fwd: HBGary Mirrors?
Sorry, when I say eligible, I mean which server would they be allowed to take down by law?. I'm not too hot on the laws of encryption, but I'm sure there is something which states that hosting encrypted files are not illegal, it's distributing the key which allows you to gain access to those fails, which is actually illegal. *DISCLAIMER: I don't know if the above is true or not, so apologies if I got this wrong* Attempt A: Cal, I'm not sure on this point off-the-cuff, however encrypted files should* be indistinguishable from random data, so assuming that even if a given LEE has obtained the key and knows that your distributed data is illegal, you could be held blameless as you have no feasible way to know what the data was. Attempt 2: You could also consider a key and an algorithm a transform for a set of random bits, such that once the transform is applied to those bits it would result in something bad, so you aren't actually distributing encrypted files at all.. just random bits :D *DISCLAIMER: The above will PROBABLY NOT hold in court, so apologies if you get jailed for life ___ 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] Filezilla's silent caching of user's credentials
On Thu, Oct 7, 2010 at 11:10 PM, Ryan Sears rdse...@mtu.edu wrote: Hi all, As some of you may or may not be aware, the popular (and IMHO one of the best) FTP/SCP program Filezilla caches your credentials for every host you connect to, without either warning or ability to change this without editing an XML file. There have been quite a few bug and features requests filed, and they all get closed or rejected within a week or so. I also posted something in the developer forum inquiring about this, and received this response: I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be. Source:(http://forum.filezilla-project.org/viewtopic.php?f=3t=17932) To me this is not only concerning, but also completely un-acceptable. The passwords all get stored in PLAIN TEXT within your %appdata% directory in an XML file. This is particularly dangerous in multi-user environments with local profiles, because as we all know physical access to a computer means it's elementary at best to acquire information off it. Permissions only work if your operating system chooses to respect them, not to mention how simple it is *even today* to maliciously get around windows networks using pass-the-hash along with network token manipulation techniques. I reported a similar issue in a certain SSH client a few years ago, it was keeping the passphrase as cleartext in memory for the duration of the session as well as an arbitrarily long period after you disconnect but keep the window open. They added protections like a simple encoding for the credentials where they are stored, and nulling out the region when you ended the session. They still wanted to keep the credentials intact during the session in order to quickly create new terminal windows. This issue was much less serious than storing the cleartext in a file, and they thought it appropriate to add protections. I just wanted to gauge the FD community on this issue, because with enough backing and explanation from the security community as to why this is a problem, this issue may finally be resolved (it's been doing this for years now). It IS an issue. Plain and simple. That type of developer response really gets me. Personally I won't be allowing Filezilla on any of my systems even if they do eventually patch this issue.. who knows what else is lurking behind the scenes? Cheers, Charles ___ 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] Filezilla's silent caching of user's credentials
food for thought: https://bugzilla.mozilla.org/show_bug.cgi?id=602181 ___ 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] DLL hijacking with Autorun on a USB drive
On Tue, Aug 31, 2010 at 7:03 PM, Dan Kaminsky d...@doxpara.com wrote: On Aug 31, 2010, at 2:20 PM, Charles Morris cmor...@cs.odu.edu wrote: On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com wrote: Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. What? I can differentiate my coolProposal.doc from msword.exe just fine.. Uh huh. Here, let me go ahead and create 2010 Quarterly Numbers.ppt.exe with a changed icon, and see what you notice. Mr. Szabo has already slapped your wrist for such undeserved arrogance. And yeah, I find it a joke that you think that .ppt.exe isn't pretty damn obvious. I might have fell for that when I was 9, but I haven't had a problem with a windows box in years. I will admit, at 3AM when I've been working for 18 hours and awake for 36, it is possible that I may double-click such a malicious file and then immediately think OH shit and rebuild. I know what we can do, we can repackage the Hey watch out for badguys masquerading as innocent files that everybody already knows about, contact CERT and negotiate a fix between major vendors (Hey this isn't just a MS vulnerability right??), then give a talk at blackhat to establish our fame, but now that I think about it.. that would be rude to the people who have been complaining about this since 1999. If your statement is that the windows defaults should be changed, including the hide extensions default, then I wholeheartedly agree as I detailed in my first post. It's the first thing I turn off. Many people who think the same way have considered that a vulnerability in windows for years, I wouldn't consider it part of the DLL Hijacking fiasco. Imagine if the browser lock meant arbitrary code could run. I find your faith in small collections of pixels hilarious. Imagine if the keyboard LED meant arbitrary code could run!! What? I don't even understand what you are getting at. This has nothing to do with faith in icons. My statement was that windows defaults arguably represent a vulnerability in the GUI by making proposal.doc indistinguishable from proposal.doc.exe with a crafted icon, when you are encouraged to double-click the icons through the GUI, and when doc files are supposed to be innocent to open. I was also stating the fact that this vulnerability should be addressed outside of the scope of the DLL Hijacking mess. Cheers, Charles ___ 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] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 11:27 AM, matt m...@attackvector.org wrote: Dan, While I agree with most of what you're saying, I do find this to be a pretty serious issue, and here's why. 1) The file doesn't have to be fake. It could be a legitimately real ppt, vcf, eml, html, whatever. The program(s) load the rogue DLL file and there doesn't seem to be any major impact on the functionality of the software, meaning that the end user wouldn't know that there was something hostile taking place. The file opens, they can view it, modify it, whatever, and all the features seem to work. Perception is reality. 2) This opens the door for more widespread attacks. In the case of PowerPoint, one could simply find a share on a network that contains a large amount of ppt files and save his/her rogue DLL file in that directory. Then, whenever anyone opens one of the files, the attacker gets immediate access to the victims PC without the victim having any idea. 3) People are getting smarter and do view .exe's as threats. Yes, because of the fact that extensions are usually hidden and that you can modify the icon to be whatever you want it to, it's trivial to trick an end user into clicking on just about anything. However.. if I pass out my Power Point presentation on a USB stick at a business meeting that has legitimate content, no one is going to have any clue that anything else took place. There's also very little risk of detection, because you don't have to worry about that one user who doesn't have extensions hidden, or someone noticing that the icon looks funny, or different. It simply makes for a more stealthy attack. To be honest, the whole DLL hijacking concept reminds me a lot of the old temp race vulnerabilities from back in the day. Is it really a vulnerability in the true sense of the word? Not really.. it's taking advantage of a series of events and being first to cross the finish line. But, I believe that because we can get the system to execute arbitrary code (OUR arbitrary code), this really does present a serious problem, just like the old temp race conditions did. Anyway, I appreciate the feedback.. and yes, ultimately I agree that invoking this through Autorun is probably, for the most part, useless, but I was asked if it was possible and I honestly wasn't sure that it would be, which is why I wrote the post after I found out that it was. - matt www.attackvector.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/ I'm going to be honest here, I see this whole DLL Hijacking thing as a non-issue. It's a known behavior. Don't run applications from untrusted locations- because then you can't trust the application- not just the DLLs it loads. We aren't in the UNIX world here, yes windows may have fine-grained permissions but with the bubbly/stupid GUI from Vista onward.. I'm not even sure how to use them off-hand- so I know for a fact random-user-sixpack can't do it. You can't just casually glance at a file on a random network share and know that nobody has been manipulating it; and it's stupid to think otherwise. Do you run random executables from flashdrives you find on the floor? Even if it has a solitaire icon? No. If there was a setuid root executable that gave you a nice game of solitaire over X, while running any script at /tmp/runme.dll^H^H^Hsh - would you call this a vulnerability or a horrible design choice? Especially so when it's -clearly- documented that it runs said script? And yes, the first thing to do on a windows desktop is to disable crappy menu fades, UAC, and hide extensions; along with a slew of other garbage. I normally spend two hours in MMC as soon as it's up. It's time for others to do the same. If you want to fix this, you may of course implement signed DLLs, but then you get the issue of signed DLLs. It would just turn out to be another UAC or MS-Maintained SSL Authority List. I suppose it would be nice if an application would compare a checksum of a DLL to a hardcoded value before it loaded it, but then you get the issue of newer (but fully compatible) DLL versions having different checksums, etc, etc. It's just a mess caused by stupid design by Microsoft. Now, if there was a way to move a CWD of a more-privileged-user process to a less-privileged-adversary defined directory before loading a given DLL, that would be a real vulnerability. the old temp race vulnerabilities from back in the day. Is it really a vulnerability in the true sense of the word? Not really.. Oh, and, race conditions are real vulnerabilities. There is no question/argument on this. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia -
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
... Don't run applications from untrusted locations ... You got it wrong. Only trusted applications are run. - The attacker prepares a WORD.DOC (and a RICHED20.DLL) file in some place. The victim clicks on the WORD.DOC file, using his own installed MSWord. Aaah, well if that is the issue, it seems to me that the vulnerability here is that the application in question (MSWord) has it's CWD set to the directory of the file that it is opening through the explorer shell. It should chdir() to it's own parent directory before doing anything interesting that depends on CWD. (i.e. loading DLLs or executing ./amazingApp.sh) It's general good programming practice to be mindful of your CWD, I know that personally; a call to chdir() is almost always at the top of my script. So, I take back what I said about it being a non-issue, it IS in fact a vulnerability in the application. Cheers, Charles ___ 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] DLL hijacking with Autorun on a USB drive
On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com wrote: Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. What? I can differentiate my coolProposal.doc from msword.exe just fine.. If your statement is that the windows defaults should be changed, including the hide extensions default, then I wholeheartedly agree as I detailed in my first post. It's the first thing I turn off. Many people who think the same way have considered that a vulnerability in windows for years, I wouldn't consider it part of the DLL Hijacking fiasco. Cheers, Charles ___ 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] blackboard security contact that can actually handle a report?
is there anyone?? vulnerabilities found, off-list replies sought. fall students approach; standard contact methods give: just disappointment. ___ 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] Expired certificate
On Wed, Aug 4, 2010 at 2:44 PM, Marsh Ray ma...@extendedsubset.com wrote: On 08/04/2010 09:44 AM, Paul Schmehl wrote: --On Monday, August 02, 2010 12:36:37 -0400 Elazar Broadela...@hushmail.com Spot on. I know of one large accounting/ERP system(which shall remain nameless, though I am sure there are those out there who have come across it) that checked the SQL version, including the revision number at runtime, which made patching SQL impossible. In those cases where there are such systems, there should be mitigating controls around them that increase the difficulty of break-in. Otherwise the IT department is negligent. It's not the IT department's fault if the vendor ships a product that refuses to run with a patched system. There have always been products out there that behave like this, it's a simple coding or policy mistake to make. The attraction is that they don't have to support any configuration that they haven't tested. Unfortunately, products that do so are straying away from the herd and choosing not to participate in its collective defense. They are still subject to all the same published attacks, but cannot benefit from the standard update and patch cycle. A secondary effect is that since it's so hard to predict the security of such a system over the long term, they simply can't be considered when developing general guidelines and best practices. For example, we might be discussing the schedule of disclosing a bug in the SQL vendor's product. If the SQL vendor can patch it easily for their primary customer base, those oddball downstream vendors are just not going to get much consideration. Eventually, they will probably tire of playing catch-up and adjust their policy. - Marsh ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ This is all true, however Paul is also correct. In the real world where you may not get to make the decision of what software products to implement, mitigating controls for that exposure must be put into place; whether they be firewalls, patches, extensive logging, or etc. It isn't the IT Department's fault that the product is garbage, however it is the IT Department's fault if they don't control and isolate it. The reality is that when you walk into a room one of your options isn't always clean house.. - Charles ___ 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] Hackery Channel 01-09-01-LOLZ: Cat Spoofing against Flow Control
On Thu, Jan 29, 2009 at 6:04 PM, hack ery hackery.chan...@gmail.com wrote: Security Risk: High Exploitable: Local Vulnerability: Arbitrary Flow Control Control, Cat Spoofing Discovered by: The Hackery Channel Tested: No The Flow Control project is an access control project for a cat. It consists of a cat door, an electromagnetic latch, a access control device, and image recognition software that allows Flow to enter the house, and only when she is not carrying prey. When Flow is within proximity of the door, she passes through a light that casts a shadow on an area monitored by a camera. If the silouhette, appears to be Flow without prey, access is granted. Cat Spoofing: An attacker could potentially gain access by posing as a kitty by placing a cut out of the kitty next to the light. Mitigation: None. Work around: Guard dog Vendor Notified: No Vendor Site: http://www.quantumpicture.com/Flo_Control/flo_control.htm ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ The solution of course would be to clone the system and take a vertical image, creating a decent 3-D map of the Cat attempt. What about two-factor authentication? I'm thinking a mass spectrometer reading in combination with the facial recognition. That could detect a Cat spoofing and/or brute-force attack with a bust or cardboard cut-outs. With any biometric authentication it's going to be expensive and have all kinds of bugs and quirks... just teach him a password.. sheesh. -- Charles Morris cmor...@cs.odu.edu, cmor...@occs.odu.edu Network Security Administrator, Software Developer Office of Computing and Communications Services, CS Systems Group Old Dominion University http://www.cs.odu.edu/~cmorris ___ 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] Microsoft takes 7 years to 'solve' a problem?!
snip On Tue, Nov 25, 2008 at 10:51 AM, Memisyazici, Aras [EMAIL PROTECTED] wrote: snip M$ should just bite the incompatibility bullet and turn NTLM off - that's been an option for users, theoretically speaking, since about the time Windows Kerberos support became mature, and practically speaking, nobody seems to be turning NTLM off here in the real world. /snip Err... Have ya' ever attended 'any' sec. conf. in the past 6 years?? If so, you'd see recommendation #1 has always been: *) refuse LM NTLM, accept NTLMv2 only /snip In reality, every machine I've ever built here at ODU (production included) has had NTLM turned off. No complaints yet. -- Charles Morris [EMAIL PROTECTED], [EMAIL PROTECTED] Network Security Administrator, Software Developer Office of Computing and Communications Services, CS Systems Group Old Dominion University http://www.cs.odu.edu/~cmorris ___ 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] wow.
http://www.sowela.edu/elearning.html ... comments? -- Charles Morris [EMAIL PROTECTED], [EMAIL PROTECTED] Network Security Administrator, Software Developer Office of Computing and Communications Services, CS Systems Group Old Dominion University http://www.cs.odu.edu/~cmorris ___ 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] Dear full disclosure
Dear full-disclosure, please forever archive and cherish these beautiful RIPEMD160 SHA1 sums. a26a3bc9210ea737111477df501d9f9235d94d46 3c5b90c8b6fcc65122da864931f76e0e39f0c384 Sincerely, -- Charles Morris [EMAIL PROTECTED], [EMAIL PROTECTED] Network Security Administrator, Software Developer Office of Computing and Communications Services, CS Systems Group Old Dominion University http://www.cs.odu.edu/~cmorris ___ 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] Insecure call to CreateProcess()/CreateProcessAsUser()
Microsoft Explorer (iexplore.exe) calls CreateProcess() with lpApplicationName = NULL. Instead, the lpCommandLine variable is used. Unfortunateally, if the lpCommandLine variable is not quoted properly, the function will attempt to loadexecute multiple other applications in the following fashion: lpCommandLine = C:\Program Files\Google\Google Talk\googletalk.exe Will attempt to execute: C:\Program.exe C:\Program Files\Google\Google.exe C:\Program Files\Google\Google Talk\googletalk.exe If Microsoft Hyperterminal is set up to be your default telnet client, this behavior is known to be triggered from the web with a telnet:// style link. Microsoft was notified, they told me it was a non issue, that they coulden't reproduce it, and basically dont worry about it. or something. Unfortunateally although explorer.exe warns a user when the file C:\Program.exe exists, it does not check any other paths, therefore it is not nearly a sufficient workaround. -- Charles Morris [EMAIL PROTECTED] Network Administrator CS Systems GroupOld Dominion University http://15037760514/~cmorris ___ 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] Insecure call to CreateProcess()/CreateProcessAsUser()
I understand that this issue is known, however different applications run CreateProcess in different ways, some use the lpApplicationName variable and some use lpCommandLine properly. My point is however that the explorer program itself does not do this properly, and that anyone using explorer or Internet explorer, is vulnerable to attack from the web through at least telnet:// links. (at least proven with Hyperterminal as coincidently C:\WINNT\SYSTEM32\telnet.exe has no spaces) Other telnet clients installed to different directories (with spaces) will also trigger the problem. It seems to me that I (speaking from a web programmers point of view) should not be able to ask your computer to run executables at (what seems to me, at least) arbitrary paths. This is also a major problem in multiuser environments, as you can trick some windows services into running your applications. I have been notifying vendors one by one of their problem, if it is in their code, as it seems that nobody wants to really talk about the huge implications of this; maybe I am exaggerating the problem. what do you think? On 5/21/06, Andres Tarasco [EMAIL PROTECTED] wrote: That's a well known issue and is documented at http://msdn.microsoft.com/library/default.asp?url="" Andres tarasco2006/5/21, Charles Morris [EMAIL PROTECTED] : Microsoft Explorer (iexplore.exe) calls CreateProcess() withlpApplicationName = NULL. Instead, the lpCommandLine variable is used.Unfortunateally, if the lpCommandLine variable is not quoted properly, thefunction will attempt to loadexecute multiple other applications in the following fashion:lpCommandLine = C:\Program Files\Google\Google Talk\googletalk.exeWill attempt to execute:C:\Program.exeC:\Program Files\Google\Google.exeC:\Program Files\Google\Google Talk\googletalk.exe If Microsoft Hyperterminal is set up to be your default telnet client,this behavior is known to be triggered from the web with a telnet:// style link.Microsoft was notified, they told me it was a non issue, that they coulden't reproduce it, and basically dont worry about it. orsomething. Unfortunateally although explorer.exe warns a user when thefile C:\Program.exe exists, it does not check any other paths, therefore it is not nearly a sufficient workaround.--Charles Morris[EMAIL PROTECTED] Network AdministratorCS Systems GroupOld Dominion University http://15037760514/~cmorris___ Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ -- Loco de aTar -- Charles Morris[EMAIL PROTECTED]Network AdministratorCS Systems GroupOld Dominion Universityhttp://15037760514/~cmorris ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
