Call: +44 (0)1904 557620 Call

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.

[Previous entry: "New Conference Speaking Dates Added"] [Next entry: "Protect Your APEX Application PL/SQL Source Code"]

Oracle Security and Electronics

How does Oracle Security and Electronic mix together? - Well I started my working life in 1979 as an apprentice electrician in a factory here in York, England where I live. The factory designed and built trains for the national railways here in the UK and also sometimes for other countries.

When I left school at 16 I already had an interest in electronics and whilst learning to be an electrician we also did some small elements of electronics as part of the work. We had clean rooms and we had electronics people who mended the circuit boards on trains and also electronics in machines used in the factory. I loved my time there and also at the training school where we also did some electronics.

In and around 1980 - 1981 when I was 16-17 years old I had already done some simple projects and then I built my own multi-meter (it has gone years ago and I cannot find any pictures of it) and some other bits and bobs and then I decided to build an Oscilloscope from scratch including the chassis and case. This was a big project at the time and getting all of the parts needed was a faff as there was no online ordering in 1981. You needed to ring electronics shops or order from magazines or catalogs.

I still have the oscilloscope. It is not in good condition and I would never be fool hardy enough to try and power it up now but I can assure you that it worked at the time and I even loaned it to an exhibition. Some switches are missing and some knobs from switches missing also and the chassis is rusty now but i was proud of it at the time. Here are a few pictures that I took yesterday:

Oscilloscope from the Front

Above is my Oscilloscope from the front with the case on. Next:

Oscilloscope from the Front other side

Above is from the front but the other side. Next is a picture of the back with the case on:

Oscilloscope from the back

Next is a picture of the inside from the left with the case off and the picture shows the rust on the chassis that i built myself 34 - 35 years ago. Here it is:

Oscilloscope inside left with case off

Next is from the insider but the right hand side top:

Oscilloscope inside top right hand side

Here is another view from the top:

Oscilloscope top view

And finally a view of the underside and the HV (High voltage) and LV (Low Voltage) transformers. A tool like an oscilloscope requires very high voltage to drive the cathode ray tube hence its dangerous to play with the insides of this when its turnd on. Here is the underside:

Oscilloscope underside

Around the same time I built the oscilloscope I also built a 6502 computer with very limited RAM and ROM and no keyboard; I had to use buttons for input but i did provide composite to output to a TV. I do not have that first computer that I made anymore (pity) and also do not have any pictures of it.

I continued to be interested in electronics into the middle 1980's and then lost interest as other things came along. Then in the late 80s, very early 90s I learned to program in C and Assembler and got into low level DOS and that was it.

In recent times I was re-kindled with the desire to play with electronics as I bought a Raspberry Pi to use as a basis for an Asterisk server. I wanted a simple small computer that would run silent, generate little heat but be able to connect to the phone system via an adaptor and run Asterisk. I was also interested to create a GSM gateway to allow asterisk to be used to connect the land line to mobiles and also VOIP mainly to allow me to take calls anywhere no matter how the call originates. This is not complete yet. As part of that I made a mobile phone but using an Ardiuno and a GSM900 chip and a simple LCD. This was to test the GSM card and AT commands and also to interface with an LCD and Arduino. The Arduino is programmed in C so thats good.

This mobile was taken apart and I have now got a GSM800 chip / card which is much smaller and I am going to make another mobile phone with that shortly that will be used in my Asterisk server. In playing with the GSM -> Arduino this lead me into breadboarding and building an Arduino from the Atmel chip so I looked around for a simple project and built a Digital clock with 4 seven segment displays, 5 shift registers, a DS1307 real time clock and an Arduino from chip and components. I am now tempted to build this now onto vero board and solder it or possibly make a PCB. I was looking in Maplin last weekend at a starter kit to make a PCB by etching. This brings me back to when i was 16 - 17 and working in the clean room at the factory making new PCBs from scratch.

Electronics has changed. It is now more commoditised; In the old days its was more about descrete components and no programming unless you built a computer and then it was about 74 series TTL for a computer that you built. Now its more common to use microcontrollers and small hardware glue but also software glue and instructions. Modern day applications can also take on the customised feel by this approach or by using CPLD's or FPGA's. These are programmable logic where you can essentially go full circle. A big company may use an ASIC (A burned chip that implements custom logic) but we can use FPGA, CPLD etc to create our custom hardware but also with software. Its not uncommon to implement a CPU now in an FPGA. So you could create an Arduino (an Atmel 328 for instance) in an FPGA, so hardware programmed with software simulating hardware that runs software!!

