AOH :: ISN-1296.HTM

Virus Shuts Down Customs Computer System




Virus Shuts Down Customs Computer System
Virus Shuts Down Customs Computer System



http://apnews.myway.com/article/20050819/D8C2RE000.html 

By LISA ORKIN EMMANUEL
Aug 19, 2005

MIAMI (AP) - Travelers arriving in the United States from abroad were 
stuck in long lines at airports nationwide when a virus shut down a 
U.S. Customs computer system for several hours, officials said.

Homeland Security spokesman Russ Knocke said the virus impacted 
computer systems at a number of airports Thursday night, including 
those in New York, San Francisco, Miami, Los Angeles, Houston, Dallas 
and Laredo, Texas.

Knocke said customs agents immediately switched to manual inspections. 
He declined to provide details on where the computer virus originated.

The worst delays appeared to be at Miami International Airport, where 
as many as 2,000 people waited to clear immigration, airport spokesman 
Marc Henderson said. The passengers were not permitted to leave the 
area before then.

Brian Hunt and his wife, who were visiting from Spain, said it took 
them nearly five hours to be processed.

"The agent was very charming, very nice and greeted us with a smile," 
he told The Miami Herald. "It was just an unfortunate thing, but these 
things happen. Who do we blame?"

The computer problem originated in database systems located in 
Virginia and lasted from around 6 p.m. until about 11:30 p.m., said 
Zachary Mann, spokesman for U.S. Customs and Border Protection in 
southern Florida.

At New York's airports, customs officials processed passengers by 
hand. Officials used backup computer systems to keep passengers moving 
at Los Angeles International Airport, where the computers were only 
down for an hour and a half.

"It was during a light time of travel for international passengers at 
LAX," said Mike Fleming, customs spokesman in Los Angeles. "All 
systems have been restored to full capacity." 



_________________________________________
Attend ToorCon 
Sept 16-18th, 2005
Convention Center
San Diego, California
www.toorcon.org 
.
+OK 8219 octets
Received: from [66.80.146.7] by scratchy
  (ArGoSoft Mail Server Plus for WinNT/2000, Version 1.8 (1.8.5.6)); Mon, 22 Aug 2005 01:24:57 -0700
Received: from forced.attrition.org (localhost.attrition.org [127.0.0.1])
	by forced.attrition.org (Postfix) with ESMTP id 2039BE8E24;
	Mon, 22 Aug 2005 04:23:31 -0400 (EDT)
Received: from idle.curiosity.org (idle.curiosity.org [207.7.59.40])
	by forced.attrition.org (8.11.6/3.8.9) with ESMTP id j7M8J6308338
for ; Mon, 22 Aug 2005 04:19:13 -0400 
Received: from idle.curiosity.org (idle.curiosity.org [207.7.59.40])
	by idle.curiosity.org (8.11.6/8.11.6) with ESMTP id j7M8EAN04662
for ; Mon, 22 Aug 2005 03:14:10 -0500 
Date: Mon, 22 Aug 2005 03:14:10 -0500 (CDT)
From: InfoSec News  
X-X-Sender: isn@idle.curiosity.org 
To: isn@attrition.org 
Message-ID:  
X-Subscription_Info: http://www.c4i.org/isn.html 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-Mailman-Approved-At: Mon, 22 Aug 2005 04:21:58 -0400
Subject: [ISN] Security Firm: Oracle Opatch Leaves Firms Uncovered 
X-BeenThere: isn@attrition.org 
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: isn@c4i.org 
List-Id: InfoSec News 
List-Unsubscribe: , 
 
List-Archive:  
List-Post:  
List-Help:  
List-Subscribe: , 
 
Sender: isn-bounces@attrition.org 
Errors-To: isn-bounces@attrition.org 
Content-Transfer-Encoding: quoted-printable

http://www.eweek.com/article2/0,1895,1850287,00.asp 

By Lisa Vaas 
August 19, 2005 

Think you're patched? Think you'll get the thumb's-up from the auditor
when she comes knocking on your door to make sure you're in compliance
with HIPAA (Health Insurance Portability and Accountability Act), or
GLBA, or Visa CISP and MasterCard PCI?

According to an upcoming paper from Next Generation Security Software
Ltd., a majority of users of Oracle Corp. database servers are in fact
mistaken in their perception of their patch levels and are actually
not compliant with such regulations.

David Litchfield, managing director of NGSS, said that out of a total
of more than 100 recently surveyed database servers, a staggering 76
percent have anomalies between expected and actual patch levels.

