Archive for October 25, 2008

FTC’s Red Flag Rule – Identity Theft

Last year the Federal Trade Commission (FTC) and several Federal Banking agencies issued a new regulation named the Red Flag Rule, which is intended to reduce the risk of identity theft.

Background on Red Flags Rule

The FTC issued the Red Flags Rule under sections 114 and 315 of the Fair and Accurate Credit Transactions Act (FACT Act), which amended the Fair Credit Reporting Act (FCRA). The rule requires “financial institutions” and “creditors” that hold “covered accounts” to develop and implement an identity theft prevention program” for new and existing accounts.

The Red Flags Rule is actually three different but related rules, one or two of which apply to many colleges and universities:

(1) Debit and credit card issuers must develop policies and procedures to assess the validity of a request for a change of address that is followed closely by a request for an additional or replacement card. (This provision is likely not applicable to colleges and universities, because, as discussed in the preamble to the Red Flags Rule, the definition of “debit card” specifically does not include stored value cards. However, this provision could implicate student ID’s that also can be used as part of a national debit card network, such as Visa or MasterCard.)

(2) Users of consumer reports must develop reasonable policies and procedures to apply when they receive notice of an address discrepancy from a consumer reporting agency. (This provision applies to colleges and universities when they use consumer reports to conduct credit or background checks on prospective employees or applicants for credit.)

(3) Financial institutions and creditors holding “covered accounts” must develop and implement a written identity theft prevention program for both new and existing accounts. (This provision likely applies to many colleges and universities).

This rule adds to the burden institutions already have having to comply to law already on the books, including FERPA, HIPPA, GLBA, DMCA and Federal Copyright Laws.

Even though there needs to be something done about the escalating problem of identity theft, I seriously doubt that additional laws are going to make a difference, specially if those laws go too far.

With the extensive laws already on the books, what really need to happen is for them to be enforced. Too many times institutions take for granted these laws and only go as far as writing some paragraphs and naming it their policy.

No real enforcement of any kind, but instead drafting a piece of paper to say something was done when the shut hits the fan.

Examples need to be made from the big guy to the little guy, to send a message that the customer information these institutions hold is valuable and not taking appropriate steps to guard it will be dealt with swiftly and with severe consequences for management of those institutions.

Getting back to identity theft, one of the major reasons identities are stolen is for fraud.

LifeLock’s approach to this offers some interesting lessons on the way credit is issued.

In December 2003, as part of the Fair and Accurate Credit Transactions Act, or Facta, credit bureaus were forced to allow you to put a fraud alert on their credit reports, requiring lenders to verify your identity before issuing a credit card in your name. This alert is temporary, and expires after 90 days. Several companies have sprung up — LifeLock, Debix, LoudSiren, TrustedID — that automatically renew these alerts and effectively make them permanent.

This method is simple and straight forth.

This is what policy should be about. Simple to write, simple to implement and simple to execute.

Some examples of this within a company could be:

  1. Scanning PC’s for Social Security Numbers (SSN) and Credit Card numbers and erasing them using software like Identity Finder.
  2. Wiping all computer hard drives and media before it leaves the premises for disposal. Darik’s Boot and Nuke is a tool which securely wipes information on media.
  3. Implement policies for the centralization of data, making IT responsible for the security and integrity  of the data. (Its not feasible for IT to protect an undetermined number of data repositories)
  4. Implement polices preventing the communication of SSN’s and credit card information via e-mail.
  5. Enforce password changes on a regular basis.
  6. Restrict outbound access from servers, only allowing limited access for required tasks.
  7. Deploy Intrusion Detection Systems (IDS) and/or Intrusion Prevention Systems (IPS)
  8. Deploy solutions capable of logging transactions and monitor them.
  9. TRAINING, TRAINING, TRAINING.

The original date for compliance for the new Red Flag Rule was November 1, 2008; which has now been extended to May 1, 2009.

[ad]

Worm Takes Advantage Of Microsoft Flaw

Just as I had predicted it would happen, there are already reports that a worm exploiting the hole in the “Server Service” has been seen in the wild. Microsoft released yesterday a critical “out-of-band” patch (MS08-067) release having known about the issue for a while.

