Leaderboard

September 26, 2016 Rotten Potato – Privilege Escalation from Service Accounts to SYSTEM By @breenmachine This past Friday, myself and my partner in crime, Chris Mallz (@vvalien1) spoke at DerbyCon about a project we’ve been working on for the last few months. For those interested in watching the talk, it’s online here and the code is available on the FoxGlove Security GitHub page. This blog post is going to dive into some of the technical details of our project in order to remediate @singe’s very accurate observation about our README file on Twitter: So without further delay… Overview As we mentioned a number of times throughout our talk, this work is derived directly from James Forshaw’s BlackHat talk and Google Project Zero research. I highly recommend reviewing both of these resources to anyone interested in pursuing this topic. The idea behind this vulnerability is simple to describe at a high level: Trick the “NT AUTHORITY\SYSTEM” account into authenticating via NTLM to a TCP endpoint we control. Man-in-the-middle this authentication attempt (NTLM relay) to locally negotiate a security token for the “NT AUTHORITY\SYSTEM” account. This is done through a series of Windows API calls. Impersonate the token we have just negotiated. This can only be done if the attackers current account has the privilege to impersonate security tokens. This is usually true of most service accounts and not true of most user-level accounts. Each of these steps are described in the following 3 sections. NTLM Relay to Local Negotiation NTLM relay from the local “NT AUTHORITY\SYSTEM” (we will just call it SYSTEM for brevity) account back to some other system service has been the theme for the Potato privilege escalation exploits. The first step is to trick the SYSTEM account into performing authentication to some TCP listener we control. In the original Hot Potato exploit, we did some complex magic with NBNS spoofing, WPAD, and Windows Update services to trick it into authenticating to us over HTTP. For more information, see the original blog post. Today, we’ll be discussing another method to accomplish the same end goal which James Forshaw discussed here. We’ll basically be tricking DCOM/RPC into NTLM authenticating to us. The advantage of this more complex method is that it is 100% reliable, consistent across Windows versions, and fires instantly rather than sometimes having to wait for Windows Update. Getting Started We’ll be abusing an API call to COM to get this all kicked off. The call is “CoGetInstanceFromIStorage” and to give you some context, here is the relevant code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public static void BootstrapComMarshal() { IStorage stg = ComUtils.CreateStorage(); // Use a known local system service COM server, in this cast BITSv1 Guid clsid = new Guid("4991d34b-80a1-4291-83b6-3328366b9097"); TestClass c = new TestClass(stg, String.Format("{0}[{1}]", "127.0.0.1", 6666)); // ip and port MULTI_QI[] qis = new MULTI_QI[1]; qis[0].pIID = ComUtils.IID_IUnknownPtr; qis[0].pItf = null; qis[0].hr = 0; CoGetInstanceFromIStorage(null, ref clsid, null, CLSCTX.CLSCTX_LOCAL_SERVER, c, 1, qis); } I’m far from being an expert on COM. The “CoGetInstanceFromIStorage” call attempts to fetch an instance of the specified object from a location specified by the caller. Here we are telling COM we want an instance of the BITS object and we want to load it from 127.0.0.1 on port 6666. It’s actually a little more complex than that, because really we’re fetching the object from an “IStorage” object, not just passing a host/port directly. In the code above “TestClass” is actually an instance of an IStorage object in which we’ve replaced some bits and pieces to point back to “127.0.0.1:6666”. Man-In-The-Middle So, now we have COM trying to talk to us on port 6666 where we’ve spun up a local TCP listener. If we reply in the correct way, we have have COM (running as the SYSTEM account) try to perform NTLM authentication with us. COM is trying to talk to us using the RPC protocol. I’m not particularly fluent in RPC and wouldn’t be surprised if there were slight variations based on Windows versions. In order to avoid many headaches, we’re going to use a trick in order to craft our replies. What we will do is relay any packets we receive from COM on TCP port 6666, back to the local Windows RPC listener on TCP port 135. Since these packets we’re receiving are part of a valid RPC conversation, whatever version of Windows we are running will respond appropriately. We can then use these packets we receive back from Windows RPC on TCP 135 as templates for our replies to COM. If that’s not clear, the following shows the first few packets of this exchange in WireShark: Notice that the first packet we receive (packet #7) is incoming on port 6666 (our listener, this is COM talking to us). Next, we relay that same packet (packet #9) to RPC on TCP 135. Then in packet #11, we get a reply back from RPC (TCP 135), and in packet #13, we relay that reply to COM. We simply repeat this process until it’s time for NTLM authentication to occur. You can think of these initial packets as just setting the stage for the eventual NTLM auth. NTLM Relay and Local Token Negotiation Before we dive into the NTLM relay details, let’s look at it at a high level. The following is from our slide deck: On the left in blue are the packets that COM is going to send to us on TCP port 6666. On the right, in red, are the Windows API calls that we’re going to make using data that we pull out of those packets. Let’s look a little closer at the API calls on the right, since most people will not be familiar with them. In order to locally negotiate a security token using NTLM authentication, one must first call the function “AcquireCredentialsHandle” to get a handle to the data structure we will need. Next, we call “AcceptSecurityContext”, and the input to this function will be the NTLM Type 1 (Negotiate) message. The output will be an NTLM Type 2 (Challenge) message which is sent back to the client trying to authenticate, in this case, DCOM. When the client responds with an NTLM Type 3 (Authenticate) message, we then pass that to a second call to “AcceptSecurityContext” to complete the authentication process and get a token. Let’s look at the packet capture and break this all down… TYPE 1 (NEGOTIATE) PACKET After relaying a few packets between RPC and COM, eventually COM is going to try to initiate NTLM authentication with us by sending the NTLM Type 1 (Negotiate) message, as shown in packet #29 of the packet capture below: This is where things start to get interesting. Again, we relay this to RPC (on TCP 135), and RPC will reply with an NTLM Challenge. But there’s one more thing going on here that you don’t see in the packet capture. When we receive the NTLM Type 1 (Negotiate) message from COM, we rip out the NTLM section of the packet (as shown below), and use it to begin the process of locally negotiating a token: So, as discussed above, we call “AcquireCredentialsHandle”, and then “AcceptSecurityContext”, passing as input the NTLM Type 1 (Negotiate) message we pulled out of that packet. NTLM TYPE 2 (CHALLENGE) PACKET Recall that we forwarded the NTLM Type 1 (Negotiate) packet to RPC on port 135, RPC will now reply with an NTM Type 2 (Challenge) packet which can be seen in our packet capture above in packet #33. This time, we do NOT simply forward this packet back to COM, we need to do some work first. Let’s take a closer look at the two NTLM Type 2 (Challenge) packets from the capture above: Notice the highlighted field “NTLM Server Challenge” and the field below it “Reserved”, and that they differ in value. This would not be the case if we had simply forwarded the packet from RPC (on the left) to COM (the one on the right). Recall that when we made the Windows API call to “AcceptSecurityContext”, the output of that call was an NTLM Type 2 (Challenge) message. What we’ve done here is replace the NTLM blob inside the packet that we are sending to COM with the result of that API call. Why would we do this? Because we need COM, running as the SYSTEM account to authenticate using the NTLM challenge and “Reserved” section that we are using to negotiate our local token, if we did not replace this section in the packet, then our call to “AcceptSecurityContext” would fail. We’ll talk more about how local NTLM authentication works later, but for now just know that the client who is trying to authenticate (in this case SYSTEM through COM) needs to do some magic with the “NTLM Server Challenge” and “Reserved” sections of the NTLM Type 2 (Negotiate) packet, and that we’ll only get our token if this magic is performed on the values produced by our call to “AcceptSecurityContext”. NTLM TYPE 3 (AUTHENTICATE) PACKET So now we’ve forwarded the modified NTLM Type 2(Negotiate) packet to COM where the “Challenge” and “Reserved” fields match the output from “AcceptSecurityContext”. The “Reserved” field is actually a reference to a SecHandle, and when the SYSTEM account receives the NTLM Type 2 message, it will perform authentication behind the scenes in memory. That is why it is so crucial that we update the “Reserved” field… Otherwise, it would be authenticating to RPC instead of US! Once this is completed, COM on behalf of the SYSTEM account will send us back the NTLM Type 3 (Authenticate) packet. This will just be empty (because all the actual authentication here happened in memory), but we will use it to make our final call to “AcceptSecurityContext”. We can then call “ImpersonateSecurityContext” with the result of the final call above to get an impersonation token. Using the ImpersonationToken The following diagram (youtube play bar included) from James Forshaw’s BlackHat talk“Social Engineering the Windows Kernel” shows the pre-requisites to impersonating the token that we have now negotiated: From this, it is clear that if we want to impersonate the token, we better be running as an account with SeImpersonate privilege (or equivalent). Luckily this includes many service accounts in Windows that penetration testers often end up running as. For example, the IIS and SQL Server accounts. The following two videos show the exploit in action: IIS: SQL Server: Sursa: https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/

Poate e optimizat pentru campanii de marketing prin email.

nu are treaba impozitu cu datoria care o ai la banca dar din nefericire trebuie sa achite totul ca sa poata inchide contul implicit anularea cardului ... semnatura data pe contract e acceptul tau inlegatura cu clauzele ...bancii ... tocmai din acest motiv imi place sa semnez doar pe Hartia Igienica

Recuperatorii de creanțe vor putea să contacteze doar anumite persoane în afară de datornic, iar contactarea la muncă sau între anumite ore ale zilei va fi interzisă, potrivit unui act normativ care se va aplica de vineri. Pe deasupra, recuperatorii nu vor avea voie să amenințe, să hărțuiască sau să abuzeze datornicii. În caz contrar, amenzile vor putea ajunge până la 100.000 de lei. Recuperatorii de datorii vor avea o serie de interdicții exprese atunci când vine vorba de contactarea cetățenilor și comunicarea cu aceștia, a căror încălcare va fi egală cu sancționarea drastică de către autorități. Prevederile se găsesc în Ordonanța de urgență a Guvernului nr. 52/2016, ce va intra în vigoare vineri, și acestea vor viza creditele pe care le contractează consumatorii. Mai exact, contactarea datornicilor la locul de muncă al acestora, precum și comunicarea cu ei între orele 20:00 - 09:00 vor fi interzise, după cum se arată în actul normativ. Totodată, interzisă va fi și „contactarea, în legătură cu recuperarea creanțelor, a oricărei altei persoane diferită de consumator, succesorii legali, avocatul sau împuternicitul acestuia, creditorul, avocatul sau împuternicitul creditorului”, scrie în OUG nr. 52/2016. Tot de vineri, recuperatorii de datorii nu vor avea voie să folosească tehnici de hărțuire sau abuz și nici amenințări sau alte tehnici agresive, „cu scopul de a vătăma fizic ori psihic consumatorul ori rude ale acestuia ori de a-i afecta reputația sau proprietatea”, mai prevede documentul. În afară de actele de procedură ce trebuie afișate la cererea executorului judecătoresc sau a instanței, recuperatorilor de creanțe le va fi interzis să afișeze, la ușa apartamentului sau a blocului, notificări/somații/adrese în legătură cu recuperarea creanțelor. De asemenea, recuperatorii nu vor putea să perceapă comisioane, dobânzi și dobânzi penalizatoare (în afară de dobânzile penalizatoare legale) și nici să perceapă costuri pentru activitatea de recuperare (în afară de costurile procedurilor de executare silită). În principiu, încălcarea acestor prevederi va putea fi sancționată cu amenzi cuprinse între 10.000 și 80.000 de lei, de către reprezentanții Autorității Naționale pentru Protecția Consumatorilor (la sesizarea cetățenilor sau din oficiu). Totuși, dacă va fi vorba de un credit pentru un bun imobil, amenda va fi cuprinsă între 20.000 și 100.000 de lei. Consumatorii vor trebui atenționați că pot contesta datoriile Recuperatorii de creanțe vor fi obligați, începând de vineri, să atenționeze cetățenii că sunt îndreptățiți să conteste atât existența datoriei, cât și cuantumul acesteia. Concret, contestația va putea fi transmisă în cel mult 30 de zile calendaristice de la primirea notificării. Conform OUG nr. 52/2016, în această perioadă, precum și până la momentul comunicării răspunsului, recuperatorilor le va fi interzis să deruleze activități pentru recuperarea datoriilor, altfel vor risca o amendă cuprinsă între 10.000 și 80.000 de lei. La fel, dacă va fi vorba de un credit pentru un bun imobil, amenda va fi între 20.000 și 100.000 de lei. Important de știut este că cetățenii vor putea să se adreseze direct instanțelor judecătorești pentru a contesta existența unei datorii sau cuantumul acesteia. Totodată, noile prevederi vor stabili că, dacă datoriile nu sunt contestate la recuperatori în termenul de 30 de zile calendaristice, acest fapt nu va reprezenta o recunoaștere a sumei de către datornici, iar dreptul de a se adresa unei instanțe își va păstra valabilitatea. În prezent, recuperatorii de datorii se ghidează după un Cod de conduită elaborat de Asociația de Management al Creanțelor Comerciale, despre care AvocatNet.ro a scris anul trecut. Totuși, Guvernul a decis să introducă în legislația creditelor atât interdicții exprese pentru recuperatori, cât și sancțiuni drastice pentru nerespectarea acestora. În altă ordine de idei, ordonanța de urgență amintită dispune că, de la 1 ianuarie 2017, doar recuperatorii de datorii înregistrați la Autoritatea Națională pentru Protecția Consumatorilor vor putea să funcționeze în mod legal. Detalii despre acest aspect găsiți aici. Notă: Informații pe larg despre noile reguli ce se vor aplica, începând din 30 septembrie, în cazul creditelor pentru bunuri imobile pot fi găsite aici. http://www.realitatea.net/recuperatorii-de-crean-e-nu-mai-au-voie-sa-te-hartuiasca-incepand-de-vineri_1986333.html

mie mi sa intamplat sa mio iau ... gen .. un prieten mi-a trimis din sua .. un htc .. ma rog numai in sua comercializat .. el nu stia ca la noi se arde cu simuri .. si singurul care putea sa ma preia cu telefon .. era zap mobile .. la care am incercat sal inscriu fara reusita .. asa ca lam revandut pe ebay in sua ... si acum am actele vamale de atunci ... de la posta romana absolut tot ... dar .. degeaba ... si sau pus dupa 5 ani firecredit pe mine ca le datorez acum de la pretul de 200 usd cu cat lam vandut .. am sa le dau 1700 ron actual ... sa ajunga in instanta asta vreau dar stiu ca nau sanse .. dar o forteaza si ei ca na deci in general pe platforma ebay paypal .. cine cumpara e rege vanzatorul .. e JUST SHIT ... .. de fapt ei incurajeaza FURTUL ...

Microsoft previews Project Springfield, a cloud-based bug detector David Molnar, left, and Patrice Godefroid, right, are two of the key researchers behind Project Springfield. (Photography by Scott Eklund/Red Box Pictures) Posted September 26, 2016 By Allison Linn Microsoft is making available to its customers one of the most sophisticated tools it has for rooting out potential security vulnerabilities in software including Windows, Office and other products. The offering is code named Project Springfield, and up until now, the team that built it has thought of it as the million-dollar bug detector. That’s because every time the system finds a potentially serious bug proactively, before a piece of software is released, it is saving a developer the costly effort of having to release a patch reactively, once the product is already public. With widely used software such as an operating system or productivity suite, deploying those patches can cost as much as $1 million, the researchers say. Patrice Godefroid (Photography by Scott Eklund/Red Box Pictures) “Those are the bugs that hackers will try to use,” said Patrice Godefroid, a principal researcher at Microsoft who invented a key technology behind Project Springfield and is the project’s chief scientist. “The more we can find those bugs ourselves, the more we can fix them before we ship the software.” Microsoft announced a preview of Project Springfield on Monday at its Ignite technology conference in Atlanta. It has previously been testing the new cloud security service with a small number of customers and collaborators using software on a smaller scale than Windows and Office. The company itself has been using a key component of Project Springfield, called SAGE, since the mid-2000s, testing products including Windows 7 prior to release. Although the Windows 7 operating system code had already been checked by other, similar security tools, Godefroid said SAGE unearthed a number of additional vulnerabilities, eventually accounting for one-third of all the bugs this kind of security testing, which is called fuzz testing, discovered prior to the release. The team overseeing the fuzz testing was impressed. “There aren’t a lot of tools that can do what SAGE does,” said Mark Wodrich, a senior security engineer with Windows Defender Advanced Threat Protection. One tool in the security toolbox Fuzz testing is far from the only security measure developers use, but security experts say it’s an important one in the security development lifecycle. David Molnar, the Microsoft researcher who leads Project Springfield, said fuzz testing is ideal for software that regularly incorporate inputs such as documents, images, videos or other pieces of information that may not be trustworthy. Fuzz testing looks for vulnerabilities that could open the door for bad actors to launch malicious attacks or simply crash the system, causing delays and other problems. “These are the serious bugs that it’s worth investing to prevent,” Molnar said. Broadly speaking, fuzz testing works like this: The system throws random, unexpected inputs at a piece of software to look for instances in which those unforeseen actions cause the software to crash, signaling a security vulnerability. Project Springfield builds on that idea with what it calls “white box fuzz testing.” It uses artificial intelligence to ask a series of “what if” questions and make more sophisticated decisions about what might trigger a crash and signal a security concern. Each time it runs, it gathers data to hone in on the areas that are most critical. This more focused, intelligent approach makes it more likely that Project Springfield will find vulnerabilities other fuzzing tools might miss. David Molnar (Photography by Scott Eklund/Red Box Pictures) From software research to security product SAGE grew out of years of Microsoft’s basic research into formal methods, which are systems for reasoning about code to look for imperfections. As SAGE developed, the researchers were regularly publishing research papers detailing the advantages of their approach. That, in turn, drew the interest of security experts and other researchers who wanted to use the tool as well. “Customers had asked about it for years, but we’d never been able to offer it to them,” Molnar said. In order to make the software security tool available to a broader group of people with fewer resources and security expertise than the Windows and Office organizations, the researchers built Project Springfield. It bundles SAGE with other tools for fuzz testing and adds an easy-to-use dashboard and other interfaces that make it accessible for people without an extensive security background. Then, it runs its tests using an Azure cloud-based system, so individual clients don’t need to have data centers of their own. Finally, the results are delivered securely to the customers, so they can fix the bugs and test the code again. “It’s very simple to use – it’s ‘fire and forget,’” said Gavin Thomas, a principal security software engineering manager with the Microsoft Security Response Center. “You set it up and you walk away.” Thomas first used Project Springfield when a Microsoft customer came to him for help in looking for security vulnerabilities. Thomas said Project Springfield proved as easy to use as any app, and it was so effective at finding bugs that Thomas is in the process of implementing it in his own labs. That will save his expert security engineers the time of manually creating similar tools, allowing them to focus on other issues. The team behind Project Springfield includes, from left, Stas Tishkin, William Blum, Marc Griesen, Cheick Omar Keita, Dave Tamasi, David Molnar (seated) , Theresa Pacheco, Marina Polishchuk, Patrice Godefroid and Ram Nagaraja. (Photography by Scott Eklund/Red Box Pictures) Too many bugs, not enough security experts It turns out that Microsoft customer’s challenge wasn’t unusual. Project Springfield is being released at a time when many companies are facing a tough conundrum: Serious attacks on software are going up, but the supply of security engineers trained to fight those attacks is staying steady. That means plenty of companies can’t afford, or can’t find, the staff they need to do fuzz testing. They need an easier, more automated solution. “Most companies may not have a security engineer and wouldn’t even know what a fuzzer is,” Thomas said. It’s also coming at a time when many companies are revamping their systems to appeal to new digital tastes, adding mobile offerings, online sales or cloud-based services. Chad A. Holmes, a principal and cyber strategy, technology and growth leader for the professional services firm Ernst & Young LLP, said that means many companies need a system like Project Springfield, which has the cloud-based capacity to run a very high volume of security tests at the same time and root out the most critical concerns. “That’s one of the largest challenges they run into, the scale of testing these applications,” Holmes said. “That’s where a tool like Springfield comes in.” EY may offer Project Springfield as part of the security offerings it has for customers. Making beer and finding bugs For many companies, finding bugs is important not just because it can protect a company against hackers but also because it can save time and money. Take the craft beer brewer Deschutes Brewery, for example. If there’s a glitch in the software it uses for analytics, it can literally mean that money – or, in this case, beer – has to go down the drain. “The brewery doesn’t get a batch of beer back when something goes wrong,” said Bryan Owen, a cyber security manager with OSIsoft, which has been helping Deschutes build a system that can bring together data from multiple sources. “It’s just lost.” OSIsoft used Project Springfield to proactively look for bugs and other vulnerabilities as part of an overhaul of Deschutes’ analytics systems, which included installing its PI System,PI Integrator for Microsoft Azure, and deploying the Cortana Intelligence Suite. Deschutes Brewery’s brewmaster, Brian Faivre, said the new analytics systems have helped them figure out ways to make better beer, without having to worry about the technical details. “Our job is really focusing on quality and making beer,” Faivre said. “If, at the end of the day, this is helping us do a better job, that’s what we really value and we care about.” Peter Lee (Photography by Scott Eklund/Red Box Pictures) Beating the bad guys Project Springfield also has been developed at a time in which Microsoft researchers are getting more aggressive about quickly translating their groundbreaking research into tools customers can use. With Project Springfield, Peter Lee, the corporate vice president in charge of Microsoft Research’s New Experiences and Technologies organization, said the team was determined to make sure it was “literally rubbing elbows” with the clients who were participating in an early preview of the system, having regular, face-to-face meetings to make sure it would meet their security needs. “I actually view it as a collaboration,” he said. “In my mind, we’re doing the research together.” Lee said that type of collaboration between researchers and developers is especially important in the security field, because it’s so tough for the good guys in computer security to stay ahead of the bad guys. That’s because the bad guys have the tools, expertise and financial incentive to exploit vulnerabilities faster than the good guys can find them. He sees cloud-based tools like Project Springfield as a key tool in the good guys’ arsenal. “This is one of the areas where, finally, the good guys have an advantage,” he said. Sursa: https://blogs.microsoft.com/next/2016/09/26/microsoft-previews-project-springfield-cloud-based-bug-detector/#sm.001xkp83k12aoe5uqzo2o1ae0f0fz

Pe spok il gasesti pe localbitcoin si are si nr de tel .. de gasit il gasesti in buc pe undeva prin munci ...