Domain: niscc.gov.uk
Stories and comments across the archive that link to niscc.gov.uk.
Comments · 7
-
... or just a chance to bash security researchers?Interestingly enough, I saw Litchfield's post to Bugtraq on this issue. He did not disclose any 'real' information (compared to other posts detailing what problems are and where they are, or even proof of concept exploit code) about the vulnerability that would lead to a compromise, unless you already knew what the compromise was. He did post a workaround, which was an Apache mod_redirect config which catches the attack and rewrites the URI to the denied page.
But, hey, I'll let you all judge. Here's his posting to Bugtraq:
There's a critical flaw in the Oracle PLSQL Gateway, a component of iAS, OAS
and the Oracle HTTP Server, that allows attackers to bypass the
PLSQLExclusion list and gain access to "excluded" packages and procedures.
This can be exploited by an attacker to gain full DBA control of the backend
database server through the web server.
This flaw was reported to Oracle on the 26th of October 2005. On November
the 7th NGS alerted NISCC (http://www.niscc.gov.uk/ to the problem. It was
hoped that due to the severity of the problem that Oracle would release a
fix or a workaround for this in the January 2006 Critical Patch Update. They
failed to do so.
The workaround is trivial; using mod_rewrite, which is compiled into
Oracle's Apache distribution it is possible to stop the attack. The
workaround checks a user's web request for the presence of a right facing
bracket, ')'.
Add the following four lines to your http.conf file then stop and restart
the web server
RewriteEngine on
RewriteCond %{QUERY_STRING} ^.*\).*|.*%29.*$
RewriteRule ^.*$ http://127.0.0.1/denied.htm?attempted-attack
RewriteRule ^.*\).*|.*%29.*$ http://127.0.0.1/denied.htm?attempted-attack
I don't think leaving their customers vulnerable for another 3 months (or
perhaps even longer) until the next CPU is reasonable especially when this
bug is so easy to fix and easy to workaround. Again, I urge all Oracle
customers to get on the 'phone to Oracle and demand the respect you paid
for.
Cheers,
David Litchfield -
Not a rdbms vulnerability, per sebut a hole in OHS (Oracle's distributed Apache server).
There's a critical flaw in the Oracle PLSQL Gateway, a component of iAS, OAS
and the Oracle HTTP Server, that allows attackers to bypass the
PLSQLExclusion list and gain access to "excluded" packages and procedures.
This can be exploited by an attacker to gain full DBA control of the backend
database server through the web server.
This flaw was reported to Oracle on the 26th of October 2005. On November
the 7th NGS alerted NISCC (http://www.niscc.gov.uk/ to the problem. It was
hoped that due to the severity of the problem that Oracle would release a
fix or a workaround for this in the January 2006 Critical Patch Update. They
failed to do so.
There is even a simple workaround:
The workaround is trivial; using mod_rewrite, which is compiled into
Oracle's Apache distribution it is possible to stop the attack. The
workaround checks a user's web request for the presence of a right facing
bracket, ')'.
Add the following four lines to your http.conf file then stop and restart
the web server
RewriteEngine on
RewriteCond %{QUERY_STRING} ^.*\).*|.*%29.*$
RewriteRule ^.*$ http://127.0.0.1/denied.htm?attempted-attack
RewriteRule ^.*\).*|.*%29.*$ http://127.0.0.1/denied.htm?attempted-attack
I've already applied this on my OAS install on by development box and I'm ready to spend the next couple hours testing before recommending that we do this on our production box.
I don't think leaving their customers vulnerable for another 3 months (or
perhaps even longer) until the next CPU is reasonable especially when this
bug is so easy to fix and easy to workaround. Again, I urge all Oracle
customers to get on the 'phone to Oracle and demand the respect you paid
for
I couldn't agree more. Can't fathom why they couldn't have notified customers (even if they couldn't have fixed mod_plsql through the CPU), or why they are going after the guy when he told them about this 3 months ago and waited for the January update before getting impatient and going public. -
Re:Missing something fundamentalI believe what the parent is trying to say is that while the default security model in *NIX derived OSes is pretty strong, it isn't perfect. All you need is one privilege escalation bug (giving root access to a normal user's process), and root ownership/non world writable status of files is no longer a problem for the virus seeking to run in
/bin (or wherever). There have been a few Linux advisories of just this type of bug (for example, this one - first thing I found with a quick Google search), as well as for FreeBSD, OpenBSD, Mac OS X, etc.It is unlikely that we've seen the last ever privilege escalation bug in Linux.
-
Doesn't seem to be any different
http://www.niscc.gov.uk/niscc/docs/ttea.pdf
That NISCC advisory exactly describes exactly what I'm seeing. Even down to the 'newspaper article' reference, e.g. the one I shows as an example was from uniontrib.com = San Diego Union Tribune.
I don't see the difference, what they describe is exactly what is normal for this sort of attack, custom backdoor variants, social engineering, website or attachment delivery, sender spoofed, IP address typically Asian.
What exactly is this 'critical infrastructure' thats connected to the NET and why exactly is it connected to the NET when these sorts of things are so common?
-
Re:"Secret" data?
I didn't find in the actual report PDF where they used the word secret or confidential as in government classified SECRET or CONFIDENTIAL, so the implication is the government data was as the report said sensitive or as it implied a business secret.
Also it may be that somebody wants to turn an employee so putting him in financial difficulty or learning an embarassing personal secret can have great rewards. -
Solution
Taken from the NISC website.
Solution
- - --------
Any of the following methods can be used to rectify this issue:
1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution.
2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done carefully: for example, the configuration where AH in transport mode is applied end-to-end and tunnelled inside ESP is still vulnerable.
3. Remove the error reporting by restricting the generation of ICMP messages or by filtering these messages at a firewall or security gateway. -
Re:So...
No one here seems to have noted that the vulnerability is not limited to Windows.... According to The Reg, "Qualys, the firm credited with finding the TCP/IP stack flaw, warns that the problem is not limited to Microsoft. The vulnerability in Internet Control Message Protocol (ICMP) messages makes it possible to reset or slow an established connection as explained in a UK National Information Security Co-ordination Centre UNIRAS alert here: http://www.niscc.gov.uk/niscc/docs/al-20050412-00
3 08.html?lang=en."
So yes it is damn serious, and not just for people running Windows.