Why you should reduce attack surfaces!

I normally steer clear from blogging about security topics for one thing there are plenty of other people that do it better than me and  i generally find the whole topic pretty dry and boring - a necessary evil.......

However something I've been looking at today is quite interesting and gives some new insight on the topic of reducing the 'attack surface' - in the case I'll talk about below you may not realize what I'm about to demo is even possible and could be inadvertently activated.

So what I'm going to talk about is the XDB/XMLDB component and how it can be used to browse (and delete from) ASM from a browser - or even windows explorer - yes , shock horror I'll show how you could map a network drive to a linux box and from that delete individual files from with ASM!

In previous installations of oracle  (prior to 12c) xmldb was not an essential component and i would generally not advise to install it - it adds loads of objects, makes patching longer and is just another thing to worry about. In 12c however there is no getting away from it - it's part of the core system created by running catalog/catproc - you can't not have it. The primary reason for this being that EM express is all served up using it so it has to be there (the default url being https://server-name:5500/em) as I'm sure will become familiar to everyone.

So anyway assuming you have it installed what happens if you innocently do this:

alter user XDB identified by xxxxxx account unlock;

Pretty harmless you might think?

(As a side note there was an interesting article about why you shouldn't ever lock internal accounts - it gives hackers information that a certain feature is installed rather than just throwing an invalid username/password error you get an account locked error).

Anyway ignoring the digression there what has that actually done by activating that account?

Well for one thing it's enabled this browser access:

http://server-name:5500

Which when you go to it presents you with this login page

Logging in with the details i set above (i.e. XDB/xxxxx) i can then browse quite happily

Nice eh - and because it's a browser you can't delete anything - you can have a look round

Which is exactly what i did when i noticed the ASM directory (under the sys root directory) - it actually lets you browse through ASM as you would do in ASMCMD

So that's kind of useful i guess?

However this now gets a whole lot more sinister.....

I can also access the xmldb via webdav (basically just map a network drive to it) like the steps below

Enter same credentials again

And we have an X drive that lets us view ASM directly as we did in the browser

The worrying thing now is that it's not read only.........

Lets demo that with a datapump export (as i don't want to mess with actual datafiles!)

First up i create a directory in ASM rather than on the filesystem

CREATE directory test as '+EXPORT';

then i do an export

 expdp user/pass directory=test nologfile=y full=y

I do nologfile=y as you can't write the logfile to ASM (i could have created another directory and user directory:logfile syntax but that was more effort....)

That finishes and shows me the created file

Dump file set for SYS.SYS_EXPORT_FULL_01 is:
  +EXPORT/expdat.dmp
Job "SYS"."SYS_EXPORT_FULL_01" successfully completed at Mon Dec 28 15:18:05 2015 elapsed 0 00:01:43

We can go and view that from asmcmd

 unix> asmcmd

ASMCMD> ls

DATA/

EXPORT/

FRA/

ASMCMD> cd EXPORT

ASMCMD> ls -l

Type     Redund  Striped  Time             Sys  Name

                                           Y    CDBHUB/

DUMPSET  UNPROT  COARSE   DEC 28 15:00:00  N    expdat.dmp => +EXPORT/CDBHUB/DUMPSET/SYSSYS_EXPORT_FULL_01_95828_1.256.899651783

Interestingly enough the expdat.dmp name is just an alias for another file - anyway it's all created fine and i can browse to that in my windows explorer session

If i now press delete

and click yes - it happily removes it - confirmed by asmcmd

ASMCMD> ls -l

ASMCMD>

Scary huh.....?

By just unlocking and setting a password on XDB i have given full access to the entire ASM tree to anyone who knows those credentials - they could easily just go and delete the database files.

So the lesson here is set an impossible password on XDB and never grant the access (unless of course you want to make use of this feature for some reason - maybe for an ASM migration in the first place?)

Anyway - quite interesting however you view this!