Nytro

"In the late 1950's MIT hackers belived as I do: that information should be free. We call that terrorism nowadays..." http://vimeo.com/98771421

A Closer Look at Pass the Hash, Part I Posted by: Andy Green We’ve done a lot of blogging at the Metadata Era warning you about basic attacks against passwords. These can be mitigated by enforcing strong passwords, eliminating vendor defaults, and enabling reasonable lockout settings in Active Directory. But don’t rest yet! Hackers have another password trick that’s much more difficult to defend against. Advanced password, or more precisely, credential attacks are still very popular and, unfortunately, quite effective. Known generically as pass-the-hash or PtH, these attacks are seen by some as more of an issue with older Windows systems. Somewhat true, but they’re still very much a menace: PtH is the subject of presentations at recent Black Hat conferences, several white papers from Microsoft’s own Trustworthy Computing division, and a security bulletin from the NSA (for what it’s worth!). What’s a Hash? Security researchers have known almost since the beginning of modern computing that storing plain-text passwords is a poor security practice. Instead, they came up with the idea of passing the plaintext string through a special 1-way encryption function to produce a hash. You can read more about hashes in Rob’s excellent posts on the subject. The key point is that in both Windows (and Linux systems too) the hashed password is stored instead of the readable password. If you think about this a little, the hash acts as a proxy for identity—if you can prove you have it, it’s your ticket in. In Windows, the NTLM authentication protocol involves exchanging messages to validate that users have the hash without actually sending the hash over the wire. This authentication technique is at the center of how Active Directory supports remote logins within a domain and is also used for other Windows services, most significantly remote file access By the way, vulnerabilities in earlier implementations of NTLM—since corrected—have led some to believe that PtH attacks are a thing of the past. Not only is PtH still viable but the same idea—grabbing hashes from disk or memory—can also be used against more sophisticated Kerboros authentication. Don’t Crack the Hash, Pass it Windows caches the hashed passwords in memory to implement Single Sign On or SSO, which is an essential feature of Windows enterprise environments. So far, so good. For example, on my Varonis laptop, I logon once with my password, Windows hashes it and stores the code—currently 128-bits in NTLMv2— in memory so that when, say, I mount a remote directory or use other services where I need to prove my identity, I don’t have to re-enter my password— Windows instead uses the cached hash. And that is enough of an opening for hackers to exploit. We’ve seen other attacks, most significantly with RAM scrapers used on Point-of-Sale devices, where hackers use easily available software to peek into this memory. Not surprisingly there are toolkits out there that will let hackers grab the credentials from memory, and log them in as that user—see SANS’ Why Crack When You Can Pass the Hash. And that’s one of the major benefits of SSO, so to speak, for hackers: they don’t have to crack the hashes, they just re-use or pass them to an authenticating server! PtH: It’s a Feature, Not a Bug The assumption that this attack makes is that the cyber thief gains administrator-level permissions for a user’s machine. Any expert will tell you, that’s not necessarily difficult to pull off, as we’ve seen in the Target hack. In a typical exploit, the hacker will grab some hashes, log onto other servers, and continue the process of stockpiling credentials. If they hit the jackpot—a domain controller or SQL server—they may able to get the hashes of just about everyone. As an aside, we don’t know exactly how Snowden obtained employee logon credentials—social engineering likely played a part. But his admin-level access would have made PtH a very good choice to extract the credentials of those with a higher security clearance than him. Unfortunately, pass-the-hash is a feature of Windows! After all, the underlying NTLM authentication is effectively passing the hash to implement SSO, saving you from password entry fatigue. Hackers are just exploiting this feature for their own purposes. Not to be too hard on Windows, PtH is also an issue in Linux systems that implement Kerboros , where you have an equivalent pass-the-ticket or PtT attack. Here’s the most important takeaway: you can’t prevent PtH, you can only mitigate or greatly reduce the possibility of this attack occurring. Hold that thought and we’ll take up PtH mitigation through smart configurations of Active Directory and other services in the next post. Image Credit: Mattia Luigi Nappi A Closer Look at Pass the Hash, Part II: Prevention Last week, I attended a webinar that was intended to give IT attendees a snapshot of recent threats—a kind of hacker heads-up. For their representative case, the two sec gurus described a clever and very targeted phishing attack. It led to an APT being secretly deposited in a DLL. Once the hackers were in, I was a little surprised to see they were probing memory for password hashes. Pass the Hash, or PtH, I learned, was a standard hacker trick for gaining new identities. It makes sense. Hackers prefer to use credentials taken this way and logon directly as a user, rather than using more roundabout C2-style backdoors. Without sophisticated monitoring in place, they’re less likely to be spotted in real-time or even forensically afterwards when appearing as an ordinary insider. Beware of Local Admin As I mentioned last time, PtH assumes that an attacker has admin-level privileges on the machine they’ve first entered. The hash, which is kept in the memory space of a process with local admin permissions, is by itself not used to establish identity. Instead, it becomes part of a secret key for encrypting and decrypting messages in a challenge-response protocol. In effect, you need just the hash code to take over the identity of another user. The hard part is getting local admin access. Unfortunately, this is not a major hurdle. On older Windows systems (pre-Vista), the local admin account is automatically created and even worse, IT may have given each user machine the same admin password. Suppose a laptop is compromised through a phish-mail that deposits malware. The malware succeeds in a brute force assault on the local admin passwords. From this machine, the hackers can leapfrog to other devices and servers, either through new credentials that’ve been scooped from memory by PtH toolkits or by simply reusing the admin password. It may be an annoyance for admins, but UAC is a good defense against PtH. Thankfully, newer Windows OSes—Windows 7 and 8—by default don’t create a local admin account. Even better, Microsoft added a new malware defense known as User Account Controls or UAC, which requires explicit authorization for a user (or software) to gain elevated privileges. Admins know UAC through the Consent or Credential prompts (see pic) that pop up when they do legitimate work. While they may find this somewhat inconvenient, it does go a long way towards preventing malware and APTs from getting a critical foot hold. For organizations with older OSes, IT can enforce a policy of creating unique and robust admin passwords for each user machine. It’s a low-effort remedy for preventing the hackers from easily guessing admin credentials and then reusing hashes on other machines. One simple trick is to append the machine name (or variation of it) to the password. Stomp Out Local Network Logon Access Another powerful mitigation that works on both old and new Windows OSes is to prevent ordinary and local admin users from directly networking into other users’ machines. In an Active Directory environment, you’d do that by using the Group Policy Object (GPO) Editor to configure a User Rights Assignment networking policy. You can read more about how to do this here. Quick summary: disable network and remote interactive logon privileges and then link users and groups to these specific User Rights policies. And Just Limit Hashes The above measures take care of a large part but not all the entry points for PtH attacks. In the exploit that I opened this post up with the hackers used SQL injection techniques to hijack a database server that was already running with elevated privileges. Result: they were able to scoop up high-level hashes. The least privilege security principle now comes to the fore: don’t run services—SQL servers, and other IT infrastructure—with domain or enterprise level access rights. These permissions are far broader than what system tools and services generally need to do the job, and if the software is ever compromised, the shells or commands that are spawned automatically run at elevated access. However, sometimes this may not be feasible, and of course, there are always zero-day exploits waiting to happen. So the key idea now is to limit the “bad” hashes—typically domain administrators—from spreading throughout the network. Recall that with Single Sign On, the hash, even for DAs, is always deposited in memory when logging onto a machine. The rule is simple: only give domain administrators the right to access machines with high-privilege levels—i.e., domain controllers—and never allow the same accounts access to plain-old employee laptops and desktops. You can always create a separate account for system admins for servicing user devices but with non-domain admin privileges. That way, if a hacker (or internal user) should ever get control of a machine, they’ll never get the “keys to the kingdom”—a domain administrator’s hash that just happens to be in memory at the time. A Closer Look at Pass the Hash, Part III: How NTLM will get you hacked (and what you should do about it) I was about ready to wrap up this series of posts (part 1, part 2 ) on PtH and make my larger point, which is that you should assume hackers will break into your system. And then I learned new information about credential stealing that amplifies this warning by a factor of 10. The most important takeaway about PtH is that the password hashes that are stored in memory (and grabbed by hackers) are a feature of Single Sign On. Most organizations can’t live without SSO, so they’re stuck with PtH risks. I already blogged about ways to reduce these risks, but they can’t altogether be eliminated. More Features to Worry About There’s another underlying feature that also has to be taken into account. Existing Windows authentication protocols, which directly use the password hash, have had a long history of problems. As of January 2013, Microsoft’s official line on NTLM, their workhorse logon authentication software, is that you should not be using version 1—the newer v2 is better (but still has some vulnerabilities). By all means, if feasible, jump from NTLM to Kerboros, which will greatly reduce your security exposure. But many IT groups can’t completely cut their ties to NTLM—mostly because lots of client apps (email, browsers, VPN, file sharing) still depend on it. And then there’s SAMBA, a suite that provides windows file and print services for UNIX/Linux, which also uses NTLM. Bottom line: NTLM has deep hooks into Windows. But even more troubling—and here’s one piece of new information I learned from security blogger Mark Gamache—is that there’s an enormous security exposure because of all the XP out there—at least 20% of all computer based on W3 data. And these legacy clients can only authenticate with—you guessed it—NTLM version 1. A Little NTLM To understand what’s wrong with NTLM, we need to know a little more about how its challenge-response works. Rather than write out a geeky protocol syntax, the interaction (for version 1) can be roughly summarized by the following dialogue: Server: Hi. I know you’re claiming to be user XYZ, but you’ll need to prove it. But don’t tell me the password out loud—someone will overhear! Instead, I want you to take this challenge: encrypt “swordfish”, and then tell me the results. You can use DES. User: And what key should I use for DES? Server: The MD4 hash of your password—use that. Client: Ok, I’ve encrypted “swordfish” with the password hash and I have weird 24-byte string. Is that what you want? Server: Yes Client tells server the encrypted string. And server compares with its encryption of swordfish, which matches. Server: You are worthy, please enter! The most important improvement in NTLMv1 over an even earlier Windows authentication method, known as LM, was not directly sending the password over the wire. Instead, encrypting the challenge with the hash of the password is proof that the user is who he/she claims to be. The initial version of NTLM dates back to pre-internet NT systems—it stands for NT LAN Manager. Certainly, a more innocent time—circa 1990s—where the assumption that no one could get into an office LAN and launch crafty relay or man-in-the-middle exploits was a good one. That was then. NTLMv1 eventually became susceptible to a style of attack wherein users were redirected to connect to a rogue server—you can read more about that here. The server would send a challenge for which it had already pre-computed the hashes for zillions of passwords and stored the encrypted challenges in a giant dictionary. If the fake server finds a match, it then automatically has the password hash for that user. NTLM Is Really Broken In response, Microsoft improved the challenge-response protocol in NTLMv2 to prevent these server-based dictionary attacks. However, it still left open the possibility of man-in-the-middle exploits, as well as PtH. But up until recently, you could make a case for staying with v1. In 2012 some astonishing news came out of a Defcon conference. Using special purpose-built hardware, security researchers had succeeded in cracking the DES encryption used in the NLTMv1 challenge-response exchange. In other words, by watching the wire and grabbing the packets containing the challenge text from the server and the encrypted DES response, hackers could, through a brute force approach, work out the key— i.e., the underlying password hash. Yikes! And then the researchers made this DES cracking capability available as a service, known as CloudCracker, for penetration testers! I don’t want to get too much into the weeds about the fatal flaw in NTLMv1. In short: NTLMv1 doesn’t use the full 128-bit output of the MD4 hash as a DES key, but smaller 56-bit groupings, thereby making the client response amenable to being cracked by a powerful computing device. By the way, NTLMv2 use a full 128-bit key. And Going Forward This crypto-news eventually made its way to Microsoft, which then issued the NTLMv1 warning I mentioned earlier. So what’s a reasonable next step considering all this? The first action for IT is to review current LAN authentication levels (in GPO or within Local Security Policy). It’s not unusual to have set NTLMv2 as default, but still allow clients to negotiate NTLMv1 or the still older LM. If it’s feasible, they should set the “refuse LM and NTLM” option. NTLMv2 is—as far as we know and assuming you’re not dealing with the NSA—immune to DES cracking. The caveat here is that user passwords are long enough—at least 8 characters—otherwise even this new version is also vulnerable to DES brute force approaches. So another ‘to do’ on your list is to really enforce a strong password policy across the organization. The v2 challenge-response protocol can still, though, be tricked by sneaky servers getting in the middle and relaying credentials from a client to an authenticating app. And v2 doesn’t do anything to prevent PtH attacker from grabbing credentials. Here’s a simple rule of thumb based on all this: assume the hacker will get in. You therefore need a solid ‘Plan B’ defense strategy. In my previous PtH post, I recommended disabling remote access rights for ordinary users to prevent hackers from harvesting credentials by hopping on to other machines. It’s a good idea, and even more so considering all this new information. Your final defensive wall should, of course, be business-as-usual data governance practices—monitoring, alerting, etc. And you do that, as the Metadata Era has pointed out on many occasions, by finding where PII and other sensitive data is located, determining the true data owners, making sure the owners limit access to those who truly need it as part of their job or role, monitoring use and using automation to detect possible abuse. So when the hackers enter the site, they’re not coming in as if they “own the place” since they no longer have easy access to troves of sensitive data. Surse: 1. A Closer Look at Pass the Hash, Part I 2. A Closer Look at Pass the Hash, Part II: Prevention 3. A Closer Look at Pass the Hash, Part III: How NTLM will get you hacked (and what you should do about it)

