Microsoft JET Database Code Injection

After doing a penetration test for a client, I discovered that the site was vulnerable to code injection. I was able to run scripts (vbscript, jscript, asp) in the context of the server. After recoding the filtering mechanisms to look for characters like ' " ; < > ( ), everything seemed fine except for one thing. A certain sequence of characters repeated a certain number of times produces an SQL error message. This isn't good, It plainly shows that the site is still vulnerable. I'm at a complete loss to explain it. I know their is syntax differences between SQL and Microsofts Jet Database implementations in regards to XSS and code injection, but I can't find any resources on this anywhere. So if anyone knows anything about this, please let me know. Thanks...

Can you post some (partial) code? That may give us an idea...

I'm guessing they're running on IIS; should be easy to configure the server not to give out an exact error message and replace it with something less informative (from an attackers point of view).

Also a bit of error detection in the code not only makes the code more "solid" but it can also prevent these error messages.

I've seen it happen before. They [developers] write some code that makes a connection to a database. The object returned will be used without testing if this object actually got created. The code will run fine.......until the day the database isn't available (for whatever reason). Then it throws up some error message with way to much info in it. If they checked to see if the object really existed they could have created a more 'sanatized' and meaningful (to the user) error message.

Thanks for the reply...What you are saying is completely solid, Jet Database error reporting can be configured to not display this behavior. After testing is complete I have every intention of turning it off, it is a HUGH security risk by giving way to much info. After reading your reply I rewrote my code to trap all errors (Including looking for nonexistant objects) not just the one's I was expecting. That was really good advice, thank you...

Even though my routine is secure by catching the behavior I mentioned in my previous post, It still happens and I'm curious why? I'd really like to find some info on 'Microsoft JET Database code injection'. I know there are major differences between injection methods for SQL and JET,
but can't seem to find any references.

I hope, your first "problem" was solved using SirDice's advice.
To your second request - information about

Quote:

---

differences between injection methods for SQL and JET

---

As you say, it's not easy to get such specific information.
The only differences known to me are dealing with various delimiters,
eg. in JET, dates can be delimited with the '#' character. Some additional
information might be found in [1] and references therein.

Since my personal archive is full of general SQL injection papers,
but none of them specific to JET, I also would appreciate any additional
material. You also might check (older) material dealing with the MS
exchange server.


[1] http://www.giac.org/practical/GSEC/Phil_Janzen_GSEC.pdf

After doing a little googling (Almost 2 days worth...), I was able to find the information I needed. Code injection information regarding JET is really hard to find. However, from what I was able to discover, it's not as much of an issue as with SQL. This is largly because of the way JET handles multiple statments in a line. It DoSenT! In SQL, once the filtering mechanisms are broken (Usually by using ' followed by other characters, depending on situation) additional statements are easily appended using (;). This behavior is not present in JET. Although this seems to harden' querys from attack, it limits legitamite uses as well. JET really has no security mechanisms of it's own, but tends to rely on 'Data Access Objects' for this. Querying specific databases is possible using the 'in' statement in ways not possible in SQL. BLAH BLAH BLAH BLAH...

Since, Microsoft decided to phase JET out in late 2002 / early 2003 (As long as Access is around they will support it, but not add any new enhancements or functionality) and push for it's replacment by MSDE...BLAH BLAH BLAH...Nobody really seems to care about JET anymore.

As for my original post: I have trapped the error and it's not a security issue anymore. I'll just have to accept the fact that I can't explain it (It's that or break out the dissassembler...,But I don't think i'll be doing that anytime soon). I'm really tired of JET now...

On a more upbeat note: If anyone has any questions about XSS filters in JET I bet I can answer 'em now...

Quote:

---

If anyone has any questions about XSS filters in JET I bet I can answer 'em now...

---

I bet so ;)
Can you publish some references with details?

Tx.

What i've learned has been pieced together from various sources. Sadly, I didn't take many notes when I was researching, but the links I did write down are listed below.

www.sjsoft.com/docs/jworkbook/sqlreference.htm
Command syntax and using specific to JET. Not very comprehensive.

http://www.compcomgrp.com/downloads/...rReference.doc
Good reference for gathering information about the system from error messages. Also www.technicalinfo.net" has a good paper on using this technique. Although it is not specific
to JET. Use inconjection with previous link to adapt the technique to JET.

dbforums.com has some good general JET stuff.

I know my references aren't very comprehensive, but by the second day of looking for info I was in kinda a mad, frenzy, search mode and didn't really think about references...I just kinda learned the stuff I needed and forgot the rest.

Tx anyway. Always good to have some refs handy.