6
I n this annual IT audit and security update, I want to point out the issues we identified in our tech- nical audits over the last year. It is surpris- ing to find that many of the risks from the previous year have not been remediated. One would think that after several years of Sarbanes-Oxley (SOX) audit work, networks would be more secure. We can see improvements in documenting financial control as well as servers that host finan- cial systems. Unfortunately, we have noticed no overall improve- ment in information security. During our closing meetings for our audits and security reviews, I am often asked how the results could be so dismal given that the client is SOX-com- pliant. The answer is simple: SOX assesses the overall man- agement and financial control structure. Security on the SOX- related servers is usually good, as these servers are thoroughly audited and any issues identified are quickly remediated. Unfortu- nately, the overemphasis on SOX means there are less resources available to identify and secure flaws on other servers and data- bases. These non-SOX machines may be vulnerable to attack due to missing patches, poor configu- ration, and other serious issues and well-known exploits. By tak- ing advantage of these machines, in all but one of our audits last year we gained complete access to the Windows domains and Active Directory. Once this access was gained, we were able to compromise a number of machines that were SOX-related. Keep in mind that a single security flaw can topple the entire Windows environment. Crossover accounts (accounts that have the same password in multiple envi- ronments) between the Active Directory, UNIX, mainframe, or other devices enable these machines to be compromised, leading to a potential security domino effect. In this article I will focus on some of the key issues we identified and offer some advice on how to better secure the IT environment. Let us start with the Win- dows environment, as it remains the most poorly secured of all of the environments we audit. ACTIVE DIRECTORY AND THE WINDOWS ENVIRONMENT ARE OFTEN POORLY CONFIGURED My first concern is Active Directory implementation. This Microsoft product can be well controlled if the vendor’s recom- mendations are followed. After a failure to properly implement patches and security updates, the biggest issue, in my opinion, is the failure to eliminate the LanMan password. This has been around since the imple- mentation of Windows NT. It stores passwords in uppercase only, and the password is split into two seven-character pass- words, which makes it easier to crack. Using RainbowCrack, a password-cracking tool, we can crack any LanMan password that is up to 14 characters in length in less than 30 minutes. We An expert in IT audit and security reveals the greatest audit risks discovered by his firm in 2006. An overemphasis on Sarbanes-Oxley (SOX)-related servers left companies with fewer resources to identify other risks. The author explains what they are and how to eliminate them. © 2007 Wiley Periodicals, Inc. Gordon Smith Greatest IT Audit and Security Risks of 2006 f e a t u r e a r t i c l e 43 © 2007 Canaudit, Inc. Printed with permission. Published online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/jcaf.20307

Greatest IT audit and security risks of 2006

Embed Size (px)

Citation preview

Page 1: Greatest IT audit and security risks of 2006

In this annual ITaudit and securityupdate, I want to

point out the issues weidentified in our tech-nical audits over thelast year. It is surpris-ing to find that manyof the risks from theprevious year have notbeen remediated. One wouldthink that after several years of Sarbanes-Oxley (SOX) auditwork, networks would be moresecure. We can see improvementsin documenting financial controlas well as servers that host finan-cial systems. Unfortunately, wehave noticed no overall improve-ment in information security.

During our closing meetingsfor our audits and securityreviews, I am often asked howthe results could be so dismalgiven that the client is SOX-com-pliant. The answer is simple:SOX assesses the overall man-agement and financial controlstructure. Security on the SOX-related servers is usually good, asthese servers are thoroughlyaudited and any issues identifiedare quickly remediated. Unfortu-nately, the overemphasis on SOXmeans there are less resourcesavailable to identify and secure

flaws on other servers and data-bases. These non-SOX machinesmay be vulnerable to attack dueto missing patches, poor configu-ration, and other serious issuesand well-known exploits. By tak-ing advantage of these machines,in all but one of our audits lastyear we gained complete accessto the Windows domains andActive Directory. Once thisaccess was gained, we were ableto compromise a number ofmachines that were SOX-related.

Keep in mind that a singlesecurity flaw can topple the entireWindows environment. Crossoveraccounts (accounts that have thesame password in multiple envi-ronments) between the ActiveDirectory, UNIX, mainframe, orother devices enable thesemachines to be compromised,leading to a potential securitydomino effect. In this article Iwill focus on some of the key

