©2002 By Information Systems Audit and Control Association
www.isaca.org
F E AT U R E F E AT U R E
Application Risk in a
TCP/IP Environment
By Robert M. Harrison
I
t often is said that the greatest risk to an organization comes from within its own walls. There are
numerous cases where an employee intentionally
causes harm to a company. Sometimes, a company
can be exposed to risk simply by carelessness of
its employees. This article addresses a common
risk caused by carelessness in corporate networks.
TCP/IP
As a general rule, the flexibility of a networking technology is related inversely to the strength
of its security capabilities. One networking technology, more than any other, was created with the
specific goal of flexibility although it comes at the
expense of virtually all inherent security. This
technology is TCP/IP.
TCP/IP is, by its very nature, a highly adaptable
and fluid technology. However, these attributes do
not come without cost in the form of increased
security risks. In particular, specific applications
using the TCP/IP technology can pose a major
threat to every organization’s information assets
without the proper monitoring tools in place.
Scenario
The network under review for this case study
was a multistate Ethernet wide area network using
several protocols with a variety of server, workstation and network operating systems.
One aspect of the audit was to identify security
weaknesses within the TCP/IP structure using
common, easy-to-obtain tools used by hackers. We
did not use any special hardware technology, and
only used software that was freely available either
on the Internet or on the company’s internal
network. We worked with the network access that
had been granted to us by the information security
services department. This access was similar to
any typical end user.
Audit Process
We began our audit by gathering data about the
size and scope of the organization’s TCP/IP environment. This effort involved determining a range
of TCP/IP addresses with which to work. We used
our own address (obtained using the WINIPCFG
command in Windows 98) as the starting point.
Since we were operating within the organization’s
firewall, it was easy to obtain other TCP/IP
INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 6, 2002
addresses with a freeware port scanner.
In less than one hour, we had identified all
TCP/IP nodes at the company’s main office and all
remote locations. Using this information, we noted
that many of the host names assigned to individual
PCs often either identified the end user or provided location information. This allowed us to zero in
on the high-risk areas of the organization.
However, despite this knowledge, we were
unable to compromise the network operating systems or the operating systems of any of the PCs
identified. The information security department
had done an excellent job in securing the operating
systems. However, we were able to spend a significant amount of time “hacking” without fear of
being caught. There were no monitoring tools on
the network that would have detected our actions
and reported them to the appropriate personnel.
At this point, we realized a different approach
was required. Instead of attacking operating systems, this time, we would attempt to find weaknesses in applications commonly used at the company.
Working within our own subnet, it took less than an
hour before this effort yielded promising results.
The organization was a heavy user of a popular
remote desktop management application. This
software allows a user at one PC to connect to
another and assume control of that PC for remote
maintenance. This control can be obtained through
dial-up access or via a variety of networking protocols. In our case, the protocol exclusively in use
was TCP/IP.
By using the application itself, we were able to
quickly identify all PCs on our subnet and were
then able to connect and control the majority of
these PCs. From there, we moved onto the wider
network. Using our freeware port scanner, we
quickly determined that the vast majority of PCs
located outside of the company’s main office also
had remote access software installed. Furthermore,
none of these remote clients had password protection enabled, and all were configured to automatically startup when a PC was booted. Thus, turning
on a PC made it vulnerable.
The dangers of this situation were readily
apparent. Among them were the ability to:
• Obtain restricted company information
• Obtain limited control over other employees’
e-mail accounts and messages
• Change customer data
39
• Obtain limited control over several of the company’s core
financial systems
Since all applications were running in an unmonitored
TCP/IP environment, our actions could not even be detected.
We were not required to log on to any of the remote PCs to
perform any of these activities.
Robert M. Harrison
is senior consultant, internal audit services, at J.H. Cohn LLP,
an accounting and consulting firm. Harrison is based in
Franklin Lakes, New Jersey, USA, and can be reached at
rharrison@jhcohn.com.
Lessons Learned
Several factors contributed to the success of our penetration
attacks. First, there was poor application management at the
company. This was due to a lack of coordination between the
network and technical support departments that allowed an
application to be installed and configured in such a way that
hundreds of PCs were vulnerable to attack. Second, the company did not have network detection and intrusion tools. At no
time were the relevant people aware of our actions. Finally,
although this particular application initially may have been set
up to perform remote maintenance, it was not the ideal tool for
this purpose. There are other, more secure ways to accomplish
this task. Applications such as ZenWorks, Intel LANDesk and
MS Systems Management Server can enable support personnel
to perform maintenance on a remote PC from a central location
without introducing easily identifiable and exploitable vulnerabilities to the corporate network.
40
INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 6, 2002