[h=1]Google Races NSA to Discover Zero-Day Vulnerabilities[/h] July 15th, 2014, 15:24 GMT · By Gabriela Vatu Google has had enough of people exploiting zero-day vulnerabilities, be them hackers or government entities. After numerous efforts to make sure the system is secure following the NSA revelations, Google has now announced the so-called “Project Zero,” which makes use of hackers’ talents to discover and fix zero-day bugs. The company has already invested a lot in securing its products, including SSL encryption by default for Search, Gmail and Drive. When it discovered from the media that the NSA had also infiltrated the connection between its servers to get access to the unencrypted data traveling there, Google moved to also encrypt that data. “You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications,” Google writes in the announcement, taking a jibe at the NSA and its mass surveillance efforts, which often targeted the world’s largest Internet company. Google’s objective is to significantly reduce the number of people harmed by targeted attacks, which is why it’s been hiring security researchers who dedicate their time to improving security across the Internet, not just at Google. So, what will Google’s new team do? It will look for vulnerabilities, as well as conduct new research into mitigations, exploitations, program analysis and everything else. Not only will the company look for these vulnerabilities, but it will also file them in an external database, while reporting them to the software vendor, but no third parties. Once a patch is available, the bug report will likely become public and everyone will have access to it. This is also another jibe to the NSA, which admitted to looking for and discovering various zero-day vulnerabilities. The US government, however, said that these weren’t always reported immediately. Instead, some are kept and exploited by the NSA for a while before the risk of discovery from third parties is too big to continue and only then they are shared with the world. All this information came forth after the Heartbleed bug was exposed several months ago thanks to Neel Mehta of Google’s security team that discovered it. The NSA was then accused of knowing about the OpenSSL vulnerability and exploiting it for years, something that the intelligence agency actually denied. However, it is rather hard to believe that the spy agency, which commonly seeks such coding issues, didn’t know about Heartbleed in advance. As a reminder, the vulnerability left no traces on the affected servers and provided the attackers with unencrypted access to whatever content passed through the targeted server at the time of the attack. Google, Facebook, Yahoo and many other companies and products were affected by it since it slipped through the cracks of an OpenSSL update dating two years back. Sursa: Google Races NSA to Discover Zero-Day Vulnerabilities