Hardware and software are very interlinked nowadays. What has all of this got to do with Oracle security. In one sense nothing but in another sense everything. I was asked recently at a clients site how could they test the validity of password rules they have set up in the database with password management and also password verify functions. There are a number of possible points to this unfortunately:

1) If the rules (password management) are added to an existing account and its password not changed then a password could be weak and then forced to be strong at the next change. i.e. it is still weak.
2) If the rules are not complete then it is possible to enforce (sarcastically in this case) strong passwords via a veryify function but then not set a lifetime so the password is never forced to expire so is never forced to be changed, so never forced to be strong; again a weak password can ensue
3) you could verify passwords via the verify function as they are changed - good.
4) If the system needs to be tested now then there is no way to prove a password is strong other than by knowing that password - i.e. you can read it somewhere (not strong to do that anyway, i.e. it is thenm known) or you can work it out by cracking the password.

If a password is long enough then cracking it may not reveal the password in a useful time frame and therefore not prove its strength. For instance if i set a password to welcomewelcome its 14 characters long so it has a good attribute but because its 14 characters long we cannot brute force it to verify it using a cracker on a PC BUT the password is weak as its a doubled simple password. That is the password is too long for a software cracker to crack the password fast enough to verify its strong but in this case we know its weak.

We could take a different view and say; with this hardware I have, this software I have and these rules I make up (check defaults, simple words, known passwords, too short (small length)) then if we don't crack it it is good enough? There is a problem with this though as a test of this type on a laptop such as the one i am using now is not good enough (read not fast enough) to test thoroughly. This laptop takes too long to verify if a password is 8 characters is enough or not. The reason this is valid to say is that other methods exist that could be used by a hacker. I.e. he could use a 6 or 8 core CPU or multiple 6 or 8 core CPUs or Dennis Yurichevs SSE2 cracker is software and very fast and can do tens of millions of hashes a second on reasonably new hardware. But on this laptop the speed doubles or perhaps trebles which is still not enough.

Dennis also built an FPGA cracker for Oracle in 2009. Interestingly I mentioned using an FPGA as an Oracle cracker in 2007 in a post called Using Field Programmable Gate Arrays (FPGA) to crack passwords. Dennis post on his 60 million password hashes/second Oracle password cracker available is linked here.

The problem is that electronics has become easier in one sense for people to make things at home and its got smaller and more powerful. the electronics maker market has exploded into being in the last few years so its not infeasable that someone can build hardware crackers. The board that Dennis used is not available anymore but you can buy FPGAs for tens of dollars and even boards at cheap prices.

So to test your databases passwords for 8 characters length you could do it now with custom hardware and it should not be vastly expensive. With more money longer passwords could be tested reasonably thoroughly with FPGA based hardware or software and arrays of fast PCs.

Of course its simpler and cheaper to expire every password and to ensure profiles are added to every account and that they are enforced - i.e if a profile is changed or dropped or removed from an account the password must be expired. In this way with good design of the profile and verify function we can enforce long and strong passwords that can be tested (the password is known at change time) where its not practical to brute force. i.e. if you enforce a 15 character password brute force takes way too long so you can never verify easily after its set that a password is strong BUT with good profile design we can.

We also should ensure that password hashes are not available to anyone; user$, userhistyr$, other views, exports, strings on the data files, backups...... if the hashes are not available then its harder to crack passwords.

Also you should use case sensitive passwords and set the SQL*Net settings to enforce only the later protocols. This means that a hackers character space for brute forcing passwords has increased to include Capital letters and also symbols making it harder to crack passwords. Therefore we also must use case sensitive passwords and symbols to prevent simple cracking

So we should be aware of hardware options and tools and even software crackers but we should design our passwords and enforce them at setting time and also protect hashes and also use the lastest features and remove the older hashes.

Anyway I ordered an FPGA development board to have a play with it. It uses a Spartan-6 chip and I plan to have a play an understand how easy it is to program an FPGA nowadays and make something with software in hardware that runs software!!!