The 0.10.1d account changes
" Yes and no. Yes, it is "unique" to a computer as the MAC address is hard burned into the NIC card and no that I can get into your computer, grab your MAC address (simply look it up using 'winipcfg' or 'ipconfig') then use a MAC emulator to "spoof" my system and gain access to your accounts. I won't explain to you here as to how to do this as this is above and beyond the the topic of this forum and really don't need to be giving any script kiddies (as 98% of today's crackers are just that - have no fuckin clue about computers and just click a button to try to "crack" other systems. It's the other 2% that actually know shit that you really need to be worried about.) any ideas :o Just remember "Your Base Are All Belong To Us." Keep this mantra in the back of your mind whenever you do things and the likelihood of you being breached goes down. The Pope quit, a meteor fell on Russia, an
asteroid came close to the earth, there's snow in Arizona, star wars and star trek have the same director! Who the hell is playing jumanji? | |
" The streamer had his account restored because we made a grave mistake when doing a manual customer sevice operation. This was 100% our fault and not in any way related to him losing his password. This won't happen again in the future because we won't be making that customer service mistake again! | |
 |
|
" Cloning the MAC is easy. Find out what the MAC address is is slightly more difficult. Just visiting a website won't give them that information, nor will having some sort of password logger. Kilts for Templars <tm> - Our mission is to replace the ancient Greek toga worn by the Templar with a kilt. It fits the theme of Wraeclast better, and it fits the voice of the Templar.
|
|
|
Good call on that xkcd comic, I was about to post that too. :)
|
|
|
@Elorn = +100 This is oh so true :)
The Pope quit, a meteor fell on Russia, an
asteroid came close to the earth, there's snow in Arizona, star wars and star trek have the same director! Who the hell is playing jumanji? | |
" Thats a good one too, of course we can made a lot of imposible passwords... I can use some tricks and use dates and E=MC^2 with replacement to make a software to encrypt 1 date and give me the password :P. Example: 1110 (11/10 11th October my birthday) E=1110*(3*10^8)^2 E=9990000000000...etc Password = E / Pi Password = 317991576976068 Password Inverse Replacement = eit99ist69t6o68 Password Inverse Replacement 9 Char Lenght = eit99ist6 Password Inverse Replacement 9 Char Lenght Caps and Signs = EiT99*IsT6@ Of course this works only with an algoritm for the everyday guy mine or your password works fine :P Indestructible, determination that is incorruptible From the other side, a terror to behold Annihilation will be unavoidable, every broken enemy will know That their opponent had to be invincible, take a last look around while you're alive I'm an indestructible master of war Last edited by exploder#7028 on Feb 22, 2013, 10:36:33 AM
|
|
|
I just Use Keepass 2 http://keepass.info/ and let it generate random 256bit hex keys (or whatever password limits allow for).
Not clicking stupid links or downloading nasty software helps, too. |
|
|
Could you make this optional ?I literally have to unlock my account every time i reconnect,rarely i don't,it's annoying :/
|
|
" Once again, it will surprise you as to how easy it is to gain access to 90% of people's computers for one reason or another. For example, there are still many people today that are using a Windows OS built on an x86 (32-bit) architecture. Those of us in the security community know that this is filled with more holes than swiss cheese lmao! Most ppl today just walk around, la la la, and have no clue just how vulnerable their systems really are; due to no diligence via computer security, just ignorant of technology or being completely left in the dark by the evil forces of Microcrap, uh I mean Microsoft. You think I'm kidding?
Spoiler
http://www.soundbytes.org/phpBB2/viewtopic.php?t=13338&sid=3a752912a3fc04aae697525647e29fc7
Wow, this is a biggie. A vulnerability exists in all 32-bit versions of Microsoft Windows released since 1993, and is in what's known as the Virtual DOS Machine. This was introduced in 1993 to provide backwards compatibility with old 16-bit programs, and has been carried forward ever since, even into Windows 7. By using the old MS-DOS system, a "hacker" can inject code directly into the system's kernel. This fairly much overrides all security and makes it easy to make changes to any part of the operating system. The exploit has been tested, and works, on all 32-bit versions of Windows except for version 3.1 (NT). If a 16-bit piece of code is run, under the Windows Task Manager you will probably see both NTVDM.EXE and WOWEXEC.EXE running. NTVDM.EXE is the Windows 16-bit Virtual DOS Machine, and is used for providing a 16-bit environment for old 16-bit applications (Windows and MS-DOS). WOWEXEC.EXE (which stands for Window On Window Execution) provides additional 16-bit support, and is launched by NTVDM if it is needed. Disabling the MSDOS and WOWEXEC subsystems will prevent an attack from functioning. But this will also stop any 16-bit programs from working, and this includes any 32-bit programs that might call some older 16-bit code. Details of how to turn off the 16-bit subsystem are under the "Mitigation" section here: http://seclists.org/fulldisclosure/2010/Jan/341 or here: http://archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html It should be noted there is no known use of this security hole currently being used. Also, you could "break" some of your software if you just switch off the MSDOS and WOWEXEC subsystems. The person who found this security hole reported it to Microsoft last summer. But he got tired of waiting for Microsoft to do something about it, and released the details into the wild.
Spoiler
http://seclists.org/fulldisclosure/2010/Jan/341
Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack From: Tavis Ormandy <taviso () sdf lonestar org> Date: Tue, 19 Jan 2010 20:11:17 +0100 Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack ------------------------------------------------------------------------- CVE-2010-0232 In order to support BIOS service routines in legacy 16bit applications, the Windows NT Kernel supports the concept of BIOS calls in the Virtual-8086 mode monitor code. These are implemented in two stages, the kernel transitions to the second stage when the #GP trap handler (nt!KiTrap0D) detects that the faulting cs:eip matches specific magic values. Transitioning to the second stage involves restoring execution context and call stack (which had been previously saved) from the faulting trap frame once authenticity has been verified. This verification relies on the following incorrect assumptions: - Setting up a VDM context requires SeTcbPrivilege. - ring3 code cannot install arbitrary code segment selectors. - ring3 code cannot forge a trap frame. This is believed to affect every release of the Windows NT kernel, from Windows NT 3.1 (1993) up to and including Windows 7 (2009). Working out the details of the attack is left as an exercise for the reader. Just kidding, that was an homage to Derek Soeder :-) - Assumption 0: Setting up a VDM context requires SeTcbPrivilege. Creating a VDM context requires EPROCESS->Flags.VdmAllowed to be set in order to access the authenticated system service, NtVdmControl(). VdmAllowed can only be set using NtSetInformationProcess(), which verifies the caller has SeTcbPrivilege. If this is true, the caller is very privileged and can certainly be trusted. This restriction can be subverted by requesting the NTVDM subsystem, and then using CreateRemoteThread() to execute in the context of the subsystem process, which will already have this flag set. - Assumption 1: ring3 code cannot install arbitrary code segment selectors. Cpl is usually equal to the two least significant bits of cs and ss, and is a simple way to calculate the privilege of a task. However, there is an exception, Virtual-8086 mode. Real mode uses a segmented addressing scheme in order to allow 16-bit addresses to access the 20-bit address space. This is achieved by forming physical addresses from a calculation like (cs << 4) + (eip & 0xffff). The same calculation is used to map the segmented real address space onto the protected linear address space in Virtual-8086 mode. Therefore, I must be permitted to set cs to any value, and checks for disallowed or privileged selectors can be bypassed (PsSetLdtEnties will reject any selector where any of the three lower bits are unset, as is the case with the required cs pair). - Assumption 2: ring3 code cannot forge a trap frame. Returning to usermode with iret is a complicated operation, the pseudocode for the iret instruction alone spans several pages of Intel's Software Developers Manual. The operation occurs in two stages, a pre-commit stage and a post-commit stage. Using the VdmContext installed using NtVdmControl(), an invalid context can be created that causes iret to fail pre-commit, thus forging a trap frame. The final requirement involves predicting the address of the second-stage BIOS call handler. The address is static in Windows 2003, XP and earlier operating systems, however, Microsoft introduced kernel base randomisation in Windows Vista. Unfortunately, this potentially useful exploit mitigation is trivial to defeat locally as unprivileged users can simply query the loaded module list via NtQuerySystemInformation(). -------------------- Affected Software ------------------------ All 32bit x86 versions of Windows NT released since 27-Jul-1993 are believed to be affected, including but not limited to the following actively supported versions: - Windows 2000 - Windows XP - Windows Server 2003 - Windows Vista - Windows Server 2008 - Windows 7 -------------------- Consequences ----------------------- Upon successful exploitation, the kernel stack is switched to an attacker specified address. An attacker would trigger the vulnerability by setting up a specially formed VDM_TIB in their TEB, using a code sequence like this: /* ... */ // Magic CS required for exploitation Tib.VdmContext.SegCs = 0x0B; // Pointer to fake kernel stack Tib.VdmContext.Esi = &KernelStack; // Magic IP required for exploitation Tib.VdmContext.Eip = Ki386BiosCallReturnAddress; NtCurrentTeb()->Reserved4[0] = &Tib; /* ... */ Followed by /* ... */ NtVdmControl(VdmStartExecution, NULL); /* ... */ Which will reach the following code sequence via the #GP trap handler, nt!KiTrap0D. Please note how the stack pointer is restored from the saved (untrusted) trap frame at 43C3E6, undoubtedly resulting in the condition described above. /* ... */ .text:0043C3CE Ki386BiosCallReturnAddress proc near .text:0043C3CE mov eax, large fs:KPCR.SelfPcr .text:0043C3D4 mov edi, [ebp+KTRAP_FRAME.Esi] .text:0043C3D7 mov edi, [edi] .text:0043C3D9 mov esi, [eax+KPCR.NtTib.StackBase] .text:0043C3DC mov ecx, 84h .text:0043C3E1 mov [eax+KPCR.NtTib.StackBase], edi .text:0043C3E4 rep movsd .text:0043C3E6 mov esp, [ebp+KTRAP_FRAME.Esi] .text:0043C3E9 add esp, 4 .text:0043C3EC mov ecx, [eax+KPCR.PrcbData.CurrentThread] .text:0043C3F2 mov [ecx+KTHREAD.InitialStack], edi .text:0043C3F5 mov eax, [eax+KPCR.TSS] .text:0043C3F8 sub edi, 220h .text:0043C3FE mov [eax+KTSS.Esp0], edi .text:0043C401 pop edx .text:0043C402 mov [ecx+KTHREAD.Teb], edx .text:0043C405 pop edx .text:0043C406 mov large fs:KPCR.NtTib.Self, edx .text:0043C40D mov ebx, large fs:KPCR.GDT .text:0043C414 mov [ebx+3Ah], dx .text:0043C418 shr edx, 10h .text:0043C41B mov byte ptr [ebx+3Ch], dl .text:0043C41E mov [ebx+3Fh], dh .text:0043C421 sti .text:0043C422 pop edi .text:0043C423 pop esi .text:0043C424 pop ebx .text:0043C425 pop ebp .text:0043C426 retn 4 /* ... */ Possibly naive example code for triggering this condition is availble from the link below. http://lock.cmpxchg8b.com/c0af0967d904cef2ad4db766a00bc6af/KiTrap0D.zip The code has been tested on Windows XP, Windows Server 2003/2008, Windows Vista and Windows 7. Support for other affected operating systems is left as an exercise for the interested reader. ------------------- Mitigation ----------------------- If you believe you may be affected, you should consider applying the workaround described below. Temporarily disabling the MSDOS and WOWEXEC subsystems will prevent the attack from functioning, as without a process with VdmAllowed, it is not possible to access NtVdmControl() (without SeTcbPrivilege, of course). The policy template "Windows Components\Application Compatibility\Prevent access to 16-bit applications" may be used within the group policy editor to prevent unprivileged users from executing 16-bit applications. I'm informed this is an officially supported machine configuration. Administrators unfamiliar with group policy may find the videos below instructive. Further information is available from the Windows Server Group Policy Home http://technet.microsoft.com/en-us/windowsserver/grouppolicy/default.aspx. To watch a demonstration of this policy being applied to a Windows Server 2003 domain controller, see the link below. http://www.youtube.com/watch?v=XRVI4iQ2Nug To watch a demonstration of this policy being applied to a Windows Server 2008 domain controller, see the link below. http://www.youtube.com/watch?v=u8pfXW7crEQ To watch a demonstration of this policy being applied to a shared but unjoined Windows XP Professional machine, see the link below. http://www.youtube.com/watch?v=u7Y6d-BVwxk On Windows NT4, the following knowledgebase article explains how to disable the NTVDM and WOWEXEC subsystems. http://support.microsoft.com/kb/220159 Applying these configuration changes will temporarily prevent users from accessing legacy 16-bit MS-DOS and Windows 3.1 applications, however, few users require this functionality. If you do not require this feature and depend on NT security, consider permanently disabling it in order to reduce kernel attack surface. ------------------- Solution ----------------------- Microsoft was informed about this vulnerability on 12-Jun-2009, and they confirmed receipt of my report on 22-Jun-2009. Regrettably, no official patch is currently available. As an effective and easy to deploy workaround is available, I have concluded that it is in the best interest of users to go ahead with the publication of this document without an official patch. It should be noted that very few users rely on NT security, the primary audience of this advisory is expected to be domain administrators and security professionals. ------------------- Credit ----------------------- This bug was discovered by Tavis Ormandy. ------------------- Greetz ----------------------- Greetz to Julien, Neel, Redpig, Lcamtuf, Spoonm, Skylined, asiraP, LiquidK, ScaryBeasts, spender and all my other elite colleagues. Check out some photography while at ring0 @ http://flickr.com/meder. ------------------- References ----------------------- Derek Soeder has previously reported some legendary NT bugs, including multiple vdm bugs that, while unrelated to this issue, make fascinating reading. - http://seclists.org/fulldisclosure/2004/Oct/404, Windows VDM #UD LocalPrivilege Escalation - http://seclists.org/fulldisclosure/2004/Apr/477, Windows VDM TIB Local Privilege Escalation - http://seclists.org/fulldisclosure/2007/Apr/357, Zero Page Race Condition Privilege Escalation ------------------- Appendix ----------------------- SHA-1 checksum of KiTrap0D.zip follows. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 99a047427e9085d52aaddfc9214fd1a621534072 KiTrap0D.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBS1W6+RvyfE4zaHEXAQK//QgAvo/VhPdeASGe7SSfC3jLwNzsfVfM+FMo x7JZMMfVUh6b/+FxvokIpsCUf7QQkv+YcyCiatutVjUok5aw5BirFtPLHORIIKPX B5gN2a4G8RIXh5yKE6FffKGQsPJNW1Ua5Jss8rf59TEj3EDky1vco+WVmmz7TsHn TQdUreVcL8wFmCAgq5X0AKrdepYDBmYLF0AUFOdG3mKJ43dnP59p9R7+ckv0pfLW XtvOgzZDNMew4z2Z53YQpE7dO+Y3H3rnhLN7jF7i9We9iiG4ATDke8byFAIDZQZx ucq5EOcRsfAAWW3O8EbzQa0NiHHScJrKDjvg0gX1Y69MBBwCLNP6yg== =LHU0 -----END PGP SIGNATURE----- -- ------------------------------------- taviso () sdf lonestar org | finger me for my gpg key. ------------------------------------------------------- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ I NEVER kid about security… The Pope quit, a meteor fell on Russia, an
asteroid came close to the earth, there's snow in Arizona, star wars and star trek have the same director! Who the hell is playing jumanji? |
