Confessions Of A Dangerous Mind

As a passion, I keep developing my side projects and different concepts that always were of interest to me, and during that process I have always had to build input validation tools to overcome threats like SQL Injection or XSS etc. or even just to make sure that a user enters just the input type that i require of him.

That being said, I knew that it was easier to just build a simple framework that will retrieve both valid type input schemes to validate inputs against them , and also to build a simple yet robust signature matching engine that will help me build one framework that is dynamic and that i can include in any project that is built. Finally I decided to just release it to everyone who may find a use for it, and named it JSecurityModule.

Enjoy.

Labels: code, english, java

Posted by barry at 11:30 PM | Link | Comments

לאלו מכם שעוסקים בתחום אבטחת אפליקציות , או אלו מכם שעוסקים בפיתוח אפליקציות WEB שונות וודאי נתקלתם לא פעם בשאלות לגבי COOKIES שונים אשר קיימים באתרים השונים אליהם אתם ניגשים או מפתחים.

אני מקבל לא מעט שאלות לגבי עוגיות מאוד ספציפיות -עוגיות ה utm שמופיעות תמיד כ :

__utma , __utmb , __utmc , __utmv , __utmz

מדובר למעשה בעוגיות של מנגנון ה Google Analytics של גוגל. למי שאינו מכיר - מנגנון זה הינו מנגנון סטטיסטיקות ומעקב אחרי התנהגות גולשים באתרי אינטרנט אשר ניתן על ידי גוגל.

בכדי להבין את משמעות העוגיות הללו , אפרט את תפקידיהן :

utma

עוגיה זו הינה עוגיה מזן Persistant עם תאריך תפוגה של 2038 . מטרתה היא בעצם לספור את מספר החזרות של משתמש מסויים לאתר, ולכן בפעם הראשונה שניכנס לאתר נקבל SET לעוגיה , ומשם ואילך תמיד יגדל הערך בכל חזרה לאתר.

utmb + utmc

עוגיות אלו עובדות במשותף בכדי לדגום זמן שהיה באתר - כאשר utmb לוקחת SIMESTAMP של זמן הכניסה , וutmc מקבלת TIMESTAMP של זמן סיום הSESSION , או EXPIRATION. ולמעשה משמשות לשם אותן פונקציות ניתוח.

utmv

משמש עבור מערכת הדוחות של Google Analytics , למעשה אם הוגדרו סגמנטציות מסויימות או כל מבנה של חלוקת הדוח על פי התפלחות מסויימת של המשתמשים , המידע הסטטיסטי נאסף באמצעות עוגיה זו.

utmz

עוגיה זו שומרת על REFERRER ועל SOURCE URL שהפנה לאתר , עוגיה זו חיה במשך עד 6 חודשים. מטרתה בעצם לעזור לגוגל לדעת מי המקורות המפנים לאתר, ומקושרת למנגנון הניתוח שלהם לתעבורה ולהבנה ליעילות של KEYWORDS או כל קטגוריה אחרת.

נעבור לסיכונים

מה שחשוב להבין בסופו של יום , הוא שמבחינת פונקציונליות של האתר , אין כל קשר בין העוגיות הללו לבין המנגנון מאחורי האתר , כי הן משמשות מנגנון אשר אינו קשור לאופן הפעולה של האתר... לצורך העניין אם ב Web Application Firewall עסקינן , ניתן בהחלט להכניס את העוגיות הללו ל Ignore משכבת ההגנה , מבלי לחשוש לפגיעה באתר עצמו, ושימו לב - אני מתכוון רק לאתר עצמו..

יש להבין שהמידע בעוגיות אלו יכול להשפיע אם מישהו יבצע TAMPERING או INJECTION על מנגנון הURCHIN של גוגל , ובעצם הנזק הפוטנציאלי הקיים למנגנון ניתוח האתר יכול לעלות לנו בכסף. כי אם למשל אני מזריק לUTMC ערך הגדול ב10 ימים מUTMB , וכמו כן מכניס לUTMZ קישורים לגוגל עם מילות חיפוש לא נכונת .. ואני מבצע זאת על ידי מניפולציה על גבי מספר רב של מחשבים - אפשר פוטנציאלית לפגוע באמינות המידע שאנו מקבלים מהמערכת ולגרום לבעל האתר להשקיע משאבים וכסף במקום לא רלוונטי.

