Information Security News
Cisco today released a security advisory announcing that some of Ciscos IronPort virtual appliance products contain multiple default SSH keys. To quote:
A vulnerability in the remote support functionality of Cisco WSAv, Cisco ESAv, and Cisco SMAv Software
could allow an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user.
Oh, good thing its only root. You had me worried there for a second :). Interestingly, there was a somewhat similar Cisco advisory one year ago(on CUCDM) where also a default SSH key was present, and equally led to root privileges. Searching for default credentials on Cisco" />
To Ciscos credit, they seem to have foundtodays SSH key problem on their own, before it was abused, so maybe this is a sign of better times to come, and evidence that after all these years, someone at Cisco has actually started to systematically audit their entire code base for the presence of default credentials. Or maybe it just was a lucky find, and the stellar 10 year track record of default credential security bulletins will continue for another decade? Time will tell...(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
by Sean Gallagher
Pwnie Express, the company that began as a builder of "drop boxes" for penetration testers and white-hat corporate hackers, has been evolving toward a more full-service security auditing platform vendor over the past few years while continuing to refine its hardware and software in ways that appeal to the corporate security set. Now Pwnie has released the third generation of its flagship mobile penetration testing platform, the Pwn Pad, bringing the Android and Kali Linux-based platform a step further away from the rough-hewn penetration testing tools it began with and into the realm of something with a lot more polish—and performance.
Pwnie Express' Mobile Platform Engineer Tim Mossey and Director of Research and Development Rick Farina recently gave Ars a walk-through of the Pwn Pad 3, which has just begun shipping out to pre-order customers. We expect to do a full review of the Pwn Pad 3 soon but wanted to get an early look at what to expect. The biggest visible change is the hardware itself, as Pwnie has left the relative comfort zone of Google's reference platform Nexus tablets and moved to the more powerful Nvidia Shield. But there are some changes behind the scenes as well that make the Pwn Pad 3 act more like an actual flagship commercial product and less like something way off the corporate reservation.
Full disclosure is in order here—Ars bought hardware from Pwnie Express to support our own security testing lab, and we enlisted help from Pwnie Chief Technology Officer Dave Porcello for our joint project with National Public Radio last year. So we've had a bit of experience with Pwnie's platform in many of its incarnations. We've also worked with a number of open source penetration tools, including the Kali Linux-based NetHunter platform for Android.
by Sean Gallagher
The FBI's Internet Crime Complaint Center (IC3) has issued an alert warning businesses and individuals about the continued spread of cryptographic ransomware. This malware encrypts a victim's files with a key held by criminals on a remote server, and it then extorts money from the victim to recover those files. The biggest threat among these continues to be CryptoWall, the ransomware family that first emerged last April.
So far, the FBI's IC3 has been contacted by 992 victims of CryptoWall, and their combined losses total over $18 million (~£11.4 million). That number falls far short of the actual number of victims, some of whom have not reported being affected by the malware and have simply paid up or abandoned their files. And the current cost figure does not include all of the business losses from those reporting CryptoWall incidents. Those hidden impacts can include lost productivity, the cost of bringing in IT services to clean up the mess, or the price of handling the potential breach of personal information associated with the malware.
"CryptoWall 3.0 is the most advanced crypto-ransom malware at the moment," said Stu Sjouwerman, CEO of the security training company KnowBe4, in an e-mail to Ars. "The $18 million in losses is likely much more, as many companies do not report their infections to the FBI and the downtime caused by these infections is much higher.”
The goal of a penetration test is to report all identified vulnerabilities to the customer. Of course, every penetration tester puts most of his effort into finding critical security vulnerabilities: SQL injection, XSS and similar, which have the most impact for the tested web application (and, indeed, it does not hurt a penetration testers ego when such a vulnerability is identified :)
However, I strongly push towards reporting of every single vulnerability, no matter how harmless it might appear (and my penetration team coworkers sometimes complain about this, but lets prove them wrong).
Here well take a look at how two seemingly low risk vulnerabilities can be combined into a more dangerous one.
Accepting parameters in GET and POST requests
When processing parameters/responses received from the client, most of the todays web applications rely on POST HTTP requests. This is a preferred way of sending client-related input/output from the browser since it will not be visible in web servers (or proxys) logs. One of the tests I normally do is to check if the application accepts same parameters in GET HTTP requests. Lets take a look at this.
The official">POST /page HTTP/1.1
">parameter=value">GET /page?parameter=valuesecret=secret_value HTTP/1.1
If this worked it means that the tested web application (the tested page/script) accepts parameters from any request. While this by itself is not really a security vulnerability, it is not a perfect way for receiving and processing parameters as we will see below. Additionally, keep in mind that this makes an attackers job a bit easier instead of working with POST HTTP requests he can simply put everything into GET HTTP request (yeah, it works for the defenders as well since well see what he put into the request).
A seemingly harmless XSS vulnerability
While further testing this application we found an XSS vulnerability. For sake of simplicity lets say its an anonymous application that has no login forms. However, since the application depends on a certain workflow, and since the XSS vulnerability was found in the 3rd step of the workflow, it does require a valid session cookie (aJSESSIONID cookie).
What does this mean? It means that the attacker cannot exploit the XSS vulnerability: if the request to the vulnerable page is made without a valid JSESSIONID cookie, the application simply redirects the user to the front page (the first step of the workflow). Even if the victim now again clicked on the malicious link, it still wouldnt work because the tested application checks the workflow phase/step and if it is not correct again simply redirects the user to the front page.
Ahh, such a disappointment after finding a very nice XSS vulnerability: the attacker can really exploit only himself and thats no fun at all. Or is there another way?
Taking this a bit further
Remember how we figured out that the application accepts parameters in both GET and POST HTTP requests above?
Since the cookie is normally sent as part of a header, the attacker cannot get the victims browser to set the cookie for the target web application, at least not without exploiting another vulnerability such as an XSS vulnerability but remember that we cannot exploit it without a valid cookie. Catch 22 isnt it?
But, let">GET /page?JSESSIONID=560308266F93351159D8D20732C637FAmeter=valuesecret=secret_value HTTP/1.1
Bingo! This worked the tested web application happily took and parsed all submitted parameters, even the JSESSIONID parameter that should be normally delivered as a cookie. The developers probably wanted to be as flexible as possible.
Combining the vulnerabilities into an exploit
So, the attacker can now deploy the following attack:
Finally, last thing to discuss is maybe what we exploit with the XSS vulnerability in the first place: typically the attacker tries to steal cookies in order to gain access to the victims session. Since here sessions are irrelevant, the attacker will not use XSS to steal cookies but instead to change what the web page displays to the victim. This can be used for all sorts of phishing exploits and, depending on the URL and context of the attack, can be even more devastating than stealing the sessions.