• Aucun résultat trouvé

Enter/Update Wire Transfers

Dans le document William L. Simon (Page 169-174)

Anyone Interested in a Bank Account in Switzerland?

20.1.2 Enter/Update Wire Transfers

Menu: Wire Transfers (WIRES) Option: Enter/Update Wire Transfers

This option is used to enter non-repetitive wires and to select repetitive wires to be entered and sent. Non-repetitive wires are for customers who only send a wire occasionally or for noncustomers who want to initiate a wire. Through this option, incoming wires can also be maintained after they are uploaded. When this option is selected the following screen will be displayed.

Wire Transfers

Wire Transfers 11:35:08 Outgoing

Type options, press Enter.

2=Change 4=Delete 5=Display Position to...

Opt From account To beneficiary Amount F3=Exit F6=Add F9=Incoming F12=Previous

When this option is initially taken there will not be any wires listed.

To add, press F6=Add and the following screen will be displayed.

An entire chapter spelled out step-by-step the exact procedures for sending a wire from that particular bank, transferring funds to some per-son’s account at another financial institution. Gabriel now knew every-thing he needed for sending a wire transfer. He had the keys to the castle.

Aftermath

Despite such widespread access to the bank’s system and an enormous amount of unauthorized power at his disposal, Gabriel to his credit kept his hand out of the till. He had no interest in stealing funds or sabotag-ing any of the bank’s information, though he did play around with the idea of improving the credit ratings for a few buddies. As a student

enrolled in a security program at a local college, Gabriel naturally assessed the weaknesses in the bank’s protective measures.

I found a lot of documents on their server about physical security, but none of it was related to hackers. I did find something about the security consultants they hire every year to check on the servers, but that isn’t enough for a bank. They’re doing a good job on phys-ical security, but not enough for computer security.

I

NSIGHT

The bank site in Estonia was an easy target. Juhan noticed the flaw when he viewed the source code of the bank’s Web pages. The code used a hid-den form element that contained the filename of a form template, which was loaded by the CGI script and displayed to users in their Web browser.

He changed the hidden variable to point to the server’s password file, and, voilà, the password file was displayed in his browser. Amazingly, the file was not shadowed, so he had access to all the encrypted passwords, which he later cracked.

The Dixie bank hack provides another example of the need for defense in depth. In this instance, the bank’s network appeared to be flat; that is, without significant protection beyond the single Citrix server. Once any system on the network was compromised, the attacker could connect to every other system on the network. A defense-in-depth model could have prevented Gabriel from gaining access to the AS/400.

The bank’s information security staff was lulled into a false sense of secu-rity in having an external audit performed, which may have unreasonably raised the confidence level in their overall security posture. While per-forming a security assessment or audit is an important step to measure your resilience against an attack, an even more crucial process is properly managing the network and all the systems that are on it.

C

OUNTERMEASURES

The online bank site should have required that all Web application devel-opers adhere to fundamental secure programming practices, or require auditing of any code put into production. The best practice is to limit the amount of user input that is passed to a server-side script. Using hard-coded filenames and constants, while not eloquent, raises the level of assurance in the security of the application.

Lax network monitoring and poor password security on the exposed Citrix server were the biggest mistakes in this case, and would likely have

prevented Gabriel from roaming through their network, installing key-stroke loggers, shadowing other authorized users, and planting Trojan programs. The hacker wrote a little script and put it into the administra-tor’s startup folder so when he logged in, it would run the pwdump3 program silently. Of course, he already had administrator rights. The hacker was lying in wait for a domain administrator to log in so he could hijack his privileges and automatically extract the password hashes from the primary domain controller. The hidden script is often called a Trojan or a trapdoor.

A partial list of countermeasures would include the following:

● Check all accounts for password last set time on system serv-ices accounts like ‘TsINternetUser’ not assigned to personnel, unauthorized administrator rights, unauthorized group rights, and time of last login. These periodic checks may lead to iden-tifying a security incident. Look for passwords that were set during strange hours, since the hacker might not realize he or she is leaving an audit trial by changing account passwords.

● Restrict interactive logins to business hours.

● Enable login and logout auditing on all systems that are exter-nally accessible via wireless, dial-up, Internet, or extranet.

● Deploying software like SpyCop (available at www.spycop.

com) to detect unauthorized keystroke loggers.

● Be vigilant in installing security updates. In some environ-ments, it may be appropriate to download the latest updates automatically. Microsoft is actively encouraging customers to configure their computer systems to do this.

● Check externally accessible systems for remote-control soft-ware such as WinVNC, TightVNC, Damsoft-ware, and so on.

These software programs, while they have legitimate uses, can enable an attacker to monitor and control sessions logged in to the system console.

● Carefully audit any logins using Windows Terminal Services or Citrix MetaFrame. Most attackers chose to use these serv-ices in preference to remotely controlled programs, to reduce the chance of being detected.

T

HE

B

OTTOM

L

INE

The hacks in this chapter were trivial. based on taking advantage of the companies’ poor password security, and vulnerable CGI scripts. While many people — even people knowledgeable about computer security —

tend to think of hacker break-ins as something more like an “Oceans Eleven” strategic attack, the sad truth is that most of these attacks aren’t ingenious or clever. They are, instead, successful because a large portion of enterprise networks are not adequately protected.

Also, the people responsible for developing and placing these systems into production are making simple configuration errors or programming oversights that create an opportunity for the thousands of hackers bang-ing on the front door every day.

If the two financial institutions described in this chapter give any indi-cation of how most of the world’s banks are currently protecting client information and funds, then we may all decide to go back to hiding our cash in a shoebox under the bed.

N

OTES

1. Though he didn’t specify the site, this information is available at www.flumps.org/ip/.

153

Chapter 8

Your Intellectual

Dans le document William L. Simon (Page 169-174)