אם למשל הזרקתי לאלפי עוגיות ( גם בשימוש מקומי SPOOFED ) מילת חיפוש , נניח XYZ ... בעל האתר יבחין שהמילה XYZ כביכול מביאה אליו יותר נפח תעבורה - ואולי יבחר לשלם עבור השימוש בה לגוגל כדי להופיע בראש רשימות החיפוש וכדומה ... כמו גם למפרסמים באותו אתר. כנגזרת מכך אפשר להבין שהמניפולציה הפוטנציאלית לעוגיות אלו עלולה לפגוע בבעל האתר בצורה עקיפה.

דרך אחת למנוע התקפות כאלה היא על ידי הגנה כנגד COOKIE INJECTION. הגנה מסוג זה בנויה בעצם על מעקב אחרי פקודות SET של COOKIE בדרך כלל. הכוונה היא שמערכת שאמורה לשבת בין המשתמש לבין האתר מצפה לראות קודם SET לCOOKIE על ידי השרת, אם לא היה כזה SET - העוגיה הוכנסה באופן מלאכותי.

דרך שניה, על ידי COOKIE SIGNING ניתן לוודא שאכן העוגיה מכילה מה שהSETTER התכוון כאשר בנה אותה , ולא שובשו ערכים ( יעיל יותר מANTI-TAMPERING למיניהם , לפי דעתי ).

עוד מידע לגבי מנגנון הGoogle Analytics ניתן לקרוא בספרות הבאה :

Advanced Web Metrics With Google Analytics - Bryan Clifton

Google Analytics 2.0 - Jerri L. Ledford and Mary E. Tyler

Google Analytics Shortcuts - Justin Cutroni

Labels: architecture, code, cookies, imperva, privacy

Posted by barry at 1:15 PM | Link | Comments

אני אוהב לדבר על מערכות ניתוח תעבורה , ניתוח השכבות ופירוק האפליקציה והפרוטוקולים לגורמים תמיד ריתקו אותי ונתנו לי נופך לעבודתי במרוצת השנים. ועם הכל די התמחיתי בכלי ניתוח התעבורה השונים אשר התחילו מבדיקות RFC למערכות IPS מתוחכמות מבוססות אנומאליה\חתימות דרך אנטיוירוסים רשתיים וכלה כמובן במערכות ניתוח תעבורה לשכבות האפליקציה .

אחד הדברים שתמיד הפתיעו אותי הוא התפיסה הרווחת ( והמוטעית ) אשר אומרת שניתן לחסום SQL Injection במערכות IPS או מערכות FW מתקדמות עם מנגנוני חתימות. ואני כמובן מוחה.

התפיסה היא שעל ידי חיפוש של מחרוזות גנריות בתוך שאילתות HTTP למיניהן , ניתן לאתר את כל\רוב סוגי התקפות הSQL השונות. אך האם כך הדבר ?

משפט SQL הוא משפט אשר עובר Parsing מסויים ולבסוף מעובד על ידי מנגנוני קלט אשר בודקים את תקינותו מבחינת Syntax וקישורו לאובייקטים קיימים בDB , על אותה רגל - משפט SQL Injection יהיה לעולם משפט אשר מנסה לקיים תנאי TRUE. על ידי כך במידה ויש התאמה לתנאי , השאילתה אשר מפיק משפט הSQL תרוץ על השרת...

ואם מדובר במשפטי TRUE ... אז משפט כמו 1=1 הוא נכון , וגם a=a הוא נכון , וגם 100<999 הוא נכון וכן הלאה ... כלומר במילים אחרות --> לא ניתן לייצר חתימה אשר תתפוס כל SQL Injection אלא את הבסיסיים בלבד.