Milw0rm, an exploit tracking Internet site has posted the exploit code required to overflow the stack. The code can be downloaded here.

Symantec is tracking an exploit “Bloodhound.Exploit.212”, via Bugtraq ID 31874 using this vulnerability, but they report it is still not widespread. Other reports points to a certain file “n2.exe” being downloaded to compromise computers, as McAfee has been tracking here.

The worm as already received several names including Gimmiv and Dropper. The guys over at Threat Expert Blog have a pretty detailed explanation of how the code works and what it does.

Both Symantec and McAfee said Friday that they had seen only a very small number of attacks based on this exploit, but Symantec says that, starting Thursday evening, they found a 25 percent jump in network scans looking for potentially vulnerable machines. That could be a sign that more attacks are coming.

It is not likely that large networks will have ports 139 and/or 445 open to the Internet and even most DSL/Cable modem router will not allow this kind of inbound traffic either, but I have no doubt this will cause a false sense of security among pseudo-system admins and as this worm evolves and becomes more sophisticated, it will transverse corporate perimeter firewall through malware and spyware and then spread within the network wreaking havoc.

[ad]

Microsoft Releases Emergency Patch

The same principals behind gaining a root shell for a Unix system, apply for Windows systems allowing the attacker to execute remote code.

Today Microsoft release an emergency patch with a maximum severity rating of “Critical”, for Windows 2000 SP4, Windows XP SP1, SP2 and SP3, and Windows 2003; and with a severity rating of “Important”, for Windows Vista and Windows 2008 servers.

In this particular instance the attacker would craft RPC connection to TCP port 139 and/or 445 on a target system, looking to overflow the buffer, thus gaining access to execute remote code. This would allow the attacker to gain full access to the system, with the ability to install programs, view, change and/or delete data, or create accounts.

The Microsoft Security Bulletin MS08-067, provides details on the issue as well as the download links to the patches for the affected platforms.

This particular vulnerability makes use of a buffer previously unchecked in the “Server Service”, which provides RPC, file and print, and named pipe sharing support over the network.

Microsoft has acknowledged that over the last three weeks, criminals have been targeting systems using this vulnerability, but decided to rush out the patch since after handling close to a 100 incidents relevant to this flaw, had seen that number rise significantly.

As I wrote in my past blog on Root Shell – The Holy Grail, it is very likely that a worm will surface on the Internet taking advantage of the gap between the patch release date and when this patch is actually applied by IT departments worldwide.

Install the patch immediately if you are running any of the affected systems and if you are running anything older then upgrade.

[ad]

UPDATE: 9:21pm – Definitely did not expect it to happen this soon, but the New York Times is reporting that attack code to exploit the vulnerability has surfaced just hours after the patch was announced. This vulnerability is so serious that a worm with viral characteristics could be Blaster all over again.

Auditing SMS and PIN Messages on a BES

Contrary to the popular belief that is not possible to log SMS messages on a Blackberry, here are instructions on how to do just that.

Although SMS messages really do not touch the Blackberry Entreprise Server (BES) when they are sent or received, its possible to get the BES to synchronize all SMS and PIN’s to the server and thus allowing these to be logged as of version 4.1.

To modify the settings for PIN and SMS message logging, complete the following steps:

  1. Open BlackBerry Manager and select the BlackBerry Enterprise Server to be modified.
  2. Select the Server Configuration tab and click Edit Properties.
  3. Click Sync Server.
  4. Double-click Audit Root Directory.
  5. To save the log files, type the file path where the files are to be saved and click OK.
  6. In the left pane, click BlackBerry Domain.
  7. Select the Global tab and click Edit Properties.
  8. Click IT Policy.
  9. In the IT Policy Administration section, double-click IT Policies.
  10. Select one of the policies in the list.
  11. Click Properties > PIM Sync Policy Group.
  12. To monitor SMS or BlackBerry smartphone PIN messages, complete the steps in the following table.
    1. Click Disable SMS Messages Wireless Sync.
    2. In the drop-down list, select False.
    3. Click Disable PIN Messages Wireless Sync.
    4. In the drop-down list, select False.
  13. Click OK to close the open windows.
  14. Restart the BlackBerry Synchronization Service.

[ad]