issues we identifiedand offer some adviceon how to better securethe IT environment. Letus start with the Win-dows environment, as itremains the mostpoorly secured of all ofthe environments weaudit.

ACTIVE DIRECTORY AND THEWINDOWS ENVIRONMENT AREOFTEN POORLY CONFIGURED

My first concern is ActiveDirectory implementation. ThisMicrosoft product can be wellcontrolled if the vendor’s recom-mendations are followed. After afailure to properly implementpatches and security updates, thebiggest issue, in my opinion, isthe failure to eliminate the LanMan password. This hasbeen around since the imple-mentation of Windows NT. Itstores passwords in uppercaseonly, and the password is splitinto two seven-character pass-words, which makes it easier tocrack. Using RainbowCrack, apassword-cracking tool, we cancrack any LanMan password thatis up to 14 characters in lengthin less than 30 minutes. We

An expert in IT audit and security reveals thegreatest audit risks discovered by his firm in2006. An overemphasis on Sarbanes-Oxley(SOX)-related servers left companies with fewerresources to identify other risks. The authorexplains what they are and how to eliminatethem. © 2007 Wiley Periodicals, Inc.

Gordon Smith

Greatest IT Audit and Security Risks

of 2006

featur

e artic

le

43

© 2007 Canaudit, Inc. Printed with permission.Published online in Wiley InterScience (www.interscience.wiley.com).DOI 10.1002/jcaf.20307

jcaf_969.qxp 4/11/07 6:48 AM Page 43

Page 2: Greatest IT audit and security risks of 2006

strongly suggest that the LanMan password be eliminated,as it is no longer required forWindows 2000, XP, or Server2003. Once we capture the localpassword file on one machine,often a poorly secured worksta-tion, it is a simple matter tocrack passwords needed to getonto other machines.

At some of our clients,account lockout is not activatedor is poorly implemented. Weoften find the lockout policy setto five attempts in 15 minutesand the account is locked out for15 minutes. In some organiza-tions, we find that the accountlockout policy is not activated atall or is implemented on a hap-hazard basis. We believe thataccount lockout should beimplemented on all domains,servers, and workstations.We suggest a setting ofthree bad passwords in 500minutes and the account islocked until unlocked by anadministrator.

Another issue we com-monly identify is a failureto place a password on thesa account on Microsoft SQLservers. In most environments,we find several servers runningthe Microsoft SQL Server withthe default blank password or apassword of “password” or“sa.” Hackers have scripts ortools that can quickly identifysusceptible machines and thengain system administrativerights. In a few seconds, thepassword file can be down-loaded. Thirty minutes later, wewill have any crossoveraccounts we need to gain accessto other machines or domains.A crossover account is anaccount we use to go from onemachine to another. Theaccount and password are thesame. If we are really lucky, acrossover account from one

machine will give us access toother domains.

To speed our audits, wewrote a program to automatescanning for the sa account. Wecan test up to 5,000 machines inabout an hour using our tool. Ifwe have a tool, it must beassumed that the hackers haveone as well. A single occurrenceof a poorly secured sa accountcan and has given us administra-tive access to the domain. Atseveral clients, this was the onlyweakness we found that wouldgive us administrative rights. Istrongly suggest that allmachines in your environmentbe checked for poorly secured saaccounts.

Another issue is the contin-ued use of the free version ofVirtual Network Computing

(VNC) to enable administratorsto service machines. The VNCpassword can be captured anddecrypted instantly once accessis gained to a machine. Then,using VNC, we may gain accessup to the administrator level byusing the password we cracked.We suggest that VNC bereplaced with secure implemen-tations of Radmin orPCAnywhere. There are somesecure versions of VNC that canbe used—just ensure that theyuse encryption and require bothan account name and password.

Once administrative accessis gained to a Windows machine,we can often use a tool calledlsadump2 to dump the LocalSecurity Authority (LSA)secrets. Here we often find

unencrypted passwords for privi-leged accounts that are used torun Windows services.