או אולי , לפי הקונספט של לחפש את תווי הגרש ( ' ) בתוך מחרוזת ... והאם השמות "ג'ק" או "ג'ון" אינם שמות הגיוניים ? מובן שכן, ומתוך תפיסה חתימתית - לא יהיה ניתן להזין שמות כאלו לדף מאחורי IPS חתימתי שכזה ...

Labels: code, consulting, hacking, imperva, sql, threats

Posted by barry at 11:24 PM | Link | Comments

As some of you may already know , one of my biggest and oldest hobbies is linux.

As such , the first thing i will try with almost any computer \ laptop \ device i get - is to try a linux distro on it , and test it for playfulness . but most of the times , these computers are not mine , so its kind of helping guys out on the way.

This past week , ive been asked with a question by a collegue of mine , and that is actually a question that i get alot regarding wireless hacking with a linux box. the question is "how do i set my wifi card to Promiscuous Mode ?" which is something many new guys on a linux platform find hard to achive. and it is a very important knowledge for anyone in the Pentesting field , or if its a "hobbie".

The reason for that is preety simple... when you want to use your card for packet injection , and sniffing - you need to put it on a passive mode. this moe is called "Monitor-Mode" when refering to linux. after you do that - you can usually fire up any wireless hacking \ sniffing program that you want.

The problem is that on some cases , trying to set up the card to Monitor Mode by issuing the command : iwconfig ath0 mode Monitor , will result in an "Invalid Input" or a "Set Mode (8B06)" message on your screen. and any attempt to change that will not be succesful, even if you use patched drivers ( like MadWifi ) and such.

The solution to that is quite simple actually. use the wlanconfig tool.

In order to change the card's mode to the desired one , first of all - put it to sleep by issuing the command ifconfig ath0 down ( ath0 stands for the interface's name ). then use the wlanconfig tool by issuing the following commands :

wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode monitor
ifconfig ath0 up

Thats it. your card is now in Monitor Mode.

In order to put the card to the original state , repeat this sequence of commands, but instead of choosing the wlanmode monitor , choose wlanmode managed.

Hope this short guide was helpful.

Labels: code, english, hacking, linux

Posted by barry at 3:17 PM | Link | Comments

אני מניח שחלק גדול מאיתנו מכיר את ההתקפה בצורה כזו או אחרת מבחינת דרכים ליישום או סוגי התקפות שונים ודרכים להתגונן מפניהן. אך רובנו איננו מודעים לחלק החשוב שעומד מאחורי התקפות אלו , והוא מגבלות הI/O של מערכות מחשב , ומבני נתונים פגומים אשר מאפשרים להתקפות אלו להתבצע.

למעשה, המטרה בהתקפה זו , היא לגרום לקטע קוד זדוני, לעבוד תחת מערכת נתונים המוגדרת Priveledged מבחינת הרשאות הגישה שלה ( להתקפות שאינן מוטות Kernel אין צורך בגישה שכזו ) כשלמעשה המטרה שלנו כאן היא ליצור מגע עם זיכרון שכבר הוקצה למערכת ואושר על ידי מערכות הHIPS או הAV לפעולה, להשתיל קוד זדוני מבלי שיתגלה , ולהפעיל אותו.

התקפות Buffer Overflow מתבססות בחלקן ( במקרה זה לדוגמא ) על מבני הנתונים השונים המוקצים במערכת , למשל Heap או Stack שהם הנפוצים ביותר , ולגרום להם לפתוח לנו חלון להכנסת מידע.

זה קורה באופן הבא [ בפישוט ] :

כאשר תוכנה מדברת עם מערכת הזיכרון במחשב, היא מדווחת על הפעולה שאותה בכוונתה לבצע לפני כל ביצוע של פעולה שכזו . כלומר - אם המערכת מעוניינת כעת לקרוא 9 בתים מהזיכרון - היא מדווחת על כך שהיא עומדת לקרוא 9 בתים - מה שמאפשר למערכת בקרת הזיכרון לשלוף את אותם נתונים לקריאה. המערכת גם יודעת לדווח שהיא עומדת לכתוב , למשל לכתוב 4 בתים.

