New IE 0-Day Exploit in Wild
There is a new and unpatched vulnerability with exploit code in the wild that affects the latest version of IE. The exploit works by including an abnormally large (a couple thousand) number of script actions inside a single HTML tag. This will cause a memory array to write out of bounds and cause an immediate or eventual browser crash. Both McAfee and Symantec have released signatures to detect this exploit. While this is only a DoS vulnerability at the moment, there is ongoing attempts to try to use this as a vector for remote code execution.
More as it develops...
More as it develops...
Keywords:
0 comment(s)
Apple Updates the Update
Today, Apple release Version 1.1 of its 2006-002 patch which was released on Monday.
Read more about it here: Apple 2006-002 v1.1
Update: Apple released an article explaining that v1.0 of teh update caused issues with Safari if you had it moved from the "Application" folder. For details, see http://docs.info.apple.com/article.html?artnum=303472
This time, Apple only lists the patched components (php, CoreTypes, LaunchServices, Mail, rsync, Safari).
The update includes all the fixes released in the initial Apple 2006-002 an -001 patch.
Based on the included compents, I believe that this patch will address some of the missed issues in open source packages (rsync and php) which I elluded to in Tuesday's webcast. In addition, the patch will likely fix more issues related to the "safe file execution" problem.
We may update this diary later in case Apple releases any details. A couple words about mitigation:
Some Apple users report in this forum about experiencing network issues after applying 2006-002, which disapeard after applying 2006-002v1.1. See other threads in the same forum for reports of issues like system crashes and systems no longer booting correctly. Apple has not confirmed any problems with this update so far.
Read more about it here: Apple 2006-002 v1.1
Update: Apple released an article explaining that v1.0 of teh update caused issues with Safari if you had it moved from the "Application" folder. For details, see http://docs.info.apple.com/article.html?artnum=303472
This time, Apple only lists the patched components (php, CoreTypes, LaunchServices, Mail, rsync, Safari).
The update includes all the fixes released in the initial Apple 2006-002 an -001 patch.
Based on the included compents, I believe that this patch will address some of the missed issues in open source packages (rsync and php) which I elluded to in Tuesday's webcast. In addition, the patch will likely fix more issues related to the "safe file execution" problem.
We may update this diary later in case Apple releases any details. A couple words about mitigation:
- rsync: by default rsync does not run as a server on OS X, so you should be ok with respect to simple remote exploits. Recent rsync vulnerabilities required the user to be logged in.
- php: only an issue if you have Apache with php default enabled. By default, apache is not enabled, and Apple does not load php in its default httpd.conf. Recent vulnerabilities in php, which are likely addressed in this update, protect against local users overstepping restrictions provided by php safe_mode. This is likely a "must apply" patch if you provide shared web hosting with php support. Of course, validating the patch is in particular tricky in such an environment.
- "Safe file execution": You should keep this option disabled in Safari. Keeping a wrapper around 'terminal' or protecting terminal from execution by untrusted users via the parental controls is another appropriate workarround if it does not restrict your users too much.
Some Apple users report in this forum about experiencing network issues after applying 2006-002, which disapeard after applying 2006-002v1.1. See other threads in the same forum for reports of issues like system crashes and systems no longer booting correctly. Apple has not confirmed any problems with this update so far.
Keywords:
0 comment(s)
Identity Theft: Accounts Stolen vs Accounts Used - Reader Input
It seems to be the general consensus that very few of the accounts stolen from online scams, keyloggers, and phishing actually ever get used. By comparing the FTC's data (about 180,000 cases of identity fraud from possible online vectors) with my last year's estimate of how many accounts have been compromised you get about 2% of accounts that have been compromised actually get defrauded (so far). Assuming I'm full of crap (an assertion I wouldn't dispute) and my estimate was ten-fold higher than reality (an assertion I would dispute), that still means 20% of accounts compromised get used. Credit card information has a street value, and one estimate I heard was that you get $50 USD per good account.
Two questions for readers:
Do you agree that most of the accounts stolen online never get used?
Why do you think that is?
I'll post a montage of responses later in the day and include my thoughts.
Two questions for readers:
Do you agree that most of the accounts stolen online never get used?
Why do you think that is?
I'll post a montage of responses later in the day and include my thoughts.
Keywords:
0 comment(s)
Phishing Messages May Include Highly-Personalized Information
Phishing messages are becoming increasingly personalized in attempts to convince the recipients to trust originators of the messages. A phishing email recently submitted to us illustrates this trend. In this case, the message that arrived in the victim's inbox included the person's full name and postal address:
The message masqueraded as a CitiBusiness alert. The "click here" link led to a fraudulent website hosted at citibusinessonline.da.us.citibank.com.citionline.ru. The whois record for citionline.ru indicated that the Russian domain was registered a few days prior to the attack.
Where does the personal data come from? In this incident, this victim rarely used his/her full name online, and the name was not included in phone directories. It is possible that the scammer obtained the data from diverse sources and was able to link the fields (name, email address, and postal address) together. More likely, the data originated from a website that stored billing details or from a compromised credit card processor. Yet another possibility is that the scammer purchased the data from legitimate consumer data providers. Even if the scammer was not certain that the victim's records were correct, even a small number of matches would increase the number of fooled victims.
If you were wondering what awaited the victim at the website set up for the phishing attack, wonder no more:
Mimicking the real CitiBusiness Online website, the phishing site allowed the victim to enter his/her Business Code by clicking on images of numbers in the form. The URL that brought the person to the fraudulent site included a unique identifier that allowed the site to track email recipients. It is possible that the identifier was used to pull up the victim's records from the fraudulent site's database; another possibility is that the victim's name and address were actually encoded in the URL string. As a result, two screens later, the victim was presented with his/her postal address and full name without having to supply them to the site:
After allowing the victim to correct the address, the site prompted the person for additional sensitive information, such as date of birth, social security number, and mother's maiden name:
We reported this phishing attempt to Anti-Phishing Working Group and Citibank. If you have witnessed highly-personalized phishing scams of this nature as well, please send us the details.
This note incorporates comments from several ISC handlers. I am very grateful for their contributions.
Lenny Zeltser
ISC Handler
www.zeltser.com
Keywords:
0 comment(s)
Guide to Finding Safe Online Merchants
After writing the safer online shopping guide several readers asked for guidance in how to pick a trusted vendor. Well, I just wrote a guide for that as well which you can read here. Essentially it comes down to this (and not all need to be met):
1) Use well-known merchants
2) Use merchants with physical addresses
3) Use merchants with registered businesses
4) Use merchants you have a personal relationship with
5) Use merchants with good reputations
If you don't trust the merchant, use a third-party payment system such as PayPal where no account information is exchanged. Of course, this won't prevent problems but it will help consumers avoid malicious versus negligent or unlucky businesses. For good reading on how identity theft is being made easier, take a look at Brian Krebs' excellent article and blog post on the subject.
1) Use well-known merchants
2) Use merchants with physical addresses
3) Use merchants with registered businesses
4) Use merchants you have a personal relationship with
5) Use merchants with good reputations
If you don't trust the merchant, use a third-party payment system such as PayPal where no account information is exchanged. Of course, this won't prevent problems but it will help consumers avoid malicious versus negligent or unlucky businesses. For good reading on how identity theft is being made easier, take a look at Brian Krebs' excellent article and blog post on the subject.
Keywords:
0 comment(s)
×
Diary Archives
Comments