January 25, 2007

ُSniffing RDBMS authentications : Oracle Case

Back to the date I was trying to learn basic concepts of Oracle , I`ve always been curious about process of authentications and they way Oracle take care of them . My background about authentication mechanism in MS-SQL , MySQL and DB2 was not much useful since Oracle was using it`s own proprietary remote auth. mechanisms . Other RDBMS systems had their specific mechanisms too , but non of them were as complex as Oracle`s implementation. As you may already know , MS-SQL simply foil hash of used password into TDS protocol and send it over network . since TDS is a clear-text protocol , all you`ve to to do is to grab hash values out of auth. packets , decode it and feed your password-cracker with hex value . In MySQL case , all you`ve to do is extraxt SHA/MS5 hash valuse out of packets sent while authentication between MySQL and client. again , the hard part is cracking hash which is not what I`m going to talk about. CAIN is one of tens of tools out there for playing with MS-SQL or MySQL. Finally in DB2 case , we`re dealing only with simple tricks . DB2 does not truly transfer any hash value , but encode whole packets transmitted while authentication process with EBCDIC standard rather than ASCII encode. This simple trick wasted many hours of my time , trying to figure out what are these values DB2 send in middle of authentication . After I finally discovered it`s simply just another encoding , used in middle of ASCII encodes I was like a dumb looking at hex values of clear-text username and password in packet ! I`m not sure how many people have been tricked this way , but Litchfield demystified it very well on chapter 6 of "The Database Hacker`s Handbook" . Of course I could not wait more than two years in middle of my tests , so somebody publish a book about the topic !
Back to our subject , we see that sniffing RDBMS authentications and dumping user/passwords from network traffic , in most of cases is just about identifying clear-text or hash value of passwords . In Oracle however , this process is a bit more complex due to mechanism used . While playing with Oracle and trying to figure out how it transmit passwords over network , I noticed that Oracle strangely switch connections to a high-port and continue the process there . again nothing was in clear-text nor in a usual manner . checking public resources & Oracle documentations could not help since Oracle seems decided not to release any information about it . After multiple tries to query public lists for answer nothing leaked out , until DBSec mailing list have been founded y NGSoftware researchers lead by D.Litchfield again . I shoot my old spam to this new list again , and wow , after a while I had finally the answer . David`s answer is clear enough so I`m not going to rewrite it here ,but any questions are welcome . What he replayed me is actually part of his upcoming book which will be available at end of this month . This post to mailing list later have been mentioned in NGSSoftware`s new paper about Oracle Passwords and now seems it`s the only FAQ about the topic over net , so I decided to mention it here again .
Of course this is not the ultimate answer ( while solving the mystery ) but provided information and PoC , is enough for developing first brand new Oracle password sniffer which is my plan to do in future. Referring to my past blog post , Oracle servers are considered as heart of most of targets we may face with in a assessment or penetration-test . While playing with a server running any version of Oracle , you can be sure that even a strictly limited user will lead to full compromise of server and informations , and that`s because we`ve called Oracle "Enteprise-Bug" before this ;)
Btw , Litchfield`s new book on Oracle security will be out in few days . have you pre-ordered it ? :)

[updated 01 February 2007]

I noticed that this topic has been covered some where else , before D.Litchfield discuss it in details. Pete Finnigan has updated his blog and there you can find more about the first real discussion about this topic. how ever in the old paper mentioned by Finnigan there are no details focused on password stealing . seems this has been an old known flaw in oracle protocol which was researched more in depth by Litchfield.

January 24, 2007

سه قدم اساسی در بهبود امنیت اوراکل

در طی چند سال اخیر بدلیل شرایط شغلی فرصت بررسی بسیاری از شبکه های عملیاتی کشور از جمله ارگانهای دولتی ، خصوصی و بسیاری از سازمان های تابعه آنها را از نزدیک داشتم .
تقریبآ در همه موارد بررسی شده در این مدت یکسری نقاط آسییب پذیر در میان همه این شبکه ها وجود داشت: بانک های اطلاعاتی ، اگرچه در برخی موارد هدف بررسی صرفآ بانکهای اطلاعاتی نبوده ، اما نمیبایست هرگز آنها را نادیده گرفت و بطور غیر مستقیم همواره با آنها در ارتباط هسیتم.

در اکثر شبکه های عملیاتی که کاربران آن با حجم زیاد داده ها سر و کار دارند و یا درحال استفاده از نرم افزارهایی همچون سیستم های اتوماسیون اداری هستند ، بانک اطلاعاتی اوراکل بعنوان یک سیستم مورد اعتماد ( و البته ناشناخته و پیچیده از دید بسیاری از مدیران ) در حال سرویس دهی به شبکه میباشند . با توجه به نیاز به تخصص برای مدیریت اوراکل , بسیاری از مدیران بانک های اطلاعاتی ما تنها از مبانی ضروری و اولیه کاری خود مطلع هستند و کمتر مدیر بانک اطلاعاتی ایرانی را دیده ام که علاوه بر بحث مدیرت خود بانک اطلاعاتی ، به بحث امنیت آن نیز تسلط کافی و لازم را داشته باشد. با توجه به اینکه قلب اطلاعاتی بسیاری از سیستم های IT در کشور بر پایه بانک های اطلاعاتی اوراکل میباشند , این عدم آگاهی میتواند بسیار خطرساز و مهلک باشد . البته مایه بسی خشنودیست که بدلیل همین عدم وجود اطلاعات کافی و نبودن تسلط لازم , بسیاری از نفوذگران داخلی نیز به راحتی از کنار این دروازه های طلایی نفوذ به شبکه میگذرند و آنها را نادیده میگیرند.

به همین دلیل تصمیم گرفتم تا در این بلاگ , هر از چند گاهی در این مورد مطالبی را منتشر کنم تا مدیران بانک های اطلاعاتی با مراجعه به آن بتوانند حداقل کار ممکن را برای بالاتر بردن سطح امنیت سیستم های خود بانجام رسانند . در ادامه بطور خلاصه به توضیح یکی از اولین قدم های بررسی امنیت اوراکل ، و روش های بهبود آن اشاره خواهم کرد.

همانطور که میدانیم , سیستم اوراکل از چند بخش مجزای عملیاتی تشکیل شده که Listener و ساختار مدیرت و کنترل بانک های اطلاعاتی دو مورد اصلی آن میباشند . در سیستم عامل لینوکس هر بخش تحت پروسه جداگانه ایی اجرا و کنترل میگردد اما در ویندور ، تقریبآ تمام بخش های اصلی اوراکل تحت پروسه هایی مشترک اجرا میگردند . سرویس Listener اوراکل که بطور پیشفرض بر روی پورت TCP/1521 سرویس دهی مکند ، در واقع یکی از مدخل های اصلی ورود به بانک اطلاعاتی و دسترسی به آن از طریق شبکه میباشد . همانند سایر سیستم های RDBMS اوراکل نیز از روش های مختلفی برای کنترل دسترسی به این سرویس را در اختیار میگذارد که رایج ترین آن همان کلمات عبور میباشند . همچنین از طریق سرویس Listener اطلاعات و قابلیت های کنترلی دیگری نیز در دسترس میباشد . بطور مثال شما قادر خواهید بود که از طریق ارسال درخواست ها و دستورات مشخص ، اطلاعات دقیق مربوط به سیستم عامل و نسخه آن , نسخه بانک اطلاعاتی , نام Instance های موجود و بسیاری موارد دیگر را دریافت کنید . علاوه بر این شما میتوانید به سادگی خود سرویس Listener را کنترل نمایید و بطور مثال آنرا غیرفعال نمایید .

همچنین یک کاربر غیرمجاز میتواند با اتصال به سرویس Listener اقدام به سعی در کشف نام های بانک های اطلاعاتی , نام کاربران تعریف شده اوراکل و حدس زدن کلمات عبور آنها نماید ، که با درنظر گرفتن بیش از 90 نام کاربر پیش فرض اوراکل ، این عمل در اغلب موارد موفقیت آمیز خواهد بود و منجر به فراهم شدن دسترسی غیر مجاز به اوراکل خواهد شد.

نکته اینجاست که بطور پیشفرض شما قادر به انجام همه موارد فوق بدون در اختیار داشتن هرگونه نام کاربری یا دسترسی مجاز به سیستم خواهید بود . در نگاه اول شاید دانستن اطلاعات فوق مهم بنظر نرسد و تنها نکته حساس از دید مدیر بانک اطلاعاتی , غیرفعال شدن سرویس Listener باشد . اما جالب اینجاست که همین موارد بسیار ابتدایی و عدم کننرل دسترسی صحیح به آنها در صورت وجود , امکان نفوذ به بیش از 90% بانک های اطلاعاتی را فراهم میکنند ! پس موضوع جدیست .

حال چگونه میتوان این خطر را کاهش داد و از وقوع حملات از این طریق جلوگیری کرد ؟

قدم اول : مشخص کردن پسورد برای دسترسی به سرویس Listener

این کار بسیار بسیار ساده در واقع مهم ترین و اولین قدم در امن سازی اوراکل میاشد . تمام موارد خطری که در بالا به آن اشاره شد به این دلیل وجود دارد که اوراکل بطور پیشفرض هیچ محدودیتی برای دسترسی به Listener در نظر نمیگیرد پس هر کاربری قادر به استفاده از اطلاعات آن خواهد بود . روش پیشگیری از آن ، به سادگی ست کردن یک پسورد برای Listener میباشد . پس از اینکار اوراکل تنها در صورتی امکان اتصال به بانک اطلاعاتی را خواهد داد که کاربر رمزعبور صحیح برای استفاده از امکانات Listener را داشته باشد. همچنین نفوذگر احتمالی برای انجام حملات کشف نام های کاربری و کلمات عبور میبایست ابتدا اقدام به حدس زدن پسورد Listener نماید و در صورت موفقیت در این مرحله قادر به ادامه کار خواهد بود.

روش ست کردن رمز عبور برای Listener بصورت زیر میباشد که توسط ابزار LSNRCTL انجام میشود :

این عمل بهتر است همیشه توسط ابزار LSNRCTL انجام شود اگرچه امکان تغییر فابل listener.ora بصورت دستی نیز وجود دارد . اما مزیت استفاده از LSNRCTL ، دخیره شدن کلمه عبور شما در فایل بصورت کد شده است.

قدم دوم : محدود کردن دسترسی های Administration سرویس Listener

همانطور که گفته شد ، در صورت امکان دسترسی به سرویس Listener علاوه بر روش های استخراج اطلاعات , امکان کنترل خود سرویس نیز وجود دارد. ممکن است شما به هر دلیلی نیاز به یک Listener فاقد پسورد داشته باشید ( این یک مورد نادر و خاص است , پس در صورتی که مطمئن نیستید به آن احتیاج دارید , حتمآ قدم آول را دنبال کنید ! ) , اما شما باز هم قادر به محدود کردن دسترسی به امکانات سرویس خواهید بود . این کار توسط فعال کردن _محدودیت دسترسی Administration _ انجام میشود .

برای انجام آن کافیست به فایل listener.ora مربوطه مراجعه کرده و پارامتر را مانند مثال زیر تغییر دهیم یا در صورت عدم وجود آنرادرج کنیم :

ADMIN_RESTRICTION_{listener name} = ON

پس از اینکار کلیه پارامترها و دستورات SET مربوط به Listener غیرفعال خواهند شد و چه بصورت محلی و یا تحت شبکه امکان استفاده از آنها وجود ندارد. بلکه هر تغییری میباسیت مستفیمآ در فابل listener.ora مربوطه اعمال گردد. پس از این تغیررات , برای اعمال آنها نیاز به راه اندازی مجدد سرویس Listener میباشد. میتوان از دستور RELOAD ( و یا STOP و START ) ابزار LSNRCTL برای این منظور استفاده کرد.

در نسخه 10g ، امکان جدیدی بنام LOCAL_OS_AUTHENTICATION اظافه شده که بطور پیشفرض فعال میباشد . این امکان اگرچه دسترسی به امکانات administration را از طریق شبکه محدود کرده , اما این دسترسی ها از طریق محلی هنوز وجود دارند و امکان استفاده از پارامترهای SET میسر است.

قدم سوم : فعال کردن قابلیت Logging سروریس Listener

این کار به شما امکان بازرسی ومشاهده دسترسی ها و ارتباطات با سرویس Listener را میدهد که بطور مثال برای تشخیص و پیگیری حملاتی که از طریق Listener صورت میپذیرد و در بالا به آن اشاره شد بسیار مهم میباشد. در ادامه نحوه فعال کردن log سرویس Listener عنوان شده :

با پیاده سازی سه قدم فوق ، شما موفق شده اید تا حد بسیار زیادی از تفوذ به اوراکل از طریق سرویس Listener و تحت شبکه جلوگیری نمایید . گرچه موارد ذکر شده به تنهایی کافی نیستند و موارد زیادی برای بررسی و کنترل وجود دارند ، اما اینها سه قدمی هستند که هر مدیر بانک اطلاعاتی _باید_ در اولین فرصت در موردشان اقدام کند.

January 23, 2007

Enteprise-Bug 10G R2

I remember a chat with one of my friends back in 2001, about ultimate secure design of MS operating systems and various ways an MS product can be owned by talented intruders. Those days I had very low level of knowledge about security mechanism and attacks against data-base systems . anyway we agreed to call MS windows 2000 'Enterprise-Bug 2000' . I`m sure you`ll confirm us about the term we selected !
Some time later I focused on DB systems and learned cool tricks about attacking & securing them . but the more I learned about DB-Sec the more I found it funny. years ago AKA good old days it was not that shocking if you could find a critical remote pre-auth vulnerability in one of those giant softwares like MS-SQL by simple fuzzing of user supplied data , as D.Litchfield did it multiple times . After a while developers learned to replace strcpy with it`s secure clone and define size of their buffers before any fuzzer fill them with a 0x41 storm. Nowadays it`s rare to find cool things by targeting old techniques against well-developed softwares . In order to find something interesting you must be that experienced to dive into your debugger and follow thousands of instructions in order to catch something . as a result , number of people being able to hunt down something cool is getting lower and lower . well , this story match many of well-known vendors but NOT ORACLE .
I`m not going to judge their product but I just follow my own samples . years ago while ORACLE was as insecure as MS-SQL, DB2 and others we had some known attack vectors exist in any RDBMS out there , including simple buffer overflows , privilege escalation attacks due to weak permissions , abusing design-flaws and finally PL/SQL injections . In about 5 years ( assuming MS-SQL 2000 SP0~3 as source of comparison ) most of vendors learned how to mitigate such attack vectors and we had much lower amount of advisories affecting RDBMS products by use of mentioned attack vectors . for example , try to find first and last reported PL/SQL injection attacks or even buffer oveflows in stored procedures of MS-SQL , or another RDBMS . As you may notice some of these attack vectors are getting disappear in recent versions . Now let`s turn back to Oracle ; comparing results . No matter which attack vector you choose for comparison you`ll see that every single trick of attacking oracle is used repeatedly since it`s first public discloser , to discover new flaws ! it may look funny but it`s real . Try to check it yourself by following examples :

