I am writing this whilst sat on a train travelling at around 120mph between York and Darlington, this is probably my first blog entry written at speed!
I saw that David had released his paper " http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf - (broken link) Lateral SQL Injection: A new class of vulnerability in Oracle last week. I saw this paper in February when David kindly let me have a read of it in advance of publication.
I have to say I am with David in terms of his comments released yersterday in a post on his blog. This is a new class of vulnerability and its certainly not second order SQL Injection as no data is stored to be executed. I have to say its close to it in terms of principal as the attack payload is set up first but its different as the session is modified to add the payload as a date format. I am also with David, this is not mostly academic (Eric Maurice in his blog also agrees), there is a real threat, as there are a number of issues:
1) It's a new way to inject via dates and numbers
2) Just because dynamic code appears to not have an attack vector doesn't mean that it cannot be attacked.
3) Any principal that says a concat or double vertical bar is safe because the data is not passed in as a parameter or read from the database is flawed.
There are likely to be more methods come to light as time passes. Any concatenated string used as SQL, DDL, PL/SQL is potentially dangerous.
I am on my way to Edinburgh to speak at the http://www.ukoug.org/calendar/show_events.jsp?year=2008&month=04&day=30 - (broken link) OUG Scotland DBA SIG in Edinburgh to speak on the subject of Oracle Forensics. I have some updates to make to the front page of my site in terms of speaking engagements which i will get to soon but for now, I have agreed to speak in Iceland in September and also the UKOUG Northen Server technology day in June and also the management and infrastructure SIG of the UKOUG also in June.
I am also working with a number of companies to provide public training days for my two day course "How to perform an Oracle database security audit". More details in the next few days but as a summary there will be an event in London in June, July and also potentially in August or September. I will also deliver the training in Holland, Germany, Sweden and Norway in November and December. I am also delivering the course to a growing number of private companies on their own sites over the next 6 months. As I said I will put up actual dates and a detailed agenda in the next few days here on the blog and also on the training course page itself.
Blog
Pete Finnigan's Oracle Security Weblog
This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.
Slides from OUGN Norway and RISK 2008 Norway available
I was over in Norway this week and the Oracle User Group Norway (OUGN) asked me to speak at an evening user group meeting of theirs. This was a eally friendly group and it was a pleasure to speak there. The slides for the two talks I gave are on my Oracle Security white papers page. The individual papers are "Oracle Security Basics" - which out of interest is not intended to mean a basic presentation but is about getting the building blocks right in terms of securing an Oracle database. The second paper is "Oracle Security Tools".
Then I was asked to speak at the RISK 2008 Conference organised by Mnemonic one of the key security consultancies in Norway. It was a good conference (mostly in Norwegian) but I enjoyed Marcus Ranum's talk which was interesting from the point of view that we are on the same wave length, he was saying some of the same things I say about security and particularly data security. It was nice to have a chat with him after lunch also.
Then I was asked to speak at the RISK 2008 Conference organised by Mnemonic one of the key security consultancies in Norway. It was a good conference (mostly in Norwegian) but I enjoyed Marcus Ranum's talk which was interesting from the point of view that we are on the same wave length, he was saying some of the same things I say about security and particularly data security. It was nice to have a chat with him after lunch also.
Two remotely exploitable without authentication bugs to be fixed
Oracle's pre-patch advisory note for the next Critical Patch Update (CPU) due this Tuesday (15th) states that there are 17 new security fixes for the database, two for Apex and two of which are remotely exploitable without authentication. The advisory states:
"This Critical Patch Update contains 17 new security fixes for the Oracle Database including 2 for Oracle Application Express. Two of these vulnerabilities may be remotely exploited without authentication, i.e. may be exploited over a network without the need for a username and password. None of these fixes are applicable to Oracle Database client-only installations, i.e. installations that do not have the Oracle Database installed."
This, as Scott Spendolini states is confusing as it is unclear if these bugs are the APEX bugs or different bugs. If most CPU releases are anything to go by people had better beware as often exploits are released on sites such as Milw0rm soon after the CPU / patch is released. Where there are remotely exploitable bugs without the need of authentication this is much more serious.
As I said its unclear if these remotely exploitable bugs are APEX or not. If they are then a clear action for anyone to do is to de-install APEX if its not used. This is normal practice in security anyway, reduce the attack surface and ensure that only the features/components needed are installed. One of the new "features" of 11gR1 is the default install of APEX, if someone needs APEX they should install it, it doesnt need to be there by default, especially if there are security bugs in it. Clearly we need to wait for the patch and advisory and judge then. Obviously the advice has to be to patch as soon as possible especially this time because of the remotely exploitable bugs, it would be nice if Oracle would at least hint which component they are in. I guess if it was APEX then the Google hackers could easily find sites to attack!
"This Critical Patch Update contains 17 new security fixes for the Oracle Database including 2 for Oracle Application Express. Two of these vulnerabilities may be remotely exploited without authentication, i.e. may be exploited over a network without the need for a username and password. None of these fixes are applicable to Oracle Database client-only installations, i.e. installations that do not have the Oracle Database installed."
This, as Scott Spendolini states is confusing as it is unclear if these bugs are the APEX bugs or different bugs. If most CPU releases are anything to go by people had better beware as often exploits are released on sites such as Milw0rm soon after the CPU / patch is released. Where there are remotely exploitable bugs without the need of authentication this is much more serious.
As I said its unclear if these remotely exploitable bugs are APEX or not. If they are then a clear action for anyone to do is to de-install APEX if its not used. This is normal practice in security anyway, reduce the attack surface and ensure that only the features/components needed are installed. One of the new "features" of 11gR1 is the default install of APEX, if someone needs APEX they should install it, it doesnt need to be there by default, especially if there are security bugs in it. Clearly we need to wait for the patch and advisory and judge then. Obviously the advice has to be to patch as soon as possible especially this time because of the remotely exploitable bugs, it would be nice if Oracle would at least hint which component they are in. I guess if it was APEX then the Google hackers could easily find sites to attack!
Fine Grained network Access Control in 11g
I saw a post by Tim Hall on his blog recently that referenced a new article he had written about the new fine grained network access controls added in 11g. As this is an area I have also looked at last year and also mentioned in a number of my presentations I was of course interested to have a look. I am never disapointed by any of Tim's papers which are always very well written and excellent.
This paper is particularly useful as the subject, if you think deeply about it quickly becomes complex. I noticed some issues with fine grained network access and also Tim has noticed some as well. The issues for me is that its controlled by ACL's through XML DB which is complex in its own right.
One of the key gotchas I noticed when testing this last year was that if you don't notice or understand that only one ACL can be assigned to a host or port range you can become unstuck. i.e. if you assign a new ACL to an existing specific host it deletes the last one silently. I mentioned this in my 11g security new features paper.
The other major gotcha that Tim didn't pick up on is the fact that the "fine grained control" is at the package group level, for the connect privilege this includes packages such as UTL_MAIL, UTL_HTTP, UTL_TCP...
Imagine the case where you want to grant access for connect on a specific host for a schema to access the UTL_MAIL package, fine and dandy but if you haven't been "specific" enough in defining the ACL (IP/ hostname AND port range) then you have also opened up access on the same host/port range to the other packages included in the FGNA controls. In this example the use of UTL_TCP is also available and that can be used to connect to any allowed port in the range and potentially then any protocol you can write in PL/SQL. In summary the protections are not fine grained enough on their own. You need to be specific with the ACL and if you want to allow access to MAIL, then allow access to only the ports 25(smtp) and 110(pop3) or one of them or different if they have moved or different protocols are used. Then revoke the access on all the packages affected by the connect privilege and allow grants back to the specific necessary schemas. Don't be lulled into a false sense of security if for instance the ACL is tied to the host and say just port 110, the UTL_TCP package if access is not revoked could be used to do more than the more limited set of actions the UTL_MAIL package offers.
Securing Oracle is always about depth, you need to ensure that no one can alter the ACL's, access the ACL's (dictionary views, package API's, raw XML), set up ACL's, revoke access to the functional packages..... there is more..... securing Oracle is always about depth. Whilst fine grained network access is a good move forward, you need to be careful that you don't think its a network security solution on its own!!
This paper is particularly useful as the subject, if you think deeply about it quickly becomes complex. I noticed some issues with fine grained network access and also Tim has noticed some as well. The issues for me is that its controlled by ACL's through XML DB which is complex in its own right.
One of the key gotchas I noticed when testing this last year was that if you don't notice or understand that only one ACL can be assigned to a host or port range you can become unstuck. i.e. if you assign a new ACL to an existing specific host it deletes the last one silently. I mentioned this in my 11g security new features paper.
The other major gotcha that Tim didn't pick up on is the fact that the "fine grained control" is at the package group level, for the connect privilege this includes packages such as UTL_MAIL, UTL_HTTP, UTL_TCP...
Imagine the case where you want to grant access for connect on a specific host for a schema to access the UTL_MAIL package, fine and dandy but if you haven't been "specific" enough in defining the ACL (IP/ hostname AND port range) then you have also opened up access on the same host/port range to the other packages included in the FGNA controls. In this example the use of UTL_TCP is also available and that can be used to connect to any allowed port in the range and potentially then any protocol you can write in PL/SQL. In summary the protections are not fine grained enough on their own. You need to be specific with the ACL and if you want to allow access to MAIL, then allow access to only the ports 25(smtp) and 110(pop3) or one of them or different if they have moved or different protocols are used. Then revoke the access on all the packages affected by the connect privilege and allow grants back to the specific necessary schemas. Don't be lulled into a false sense of security if for instance the ACL is tied to the host and say just port 110, the UTL_TCP package if access is not revoked could be used to do more than the more limited set of actions the UTL_MAIL package offers.
Securing Oracle is always about depth, you need to ensure that no one can alter the ACL's, access the ACL's (dictionary views, package API's, raw XML), set up ACL's, revoke access to the functional packages..... there is more..... securing Oracle is always about depth. Whilst fine grained network access is a good move forward, you need to be careful that you don't think its a network security solution on its own!!
C code API to encapsulate OCI
If like me you code in C and use OCI instead of Pro*C then you will be interested in a library written by Vincent Rogier. I have looked at most C++ OCI libraries, and C libraries that encapsulate OCI in some way over the years and even though I end up writing direct OCI code myself, I was always impressed by Vincent's OCILIB.
I normally code in C for anything "real" and use C++, MFC for user interfaces as its quick and easy and also if you need to access a database (wait for it... its easy to use MSDE, SQL Server Express etc) as well as Oracle databases from MFC to create sophisticated and quick (in terms of writing) Windows code.
I saw a post on Francois Degrelle's blog today that reminded me of the library and I thought its worth a quick promote here. What's the security angle? - well we are developing Oracle security tools internally for use in audits, code audits, forensics, encryption reviews and more in C and OCI. The tools I use myself for many years are written in PL/SQL and are used to capture raw data as part of audits and other investigatory work. I have decided to convert the tools to C for speed, security of IPR and to make updates - which are frequent and often easier. The focus of our security audits is always manual in terms of analysis and we still do large parts of the audit manually and also by interview this is because a much clearer and deeper picture can be obtained in this way but tools are also important to capture and gather the large amounts of data needed to be analysed manually for all the parameters and privileges set in the dictionary. Anyway here is a glimps, it is in C, its fully instrumented, generates logs and is driven by configurations that can be read from MSDE or text based files and does SQL connections to the database and ssh to the server for gathering data and checks.
Yes, i know the timing shows GMT and the system date/time is BST, it needs to be fixed still!
I normally code in C for anything "real" and use C++, MFC for user interfaces as its quick and easy and also if you need to access a database (wait for it... its easy to use MSDE, SQL Server Express etc) as well as Oracle databases from MFC to create sophisticated and quick (in terms of writing) Windows code.
I saw a post on Francois Degrelle's blog today that reminded me of the library and I thought its worth a quick promote here. What's the security angle? - well we are developing Oracle security tools internally for use in audits, code audits, forensics, encryption reviews and more in C and OCI. The tools I use myself for many years are written in PL/SQL and are used to capture raw data as part of audits and other investigatory work. I have decided to convert the tools to C for speed, security of IPR and to make updates - which are frequent and often easier. The focus of our security audits is always manual in terms of analysis and we still do large parts of the audit manually and also by interview this is because a much clearer and deeper picture can be obtained in this way but tools are also important to capture and gather the large amounts of data needed to be analysed manually for all the parameters and privileges set in the dictionary. Anyway here is a glimps, it is in C, its fully instrumented, generates logs and is driven by configurations that can be read from MSDE or text based files and does SQL connections to the database and ssh to the server for gathering data and checks.
C:\oscan -c oscan.conf -v OSCAN: Release 0.1.12 - Alpha on Mon Apr 07 11:18:26 2008 Copyright (c) 2003, 2008, PeteFinnigan.com Limited. All rights reserved. [2008 Apr 07 10:18:26] Logger: Starting OSCAN... [2008 Apr 07 10:18:26] Logger: Running Scanner .... [2008 Apr 07 10:27:32] Logger: Closing Down OSCAN |
Yes, i know the timing shows GMT and the system date/time is BST, it needs to be fixed still!
April 2008
- C code API to encapsulate OCI - 04/07/2008 by 04/07/2008
- Fine Grained network Access Control in 11g - 04/08/2008 by 04/08/2008
- Two remotely exploitable without authentication bugs to be fixed - 04/14/2008 by 04/14/2008
- Slides from OUGN Norway and RISK 2008 Norway available - 04/25/2008 by 04/25/2008
- Lateral SQL Injection and Conferences and security training - 04/30/2008 by 04/30/2008
Archives
Syndication
Powered by gm-rss 2.0.0