כאשר מערכת ניהול הזיכרון מתבקשת לאפשר כתיבת 4 בתים , היא מחזירה נקודת זיכרון במערכת אשר אליה ניתן לכתוב. מה הרעיון ... במצב שבו אנו רוצים לתקוף את תאי הזיכרון ולהכניס מידע משלנו לזיכרון , ניתן לדווח בדיוק כך שאנו רוצים לכתוב 4 בתים , אך בפועל לכתוב 20 בתים.

המערכת אינה מודעת כך , אך דרסנו מקטע זיכרון וכתבנו קטע משלנו אשר יכול להכיל תוכנית או הפניה לתוכנית. ומאחר והתוכנית שרצה כבר קיבלה הקצאת זיכרון , ומערכות האבטחה אישרו את ההקצאה - הן לא יגיבו לכך ולא יציפו התראה.

אגב, רוב מערכות אבטחת המידע מגיבות בדרך דומה כאשר הן מזהות התקפה זו ( למשל על ידי מיפוי הזיכרון והשוואה של כתיבה מול קריאה ) ומזהים קוד זדוני שנכנס לזיכרון - הן פשוט מבצעות למחשב RESET.

Labels: code, hacking, threats, vulnerability

Posted by barry at 2:06 PM | Link | Comments

לפני מספר חודשים כתבתי עבור חודש XSS של גיא מזרחי כלי פשוט יחסית , שמטרתו הייתה בעצם להמיר מחרוזות פשוטות לדצימלי , ובכך לאפשר לבנות מחרוזות להתקפת XSS בצורה קלה יותר...

מספר אנשים פנו וביקשו את הקוד הפשוט יחסית , ובכן שיניתי מספר דברים בעקבות מיילים ותגובות בכל מיני מקומות שונים , כדי לפשט. הנה זה פשוטו כמשמעו ... כפי שוודאי ניתן להביא מדובר סה"כ בהמרות מהקסה למבנה דצימלי ובחזרה , כעת כבר לכל המחרוזת , שינוי שבוצע בעקבות בקשות במיילים.

ישנם ממירים רבים להורדה באינטרנט , חלקם אפילו נכתבו על ידי RSnake בכבודו ובעצמו, אך מי שמכיר אותי יודע שאם זה לא יצא מהידיים שלי , זה אומר שאני לא ממשיך הלאה לנושא הבא ...

הנה הקוד הסופי ... .NET כמו שאתם אוהבים .

For my english reading audience - this is my code for converting text into decimal codes for applying XSS attacks , in .NET for your convinence. enjoy ...

Public Class XSS_Translator

    Public Function hex2dec(ByVal hextext As String) As String
        hex2dec = Chr(Convert.ToInt32(Mid(hextext, 2, 2), 16))
    End Function

    Public Function myConvert(ByVal INPUT As String, ByVal Act As Integer) As String
        Dim myresult As String
        Dim i As Integer

        For i = 1 To Len(INPUT)
            If Act = 1 Then
                myresult = myresult & "%" & Hex(Asc(Mid(INPUT, i, 1)))
            Else
                If (Mid(INPUT, i, 1) = "%") And (i <= (Len(INPUT) - 2)) Then
                    myresult = myresult & hex2dec(Mid(INPUT, i, 3))
                    i = i + 2
                Else
                    myresult = myresult & Mid(INPUT, i, 1)
                End If
            End If
        Next
        myConvert = myresult
    End Function

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        If RadioButton1.Checked = True Then
            outputBox.Text = myConvert(inputBox.Text, 1)
        Else
            outputBox.Text = myConvert(inputBox.Text, 2)
        End If
    End Sub

End Class

Labels: algorithmics, code, english, script, technology, vulnerability, xss

Posted by barry at 5:59 PM | Link | Comments