Decoder located here.

Bank of America Warning

Dear Bank of America Customer,

During our regular update and verification we could not verify your current
phone number.
Either your information has been changed or it is incomplete.
Please update your phone number by
CLICKING HERE [http://www.xxxxxxx.de/gallery/albums/userpics/boa/] or on the link: http://www.xxxxxxx.de/gallery/albums/userpics/boa/ [http://www.bankofamerica.com/updatephone]

If this is not completed by April 24 , 2007, we will be forced to suspend
your account indefinitely.

The root domain was a hacked, legitimate site running one of the commonly used photo gallery scripts.

The scam page started out with an eye-catching demand that the victim forward their phone number to the phisher’s number as part of the ‘verification’ process:

Click on Image to zoom

There were two versions of the scam page. The first had specific, numbered instructions:

To confirm you phone number please fallow the steps :

Step 1- Go to your phone and Dial *72
Step 2- Dial 707xxxxxxx (Bank of America Secure Line )
Step 3- Your phone is confirmed
You will receive a call from us in 1 h for final verification !

What followed for both was the ‘standard’ identity theft form:

Click on Image to zoom

In checking with one carrier, Qwest, the procedure followed with a forwarded number is the phone will ring at the source location first. If unanswered after a certain number of rings, it will transfer through to the forwarded number.

It’s unknown what the protocol is for all carriers. The obvious concern is that there is no ‘source’ location ring and the forwarding occurs immediately, which in many tests have proven to be standard.

Depending on how long it takes the victim to realize they’re not getting inbound calls and resolve the problem, the bank is effectively blocked from conducting fraud checks for suspicious account activity and/or attempting to advise their customer of the identity theft and the need to cancel their cards. Also, from a “cashing out” perspective, if there is any required phone verification to use the credit card on the account, the verification will succeed, as the forwarded number will be routed to the phishers.

The site has been disabled and the phone number appears to be a SkypeIN number that goes to voicemail.

 
Slashdot It!

Article

Podcast

http://www.microsoft.com/technet/security/bulletin/ms06-055.mspx

Update your windows systems immediately.

More

quoted from the article:

“Botnets are one of the greatest facilitators of cybercrime these days. Really the cybercrime arena is wrapped around botnets.”
–Wendi Whitmore, special agent, Air Force Office of Special Investigations

Click image to enlarge.

You can find the BusinessWeek article with full details here.

A security firm on Tuesday reported discovering a phishing scheme in which the scammers used Internet telephony to copy a bank’s automated voice system in order to steal customers’ passwords, account numbers and other personal information.

In the attack that occurred last week, con artists sent spam disguised as coming from a small bank in a large East Coast city, Cloudmark Inc., a messaging security firm, said. The message asked the recipient to dial a telephone number to talk with a bank representative.

The number went to an automated voice system that asked for an account number and personal identification number, or PIN, in order to access the caller’s finances. The number was obtained through a regular provider of voice over Internet protocol services.

There was no indication that the VoIP provider was aware of the scam, said Cloudmark, which declined to name the company and the spoofed bank.

The incident reflected a mutation in the tactics used by phishers to snare victims. More traditional schemes involve spam asking the recipient to visit their bank’s Web site through a link in the message. At the bogus site, the visitor is asked to input personal information.

The latest scheme, however, is the first Cloudmark has seen using Internet telephony. An investigation by the San Francisco security firm showed that the scammers had used open-source software called Asterisk to convert a computer into a PBX, or private branch exchange, running an automated telephone information system. The voice system sounds exactly like the bank’s phone tree, directing the caller to specific extensions, Adam J. O’Donnell, senior research scientist at Cloudmark, said.

Click here to continue reading the story.

The full report from the Anti-Phishing Working Group is available at: http://antiphishing.org/reports/apwg_report_jan_2006.pdf.

Description:
————
The FedEx Kinko’s ExpressPay system, developed by enTrac Technologies of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory chip card. The data stored on this card is freely rewritable once a three-byte security code has been presented to the card’s security logic. Neither this security code nor the data stored on the card is encrypted; anyone able to obtain the security code is free to rewrite the data stored on the card using an inexpensive commercially available smart card reader/writer.

The first thirty-two bytes of the memory chip card are writable and subsequently permanently write-protectable (in this application, these bytes are write-protected), and contain a header which identifies the card as an ExpressPay stored-value card. Bytes 0×20 through 0×27 contain the value stored on the card, represented in IEEE 754 double-precision floating point format. Bytes 0×60 through 0×6A contain the card’s eleven-digit serial number stored as unsigned zoned-decimal ASCII; digits 0×60 through 0×63 are the store number the card was initially issued at, and the remaining seven digits are assigned sequentially at the moment of first issue. A timestamp indicating date and time of issue are located from 0×30 through 0×37, and is repeated from 0xC7 through 0xCE.

In order to write to the card, a three-byte security code must be presented in a specific sequence of commands as outlined by the SLE4442’s white paper. By soldering wires to the contact points of the card and then connecting those wires to an inexpensive logic analyzer, an attacker can sniff the three-byte code as the kiosk or a card terminal prepares to write data to the card. This security code appears to be the same across all FedEx Kinko’s ExpressPay cards currently in circulation.

Once the three-byte code is known to the attacker, the card’s stored value and serial number can be changed to any value. The ExpressPay system appears to implicitly trust the value stored on the card, regardless of what that value actually is. The system will also accept cards with obviously fake serial numbers (e.g. a non-existent store number followed by all nines). Using these altered cards, xeroxes can be made from any machine with a card reader, and computers can be rented anonymously and indefinitely. Most disturbing, however, is that since stored-value cards can be cashed out by an employee at the register at any time, an attacker could cash out altered cards obtained at little or no monetary cost. If a card is cashed out, its serial number does not appear to be invalidated in the system. If an attacker were to clone a known good card and cash it out, the clone would still be usable.

Tested Vendors:
—————
- FedEx Kinko’s

Suspected Vendors:
——————
- Any client of enTrac Technologies who uses the ExpressPay stored-value card system.
- Any company which uses a stored-value card system based on the SLE4442

Vendor and Patch Information:
—————————–
Proof-of-concept of the initial security vulnerability was achieved on 8 February 2006, with research into the ramifications continuing through 12 February. Copies of this report were sent to both FedEx Kinko’s and enTrac Technologies on 15 February; a read receipt was returned from enTrac on 19 February, while no receipt has yet been received from FedEx Kinko’s.

Solution:
———
- Encrypt data before storing it on the SLE4442 card, or migrate to a system which uses cards which have built-in encryption functionality.
- Verify that the stored value on the card does not significantly differ from a reference value stored in a database.
- Do not allow the use of cards with invalid serial numbers.
- Invalidate serial numbers of cards that are cashed out.

Credits:
——–
Strom Carlson, Secure Science Corporation: Hardware Security Division
stromc@securescience.net

What the press finds the most interesting about this story, is that the phishing site was issued an SSL certificate this morning by Equifax, which is now part of a company named Geotrust. SSL certificate issuers are supposed to have a process in place to ensure that the entity requesting the certificate is authorized to do so on the companys behalf, obviously to avoid situations like this where SSL certificates are issued to illegitimate sites. In this case, Geotrust claims that their largely automated process failed to flag the site as suspicious, because the domain name was not matched to any related financial institutions…

The Washington Post and the Internet Storm Center have more on the story.

The Seattle Times has the full story.

Story in detail found here

Technical details from the advisory:
When running a specially crafted .html file, urlmon.dll inproperly parsers the ‘BGSOUND SRC=file://—’ (approx. 344 dashes) and causes the crash.

The advisory can be found here along with a proof of concept crash page here and a screenshot of the crash here.

More at MSNBC

The story is at http://www.techweb.com/showArticle.jhtml?articleId=177104450

A while ago I was thinking that someone should create a way to bombard or sabotoge a phishers drop site with loads of randomly created false data. Just when I started to think that I had really thought of something entirely revolutionary… well, I found that someone else has already thought of it.

www.PhishFighting.com - Developed by Robin Grimes, is a very noble attempt at employing the public at large with the task of fighting phishers. With currently 5,271,683 fake entries to 17,305 URL’s, I imagine it could be quite difficult for any phisher to sift through all the junk data trying to find his real victims.

The site basically works like this:
1. Enter the phishers URL
2. Click go
3. Watch the site appear with the false data automatically entered
4. Data gets submitted and proccess repeats every twenty seconds

I’ve tried the site and I was quite impressed. Although not everyone is as enthusiastic about it as I was when I found it. Various blog write ups have picked it apart and found ethical faults with the idea of what this site is trying to do. But I say give the guy a break, it’s obviously a work in progress and I think he’s on to something of a worthy cause.

-GK

IBM also predicts that in 2006 “Criminals will focus their efforts on convincing end users to execute the attack instead of wasting time in lengthy software vulnerability discovery.”

The story from The Register can be found here and another good review of the report from Technology News Daily can be found here.

Phishers may not have won the game, but they’re definitely trammeling their opponents’ defenses, says Phishing Exposed (Syngress Publishing) author Lance James. James is the chief technology officer for Secure Science Corp., in San Diego, Calif. In this interview, he describes security failures and new anti-phishing weapons and justifies his book’s exposure of vendors’ security holes.

Are there any open source tools that help combat phishing?

James: Short answer, yes. WiKID Systems Inc. has an open source, two-factor authentication system that helps with aspects of phishing.

Long answer, yes and no. I believe people have written software that is supposed to help, but the rapid evolution [of phishing] requires in-depth, security solutions. That has yet to be seen in the open source world. There is no silver bullet for phishing.

In Chapter 5, “The Dark Side of the Web,” you mention that patches are only a cover-up for poor Web development practices. What are some examples of the latter, and what basic common-sense precautions can a user take to prevent these mistakes?

James: Follow the Comprehensive Lightweight Application Security Process or some similar framework for all operations of the software development lifecycle. If you can’t build a strong foundation, no matter how much patching you do, you’ll always keep doing that till the house just falls apart, eventually. Establish a security process from the beginning of your design phase.

SSL’s (Secure Sockets Layer’s) threat model is bad for the online banking scheme because it doesn’t address proper systems of trust to people who understand what trust is. Does a home user know what an SSL fingerprint is? No, of course not. That means that SSL was approved, deciding that that wasn’t important. Well, it is now with all this phishing going on, now, isn’t it?

How do you tell the difference between genuine software fix-its and patches masked as malware, such as a faux Red Hat patch?

James: You don’t. Trust is relative. Look at Sony and their rootkit problem. We all know Sony by name, but now we’re seeing they put a rootkit in there. [In its most basic form, a rootkit aims to disguise the presence or activities of a person or process on a target host while providing surreptitious access for later re-entry.] Validation services may help, but as I said in my book, browsing the Web is blind faith.

How do you establish trust? That [requires a] combination of trust metrics, cryptography, out-of-band communication and secure robust technology.

What are some two-factor authentication methods? How feasible or practical is this kind of setup?

James: Two-factor is coming out of the gate rather slowly. Malware will defeat it, and phishers have been using malware quite a bit now. The concept of two-factor is something you have and something you know. Your ATM card and pin code is a two-factor authentication — and, as you might have noticed, the ATM part of your card doesn’t seem to get compromised too often. The failure with that card is it usually acts as a credit card number was well.

The newer two-factor auths are designed to be moveable RSA secureID changes, thus the session gives limited access to an attacker. The RSA SecureID token — which is a 26 bit number that is appended to your password — rotates every 20 seconds, all the way up to a minute optionally.

RSA is not perfect. It’s a good start. But getting banks to deploy this to their customers doesn’t make sense. Banks don’t want to lose their customer base by adding yet another confusing thing to the already existing online banking. It’s a hard sale.

In your book, you describe exploitations of vendor vulnerabilities. Though vendors were notified of the breaches, some would claim that this crosses an ethical line. How would you respond to this?

James: Well, if they have decided not to adhere to the advisories they were given, what do I do? I believe it’s OK to apply pressure to a vendor to get them to do their actual job of protecting their customers. It’s the same as Bugtraq; in most cases, you report it to the vendor and hope they fix it and then release it. This book publicizes the vulnerabilities. I’m sure the vendors will be fixing them, if they haven’t. It’s better they were notified by someone doing good, rather than finding out in a phishing attack and possibly losing some of their customer base due to lack of confidence in their security.

What are the most effective ways to defend against phishing?

James: Common sense is the answer; but it’s not perfect. The standard answer is make sure you’re not running Windows 98 or ME, keep your 2000/XP boxes up to date. Trust your instincts. If an e-mail feels suspicious, don’t click on it. Run protective software that assists with keeping an eye on suspect e-mail. Keep your antivirus [program] up to date.

The truth of the matter is that users can’t prevent [phishing], because the ones that get hit never knew what the problem was in the first place. So, the problem can’t be dramatically reduced from their end.

Secondly, the attacks are getting way more sophisticated. Take a look at the recent .WMF exploit that is out there. A week goes by, and Microsoft just got a patch going. That’s a week where phishers probably made a lot of money, being that it’s a phisher that designed the exploit in the first place.

Demand that vendors, such as banks and e-commerce [firms], start getting smarter about phishing! They can reduce the e-mails they send that look like phishing e-mails. Something similar to eBay’s MyInbox is a great start. They should audit their Web sites for content and vulnerabilities that may lend a hand to a phisher. Stop reacting. Get proactive.

Sometime ago, we made the [[Honeylux]] contest and it was a very funny
and interesting contest. Now inside various projects at CSRRT-LU, we
are collecting a lot of undefined malware. We would like to give the
ability to all the people that are interested to better understand
what malware is doing. So if you want to give a try and maybe
win… just pick the following files and read the very basic rules.

=== The malwares to be analyzed ===

* Files X
http://www.csrrt.org.lu/wiki/mlcontest/edb2ade8bca0a6b82b9d160ca40db8e5
- Checksum MD5 edb2ade8bca0a6b82b9d160ca40db8e5 (from automatic
malware collection filename)
* Files Y
http://www.csrrt.org.lu/wiki/mlcontest/21dad79747a3293293366fe5234575eb
- Checksum MD5 21dad79747a3293293366fe5234575eb (from automatic
malware collection filename)
* Files Z
http://www.csrrt.org.lu/wiki/mlcontest/76d49cddb57ff0703db82158e900f245
- Checksum MD5 76d49cddb57ff0703db82158e900f245 (from a Luxembourgish
Honeynet)

=== Rules ===

You are free to use whatever tools or techniques you like, provided
that the jury is able to really interpret your results. Provide also
the name of the tools you used and how you used them. Nonetheless you
should explain your tools and techniques in your analysis and cite
references to resources to allow others to learn by example.

You can enter submissions as a team but there will only be one price
given to the team, so up to you then to decide how you share the
price. :-))

All submissions must be timestamped prior to 15 May 2006 00:00 CET.

Submissions must be sent to malwarecontest@csrrt.org

Entries must be written in English.

”’Please keep in mind that the files are malware so great care must
be followed when analyzing.”’

=== CSRRT-LU ===

CSRRT-LU is a computer security research and response team association
localized in the Grand-Duchy of Luxembourg. CSRRT-LU engages in
advanced computer security development and research projects in order
to increase security awareness and advancement especially in
Luxembourg but also on an international level. CSRRT-LU is in close
partnership with research institutes, the industrial sector and
governmental institutions.

CSRRT-LU provides a cooperative and virtual organization for working
with individuals, groups and industries. Everybody is welcome to
participate in the various research projects in computer
security. Please check the participation page for more information on
how to help.

CSRRT-LU is also organizing the hack.lu conference.

http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf

Story here:
Security Tips From ‘Anatomy of a Hack’
InternetNews.com (01/03/2006) By David Needle