Re: [Full-disclosure] Quick Blind TCP Connection Spoofing with SYN Cookies
Good write up that Jakob and an interesting read. Thanks ,) ___ 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] Abusing Windows 7 Recovery Process
My initial thoughts after adding the user and rebooting was that it was only valid in the recovery console session or something as once i rebooted it was gone... Tried it again today in a different place and same deal. Reboot no new user... Anyone have this working after reboot? Once you've inserted your payload with admin-or-better rights, it can be anything from a rootkit that GP can't touch to a patched GP subsys that doesn't apply AD policies. This isn't really a caveat. On 2013-07-08 12:39:18 (+0200), Fabien DUCHENE wrote: There may be an Active Directory domain policy which only allows a configured set of groups/users to be admin of your workstation. Keep in mind domain policies are applied at startup and periodically. ___ 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] Abusing Windows 7 Recovery Process
On Jul 10, 2013 1:51 PM, Gregory Boddin greg...@siwhine.net wrote: It won't. The whole point is to have full local access to hard-drives (from a locked workstation for eg), to modify/read things in it. The loaded environment IS a live environment. I would say: almost a copy of the install CD loaded from the hard-drive. What you can do is : take the SAM, modify somewhere else (not a windows expert tough), re-inject and gain local access. (which is kind of useless since local data are already available once the recovery is booted, unless there's software you would like to run in that workstation once the password is reset). Hmm, not sure about this... Haven't tried but lets say we can copy the SAM off the box somehow, recovery console is running as system which can read the SAM and On 9 July 2013 20:39, some one s3cret.squir...@gmail.com wrote: My initial thoughts after adding the user and rebooting was that it was only valid in the recovery console session or something as once i rebooted it was gone... Tried it again today in a different place and same deal. Reboot no new user... Anyone have this working after reboot? Once you've inserted your payload with admin-or-better rights, it can be anything from a rootkit that GP can't touch to a patched GP subsys that doesn't apply AD policies. This isn't really a caveat. On 2013-07-08 12:39:18 (+0200), Fabien DUCHENE wrote: There may be an Active Directory domain policy which only allows a configured set of groups/users to be admin of your workstation. Keep in mind domain policies are applied at startup and periodically. ___ 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] Abusing Windows 7 Recovery Process
On Jul 10, 2013 9:16 PM, some one s3cret.squir...@gmail.com wrote: On Jul 10, 2013 1:51 PM, Gregory Boddin greg...@siwhine.net wrote: It won't. The whole point is to have full local access to hard-drives (from a locked workstation for eg), to modify/read things in it. The loaded environment IS a live environment. I would say: almost a copy of the install CD loaded from the hard-drive. What you can do is : take the SAM, modify somewhere else (not a windows expert tough), re-inject and gain local access. (which is kind of useless since local data are already available once the recovery is booted, unless there's software you would like to run in that workstation once the password is reset). Oops, pressed send... Try again... Hmm, not sure about this... Haven't tried but lets say recovery console is running as system which can read the SAM and it lets us copy it off the box to a share or usb or whatever, if we can get it off i'm guessing we can rip out the hashes for the users and attempt to crack them, spray them about or whatever... But changing one so we know the password and then putting it back, doubt this will work will it, as essentially we are changing the SAM file anyway aren't we when we create a new legit user through net commands and it discards this change when we reboot, or are there 2 SAM files? One in live environment which dissapears and the real one... Pass, i will try it out again when i get 10mins..:-) On 9 July 2013 20:39, some one s3cret.squir...@gmail.com wrote: My initial thoughts after adding the user and rebooting was that it was only valid in the recovery console session or something as once i rebooted it was gone... Tried it again today in a different place and same deal. Reboot no new user... Anyone have this working after reboot? Once you've inserted your payload with admin-or-better rights, it can be anything from a rootkit that GP can't touch to a patched GP subsys that doesn't apply AD policies. This isn't really a caveat. On 2013-07-08 12:39:18 (+0200), Fabien DUCHENE wrote: There may be an Active Directory domain policy which only allows a configured set of groups/users to be admin of your workstation. Keep in mind domain policies are applied at startup and periodically. ___ 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] Abusing Windows 7 Recovery Process
E The user wasn't there never mind him being admin... I'll test this out again when i next do a win7 review on a job On 8 Jul 2013 11:39, Fabien DUCHENE f.duch...@car-online.fr wrote: There may be an Active Directory domain policy which only allows a configured set of groups/users to be admin of your workstation. Keep in mind domain policies are applied at startup and periodically. Message: 1 Date: Mon, 1 Jul 2013 15:16:45 +0100 From: some one s3cret.squir...@gmail.com To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Abusing Windows 7 Recovery Process Message-ID: CA+1kKf460FE0uo7ps780N3f=gFh8G= i0+o1yr5w1upoczub...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I tried this out onsite today. Got the cmd.exe as described and added a user into local admin group... Restart the box try and login as new user and it isn't there... Logged in as a legit admin and ran net users and no mention of my created account... Weird... On Jun 30, 2013 10:54 AM, Cool Hand Luke coolhandl...@coolhandluke.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/29, Grandma Eubanks wrote: However, I think this is still interesting. It's been a while since I've played with Windows boxes and won't have access to one for a couple days, but isn't this triggering off of vendor supplied recovery partitions? This is a regular Windows 7 sole partition box you tried this one? from a first look, i don't think a vendor-supplied recovery partition is necessary. it appears that it would also be possible if the system restore setting was enabled (but don't quote me on that). i'm not sure how likely that is in your average large, corporate environment. the ones i've seen have system restore disabled and opt to reimage systems instead when issues occur. i'm sure there are some environments where this could be useful, however. - -chl - -- cool hand luke ___ 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] Abusing Windows 7 Recovery Process
I tried this out onsite today. Got the cmd.exe as described and added a user into local admin group... Restart the box try and login as new user and it isn't there... Logged in as a legit admin and ran net users and no mention of my created account... Weird... On Jun 30, 2013 10:54 AM, Cool Hand Luke coolhandl...@coolhandluke.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/29, Grandma Eubanks wrote: However, I think this is still interesting. It's been a while since I've played with Windows boxes and won't have access to one for a couple days, but isn't this triggering off of vendor supplied recovery partitions? This is a regular Windows 7 sole partition box you tried this one? from a first look, i don't think a vendor-supplied recovery partition is necessary. it appears that it would also be possible if the system restore setting was enabled (but don't quote me on that). i'm not sure how likely that is in your average large, corporate environment. the ones i've seen have system restore disabled and opt to reimage systems instead when issues occur. i'm sure there are some environments where this could be useful, however. - -chl - -- cool hand luke -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQF8BAEBCgBmBQJRz0jUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RUE3NjY3OTY3NTE0RjAyMDgyRTNBQzAy QkE2NTVENTVDODgzNUVCAAoJECumVdVciDXraG4H/0rOTqDYy5wzmI5/Rs8n/1Ts Z3/xwsUuSCQzFNmA6VuPD5hRNtygPVoq3nhcm4ADZzWHPwOy32RTbtriUgK4mAF/ S2yuGsGk1rszxPdW4/DZ+APInTCMxTwtViL5NGa9AsVRKAxQ87i9XyxTUeB4V0H5 XlUMCCzmX1yNupdyIEkE4zYc4RiNTaPeamXlnds+gaW+/hmMVz9d1tC6vYBmtaAz urXy55TnEUoAwUlAGxgtwKappfKenggqFFEc2OY0s2HTRpd1WbVEiCW7VV3BR33z JOpwwF3IfRbOvcrZai5BztyIRmSw1r5olymXr2l3PYLXNZVmLJXmQei1CzZJ58I= =+kX6 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] n.runs-SA-2013.001 - Polycom - Command Shell Grants System-Level Access
I think because if/when someone enables it there is no authentication needed to remote log in as root? On Mar 16, 2013 4:32 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Why exactly is this a bug? 2013/3/15 secur...@nruns.com n.runs AG http://www.nruns.com/ security(at)nruns.com n.runs-SA-2013.001 15-Mar-2013 ___ Vendor: Polycom, http://www.polycom.com Affected Products: Polycom HDX Series Affected Version:3.1.1.2 Vulnerability: Polycom Command Shell Grants System-Level Access Risk: LOW ___ Overview: The Polycom Command Shell is a command-line based administrative interface to the Polycom HDX system. It can be accessed either via a RS-232 serial connection or via telnet on port 23. Description: The Polycom Command Shell can be used to view and also change several settings of the system. However it can also be used to get system-level access (i.e. root access) to the HDX system. The printenv and setenv commands can be used to read and write variables respectively which are stored in flash memory. The easiest way to get root access to the HDX system is to enable the development mode of the system which will then enable a telnet server where a root login without a password is possible. In order to enable the development mode, the devboot U-Boot environment variable must be set. This can be done through the Polycom Command Shell with the following commands: $ cu -l ttyUSB0 -s 9600 - setenv othbootargs devboot=bogus - reboot reboot, are you sure? y,n y This will reboot the system and enable a telnet server where a login as root is possible. $ telnet 192.168.0.218 Trying 192.168.0.218... Connected to 192.168.0.218. Escape character is '^]'. hdx7000.lan login: root ## Error: vidoutsize not defined # id uid=0(root) gid=0(root) # uname -a Linux hdx7000.lan 2.6.18.1.p2.14 #1 PREEMPT Wed Feb 3 10:25:31 CST 2010 ppc unknown # Impact: Someone with legitimate access to the Polycom Command Shell can get direct system-level access to the underlying embedded Linux system. This can be used to further analyze the system. Solution: Polycom released version 3.1.1.2 of the HDX software which fixes this issue. It can be downloaded from the Polycom Support page at http://support.polycom.com. ___ Credit: Bug found by Moritz Jodeit of n.runs AG. ___ Unaltered electronic reproduction of this advisory is permitted. For all other reproduction or publication, in printing or otherwise, contact secur...@nruns.com for permission. Use of the advisory constitutes acceptance for use in an as is condition. All warranties are excluded. In no event shall n.runs be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if n.runs has been advised of the possibility of such damages. Copyright 2013 n.runs AG. All rights reserved. Terms of use apply. ___ 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] BF, CSRF, and IAA vulnerabilities in websecurity.com.ua
If you reread what i posted you will see that i do not give my opinion on the quality of his posts. I will keep that to myself, I just state that its better than dudes (and your) troll posts. Regards On Jan 1, 2013 3:04 PM, Benji m...@b3nji.com wrote: So you would say, that you find the things he posts of interest? Please expand on how and why anti automation bugs in unknown cms's are of interest? On Mon, Dec 31, 2012 at 11:58 PM, some one s3cret.squir...@gmail.comwrote: If you do not like or find of interest what the guy posts is it not easier to just press delete or filter him out rather than try to make fun of him? Give the dude a break man, hes submitting more things of interest than you are and you just make yourself sound bitter and twisted. Its new year man, go out and drink a beer or eat some fireworks On Dec 31, 2012 5:17 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Hello list! I want to warn you about multiple extremely severe vulnerabilities in websecurity.com.ua. These are Brute Force and Insufficient Anti-automation vulnerabilities in websecurity.com.ua. These vulnerability is very serious and could affect million of people. - Affected products: - Vulnerable are all versions of websecurity.com.ua. -- Details: -- Brute Force (WASC-11): In ftp server (websecurity.com.ua:21) there is no protection from Brute Force attacks. Cross-Site Request Forgery (WASC-09): Lack of captcha in login form (http://websecurity.com.ua:21/) can be used for different attacks - for CSRF-attack to login into account (remote login - to conduct attacks on vulnerabilities inside of account), for automated entering into account, for phishing and other automated attacks. Which you can read about in the article Attacks on unprotected login forms ( http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html ). Insufficient Anti-automation (WASC-21): In login form there is no protection against automated request, which allow to picking up logins in automated way by attacking on login function. Timeline: 2012.06.28 - announced at my site about websecurity.com.ua. 2012.06.28 - informed developers about the first part of vulnerabilities in websecurity.com.ua. 2012.06.30 - informed developers about the second part of vulnerabilities in websecurity.com.ua. 2012.07.26 - announced at my site about websecurity.com.ua. 2012.07.28 - informed developers about vulnerabilities in websecurity.com.ua and reminded about previous two letters I had sent to them with carrier pigeons. 2012.07.28-2012.10.31 - multiple attempts to contact the owners of websecurity.com.ua were ignored by the owners. 2012.11.02 - developers responded fuck off and kill urself irl!. 2012.12.31 - disclosed on the list Best wishes regards, MustLive Security master extraordinaire, master sysadmin http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] BF, CSRF, and IAA vulnerabilities in websecurity.com.ua
If you do not like or find of interest what the guy posts is it not easier to just press delete or filter him out rather than try to make fun of him? Give the dude a break man, hes submitting more things of interest than you are and you just make yourself sound bitter and twisted. Its new year man, go out and drink a beer or eat some fireworks On Dec 31, 2012 5:17 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Hello list! I want to warn you about multiple extremely severe vulnerabilities in websecurity.com.ua. These are Brute Force and Insufficient Anti-automation vulnerabilities in websecurity.com.ua. These vulnerability is very serious and could affect million of people. - Affected products: - Vulnerable are all versions of websecurity.com.ua. -- Details: -- Brute Force (WASC-11): In ftp server (websecurity.com.ua:21) there is no protection from Brute Force attacks. Cross-Site Request Forgery (WASC-09): Lack of captcha in login form (http://websecurity.com.ua:21/) can be used for different attacks - for CSRF-attack to login into account (remote login - to conduct attacks on vulnerabilities inside of account), for automated entering into account, for phishing and other automated attacks. Which you can read about in the article Attacks on unprotected login forms ( http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html ). Insufficient Anti-automation (WASC-21): In login form there is no protection against automated request, which allow to picking up logins in automated way by attacking on login function. Timeline: 2012.06.28 - announced at my site about websecurity.com.ua. 2012.06.28 - informed developers about the first part of vulnerabilities in websecurity.com.ua. 2012.06.30 - informed developers about the second part of vulnerabilities in websecurity.com.ua. 2012.07.26 - announced at my site about websecurity.com.ua. 2012.07.28 - informed developers about vulnerabilities in websecurity.com.ua and reminded about previous two letters I had sent to them with carrier pigeons. 2012.07.28-2012.10.31 - multiple attempts to contact the owners of websecurity.com.ua were ignored by the owners. 2012.11.02 - developers responded fuck off and kill urself irl!. 2012.12.31 - disclosed on the list Best wishes regards, MustLive Security master extraordinaire, master sysadmin http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