A tool called CacheDumpcan also be used to dump thecontents of the domain cache.The cache exists so that userscan log onto their system whenthey are traveling (i.e., via lap-top) or when the domain con-troller is down (preventing themfrom logging onto the domain).Once retrieved, the passwordsmust be cracked. By default, thelast ten accounts and passwordsare stored in the cache. We sug-gest that this be reduced to twoto lower the risk that an adminis-trator-empowered account andpassword could be gleaned fromthe cache.

Service accounts continue tobe a serious issue. Some, such as

the Blackberry (bberry),Exchange admin (exchad-min), and other similarones, give us administra-tive access. They oftenhave well-known defaultvalues and, as such, makethe machines vulnerable toattack. Missing patches,

particularly the NetAPI32, thePlug and Play (UPnP), and theDCOM exploits, give an attackerinstantaneous administratoraccess. Most of our clients havecorrected the DCOM vulnerabil-ity; however, the other vulnera-bilities remain a serious issue.We had many other issues in the Windows environment. If youwould like further informationon these issues, please e-mail me([email protected]).

ORACLE DATABASE ISSUESINCREASED SIGNIFICANTLY

This past year, we found asignificant increase in poorlysecured Oracle databases. Ournew OraScan software auto-mated the penetration and

44 The Journal of Corporate Accounting & Finance / May/June 2007

DOI 10.1002/jcaf © 2007 Wiley Periodicals, Inc.

A single occurrence of a poorlysecured sa account can and hasgiven us administrative access to thedomain.

jcaf_969.qxp 4/11/07 6:48 AM Page 44

Page 3: Greatest IT audit and security risks of 2006