Hacker Dream Team, by Google July 15th, 2014, 14:36 GMT · By Ionut Ilascu Google has announced today Project Zero, a group of elite hackers formed to hunt down zero-day security risks in various pieces of software, not just in Google products. The members of the group are led by security engineer Chris Evans and all of them have proved their skills on numerous occasions, being credited for finding numerous security bugs in products developed by heavy-weight companies such as Google, Adobe, Microsoft, Apple or Sony. At the moment, the dream team is composed of Ben Hawkes, Tavis Ormandy, Ian Beer, and the latest addition, George Hotz, who has been given the status of “intern,” according to Wired. “You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of ‘zero-day’ vulnerabilities to target, for example, human rights activists or to conduct industrial espionage. This needs to stop,” said Chris Evans in the first blog post for the project. Project Zero is not limited to just these five super-hackers and is open for new talent. The team is expected to exceed ten full-time researchers working in an office equipped with all the necessary tools for finding software security glitches. The purpose of the project is touted as being primarily altruistic, but there is more to the idea behind it. Evans told Wired that increased user confidence in the security of the web also benefits Google “in a hard-to-measure and indirect way.” Security vulnerabilities are not leveraged by cybercriminals alone, as Snowden’s revelations showed that government organizations also used them for spying purposes. As such, Project Zero also increases the general confidence in Google’s posture for improving the privacy protection of customer information. Moreover, since a chain is as strong as its weakest link, Google products are also vulnerable if third-party content included in them presents a security risk. The security researcher told the online publication that “it’s a major source of frustration for people writing a secure product to depend on third party code,” and that a serious and skilled attacker would always go for the weakest spot. Project Zero offers companies whose product has been found vulnerable a tolerance of 60 to 90 days to issue a patch. After this period, the flaw will be disclosed publicly. If the flaw is already exploited in the wild, the tolerance limit drops to a week, since a larger period of time could mean more victims. The hacker dream team concentrates on bugs in specific areas to make sure that an exploit is rendered unsuccessful. Most of the time, defeating the protection measures implies leveraging a sequence of flaws, and if one of them is patched, exploitation is no longer possible. The team is confident that they’ll be able to successfully hunt down zero-day bugs and “step on some toes,” as Ben Hawkes puts it. Sursa: Hacker Dream Team, by Google