Surveyed database instances included a range of industries and company
sizes. Size and industry are irrelevant with regards to the potential
for database exposure, however, since Oracle software itself is
causing the exposure, not what customers are doing with their
databases, Litchfield said.

"The fact is that Opatch is failing, or [an Oracle] patch failed to
fix certain issues appropriately," he said. "Customers aren't doing
anything wrong. It's the tools themselves that are faulty."

The problems are manifold, according to NGSS. At times, Oracle's CPUs
(Critical Patch Updates) fail to install updated, fixed copies of
files. Both the April and July 2005 CPUs, for example, failed in
multiple areas.

In the April CPU, on all platforms, new Java classes supplied to fix
SQL injection vulnerabilities in DBMS_SUBSCRIBE and DBMS_ISUBSCRIBE
were not actually loaded, according to NGSS. In addition, on Windows
platforms, a SQL script file with a fixed version of the CTXSYS-owned
DRILOAD package was copied to the wrong directory and thus was never
executed.

Many other problems relate to Oracle's opatch utility. Opatch is a
utility through which patches are applied to Oracle database servers.  
Information on patches and fixed bugs are stored in Oracle Inventory,
a flat XML file. Opatch is used to query the inventory to determine
whether a server is patched.

After running Opatch, users are typically given the message "Opatch
succeeded." However, necessary post-installation tasks include
updating components such as PL/SQL packages and Java Class files in
the database. If these post-installation steps aren't taken, the
server remains vulnerable in spite of the Opatch utility having
indicated that the server is in fact patched.

In addition, according to NGSS, Opatch often fails for various
reasons. "Permissions are wrong; files that are to be patched are
still in use; environment variables are wrong; whatever the reason
might be, and a quick search on Google reveals many more, Opatch can
often fail to update the inventory," according to a preliminary draft
of the search firm's paper, titled "Patch Verification of Oracle
Database Servers."

"If information in the inventory is wrong, then so too are any
observations made about patch status and levels," the paper said.

Does any of this matter? Oracle users tend to consider themselves
generally safe from risk, given that their databases are typically
locked down behind firewalls instead of being exposed to the Internet
- as is often the case with installations of Microsoft Corp.'s SQL
Server database.

Carl Olofson, an analyst with IDC, said it's hard to get concerned,
given that he's not hearing stories of SQL code injection or other
types of security exploits. "If we were getting stories about people
whose systems were brought to their knees or getting security
breaches, if this were coming up in multiple places, that would be an
area for concern," he said.

But, according to Litchfield, there are ample numbers of unprotected
Oracle database servers, particularly when it comes to universities,
which often expose their servers to the Internet. In addition,
back-end Oracle database servers are vulnerable to SQL injection via
Web applications.

"There is exposure, regardless of what Oracle would have you believe,"  
he said. "Some people are running Web applications that are exposed to
the Web, and we [have demonstrated that] we can gain control of the
back end through SQL injection."

Oracle, maker of what it has marketed as the "unbreakable" database,
seldom addresses criticisms about its security. The move to quarterly
patch releases a la Microsoft came only after a protracted silence on
34 vulnerabilities for which it reportedly had fixes in 2004.

Recently, however, Oracle Chief Security Officer Mary Ann Davidson
broke the silence by writing an article in which she said that
self-interested security researchers who publish flaws before patches
are available endanger the industry with their thirst for fame.

In that article, Davidson said that getting fixes into customers'
hands takes far longer than security researchers imagine.

"Remediation may require the vendor to analyze whether the bug is
specific to a particular version/platform or all versions/all
platforms or analyze whether related code has a similar problem [to
fix the problem everywhere]," Davidson said.

"Vendors may also need to provide fixes on multiple versions/platforms
or bundle multiple security fixes together to minimize patching costs
to customers, not to mention peforming various testing on the products
shipped to ensure the fix does not break anything else," she said.

Litchfield dismisses this criticism by pointing to patches issued by
Oracle that in fact don't fix what they were intended to fix.

"You'd expect, if they take so long to write these patches, the
patches would be robust," he said. "I'm absolutely appalled. Why do
they take so long and still fail to patch? I'm gobsmacked. =85 There are
still SQL injection issues in the things Oracle supposedly fixed. If
it took two years to fix these things, they should really have fixed
these things. And they're not [fixing them].

"They built the Empire State Building in 14 months," he said. "If we
can do that, surely Oracle can get out patches that work."



_________________________________________
Attend ToorCon 
Sept 16-18th, 2005
Convention Center
San Diego, California
www.toorcon.org 

Site design & layout copyright © 1986-2014 CodeGods