vulnerability assessment process.As a result, we were able to testOracle security issues withoutincreasing the cost of the audit.The key factor we identified wasa poorly secured listener port.By connecting to the listenerport that is not password-protected, we can obtain a list ofOracle databases running on theaffected database server andsafely test for known defaultusername/password combina-tions. It is not uncommon duringthis audit segment to identifyover 20 accounts across severaldatabases with default pass-words, some of which are Data-base Administrator(DBA)–empowered. This simpleexploit can also be accomplishedusing OScanner, which is freesoftware from Cqure.net(http://www.cqure.net/wp/?page_id=3). In addi-tion to known accountswith default passwords,many Oracle accounts havesimplistic passwords thatalso facilitate access to theaffected database. We usu-ally find several accountswith a password equal to theaccount name and the “ORACLE” account with one ofseveral defaults or variations of aknown default.

We use our own proprietaryscripts to audit Oracle parame-ters and settings. We found a sig-nificant number of Oracle issuesthat are present at most of ourclients. One significant issue weoften identify is the inclusion ofDBA-empowered accounts andpasswords in Structured QueryLanguage (SQL) scripts (pro-grams). Since many of thesescripts are world-readable (any-one on the system can readthem), the passwords are acces-sible to anyone who gains accessto the system. Developer accessto production databases was

quite common, violating basicseparation of duties. We alsofound that those who know theroot password often have OracleDBA access due to operatingsystem authentication. This isalso a very poor separation ofduties.

Basic Oracle security, suchas account lockout for multipleunsuccessful login attempts, therequirement to change pass-words, and the implementationof critical auditing features, aregenerally not in place. Unsuc-cessful login attempts are notbeing monitored or are moni-tored very infrequently. Anotherissue, which occurs less fre-quently, is programs and scriptsthat are world-writable. Anyonewho gains access to the systemcould then modify these scripts

and programs to create anaccount or perform some othernefarious function. The nexttime the script or program exe-cutes (with DBA rights), the Trojan embedded in the programexecutes, possibly creating abackdoor into the database.

We found significant issueswith excessive or unnecessarydatabase links and poorlysecured database links. Databaselinks can be used to facilitateintegration of databases and canresult in unauthorized disclosureof confidential information. Akey audit task that is often for-gotten is the controls over data-base links. All unnecessary linksshould be disabled.

Lastly, we found that criticalOracle patches are not installed.

The usual reason is the fear thatvendor application software willnot function properly if the patchis applied. The failure to imple-ment an automated testing facil-ity, such as Mercury TestDirector(http://www.mercury.com/us/products/quality-center/testdirector/ features.html),means that Oracle patches forcomplex applications cannot beeasily tested. This may be thetrue cause of poor patch man-agement. If there is a test facilitythat can ensure that the Oraclepatches work on the affectedapplications, then implementingpatches is not only safer, but it isoften easier. Based on the issueswe identified in 2006, I stronglysuggest that our clients scheduleaudits of critical Oracle data-bases and applications this year.

E-MAIL AND VPNS WERENOT PROPERLYPROTECTED

2006 was also the yearwe focused on e-mail.Executives and key person-nel using BlackBerries and

similar devices are linked 24hours a day. Our audit resultsindicate that e-mail is oftenpoorly secured. The greatestweakness is the poorly securedWindows environment that oftenhosts e-mail. The e-mail servers are usually con-nected to Active Directory. Oncethe domain administratoraccounts are compromised,everyone’s e-mail can beaccessed. A hacker can evensend and receive mail fromanother user’s account. There areseveral controls that need to beimplemented. The first is toremove exchange administratoraccess from as many administra-tor accounts as possible. Next,two-factor authentication(described below) should be

The Journal of Corporate Accounting & Finance / May/June 2007 45

© 2007 Wiley Periodicals, Inc. DOI 10.1002/jcaf

Database links can be used to facili-tate integration of databases and canresult in unauthorized disclosure ofconfidential information.

jcaf_969.qxp 4/11/07 6:48 AM Page 45

Page 4: Greatest IT audit and security risks of 2006

required for e-mail access. If thisis considered too expensive, thenthose with sensitive access, suchas system and database adminis-trators, executives, lawyers, audi-tors, and human resources staffshould use two-factor authenti-cation. Another common issuewas the use of the default Black-berry password on the domain.This gives an unauthorized per-son the ability to access e-mailand to disable devices at will.Imagine the impact of the CEOand CFO’s Blackberries beingdisabled during a hostiletakeover attempt!

We are also concerned bypoorly secured Virtual PrivateNetworks (VPNs) that are oftenused to remotely connect to thenetwork for e-mail and other net-work activities. I am a truebeliever that workingremotely is essential. Dur-ing the last year, wenoticed that many organi-zations do not use two-factor authentication toproperly validate a userbefore granting him accessto the internal network or toe-mail. We urge our clients touse tokens, digital certificates, orbiometrics in addition toaccounts and passwords forauthentication.

Security tokens are smalldevices that fit on a keychain.When logging into the network,a user enters his account nameand password. He then enters thevalue displayed on the token.This value changes frequentlybased on a precoded algorithm.If the token entry is incorrect orthe person does not have a token,then he will not be able to log insuccessfully.

The cost of all these tech-nologies is dropping as the riskof not using them is rising. In2007, I would make two-factorauthentication a very high prior-

ity if it is not already in place. Iwould also ensure that thosewith administrative access tooperating systems, databases,network devices, and e-mail usetwo-factor authentication.

A few of the VPNs weaudited permitted vendors andsome users to bypass two-factorauthentication. An auditor orsecurity professional has to bevery careful about the questionsasked during audits and reviews.If the question is “Is two-factorauthentication used?” the answermay be yes. Make sure you askfor a list of all accounts thatbypass two-factor authentication.This should include vendors whorequire remote access to theinternal network to service theirsoftware and employees whoneed temporary access because

they lost or misplaced theirtoken.

The vendor issue is morecomplicated than most of ourclients realize. Often, the ven-dors do not want a token, as theycannot identify which personwill be on call when your organ-ization has a problem. I alsocontend that they may want touse offshore technicians to pro-vide assistance to save on theirmaintenance costs. By using asecondary password instead of atoken, the vendor has the optionof using an in-country resourceat any one of their support sites,or they can use an offshoreresource. I have several concernswith this. The first is that thepassword is passed around andmay be used for unauthorized

access. This risk increases whenthe vendor outsources mainte-nance and support to anotheroverseas firm. To counter this, Istrongly suggest that a single-usepassword be set up for everyservice activity. The passwordexpires when the service personlogs off. If he or she needs tocome back in, he or she needs toobtain a new secondary pass-word.

My other concern is that thevendors only need to access themachines that they service.Many VPN configurations letthem into the network with nolimitations on the machines theycan access or any time con-straints on their access. As aresult, they can enter the net-work and freely roam. Thepotential exists for the vendor’s

staff or subcontractors toextract information frommachines outside their areaof responsibility, downloadconfidential data, or per-form malicious activities. Iurge our clients to limit thenetwork scope to only themachines and applications

the vendor services and torestrict their logon time to a rea-sonable time frame, say twohours. If they need more time,they must contact your organiza-tion for an extension. I alsobelieve that all of their actionsshould be logged and the logsmonitored so that if issues arise,the logs can be used to docu-ment the vendor activity.

It is a good practice to dis-able lost tokens immediately. Ifan employee forgets his tokenand is issued a secondary pass-word, it should be for a singleday. It is best to assume that aforgotten token has been lost.Ensure it is disabled as part ofthe process of creating the sec-ondary password. When theemployee returns with the token,

46 The Journal of Corporate Accounting & Finance / May/June 2007

DOI 10.1002/jcaf © 2007 Wiley Periodicals, Inc.

We urge our clients to use tokens,digital certificates, or biometrics inaddition to accounts and passwordsfor authentication.

jcaf_969.qxp 4/11/07 6:48 AM Page 46

Page 5: Greatest IT audit and security risks of 2006

it can be reactivated. One lastthing on tokens—make sure thata security alert is generated anytime a lost token is reactivated.

NETWORK DEVICES REMAINAN ISSUE

In the last year, networkdevices had many of the sameissues and some new ones. Com-munity strings (passwords fornetwork devices) are often set tothe default value of “public” or“private.” “Public” communitystrings can enable an unautho-rized user to view informationon the device. A “private” com-munity string can enable anunauthorized user to change theconfiguration of the device, cre-ate a pathway out to or in fromthe Internet, or program a back-door account into thedevice so that he can haveaccess if the communitystring is changed.

Another older issue isunnecessary services activeor ports running. Only therequired services and portsshould be active. Again lastyear, we encountered severalclients who had TCP port 80open on some of their Ciscodevices that were not patched.As a result, we were able to con-nect to the devices withoutauthentication, with the ability toalter the configuration of thedevice or simply download theconfiguration. Cisco issued apatch for this several years ago,so it is not a Cisco issue. Makesure that these devices arepatched and that TCP port 80,which should not be open, isclosed.

Other clear-text services,such as Telnet and File TransferProtocol (FTP), as well asHyper-Text Transfer Protocol(HTTP) and Simple NetworkManagement Protocol (SNMP),

transmit data unencrypted. Thisincludes accounts and passwordsas well as the data that is passingthrough the network and possi-bly the Internet. This makes iteasy for an unauthorized personor software program to sniff thepasswords and data off the net-work. Once sniffed, they may beused to gain access to thedevices.

My last concern with net-work devices is the failure tosegment the network using sim-ple filters available on mostrouters and switches. Networksegmentation greatly limits thedamage that can be done shouldthe network be breached. Seg-mentation can also be used toprotect legacy machines, whichcan be placed behind an internalfirewall or filtered network

device. If the issues with alegacy machine or applicationcannot be remediated, then itshould be isolated. Networkdevices are ideal for performingthis function.

We identified the need forfurther controls over SNMP thisyear. Since SNMP providesinformation about the device tothose who can connect to thedevice with read or write capa-bility, we strongly suggest thatthere be an access control list forinbound SNMP requests. If auser or device is not on the list,access will not be granted. It isimportant to ensure networkdevices are properly secured, asdisruption of the network canlead to a complete loss of con-nectivity, preventing users and

trading partners from performingcritical business transactions.

UNIX/Linux MACHINES NEEDTO BE SECURED

UNIX and Linux machinesremain prone to poor securityimplementation. The finger serv-ice or the expand (EXPN) andverify (VRFY) Simple MailTransfer Protocol (SMTP) com-mands, if active, enable accountsto be enumerated. This is a boonto an unauthorized user, as pass-words are often equal to theaccount name and occasionallyare blank. Last year, we had sev-eral clients with blank passwordson root or root-empoweredaccounts. This is highly unusualand came as quite a surprise toour team members. Once onto a

machine with a poorlysecured account, an unau-thorized user can takeadvantage of vulnerabili-ties to escalate their capa-bilities, often to the rootlevel.

The most successfulexploit remains trust rela-

tionships. Once a user (author-ized or unauthorized) is loggedonto the computer, he can usetrust relationships to connect toanother machine without authen-tication. Once he is connected,he will have rights at least equalto his rights on the first machineand may be able to escalate up tothe root level. In the last year,we noted several organizationsthat had trust relationships set to“+ +.” This means that any usercan log on without authentica-tion from any UNIX or Linuxmachine. Once on the machine,he may have up-to-root access.The double-plus sign is highlyunusual. If your organization hasvendor-installed and supportedUNIX machines, ensure the.rhost and host.equiv file entries

The Journal of Corporate Accounting & Finance / May/June 2007 47

© 2007 Wiley Periodicals, Inc. DOI 10.1002/jcaf

Network segmentation greatly limitsthe damage that can be done shouldthe network be breached.

jcaf_969.qxp 4/11/07 6:48 AM Page 47

Page 6: Greatest IT audit and security risks of 2006

are scrutinized. That said, alltrust relationships should beeradicated, as they are extremelyhigh-risk and there is a highlikelihood of a security event.Since both risk and likelihood ofoccurrence are high, this shouldbe an immediate fix.

Some of our clients find thatlegacy software issues preventthem from removing trust. Incases like this, we suggest thatthey isolate the machines behindan internal firewall (if the issuecannot be remediated, isolate themachine). Another alternatetechnique is to use a combina-tion of Secure Shell (SSH) andTCP Wrappers. TCP Wrappersplace access controls on servicesto limit who can connect; SSHensures the connection isencrypted.

A failure to properly patchmachines was also an issue inthe last year. Various versions ofLinux and Sun OS had issues. Inthe case of Sun, the two criticalissues are the Sadmind exploitand the Integer Overflow exploit.Sun’s recommended securityenhancements for these issueshave been around for over twoyears, yet we still find clientswho have Sun machines thathave not been patched. In theLinux environment, organiza-

tions with multiple versions ofLinux from different vendorsoften have a difficult time keep-ing up with patches. We suggestthat patches be applied on a veryregular basis.

THE MAINFRAME CAN BEATTACKED

Our mainframe clients useRACF, ACF2, or Top Secret tosecure the environment. A com-mon flaw we identified in thelast year was a failure to imple-ment monitoring of failed loginsor account lockout on the FTPservice. A smart attacker whogains access to the Windowsenvironment will harvest andcrack the passwords. He willthen use brute force against theFTP port using the Windowsaccounts with cracked pass-words. If FTP failed logons arenot monitored, the attack will gounnoticed. At one recent client,we brute-forced the mainframeusing over 12,000 accounts withcracked Windows passwords.This took about an hour andgave our team three passwordswe could use to log on. Oneaccount gave us OPERATIONSand AUDIT capability (the keysto the kingdom). The commentat the exit interview was that we

got lucky. Out of 12,000accounts, only one gave us sig-nificant access. Our responsewas that it only takes one. Need-less to say, this vulnerability wascorrected immediately. To detectbrute-force attacks, make surethat FTP logons are monitoredand that a high-level alert is sentto the security analyst whenthere are more than 25 failedlogons to the FTP port in fiveminutes. With a brute-forceattack, there is not much time todetect the issue before a validaccount might be compromised.

CONCLUSION

I trust that the items I dis-cussed in this article will helpyou in several ways. Many ofour clients feel that their secu-rity is much worse than otherorganizations because themajority of the above flaws existin their organization. Well, theyshouldn’t feel too bad. Mostorganizations suffer from manyor all of the above issues. If youhave not had a major securityevent, then count your blessings.If you have, you already knowhow serious these issues are. Ineither case, 2007 should be theyear that these issues are corrected.

48 The Journal of Corporate Accounting & Finance / May/June 2007

DOI 10.1002/jcaf © 2007 Wiley Periodicals, Inc.

Gordon Smith is president of Canaudit Inc. (Simi Valley, California) and an expert on IT audit and security.He can be reached via e-mail at [email protected].

jcaf_969.qxp 4/11/07 6:48 AM Page 48