Thanks. Astept un fix de la vBulletin, un realease care sa repare problema, mai astept putin sa isi mai faca lumea update apoi public exploit-ul.

Stiu ca e probabil doar o obsesie a mea, dar daca nu puteti scrie un post incepand propozitia cu majuscula, macar cacatul de titlul sa il incepeti cu majuscula. Tutorial: Tinand apasata tasta Shift, apasati prima litera din titlu. Eliberati tasta Shift. Pentru avansati: Aveti grija sa nu aveti Caps Lock apasat. Multumesc.

Thanks. Postasem si pe forumul lor, dar au sters postul.

Author: Nytro @ Romanian Security Team All details will be available after a fix from vBulletin.

Faceti publice toate informatiile despre el. Jeg de om.

Mergi la Iasi.

Mergi la Iasi.

Si ati luat muie.

Nu am idee. Am primit un card (gift card) cu acel cod. Nu l-am incercat, dar banuiesc ca e bun.

Securitate complet? Aceast? solu?ie de protec?ie complet? permite utilizatorilor individuali ce folosesc orice combina?ie de PC-uri, Mac-uri?i Smartphone-uri sau Tablete cu sistem de operare Android s? î?i protejeze toate dispozitivele de amenin??rile informatice. Acest produs poate acoperi pân? la 3 utilizatori ?i este dedicat exclusiv folosirii la domiciliu! Fiecare utilizator poate proteja un num?r nelimitat de dispozitive. Am primit-o la Defcamp Sparks si nu o folosesc. Primii norocosi... Serial No: http://X44PC5M (Doar pentru userii inregistrati) Have fun.

