Re: [Full-disclosure] Compliance Is Wasted Money, Study Finds
> PCI only requires antivirus for systems commonly affected by > viruses. This means Windows. PCI security council has said that UN*X > OSs etc. are not required to have antivirus. > > -- > Tracy Reed > http://tracyreed.org Just an FYI...if your nix devices are in scope, my last audit (4 weeks ago) directed me to install A/V plus a rootkit finder on linux devices in scope. Whitelisting is an alternative, but seems more a headache then A/V. Hope this helps someone somewhere. James ___ 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] Compliance Is Wasted Money, Study Finds
>>> Whether said checkbox is actually the best solution *for the actual problem* >>> is the issue. I've seen cases where checkbox auditors insisted that a >>> certain critical system "absolutely positively *HAD* to have a firewall". >> >> This is where compensating controls come in with PCI. If there is an >> even better solution you are free to implement it. > > Yes, the PCI "compensating controls" are overall a Good Thing. Unfortunately, > a lot of regulatory regimes don't see things that way yet. And it still > requires a clued PCI auditor who actually understands the real world enough > to deal with compensating controls. Having just gone through a PCI audit I can safely say a few things: A) Approaching compliance from a risk management approach went out the window B) Items the auditor didn't understand absolutely went back to a checkmark mentality C) Items that were gray areas were treating VERY liberally in their interpretation Bleh ___ 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] 0-day hackers are vista-ready
hai fun begins DEC-18-2006 ;) ___ 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] private imap4d exploit
Don't lie crash-x we all know you ripped the code off rave and changed the printf()'s to make it look like yours. You even admit to changing it again now!!!ravecool wrote this code - crash-x is a code thief!!! rave deserves the credit for this exploit as he is the real hacker here.>On 1/22/06 crash-x <crash.ix_at_gmail.com> wrote: >>On 1/22/06, str0ke com> wrote:>> My bad.>>>> printf("[!] mailutils imapd4d universal(?) exploit 0.5 by crash-x />> unl0ck / scozar\n"); >Oops sorry, my bad. I wrote the code a long t
ime ago.
I probably>changed the printf a while ago.
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.___
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] private imap4d exploit
On 1/22/06, str0ke <[EMAIL PROTECTED]> wrote:
> My bad.
>
> printf("[!] mailutils imapd4d universal(?) exploit 0.5 by crash-x /
> unl0ck / scozar\n");
Oops sorry, my bad. I wrote the code a long time ago. I probably
changed the printf a while ago.
___
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] private imap4d exploit
On 1/22/06, str0ke <[EMAIL PROTECTED]> wrote: > Why change the information inside? I thought this was unl0cked's code > not rosiello's. Because the guy thinks it is funny and would annoy me. The code is neither unl0ck's nor rosiello's. ___ 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] private imap4d exploit
Very funny... This code wasn't written by Rave, but by me. Someone thinks it's funny to fake headers of code and post it to mailinglists then. That code wasn't even private... ___ 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] private imap4d exploit
Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with voicemail imap4d.c Description: 2126124349-imap4d.c ___ 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] Re: Multiple Vendor Anti-Virus Software DetectionEvasion Vulnerability through forged magic byte
Bipin Gautam said: + > Consequently, the issue that you describe is *not* a + > vulnerability issue, but rather just an example of a new + > variant that has not yet been added to an AV vendor's + > database of "known viruses". + + yap, maybe* but i consider this issue equv. to the + 'classic issue' of adding NOP to the shell-code to bypass + IDS/IPS You ain't gonna add every possible combinations + as signatures! That is true, but the key point is that you _don't have_ to add a sig for every possible combination. You only have to add a sig when somebody actually releases a functioning "variant" into the wild. Or, if your AV scanner uses heuristic / rules-based scanning by default, you can just write a rule to detect most/all of the combinations. And this is exactly the way IDS/IPS works too. They don't write sigs for every theoretically possible vulnerability or threat; they just write sigs/rules for known exploits and vulnerabilities, and for theoretical issues that have a good probability of showing up in the wild. So, the AV vendors wouldn't have to do anything unless somebody actually created a working variant of a virus based on this magic byte concept, and released it into the wild. + Variant huh? + + My defination of variant are bit straight forward. And + sure isn't a 'universal trick' that can be used to + modified any malicious executable (which has known Av + signature) by a 8 year old with 0 programming knowledge + or by using any special tools to make it un-detectable, + later. Admit it... Av vendors aren't going to + doyuble/tripple their Av defination to detect all of such + possible varient. Common, is the execution point of ANY + instruction code or program flow is being changed? See above. 8 year olds? Considering the maturity of current "virus creation toolkits", I have no doubt that 8 year olds with no programming skills are pointing and clicking to create new viruses. All that said, if an AV vendor can fix this issue by easily creating patches for all of their products, then great. I'm simply stating that the issue can be effectively, and probably more easily, fixed too by creating new signatures or rules. I bet this is how most vendors will handle the issue now. Remember: the AV vendors only have to write signatures/rules if Andrey, or somebody else, actually creates a functioning "variant" and releases it into the wild. Andrey Bayora said: + > The AV vendors aren't going to patch their products if + > they don't detect your PoC; they're just going to write a + > new signature or modify an existing signature to detect + > your new variants. The fact that it can and will be + > fixed by AV signatures instead of product patches should + > help you figure out if this is a product vulnerability + > issue or just a "new virus variant" issue. + + Good point, so I have news for you - some AV vendors + contacted me and they are WILL issue patches for their + products. Is it what you need as a proof of existence of + a bug? Please, wait couple of weeks. Cool - there's more than one way to skin a virus. As long as they take action when necessary to mitigate the actual / real risks. + > BTW, Andrey, did you bother to use the "deep scan", + > "heuristic mode", "reviewer mode", etc to see if any + > of those AV scanners picked up your new variants? + + YES, that is the reason why I prefer to use my AV lab + instead of virustotal.com and others. The only exception + is CA - I tested 7.0 version that didn't has "reviewer + mode" (or I didn't found how to enable this). None of the 15 vendors you listed as vulnerable had any sort of "deep scan" or heuristic mode that detected your variants? + Best regards, + Andrey Bayora. Bottom line: the issue you have discovered/reported is just one of zillions of theoretical attacks / viruses / variants. The "known virus" AV vendors only need to address the actual viruses/variants that make it into the wild or are sent to them. This is the way most AV, and heck even network security, products work. They only address the real or probable threats. If they tried to address all of the theoretical stuff too, their products - and even the internet - would grind to a halt (nightmares like TCP/IP, SMTP Win32, etc insure this). IMO, the best solution for this, and all other AV issues, is to just lock down a *BSD or linux box and use that instead. We can probably all agree on that. -- x @ bos ___ 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] Re: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte
Andrey Bayora said: + > If your altered virus sample + > still executes correctly, you have simply created a new + > virus variant. + + Not exactly, please look at this virustotal.com log + http://www.securityelf.org/updmagic.html + + The altered (120 bytes prepended) TXT_* variant is STILL + detected by your product (CA), but when I change the first + byte from "Z" to "M" - your product fails (MZ_* variant). + I believe, that if I PREPEND 120 bytes to known virus and + the virus is still detected with the SAME signature - + then I DID NOT create a new variant. Now one more example: + try to change the first byte "Z" in the TXT_* variant to + any value, but not to "M" - this virus will be detected, + but when you change to "M", thus creating the .EXE magic + byte - the variant is not detected !!! My conclusion: + the antivirus thought that the file is the executable + type instead of determining the file type by the + extension. + + That is my point, if you still think that your product is + OK - do not do anything. Thierry Zoller said: + WJK> You are effectively altering existing viruses to the + WJK> point that AV scanners do not detect them. + + No, he is changing a few bytes only. + + WJK> If your altered virus sample still executes + WJK> correctly, you have simply created a new virus + WJK> variant. + + No, there is no variant, the virus executes EXACTLY as + before. A variant acts differenlty then a precedent + version, else it would be no variant. To your AV engine it + is a variant, yes, but only because it is flawed. Why are you guys having such a difficult time comprehending this? Read both the general and AV-specific definitions of the word "variant". http://dictionary.reference.com/search?q=variant http://www.symantec.com/avcenter/glossary/index.html#v http://us.mcafee.com/VirusInfo/VIL/glossary_app.asp#v If you take an existing virus and modify it, you have created a variant. The AV vendors aren't going to patch their products if they don't detect your PoC; they're just going to write a new signature or modify an existing signature to detect your new variants. The fact that it can and will be fixed by AV signatures instead of product patches should help you figure out if this is a product vulnerability issue or just a "new virus variant" issue. BTW, Andrey, did you bother to use the "deep scan", "heuristic mode", "reviewer mode", etc to see if any of those AV scanners picked up your new variants? I bet you didn't. Thierry Zoller said: + WJK> Consequently, the issue that you describe is *not* a + WJK> vulnerability issue, but rather just an example of a + WJK> new variant that has not yet been added to an AV + WJK> vendor's database of "known viruses". + + Thank you James, this _to my knowledge_ (perhaps the guy + from vmyths knows better) is the first time the complete + failure of todays AV solutions is shown naked publicaly + directly by a representant of an AV company. This + statement coming from a AV vendor is simply exposing what + is known in the sec. community since many years. To say that an AV scanner is a "complete failure" because it fails to detect a variant you just created is inane. Each of the top 10 AV scanners detects well over 95% of all known viruses. The AV scanners aren't perfect, but they definitely make a BIG BIG difference wrt malware risk mitigation. ftp://agn-www.informatik.uni-hamburg.de/pub/texts/tests/pc-av/2003-04/0xecsum.txt Thierry Zoller said: + The solution was to make the engines a bit "smarter", i.e + analyse the header to determine the type and then ONLY + apply the signatures/heuristics which apply to the type of + the file (i am not speaking about the extension of the + file here) thus speeding up the process. Changing the + header just makes the smart engines look...well... a bit + dumb in my regards. There are two types of people in the world: those who complain about problems, and those who find solutions to problems. Where's your superior AV scanner? -- x @ bos ___ 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] fport results
i got these results from fport, i found Messenger suspcious on port 13929 and its listening if i do telnet to it. Pid Process Port Proto Path1292 svchost -> 135 TCP C:\WINDOWS\system32\svchost.exe1384 svchost -> 1025 TCP C:\WINDOWS\System32\svchost.exe792 navapw32 -> 1027 TCP C:\PROGRA~1\NORTON~1\navapw32.exe 344 alg -> 3002 TCP C:\WINDOWS\System32\alg.exe1384 svchost -> 3003 TCP C:\WINDOWS\System32\svchost.exe1384 svchost -> 3004 TCP C:\WINDOWS\System32\svchost.exe 880 MsnMsgr -> 3363 TCP C:\Program Files\MSN Messenger\MsnMsg880 MsnMsgr -> 3413 TCP C:\Program Files\MSN Messenger\MsnMsg1588 svchost -> 5000 TCP C:\WINDOWS\System32\svchost.exe 964 msmsgs -> 13929 TCP C:\Program Files\Messenger\msmsgs.exe ___ 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] Best way to crack NT passwds
i used http://www.loginrecovery.net for getting my lost passwd, passwd resetting is no prob. But i wanted to recover it. Thats a pay service but if you can wait for days then they give out ur recovered passwd for free. They had guessed my alphanum passwd in around 5 min. On 7/31/05, Ken <[EMAIL PROTECTED]> wrote: http://rainbowtables.shmoo.com-KenOn Jul 30, 2005, at 3:21 PM, Clement Dupuis wrote: > Pre computed tables are the way to go.>> Considering the time it takes to compute them, you may as well buy> them.>> www.rainbowtables.net is a good place amongst others to get them.> Their key> difference is the variety they have and they keep expanding.>> Clement>>> ___ > 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.htmlHosted and sponsored by Secunia - http://secunia.com/-- Muhammad Shahid Electrical EngineerX4ce.net Network AdministratorUCET, BZU, Multan.E-Mail: [EMAIL PROTECTED]Mobile: +92(300)6326611Web: http://www.x4ce.net ___ 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] Best way to crack NT passwds
hiya! I have tried many softwares for cracking NTLM hashes, like NC4, Cain and have't tried Rainbow Crack yet. Once i had to recover my XPs lost admin password and i spend around 1 day but Cain/NC4 were not able to guess that. Then i posted that hashes on some site and it did recover my passwd in around 5min. I want to know which technique they used to crack so fast ? Xurron ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