-Try to google first and last reported flaws in Oracle , in class of PL/SQL injection , sort PoCs together and compare them. funny huh ? you`ll see techniques demonstrated back in 2002 still affecting 2007 version of product ! nothing new in term of technique or attack vector . bug just moved from line X of code to line Y . recent Milw0rm submissions (1,2,3) are just some more samples of OLD tricks.

-Again , try to google first and last reported buffer-overflow attacks against Oracle stored procedures . same results as above !

And we have these results ,considering Oracle have tried to massively audit their codes TWO times . Most of RDBMS vendors out there learned the lesson but Oracle is still getting hurted by any medium-level knowledged person , have few hours to spend with his 10g . If you think you`re free too , why not giving it a try?
I remember an interview with RED-Database-Security CEO , announcing more than 800 unpatched flaws in Oracle products , discovered by many security firms and individual researchers.
btw , Litchfield recently released a paper about comparing MS-SQL and Oracle by number of reported vulnerabilities reported for each one . I bet you can guess the result without reading it ;)

Now, Will you let me call ORACLE the 'Enterprise-Bug' and let MS rest for a while ?

January 21, 2007

MO?B (Month of ??? Bugs)

Probably you`ve followed MOBB project launched by H.D.Moor and other Metasploit members and I believe that was an interesting and fresh idea in community , to focus on a specific class of applications and vulnerabilities and making vendors securing their buggy development life-cycles , while keeping the joy of Full-Discloser policy .

After H.D some other researchers followed this new way and we saw MOKB by info-pull guys , as second successful attempt . Argeniss co. tried to be third in this game , by offering WOOB but for some reasons it never began . I`m not going to explain why this project stopped . MOAB began once again by support of info-pull geeks as fourth effort and it`s still undergoing . Finally we`ve MOWAB ahead as fifth child of Moor`s idea . Although MOWAB seems not so scheduled MO*B like others but we still hope to see cool outputs from SNOSOFT crew.

After 5 of them been announced and released , I guess still many people have not realized the goal behind of these Months . As a simple sentence we may explain them "30 days dedicated to publish 30 advisories serially about specific range of applications " . But is it all about hunting 30 PoC included bugs packing and releasing ? I think the true goal behind every Month is to research and develop new technologies and methodologies for auditing specific group of codes/applications . Moor was fair successful proving this , by developing and releasing new fuzzers and codes as GENERAL web-browser auditing tools . while MOBB finished we`re not left with only 30 bugs but tons of new tricks to audit , hunt and exploit flaws in a web-browser software . moving to MOKB we can see this again , but much more limited than MOBB . As a result of MOKB we have single and case-specific file-system fuzzer beside 30 hunted flaws , most of them not even demonstrated to show techniques behind finding and exploiting them. not much long-term usable output . MOKB finished and we got 30 hunted bugs , but no methodology nor demonstrated technique about how to continue if you want more than 30 flaws . Finally we are following MOAB , showing us how to exploit every single flaw , which means experiencing at least few new sample of less-explained techniques on exploiting flaws. even if no new technique is demonstrated , we still have 30 real-world samples on how to break latest Mac OS-X which is under focus these days .
So now I know why some of these Months become popular and some of them just simply finish. If we learn new things we`ll call them interesting and if it's just 30 blindly hunted flaws (although some of them may be cool ) we will forget that Month as soon as next one begin.
We can talk about Months of Bugs from another point of view too . skipping technical details behind any of them and talking as a end-user of software , every Month of Bug can move our daily used codes , softwares and OS more close to a secure one . At least low hanging fruits may get hunted during the month and we can sleep well at night ,dreaming not every kid and his pet can find the flaw and abuse it against us...

Now fill in the blank :
-Next Month of Bugs will be about ..... ?


January 20, 2007

Once again...

"Hey , what`s going on ? Again another new idle blog ? "

That may be reaction of many people while visiting this place at first time. Frankly they could be right . this is my 'Yet Another Blog' attempt trying to document my brain cells . But I guess this time I`m on new way . almost all previous blogs & forums I wrote in (weblog.websecurity.ir , neominds.org , shabgard , ... ) were my friends corners or something NOT belong to myself . Although I think I`ve posted very few junks in them but after all , non of them were the place I could feel comfortable within.Finally after multiple 'create blog , keep it idle , take it down' attempts , I guess I`m ready to go with stable one .

I`m not sure which topics will fill it but, as most of my life is about computers, networking and information security I guess my upcoming posts will be about my daily tasks and interests but I won`t guarantee not to post funny topics , junks or even personal aspects of my life . I`m not sure about the language I`ll write in too! hey don`t worry I speak only Persian & English .depending on the content of post I may decide to publish it for all or Iranian visitors .