Ai putea pune si tu un titlu normal.

Da, cred ca s-au terminat, ziceau cei de la suport ca au fost activate toate 5. Am sters din primul post licenta.

[TABLE=width: 626] [TR] [TD=width: 365, align: left]Renewal Kaspersky PURE 3.0 - 5 licenses (1 year)[/TD] [TD=width: 111, align: center]1[/TD] [TD=width: 75, align: right]$109.00[/TD] [TD=width: 75, align: center][/TD] [/TR] [TR] [TD=colspan: 2, align: center][TABLE=width: 476] [TR] [TD=bgcolor: #e5e5e5, align: center]Activation code: M19SY-VZ6BW-15VZF-REMOVED [/TD] [/TR] [/TABLE] [/TD] [/TR] [/TABLE] Am activat pe 3-4 calculatoare, deci ar trebui sa mai fie posibila activarea pe 1-2. Am rugamintea sa postati daca a mers sau nu. Nota: Kaspersky este dupa parerea mea cel mai bun antivirus, dar daca nu aveti un PC bun nu va obositi sa il instalati. Consuma extrem de multe resurse. Merge greu si un i5, cel putin cu setarile "paranoia" facute de mine.

Stiu ca e o porcarie, dar na, poate ii e util cuiva. Discount 10 euro pentru Agentie de turism – Oferte turism | Veltravel . Cod: VEL6MYLFGWR Valabilitate: 30 de zile calendaristice.

La mine, CodeBlocks + MinGW, la 1: 16777217.0 16777218.0 Am gresit pe 2. In C afiseaza "1". In C++ cu "-fpermissive" afiseaza tot "1". Nu am nici cea mai mica idee de ce. Restul le-am stiut.

Imi cumparasem pentru un an, dar nu il mai folosesc. Nu mai are chiar un an de valabilitate, dar cred ca mai e destul. Username: nytro Email: admin -at- rstforums . com Creation Date: 2014-02-17 (17.02.2014) Expiration Date: 2015-03-17 (17.03.2015) VPN Country: RU Plan: Dedicated IP Type of IP: UDP/1194 Assigned IP: 185.17.1.188 ---------------------------------------------- User: nytro Password: http://rstrullz (fara http - ca sa vada doar Registered users) ---------------------------------------------- Nu schimbati parola. PS: Nu puteti schimba adresa de mail fara "acordul meu". Asadar nu va obositi sa schimbati parola.

Bypassing Windows 8.1 Mitigations using Unsafe COM Objects In October last year I was awarded the first $100,000 bounty for a Mitigation Bypass in Microsoft Windows. My original plan was to not discuss it in any depth until Microsoft had come up with a sufficient changes to reduce the impact of the bypass. However as other researchers have basically come up with variants of the same technique, some of which are publically disclosed with proof-of-concept code it seemed silly to not discuss my winning entry. So what follows is some technical detail about the bypass itself. I am not usually known for finding memory corruption vulnerabilities, mainly because I don’t go looking for them. Still I know my way around and so I knew the challenges I would face trying to come up with a suitable mitigation bypass entry. I realised that about the only way of having a successful entry would be to take a difficult to exploit memory corruption vulnerability and try and find a way of turning that into reliable code execution. For that reason I settled on investigating the exploitation of a memory overwrite where the only value you could write was the number 0. Converting a 0 overwrite of this sort, while not impossible to exploit, certainly presents some challenges. I also stated that I could not disclose the existing contents of memory. If you have an information disclosure vulnerability then it is generally game over anyway, so I was confident that would not pass for a winning entry. ActiveX and COM The attack vector for the mitigation bypass was safe-scriptable COM objects. As COM is a general technology, not limited to safe-scripted environments such as Internet Explorer, there are many unsafe objects which could be abused if they were allowed to be created. To prevent this, hosts, such as Internet Explorer, use two mechanisms to determine whether an object is safe for being used in the host environment, Category IDs and the IObjectSafety interface. The Category IDs, CATID_SafeForScripting and CATID_SafeForInitializing can be added to a COM object registration to indicate to a COM host that the object is safe for either scripting or initialisation. These are static indicators, and are not particularly of interest. Things get more interesting with the IObjectSafety interface which is implemented by the COM object. The host can call the GetInterfaceSafetyOptions method to determine whether a COM object is safe to script or initialise (of course this means that the object must have already been created). The interface also has a secondary purpose; once a host has determined that an object is safe it can call the SetInterfaceSafetyOptions method to tell the object how safe it needs to be. This method has a particular implication; it allows COM objects to be written in a generic way with potentially dangerous functionality (such as arbitrary script code execution) and then secured at runtime by disabling the unsafe functions. The typical way this is implemented is by setting flags within the object's memory to indicate the security of the object. This is the attack vector chosen. If we have a suitable memory corruption vulnerability it might be possible to change these security flags to convert a secure object back to an insecure one and use that to circumvent in-place mitigations. A related topic is the setting of an object's site. A Site is normally a reference to the hosting environment for the COM object, such as the OLE container or hosting HTML document. This makes a number of security related functions possible, such as enforcing the same-origin policy for COM objects in a web page (through querying for the IHTMLDocument2 interface and reading the URL property), zone determination or accessing the host security manager. Depending on what we attack we might need to deal with the Site as well. The important point of all this is by default there are many objects which are unsafe until certain flags are stored within the memory allocated for the object. Therefore the unsafe state of these flags is the value 0, where as the safe state is non-zero. This means that if we have got a 0 overwrite vulnerability we can reset the security flags back to the unsafe state and exploit the unsafe functionality of the COM object. Attacking MSXML To demonstrate an attack against scriptable COM objects a suitable object is needed. It must meet some set of criteria to allow us to use the memory corruption vulnerability to bypass mitigations. I determined that the criteria were: The object must be creatable in common COM hosts without significant security issues such as being blocked by policy or site locking The object must be available on default Windows installations or be extremely common The object must do something of benefit to an attacker when insecure, but not expose that functionality when secure (otherwise it would just be a security vulnerability) It must be relatively trivial to convert from secure to insecure through a minimal number of zero memory overwrites The COM objects chosen for the demonstration are implemented by the MSXML libraries. Windows 8.1 comes with versions 3 and 6 of the MSXML library installed by default. They are pretty much considered de-facto secure as without them some websites would break; therefore there are no issues with site-locking or blacklisting. They can even be created in the immersive version of IE without issue. They also have some significant functionality when insecure, namely the ability to circumvent same-origin policy and also to execute fully-privileged scripts within the context of XSL transformation. So MSXML meets the first three criteria, but what about the 4th? Many of the objects that MSXML exposes implement the IObjectSafety interface which is the mechanism through which safety is enabled as shown above. The object also supports the INTERFACE_USES_SECURITY_MANAGER flag which means that the object will utilise the security manager from the hosted site to make some trust decisions. Through reverse engineering the safe objects such as DOMDocument and XMLHTTP, it can be seen that they all contain the COMSafeControlRoot structure, which is used to implement the IObjectSafety and security manager features. In MSXML3 this consists of 6 fields, in the default insecure version these values are all NULL, while in a secure version they contain pointers to site objects and security managers as well as the current security flags set through SetInterfaceSafetyOptions. The rough outline of this structure is shown below: Through inspection, I found that of the 6 values in memory only two were important when it came to bypassing the security mechanisms. This was a pointer to the host security manager at offset 4 and the security flags at offset 20. Crucially these can be reverted back to NULL without causing any other significant effect on the object’s functionality. This means that a very restricted memory corruption could achieve the desired effect, namely our overwrite with zero. Finding an Object in Memory The biggest issue with this technique is that whilst it would be easy enough to modify an object in memory to disable the security without an information disclosure vulnerability, we would not know where it was. If you had an information disclosure vulnerability you probably would not need to use this technique at all. The bypass must be able to guess the location of a valid object in memory and attack it blind. The design of typical scriptable COM hosts come in handy here to achieve this goal. They usually allow you to create an arbitrary number of new objects, this allows for the heap to be flooded with object instances The allocation of COM objects is up to the COM library to implement; therefore it might not be using best practice or it might disable security mitigations The scripting ability allows for executing specific sequences of operations to improve reliable allocation patterns In the general case this makes it a lot easier to use a heap flood technique to generate a reliable pattern of objects on the heap and of a large enough size to guess the location of an object. If a regular pattern of objects can be achieved we can use an arbitrary overwrite to modify values in memory through a guessed location and then find the insecure object to execute our code. There are some issues with the heap improvements in Windows 8. For a start there is a new mitigation called Low Fragmentation Heap Randomisation. The Low Fragmentation Heap (LFH) is a special memory heap used for small allocations to reduce the amount of memory fragmentation that occurs during allocation and freeing of memory. In Windows 8 the order of what blocks is allocated has a random element to it. This makes it more difficult to lay out guessable patterns of allocations. At least once you start allocating 1000s of objects it is still possible to find some level of reliability for allocations. However MSXML3 provides an ideal case, presumably for legacy reasons when running on a multi-processor system it creates its own heap passing the HEAP_NO_SERIALIZE flag. This means that the LFH is disabled which also disables some of the heap improvements in Windows 8. This makes the heap flooding considerably more reliable. The targeted COM object in that library is MSXML2.XMLHTTP.3.0. This is because this object has a considerably smaller heap footprint than DOMDocument which would be the more obvious choice. As long as the object is opened you can read the requestXML property (even without sending the request) to get a DOMDocument object. This document inherits the security settings of the parent XMLHTTP object which allows us to modify XMLHTTP and then use that to execute arbitrary script code. To lay out the heap the provided PoC creates 40,000 instances of XMLHTTP and stores them in an array. Each instance also has the ‘open’ method called on it and a request header set to increase the allocation size for a single object. This results in a repeating 8192 byte pattern of objects being created in memory which looks similar to the following: The actual code was quite simple: Once the heap was flooded the next step was to write the 0 values to a guessed address. The address was chosen empirically, and for the proof-of-concept the overwrite was actually performed using a custom control rather than a real memory corruption vulnerability. By guessing the base address of an object and writing 0s to offsets 4 and 20 we will have disabled the security on one XMLHTTP object, we just need to find which one. For that, the proof-of-concept just enumerated all allocated objects trying each one in turn with a XSL document with an msxsl:script tag containing JScript to start notepad. If the object is still secure then this process will throw an exception, if not we succeeded, notepad has been executed and we can stop looking. Real World Zero Overwrites Of course this entire bypass is predicated on finding a vulnerability which allows you to do an arbitrary overwrite with a 0. How likely is that in the real world? Well honestly I can not give any figures but don't forget that 0 is the typical default state for values, so any code which tries to initialize a value under an attackers control will probably set it to zero. A good example is COM itself. Every COM object must implement the IUnknown interface, the first function QueryInterface is used to convert the object to different interface types. It takes a pointer to the IID and a pointer to a pointer for the returned interface, assuming it supports the required interface. It is recommended that if the object doesn't support the interface it should ensure the outbound pointer is set to NULL before returning. If you've already guessed the location of a COM object you might only be a V-Table dereference away from your coveted arbitrary zero overwrite. Conclusions Obviously this particular example has limitations. It only worked reliably in 32 bit versions of IE as heap flooding is very difficult to do in a reliable way on 64 bit. Of course if you combined this technique with a memory disclosure vulnerability you can achieve code execution without needing to control EIP. The technique is more general than just COM objects in IE. Any structure in a program which has both safe and unsafe functionality is a suitable target. The PoC was necessary to demonstrate the potential. It is interesting that techniques like this are subject to convergent discovery, I wasn't the only person to stumble upon a similar idea, the only reason it is an issue now is the easy routes of exploitation have been closed. Sursa: Bypassing Windows 8.1 Mitigations using Unsafe COM Objects

PE: Portable Executable. Adica .exe, .dll, .sys, nu conteaza limbajul. Dar imi place mai mult asta: https://rstforums.com/forum/86741-cff-explorer.rst

PE Insider PE Insider is a free Portable Executable viewer for the community. It shares the same codebase for inspection as Cerbero Profiler and hence it supports the entire PE specification and is incredibly fast and stable. Click here to download the setup. Sursa: Cerbero - PE Insider

CFF Explorer [TABLE] [TR] [TD]Small announcement: the CFF Explorer was started as a side project many years ago. While I will continue to release updates from time to time, it is not going through radical improvements. If your organization needs professional PE inspection (not editing), then you might take a look at Cerbero Profiler (the commercial product of my company), which properly supports many file formats beyond the complete Portable Executable specification. In addition to that we also offer a completely free PE viewer for the community called PE Insider. [/TD] [TD] [/TD] [/TR] [/TABLE] Created by Daniel Pistelli, a freeware suite of tools including a PE editor called CFF Explorer and a process viewer. The PE editor has full support for PE32/64. Special fields description and modification (.NET supported), utilities, rebuilder, hex editor, import adder, signature scanner, signature manager, extension support, scripting, disassembler, dependency walker etc. First PE editor with support for .NET internal structures. Resource Editor (Windows Vista icons supported) capable of handling .NET manifest resources. The suite is available for x86 and x64. - Explorer Suite (Multi-Platform Version, Recommended) SHA1: 89CAB44D4956210570AB3123FBF13B2B7D870B91 - CFF Explorer (x86 Version, stand-alone, Zip Archive) SHA1: 7A287CD97BD9287C020C98C3496E284D04F5382D - CFF Explorer Extensions Repository The CFF Explorer was designed to make PE editing as easy as possible, but without losing sight on the portable executable's internal structure. This application includes a series of tools which might help not only reverse engineers but also programmers. It offers a multi-file environment and a switchable interface. Also, it's the first PE editor with full support for the .NET file format. With this tool you can easily edit metadata's fields and flags. If you're programming something that has to do with .NET metadata, you will need this tool. The resource viewer supports .NET image formats like icons, bitmaps, pngs. You'll be able to analyze .NET files without having to install the .NET framework, this tool has its own functions to access the .NET format. Useful links: - How to write a CFF Explorer Extension - CFF Explorer Scripting Language Documentation (v2) - CFF Explorer Scripting Language Documentation (v1) - CFF Explorer Extensions Repository Features: Process Viewer Drivers Viewer Windows Viewer PE and Memory Dumper Full support for PE32/64 Special fields description and modification (.NET supported) PE Utilities PE Rebuilder (with Realigner, IT Binder, Reloc Remover, Strong Name Signature Remover, Image Base Changer) View and modification of .NET internal structures Resource Editor (full support for Windows Vista icons) Support in the Resource Editor for .NET resources (dumpable as well) Hex Editor Import Adder PE integrity checks Extension support Visual Studio Extensions Wizard Powerful scripting language Dependency Walker Quick Disassembler (x86, x64, MSIL) Name Unmangler Extension support File Scanner Directory Scanner Deep Scan method Recursive Scan method Multiple results Report generation Signatures Manager Signatures Updater Signatures Collisions Checker Signatures Retriever [TABLE] [TR] [TD] Download the Explorer Suite [/TD] [TD] [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] [/TD] [/TR] [/TABLE] Sursa: NTCore's Homepage

Avem un plan mai bun pentru asa ceva.