Information Security News
German infosec bureaucrats want mail providers to encrypt
Endorsement of the idea comes from no lesser an agency than Germany's Federal Office for Information Security, according to local site Heise. Heise reports that the office has released a technical directive, BSI TR-03108, urging German email providers ...
On Tuesday, Oracle released its Quarterly Critical Patch Update or CPU for short. As usual, this release covers a long list of different products, and is too large to summarize in a diary. Oracle patched a total of 154 vulnerabilities. Here are some of the highlights :
Of course, Java is always getting a lot of attention as it has probably the largest user base among Oracles products. This time, Oracle is patching 25 Java flaws. All vulnerabilities can be exploited via Java Web Start applications, but only 5 apply to Java running on servers. 7 of the vulnerabilities have the highest CVSS score of 10 (none of these can be exploited on server side code).
The Integrated Lights Out Manager (ILOM) receives a patch that fixes a remote code execution vulnerabilities with a base CVSS score of 10. Comparable IPMI interfaces suffered from numerous vulnerabilities in the past, and Oracle does the right thing by advising users to not expose these interfaces to public networks.
Various Oracle components use OpenSSL, and this patch includes OpenSSL related updates for MySQL, Oracle Enterprise Manager andOracle Supply Chain Products.
According to Oracle, there is no evidence that any of these vulnerabilities has been exploited so far. The next update will be released in January.
Several versions of self-encrypting hard drives from Western Digital are riddled with so many security flaws that attackers with physical access can retrieve the data with little effort, and in some cases, without even knowing the decryption password, a team of academics said.
The paper, titled got HW crypto? On the (in)security of a Self-Encrypting Drive series, recited a litany of weaknesses in the multiple versions of the My Passport and My Book brands of external hard drives. The flaws make it possible for people who steal a vulnerable drive to decrypt its contents, even when they're locked down with a long, randomly generated password. The devices are designed to self-encrypt all stored data, a feature that saves users the time and expense of using full-disk encryption software.
"After researching the inner workings of some of the numerous models in the My Passport external hard drive series, several serious security vulnerabilities have been discovered, affecting both authentication and confidentiality of user data," the researchers wrote. "We developed several different attacks to recover user data from these password protected and fully encrypted external hard disks."
For years, scammers claiming that they're "calling from Windows" have dialed up Microsoft customers and done their best to trick them into parting with their money or installing malicious wares. Now, the swindlers are turning their sights on Mac users.
Researchers at antivirus provider Malwarebytes spotted a Web-based campaign that attempts to trick OS X and iOS users into thinking there's something wrong with their devices. The ruse starts with a pop-up window that's designed to look like an official OS notification. "Critical Security Warning!" it says. "Your Device (iPad, iPod, iPhone) is infected with a malicious adward [sic] attack." It goes on to provide a phone number people can call to receive tech support.
The site ara-apple.com is designed to masquerade as https://ara.apple.com/, Apple's official remote technical support page. People who are experiencing problems with their Macs can go there to get an official Apple tech support provider to remotely access the person's computer desktop. Ara-apple provides links to the remote programs the supposed technician will use to log in to targets' Macs.
A nonprofit effort aimed at encrypting the entire Web has reached an important milestone: its HTTPS certificates are now trusted by all major browsers.
The service, which is backed by the Electronic Frontier Foundation, Mozilla, Cisco Systems, and Akamai, is known as Let's Encrypt. As Ars reported last year, the group will offer free HTTPS certificates to anyone who owns a domain name. Let's Encrypt promises to provide open source tools that automate processes for both applying for and receiving the credential and configuring a website to use it securely.
HTTPS uses the transport layer security or secure sockets layer protocols to secure websites in two important ways. First, it encrypts communications passing between visitors and the Web server so they can't be read or modified by anyone who may be monitoring the connection. Second, in the case of bare bones certificates, it cryptographically proves that a server belongs to the same organization or person with control over the domain, rather than an imposter posing as that organization. (Extended validation certificates go a step beyond by authenticating the identity of the organization or individual.)
The cost and time required to break 512-bit RSA encryption keys has plummeted to an all-time low of just $75 and four hours using a recently published recipe that even computing novices can follow. But despite the ease and low cost, reliance on the weak keys to secure e-mails, secure-shell transactions, and other sensitive communications remains alarmingly high.
The technique, which uses Amazon's EC2 cloud computing service, is described in a paper published last week titled Factoring as a Service. It's the latest in a 16-year progression of attacks that have grown ever faster and cheaper. When 512-bit RSA keys were first factored in 1999, it took a supercomputer and hundreds of other computers seven months to carry out. Thanks to the edicts of Moore's Law—which holds that computing power doubles every 18 months or so—the factorization attack required just seven hours and $100 in March, when "FREAK," a then newly disclosed attack on HTTPS-protected websites with 512-bit keys, came to light.
In the seven months since FREAK's debut, websites have largely jettisoned the 1990s era cipher suite that made them susceptible to the factorization attack. And that was a good thing since the factorization attack made it easy to obtain the secret key needed to cryptographically impersonate the webserver or to decipher encrypted traffic passing between the server and end users. But e-mail servers, by contrast, remain woefully less protected. According to the authors of last week's paper, the RSA_EXPORT cipher suite is used by an estimated 30.8 percent of e-mail services using the SMTP protocol, 13 percent of POP3S servers. and 12.6 percent of IMAP-based e-mail services.
Four years ago, about a dozen credit cards equipped with chip-and-PIN technology were stolen in France. In May 2011, a banking group noticed that those stolen cards were being used in Belgium, something that should have been impossible without the card holders inputting their PINs. That’s when the police got involved.
The police obtained the international mobile subscriber identity (IMSI) numbers present at the locations where the cards were used and at the times they were used, and then they correlated those IMSI numbers to SIM cards.
Using that information, the police were able to arrest a 25-year-old woman carrying a large number of cigarette packs and scratchers, which were apparently intended for resale on the black market. After her arrest, four more members of the fraud ring were identified and arrested. That number included the engineer who was able to put together the chip card hacking scheme that a group of French researchers call "the most sophisticated smart card fraud encountered to date.”
by Sebastian Anthony
How do you defend yourself against the unknown? That is crux of the zero-day vulnerability: a software vulnerability that, by definition, is unknown by the user of the software and often its developer as well.
Everything about the zero-day market, from research and discovery through disclosure and active exploitation, is predicated upon this fear of the unknown—a fear that has been amplified and distorted by the media. Is the world really at threat of destabilisation due to lone-wolf hackers digging up vulnerabilities in popular software packages and selling them to whichever repressive government offers the most money? Or is it just a classic case of the media and megacorp lobbyists focusing on the sexy, scary, offensive side of things, and glossing over the less alluring aspects?
And then what about legislation and regulation of zero-days? In most countries, there are scant legal mechanisms for discouraging or punishing the discovery of new zero-days. There are even fewer laws and directives dictating how zero-days should be responsibly disclosed. It isn't that lawmakers aren't aware of these problems, it's just that there isn't an easy solution. How do you craft a law that allows some research groups to keep on digging for vulnerabilities while at the same time blocking the black hats? What if the government's idea of "responsible disclosure" means disclosing all vulnerabilities to GCHQ or the NSA?
Infosec workers swipe Q-tip across 'net: Ew, there's Dridex on it
The Dridex banking botnet is continuing to show some signs of life even after a high-profile FBI-led disruption operation earlier this month. Servers associated with Dridex were seized in a co-ordinated operation on 13 September weeks after a suspect, ...
Out of most penetration tests I do, XSS vulnerabilities are still probably the most common ones we encounter (if I dont count missing Secure and HttpOnly flags on cookies :)).
Even web application vulnerability scanners have become increasingly successful in finding XSS vulnerabilities so the next question (besides why do we still see them) is related to their exploitation.
I recently encountered a simple, but interesting XSS vulnerability, which demonstrated yet again how standardization is important. So, lets see what this is about.
The vulnerability in question is a very simple reflected XSS vulnerability where contents of a user supplied parameter from a GET HTTP request are copied directly into the resulting HTML.
However, there was a simple catch ">...
form action=">/myform/action/post id=myform method=post name=myform">...
The contents of the injected parameter are highlighted in the HTML code shown above (also there should be at the beginning and ">...
form id=myform action=">/myform/action/post?myparam=123 method=post name=myform
Ok hopefully all of you see where this is going to. If we insert the character we will close the action parameter and are practically free to do whatever we want. If we can insert the character its game over.
The vulnerability shown is very simple and in most cases even web application vulnerability scanners will detect is as such.
So whats the story here you might ask? Well, the tricky thing is in getting the victim to click on a link which will exploit the vulnerability. Remember how we need to send the ">http://www.vulnerable.application/myform/action/post?myparam=">GET /myform/action/post?myparam=%20Test
Say whaat (insert image from Anchorman 2 here)? Interesting! So, in other words, Internet Explorer is the only browser (of those three I tested) that will not encode the characters. This effectively allows the attacker to launch a reflected XSS attack against Internet Explorer users, while those using Mozilla Firefox and Google Chrome will be safe(r)! (so Internet Explorer is indeed less secure .. /me ducks).
Jokes aside, why is this happening? In order to dig that out we need to check URI syntax, which is specified in RFC 3986 (https://tools.ietf.org/html/rfc3986). The RFC splits characters into several groups: unreserved characters ( ALPHA / DIGIT / - / . / _ / ~ ), reserved characters ( : / / / ? / # / [ / ] / @ and ! / $ / / / ( / ) / * / + / , / / =) and all the others.
We can see that , and are in neither of the lists above! However, the RFC says the following:
then only those octets that do not correspond to characters in the unreserved set should be percent-encoded.
One would probably read this as the following: *everything* apart from unreserved characters should be encoded. However, while reading the RFC I missed what really a new URI scheme is?
In any case, it looks as Internet Explorer developers decided that they will strictly encode only reserved characters (plus some extras), but they left couple of important ones such as , and .
I had a lively discussion with my colleague Marin about reporting such vulnerabilities in penetration tests. Our conclusion was to always report it (of course), even though exploitability might be more or less difficult (or even impractical) with some browsers the underlying vulnerability is still here and should be fixed.
How does your browser behave? Let us know!