12 Sep Spam one step ahead of iPhone 5 release Maria
10 Apr Patch Tuesday April 2012 - Patching Multiple Web Based Client Side and Spearphishing Exposures Kurt Baumgartner
10 Feb When Certificate Authority Business Models and Vendor Certificate Policies Clash Kurt Baumgartner
07 Nov Gaddafi’s death in spam Maria
20 May Smart money? David
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
This month Adobe's realing fixes for both Flash Player and Shockwave.
The vulnerabilies for Flash Player affect all platforms and concern two CVEs - CVE-2013-5331 and CVE-2013-5332, which both allow for remote code execution. Eploitation of CVE-2013-5331 using Microsoft Word as a leverage mechanism has been observed in the wild. Though Flash 11.6 introduced Click-to-Play for Office, users may still be socially engineered into running Flash content in Office documents. Make sure to apply this patch promptly.
Apple fans are eagerly awaiting the arrival of iPhone 5 which is due out today. Each unveiling of an iDevice is accompanied by a global buzz of excitement which usually attracts the attention of spammers: every new iPad or iPhone inevitably becomes the bait in numerous fake lotteries and other fraudulent emails.
However, customers are not only interested in Apple’s devices but also their accessories. This year’s first registered mass mailing dedicated to the new iPhone came from a Chinese company that has decided to fill this niche.
The advertiser, having first apologized for any inconvenience that may be caused by the email, offers users the chance to buy a case for the new iPhone 5 which has not even been officially presented.
Considering the sort of promises that usually appear in spam, one can only wonder why the sender didn’t offer an actual iPhone 5 or, better still, an iPhone 6 (or whatever it’ll be called in 2013? iPhone 5v?).
This month's patch Tuesday fixes a small set of critical vulnerabilities in a variety of client side software and one "important" server side Forefront UAG data leakage/information disclosure issue. Six bulletins have been created to address eleven exploitable flaws. Three of the six bulletins are top priority and should be addressed ASAP. These are the MS12-023 bulletin, patching a set of five Internet Explorer vulnerabilities leading to remote code execution, and the MS12-027 bulletin, patching the MSCOMCTL ActiveX Control currently receiving some attention as a part of very limited targeted attacks. If they must prioritize deployment, administrators should start their work here. Most folks should have automatic updates enabled and will silently receive the patches, or they can simply navigate their start menu and manually begin the Windows update process.
RCE attacks abusing these six IE and ActiveX vulnerabilities would look like web browser redirections to malicious sites hosting web pages attacking Internet Explorer and emails carrying malicious attachments constructed to appear familiar to the targeted victim. These are currently significant vectors of attack for both consumer/home and corporate Microsoft product users.
Microsoft also is recommending that administrators prioritize the Authenticode flaw and rated it critical, which could be used as a part of targeted attacks. And ActiveX controls can be delivered leveraging this vulnerability, so some distribution vectors may become enhanced. But this flaw allows for additions and modifications to existing code that in turn won't invalidate the existing signature.
A vulnerability exists in the .Net framework, allowing for XBAP applications to be run from the Internet Zone with a prompt. But anytime a decision like that is left to a user, it seems that we have a 50/50 chance of successful exploitation. The remaining vulnerabilty in the Office converter is significant and may result in RCE, but is much less likely to be attacked.
Dangerous, but manageable.
A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo , Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave's policy clarification, and followup discussions on Mozilla's bugzilla tracking and mozilla.dev.security.policy .
The issue at hand is the willful issuance of subordinate CAs from trusted roots for 'managing encrypted traffic', used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed - even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA's if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS ) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?
“Nigerian” spammers are extremely quick to react to the world’s hottest news stories. News of the death of former Libyan leader Muammar Gaddafi had barely even broken before a string of emails from the “relatives of the deceased” began to appear.
Gaddafi’s inconsolable relatives would be amazed if they knew how many emails had been sent in their name to Internet users around the world.
Instead of joining in the funeral rites, it looks like Gaddaffi’s sons and daughters, or his wife, his brothers or even friends, have rushed straight to their PCs to write to people all over the world asking for help in spiriting uncountable millions of dollars out of the country.
According to the “Nigerians”, the family of the Libyan leader is worth hundreds of millions of dollars. The emails which fell into my hands cited a minimum figure of $300 million.
Most of these emails purport to come from “Gaddafi’s wife”. The spammers seem to think their heart-rending stories about her hard life in her husband’s family could explain her sudden desire to share his money with her close friends. Or even with distant strangers, depending on the recipient of the email.
She’s not alone, though: an unlikely coalition of “opposition forces”, “lawyers” and “bank clerks who have access to Gaddafi’s accounts” also share the general desire to transfer the Colonel’s money abroad.
“Nigerian” spam is, of course, pure fraud. None of Gaddafi’s wives or even his lawyers will ever send emails to someone they do not know asking for help in getting millions of dollars out of the country and offering an unknown agent the commission for doing so. If a user takes the bait the fraudsters will extort money from him to allegedly cover different “expenses” until no more money is left. One should be realistic about the many offers received via the Internet from an unverified source calling himself Colonel Gaddafi’s son (ALL OF A SUDDEN!).
Below are the screenshots of several “Nigerian letters” sent on behalf of Gaddafi’s family:
The BBC today reported the announcement of the first UK 'mobile wallet', allowing people to pay for things using their mobile phone.
It sounds very convenient. I use my mobile phone for so many other things these days - why not as an alternative to cash? And on the face of it, isn't this just an extension of the same concept behind the Oyster Card? For those not familiar with the Oyster Card, it's an alternative to buying tickets to travel across London. You use a card instead: you put credit on the card at your convenience and the cost of the trip is debited automatically when you travel.
There's a key difference of course. If I lose my Oyster Card my loss is limited to the credit I've put on the card. The consequences could be far more serious if it's my smartphone, since someone could get access to my entire online identity. If my phone is my wallet too, it becomes even more of a target - to real-world criminals as well as cybercriminals.
We know from experience that convenience typically wins out over security. Keep watching.
Microsoft is making changes to its exploitability index to help clarify vulnerability issues in its software to its customers, keeping its program far ahead of other major vendors. Still, no system is perfect.
Microsoft's Security Response Center team has a steep uphill climb to conquer the mountain of vulnerability handling in their software that slowly but surely are publicly discovered, exploited and discussed. It is not an enviable task.
In just five days, the team will roll out a couple of changes. One change splits exploitability ratings for their newest product versions from all older releases. The two updates for the upcoming Patch Tuesday will also provide information for the bugs even if they do not provide remote code execution, and instead provide a surface for denial of service attacks.
Ever since Stuxnet hit the news last year, there has been an increased interest in the area of industrial control systems (ICS). This has been evidenced by the fact that we've seen a recent surge in public releases of zero-day (unpatched) vulnerabilities and exploits.
Earlier this week, we saw no less than 34 unpatched vulnerabilities posted to Bugtraq. In the original article by The Register, there's also mention of a SCADA exploit pack which is currently for sale to pen-testers.
As long-time blog readers may know, I shifted my focus to North American threats some three years ago. Ever since, I've noticed major cultural differences in how security issues get tackled.
One way in which the difference is very clear is the use of secret questions as an added security measure. While secret questions are not overly common in Europe, they're very popular in the USA.
It goes without saying that out-of-band authentication used by many European banks is a much more secure approach than asking a secret qeustion next to a regular password. And banks are just one of many examples. Secret questions are everywhere now.
Enter the Facebook era. Rarely do I encounter a secret question that people wouldn't likely have posted the answer to on Facebook. It's worse with the services that allow users to reset their password based on answering the secret question(s) correctly.
A short while ago, I decided to prepare a presentation on web vulnerabilities and specifically on XSS attacks. This involved studying the way today’s filtration systems work.
I selected the most popular Russian social networking website, VKontakte.ru, as a test bed. One thing that grabbed my attention was the updated user status system.
The HTML code in the part of the page where users edit their status messages is shown below:
As you can see, filtering is performed by the infoCheck() function. The status itself is located in this string:
What we have here is two-step filtration. The first step is performed when the user enters the status message. The second step involves converting the status message to text and returning it to the page in the shape in which other users will see it.
While the second step definitely works well and it would clearly be impossible to convert to active XSS, things are not as simple where the first step is concerned, so it is that step that we will look at in greater detail.
Predictably, the simple <script>alert()</script> did not work, and the status remained empty. Other ‘script-like’ attempts didn’t work, either – it seems that this particular string is explicitly filtered.
However, the <script> tag is not essential for a script to be executed. The first vulnerability is introduced on the user’s machine by using the <img> tag: by entering the string <img src=1.gif onerror=some_function> as the user’s status, we can get that function to be executed. For example, we can call the function profile.infoSave(), which is called with an empty parameter to clear the status, but use a parameter of our choice. Thus, if we enter <img src=1.gif onerror=profile.infoSave('XSS')>, we get the string “XSS” as our status message:
Another interesting vulnerability associated with the filter is that the tag <A> is not filtered. If we enter <A HREF="//www.google.com/">XSS</A> as our status, we get… a hyperlink clicking on which brings up a status editing window and, a moment later, opens google.com.
As we all remember, XSS = cross site scripting, so I decided to test the next vulnerability using a third-party website with a script loaded on it. In addition to the tags mentioned above not being filtered, the <iframe> tag also successfully passed the filter. As a result, entering <iframe src="yoursite.com" width="100%" height="300"> in the status line will produce an iframe which will launch the above-mentioned script loaded on the page. Below is an example of what the iframe can look like:
This is a more serious vulnerability than the other two. One way of exploiting it is by creating a URL to change user status and sending it to the victim user in the hope that the user will click on it. The script will be executed on the user’s page even before the status message is published. This is a classic example of passive XSS.
These vulnerabilities existed from 01 August, 2010 – the time when the new user status system was introduced. We notified VKontakte’s administration on 01 March, 2011 and the vulnerabilities were closed on 03 March.