Friday, March 26, 2010

first impressions of Google’s Skipfish WVS

after getting really interested in a late Google project, i spent few hours today with Google’s Skipfish v1.25b , which is a Google project for a web application security scanner , or as some times referred in the professional arena – a WVS ( web vulnerabilities scanner ) and is completely open source as i like it.

as i mentioned, i am playing with version v.1.25b ( although 1.26b is available at time of writing the article ) against a vulnerable demo web application that i wrote a few months back… and got some impressions on the current version.

first of all, i have to admit , its blazing fast … once given a destination to scan, the scan is fast , and the results are displayed in a very elegant way ( although a bit too hardcore ) moreover the depth and methods of detecting problems are quite impressive.

that being said .. the security checks themselves missed lots of the application vulnerabilities , including some quite basic SQL Injections which were there especially for security demonstrations. but i will give the credit and wait until this tool matures a little more before i try it again , and i am sure it will be much better.

the report is excellent , very insightful and shows track of the trace of the stream until the vulnerability has been detected , which is always good, nevertheless – i would like to see in future versions some different export mechanisms of reports, such as XML and PDF, to make it more usable in the IT security ecosystem environment.

there is a point to remember that at current time it is being written and managed by one person at Google , as compared to enterprise tools such as IBM’s Rational AppScan or Qualys etc, so you have to give credit here :)

for ease of use , it is easy , but i do expect a UI , since most people that will run this scanner will require some interaction with it that does not require any CLI / Linux skills, since it is not in their job requirements , they just need to run a tool and test for baseline ( unfortunately that also includes lots of “consultants” ).

if i am to rate this tool , i would rate it at its current version (1.25b) with 6.5 of 10 for now , since i really like the speed and the overall architecture of it , but i do see the need for some more maturity and some more robust security tests.

it detected 9 of 14 SQLi and 4 of 8 XSS , and none of the 4 persistent XSS vulnerabilities ( although it claims to detect it ) .. and yes , i have fed it some credentials as needed..

its a descent alternative to lots of the tools out there even in its current stage , and i would definitely go back to it when some holes are put to its belt.

 

Finally, just a quick install HOW-TO for it.
if you want to install it under CentOS ( i used 5.2 ) then do the following :

1. download and extract the tgz file anywhere ( example : tar zxpfv skipfish*.tgz )
2. install some neccesary packages for the install

- yum instll gcc
- yum install openssl-devel
- yum install libidn-devel

3. step into the folder extracted and run – make
4. there you go. :)

Labels: , , , , ,

Saturday, April 18, 2009

אינטגרציה בעולם הEnterprise Datacenter

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

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

הדרך הכמעט נפוצה מכולם תמיד הייתה לשלוח Email על אירוע אבטחה כאשר הוא קורה - וזאת על מנת לתת לו מענה, אך בעולם של 1000 אימיילים ביום , הכיוון הוזנח ונעזב לטובת SNMP ולטובת SYSLOG אשר מייצרים אירועים רבים בשניה מהמרכות ואותו איש NOC\SOC לא תמיד יכול לבקר כמו שצריך ולוודא אם אכן מדובר באירוע אמיתי ואיך להגיב לו.

לפי דעתי, מוצר אשר מיועד להתחבר לסביבת Enterprise חייב לתת את האפשרויות השונות להתממשקות לכלי SIEM שונים וכלי בקרה שונים בצורת הNATIVE שלהם תוך כדי שנעשית הבנה לפני שליחת האירוע של מהו האירוע, מהי מהותו ומה נדרש לבצע.

כלומר , כאשר מוצר מותקן בסביבת Enterprise עליו לקחת בחשבון הימצאות כלי CMDB למיניהם , כלי SIEM למיניהם ומערכות Availability שונות. אם אינו מתחבר אליהן - מקבלים רק חלק מהתמונה שכנראה ברוב המקרים תיבלע בתוך המכלול.

Labels: , , ,

Monday, February 16, 2009

IP-Expect The IP-Unexpected

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

הסיבה לבעיה נעוצה בעובדה ש Proxy ( או Load Balancer ), שובר את הTCP Stream ומייצג כתובות IP אחרות בחלק הפנימי שלו . לפי כך מערכות קלאסיות כמו IPS או דומות , אינן רואות את כתובות הIP האמיתיות אשר הגיעו מהעולם. לא ניתן לזהות את מקור ההתקפה בצורה קורלטיבית ומכך נגזר - שאי אפשר להגן בצורה יעילה כנגד התקפה על פי זיהוי מקור.

כאן בדיוק נכנס עולם ניתוח האפליקציה.

כאשר Proxy או כל TCP Terminator כלשהו ( כגון Load Balancer ) קיים , אחת התכונות שלו היא הוספה או עריכה של Headers - דוגמא טובה תהיה בHTTP Header. התוספת הרלוונטית במקרה של Proxy תהיה בצורת פרמטר X-Forwarded-For , אשר הינו פרמטר המכיל את הIP המקורי אשר קולף על ידי הProxy והוחלף בכתובת שלו עצמו.

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

כמובן רצוי לוודא שקיים Trust מסויים בין הProxy לבין אותה מערכת , כדי שהמערכת תדע שהHeader אכן שונה על ידי הProxy ולא על ידי אלמנט צד שלישי ,כגון האקר שרוצה לעקוף IP Filtering בצורה זו.

Labels: , , ,

Friday, June 27, 2008

אנטי - Agent

ועם כותרת משונה שכזו , נסביר...

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

כמו שרבים וטובים יודעים, פתרונות אבטחת המידע השונים המושתתים על טכנולוגיה - מתחלקים כמעט תמיד לשתי תצורות שונות - Host Based מבוסס AGENT , וNetwork Based מבוסס Appliance.

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

ובכן , כפי שכותרת המאמר מציינת , אכן אני נגד פתרונות הAgent ברוב המקרים. אני אפילו מאמין שאם ניתן היה לבצע הכל בשכבת הACCESS ולא היו בעיות של גישה פיזית למערכות - לא הייתה הצדקה כלל לפתרונות AGENT.

ומה מניע את עמדתי ?

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

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

מובן שאין מנוס ,וישנם דברים שצריכים להיבדק ברמת מקטע מקומי , אך אלו דברים בודדים כגון גישה פיזית, וביצוע פעולות Localhost אשר הינן כ0.5% מסך הפעולות שמבוצעות על השרת ... ואם כך , לפתרון מאסת התעבורה - אין סקאלאביליות בכלל. ופתרון Agent-ONLY אינו יכול להיכנס לנישת פתרון כאשר מדובר בכמויות מידע ובמערכות גדלות.

לעומת זאת , פתרונות הAppliance השונים , נבנים תוך ראיה מסוג שונה --> Throughput.

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

קחו לדוגמא מערכות AntiVirus רשתיות , ומערכות AntiSpam רשתיות , ומערכות Application Firewall רשתיות ... ממש ניתן לראות את הטיפול המשופר בעומסים על המערכות ועל תעבורת הרשת. וזאת מאחר והטיפול בכל התעבורה המלוכלת ( או נקי ה! ) קורה בשלב לפני הגישה לשרת עצמו.

Labels: , , , , ,

Sunday, February 10, 2008

מחשבות לגבי OpenID

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

אחת הדרכים המרתקות יותר שתופסות יותר ויותר כותרות לאחרונה היא OpenID.

מדובר בעצם בתשתית הומוגנית מקוונת אשר אמורה לאחד את כל השירותים אליהם אנחנו ניגשים , כגון חשבון הדואר האלקטרוני שלנו , חשבון הFacebook שלנו, חשבון הDIGG , וממשיכה לכיוון חשבון הבנק שלנו וכדומה.

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

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

אני אישית , רואה פה בעיה חמורה.

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

אני מחפש את האלמנט הנוסף . האם ייתכן שיחול מהפך של Full Disclosure על מידע פרטי ?

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

הקלות של הפעלת התקפות Phishing היא בלתי נסבלת בהקשר זה, האם ייתכן שברגע שאני נכנס לארגון אשר מחליט ( שימו לב : נבואה ... ) ליישם OpenID במערכות המידע הפנימיות , האם גם מערכות הERP ומערכות הCRM הופכות להיות נגישות ?

החברה החדשה בקרן OpenID והמשמעותית ביותר בעיני היא VERISIGN אשר מהווה את אחד הCA החשובים והמרכזיים היום בעולם. האם אוכל עכשיו לזייף הזדהות חכמה בעקבות כך שהתעודה המונפקת לי מוצמדת לOpenID ? האם עכשיו כאשר יאבדו או יגנבו פרטי זהות , תיפתח גם התעודה של אותו משתמש ?

יותר מידי שאלות...

Labels: , , ,

Wednesday, January 09, 2008

נבואה ראשונה מתקיימת השנה - Facebook Attack

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

והנה מסתיים לאט לאט השבוע הראשון של 2008 , והוירוס הראשון ( שאני יודע עליו ) מופץ דרך אפליקציה בתוך FACEBOOK. ובדרך די מרשימה.

הראשונים לנתח ולתפוס את ההתקפה היו חברת Fortinet אשר מראים בקישור הבא את מבנה ההתקפה והתחושה למשתמש.

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

לא רע ... וגם די אפקטיבי.

Labels: , , , , ,

Saturday, December 08, 2007

הקוד , לבקשתכם - XSS Translator

לפני מספר חודשים כתבתי עבור חודש 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: , , , , , ,

Tuesday, October 30, 2007

Stateful Inspection Is Dead

ואחרי כותרת מפוצצת שכזו וכמובן אחרי שתפסתי את תשומת הלב שחיפשתי - אפשר להתחיל לדבר.

בתקופה האחרונה יצא לי לחקור רבות אודות טכנולוגיות FW שונות ומוטציות שהן עברו מאז שהומצא מנגנון הStateful Inspection ( נסמן כ "SI" כשנדרש ) וכמובן הטכנולוגיות הללו התפתחו ולקחו את עולם הNetwork Firewall לעולמות רחוקים ומתקדמים יותר , שהופכים את הטכנולוגיות

ראשית, מהו Stateful Inspection :

באופן מאוד מאוד כללי , מדובר בטכנולוגיה אשר מתבססת על טבלאות הנקראות State Tables אשר מכילות את פרטים אודות כל TCP Stream שעובר דרך המערכת. למעשה , עבור כל SESSION נשמרים פרטים מזהים אודות חלון הTCP והפרטים השונים לגבי המשך הSESSION , ולכן כל פאקט חדש שיגיע יבדק אל מול הטבלה למציאת שייכות , אם שייך - יועבר למנוע הROUTING , אם לא - יבדק אל מול הRULEBASE של אותה מערכת FW. המאפיין הכללי כמובן הוא מקור , יעד , ופורט. הומצאה במקור על ידי CheckPoint

ובכן לפני מספר שנים בודדות , עם עליית טכנולוגיות הUTM , התווספו מספר מנגנונים לעולם הSI שעיקרם הוא הDPI או בפירוט - Deep Packet Inspection. הרעיון מאחורי הקונספט הוא - להשתמש במנגנוני Content Inspection כאלו או אחרים , על מנת לוודא שהPACKET אכן תקין ונקי ממזיקים , ולשמש כשכבה נוספת במנגנון ההחלטה לגבי הכנסה לState Table. במקרה של DPI אגב , הסריקה ממשיכה להתבצע לכל אורך התהליך בכדי לשמור על תעבורה נקיה ככל האפשר. מה שכבר הופך את טכנולוגיית הSI כריקה ולא משמעותית , כי ההסתכלות צריכה להיות מעבר לLayer 4 ויותר לכיוון Layer 7. ולשם צריך לכוון.

עד היום למעשה כל FW עדיין מבסס חוקים על פי Source/Dest/Service מבלי באמת להסתכל לתוך אותו הService. וכאן בעצם הבעיה , למרות שהקונספט עובד ועובד טוב, הוא כבר לא מספיק מעמיק בשביל להתמודד עם התקפות מתפתחות שעוברות מוטציות בין שכבות שונות במודל OSI.

לצערנו ( והאמת היא שזה היה צפוי לקרות בשלב זה או אחר ) אפילו הפתרונות הרובסטיים ביותר אינם מספקים להתקפות של מחר.

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

מה באמת רץ לנו ברשת ?

הBUZZWORD שמתפתח מעולם זה הוא בעצם יצירת דור חדש ( דור 6 ? ) של מערכות FW אשר מוסיף תווך נוסף למערכת ובעצם מהווה האבולוציה האמיתית של עולם ה FW וגורם לSI לקבל את התגית Obsolete. ולמה בעצם - דור חדש של מערכות FW עולה וצף , Application Aware Firewall או בשם אחר Application Categorized Rule Based Security . והכוונה מאוד מעניינת ( ובעלת המון טכנולוגיה מאחוריה ) הקונספט הוא כזה שבו כל STREAM של אפליקציה ניתן לזהות לפי מבנה הPACKETS או מבנה של מספר PACKETS ולהשוות למול DB כזה או אחר , ובכך בעצם לתת משמעות לעמודת הService בחוקי הFW. כלומר - מידע יעבור מעתה לפי 4 שדות שונים - source/destination/port/APPLICATION .

אגב , ברור שפתרונות מסוג זה לא ניתן לבצע בתוכנה בלבד, יש צורך במעבדים מיוחדים ובחומרה שנבנתה במיוחד למטרה זו . קחו למשל אינטגרציה בין סביבת PGP לסביבה שכזו - המערכת צריכה להיות מקושרת עם הKeyring הארגוני , בשביל לפתוח את ההצפנות השונות שעוברות ברשת ולבצע ניתוח למידע המוצפן.    - הOverhead ברשת הוא מטורף, הLatency בלתי נסבל - ולכן הפלטפורמה תמיד מבוססת ASIC ואפיקי BUS אדירים.

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

Labels: , , , , , ,

Wednesday, October 24, 2007

Cryptoanalysis באמצעות GRID

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

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

למה אני טורח לכתוב ? בגלל הסיבה הזו ( לינק כאן ) . חברת elcomsoft בנתה מוצר די מעניין בתצורה שלו. המוצר משמש לפריצת ססמאות WINDOWS מורכבות ככל שיהיו , על ידי שימוש בחלק ניכר של מחשבי הארגון לצורך שבירת הסיסמאות אל מול הhash או בכל צורה אחרת המקובלת ( בעיקר Brute Force ) ואם אני לא טועה , הם הראשונים לאפשר רכישה של כלי קנייני אשר מבצע את הפעולה הזו על ידי הקמת GRID ייעודי לפעולה זו.

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

אגב , אני מכיר ניסוי אוניברסיטאי ( ברוסיה ) לניסיון שבירת AES256 באמצעות GRID , אך לא מכיר את תוצאותיו. יש כאן מגמה מעניינת ואיפשהו מובנת מאליו לגבי הכיוון של תחום הCryptoanalysis.

מאמר מעניין בנושא ניתן לקרוא בקישור הבא.

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

Labels: , , , , ,

Saturday, October 13, 2007

XML Security - קצת מחשבות בנושא

פרילוג

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

מה זה XML

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

אני ממליץ לקרוא את המדריך הבא למי שהעולם הזה חדש עבורו.

SOAP

לשפה זו מצטרף פרוטוקול הSOAP אשר נבנה לצורך יצירת תווך של העברת ידע ופקודות בין מערכות שונות ( בד"כ תוך שימוש בפרוטוקול HTTP כשכבת תקשורת ) . למי שלא מכיר - SOAP עובד בשיטה של מעטפות מידע ופקודות אשר עוברות בין שני אלמנטים שונים ( אפליקציות \ שרתים \ טלפונים IP וכדומה ). לאותן מעטפות ישנה הגדרת מידע ומבנה אשר נקרא פשוט - סיכמת הSOAP , והוא ממוקם בקובץ WSDL אשר פירושו - Web Services Descripton Language. ומכיל את המידע הרלוונטי בכדי לאפשר לשני הצדדים להבין אחד את השני. חשוב להבין שSOAP יכול ואמור לכיל פרצדורות ופונקציות כמו בכל שפת תכנות אשר עוזרות לצד השני להבין את המידע המועבר ( ומאפשרות גם עיבוד נתונים בSERVER-SIDE ).

מדריך מצויין למתחילים עם SOAP ניתן לקרוא כאן.

שימושים נפוצים

השימושים הנפוצים ביותר לXML היום הם : העברת מידע בין מסדי נתונים ובין שירותי אתרי אינטרנט , העברת מידע בין מודלים של מידע ובין פלטפורמות שונות , RSS , הגדרות לציוד ( כמו למשל קונפיגורציה של נתבי Juniper ודומיהם ) ולאט לאט כמעט כל תקשורת המכילה נתונים מידיים ומובנים עוברת למודל זה. אפילו עולם הMobile עובד בתצורה זו. נכון להיום , ישנם מוצרים רבים אשר בעבר הוגדרו על ידי SNMP או קבצי קונפיגורציה שהורדו ועבר קומפילציה על המכונה , והיום עוברים בXML. למשל טלפוניית הIP של סיסקו.

תקשורת הSOAP

הרעיון הכללי לתקשורת בXML באמצעות SOAP הוא : לכל צד אפליקטיבי אשר מבקש להעביר או לקבל נתונים יש PARSER מובנה אשר חותך את מבנה הXML ומייצג אותו בפני האפליקציה , וכמו כן יודע לקחת את נתוני האפליקציה ( וזה כבר מותאם אישית לכל אפליקציה ) ומפיק ממנה XML וגם DTD ( סכימת המבנה בXML ) את הXML עצמו מעביר פרוטקול SOAP למעטפות ושולח על גבי IP לצד השני . בצד השני מקיים התהליך ההפוך של פתיחת הפמעטפת , REPARSING והמרת המידע למבנה המבוקש.

סכימת המבנה של שימוש בSOAP בHIGH-LEVEL ( תהליך ממוספר ) :

soap_h4

התקפות

בחרתי לציין מספר קטן של התקפות מוכרות מעולם הXML בכדי להמחיש את הסיכונים :

  • SQL Injection , כן - אותה התקפה המוכרת לנו כלכך מעולם הSQL ועולם האפליקציה , מקבלת פנים חדשות לחלוטין. תחשבו על זה לרגע , למרות שתווך העברת הנתונים אינו SQL אלא XML , ישנו PARSER אשר הופך את המידע משאילתת SQL לXML ובחזרה . זה אומר בעצם שאם הייתי גורם לנתונים בתוך הXML להכיל את אותו "גרש" וסקריפ אחריו בתוך שדה נתונים - הPARSER בצד השני ימיר את ההתקפה בחזרה לSQL וההתקפה תעבוד. למרות כל ההגנה שהשקענו עד היום.
  • Recursive Payloads – התקפה המתבצעת על הPARSER אשר אמור לטפל בבקשות מסויימות , מתבצעת רקורסיה ארוכה , אשר גורמת לDOS. התקפה קלה מאוד לביצוע שכן הPARSER תמיד מנסה להבין את מבנה הנתונים ולענות לבקשות פעולה בקוד המעטפה.
  • WSDL Scanning – זליגת מידע על ידי סריקת מבנה התשתית של מעטפות הSOAP על ידי למידת מבנה מסד הנתונים המוצג בתבנית הWSDL. ברוב המקרים - במידה וכבר בחרו להצפין את תווך הSOAP או אפילו לבצע IP FILTERING כדי שהתווך יהיה רק בין שני גורמים , המעטפת תמיד נמשכת ממקור צד שלישי, שאולי אינו מוגן. כאשר אני קורא את הסכימה , אני יכול להסיק על כל מבנה הנתונים המוצג בשאילתות , ללמוד את מבנה מסד הנתונים, ולחסוך זמן בעבודת הפריצה וגניבת המידע.
  • Schema Poisoning - שינוי מעטפת הXML על מנת לשנות את מבנה הנתונים והמידע המופק ממנו , בעצם אני משנה את הצורה שבה אמור להיקרא המידע על ידי הצד השני על ידי שיבוש הסכימה, והמידע מגיע משובש לצד השני. ( MITM עובד כאן יופי יופי ).
  • SOAP Routing Detours - על ידי שתילת תגיות נוספות למעטפה , ניתן לגרום למעטפה לעבור דרך גורם שלישי בדרך , לבצע MITM ולשבש ואף לגנוב מידע מבלי שיורגש.

וירולוגיה

אין לשכוח עולם שלם של וירולוגיה ממוחשבת אשר עוברת דרך SOAP וXML. תחשבו על זה רגע ... נכון להיום כל מערכות האנטיוירוס סורקות רק נתונים מסויימים , ורק סוגי תעבורה ופרוטוקולים מסויימים. אם אני מפרק וירוס לתוך מעטפות SOAP , הוא יופעל על ידי האפליקציה שביצעה PARSING והרכיבה את הוירוס מחדש , ואותה אפליקציה , באופן לא מפתיע - מורשית לרוץ על המערכת , ולכן מערכות HOST-IPS ורוב הAV פשוט לא יתייחסו ( ברור לחלוטין גם מול הUAC של ויסטה ).

סיכום

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

אני ממליץ למי שמעוניין להעמיק בנושא , ללמוד עוד מאתר SECUNIA , אשר מפרסם כל הזמן התקפות חדשות - אפליקטיביות\מבניות\תקשורתיות בנושא XML. המודעות היא השלב הראשון והעיקרי לפתרון בעיות אבטחת המידע הנובעות מכל דבר.

Labels: , , , , , ,

Thursday, September 27, 2007

מאמר מצויין בנושא פגיעות אתרי אינטרנט

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

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

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

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

תהנו.

[ פוסט תוקן ב27.9.07 ]

Labels: , , ,

Monday, September 17, 2007

שאלת שימוש הוגן בתוכנות Freeware ( עם פרסומות )

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

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

איך זה עובד ?

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

ניתן לחסום את הפרסומות ?

כן, ניתן. זאת משום שעל מנת ליצור תקשורת עם אותם מאגרי פרסומות , על האפליקציה לצאת בבקשת תקשורת החוצה , כמובן שבמערכות האבטחה או הנתבים , PORT 80 פתוח מבפנים החוצה לטובת גלישה , ולכן התוכנות יוצרות קשר דרך HTTP בדרך כלל בכדי למשוך את המידע. מהסיבה הזו בדיוק , ניתן לבצע חסימה לכתובות הIP , לURL או למהדרין למבנה הבקשה בשכבת הTRANSPORT במערכות הIPS.

שאלת השימוש ההוגן ( רמז : זה כנראה מותר )

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

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

בהחלט נושא למחשבה...

Labels: , , , ,

Wednesday, September 12, 2007

TOR לגלישה אנונימית - מה זה , ודרכי התמודדות בסיסיות

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

לאלו מכם שטרם נתקלו באפליקצית TOR , מדובר בעצם באפליקציה אשר מהווה תוסף איכותי לFIREFOX עם תשתית של Proxifity מתחת. בעצם מה שהאפליקציה עושה ברגע שהמשתמש בוחר להפעיל TOR , היא להגדיר PROXY מקומי ולהכריח את הדפדפן לעבוד מולו , אותו PROXY מתחבר לרשת הPROXY עולמית בHTTPS ( כלומר לא ניתן לגילוי על ידי בדיקות SNIFFER בתוך הPACKET ) וכמובן לאפשר גלישה אנונימית . אך למעשה - הדבר פותח באופן תיאורטי גישה לכל דבר שהFW הארגוני חוסם על פי מדיניות אבטחת המידע הארגונית, ויתרה מכך - להוריד קבצים ללא בדיקות אנטיוירוס, להתחבר לתוכנות מסרים מיידיים ולגלוש לאתרים אשר אמורים להיות חסומים על ידי מנגנון סינון האתרים הארגוני.

המטרה המקורית היא כמובן לשמור על אנונימיות בגלישה . מה שקורה בפועל הוא שמשתמש TOR יכול לגלוש דרך מחשב של משתמש במדינה אחרת שמפנה למשתמש במדינה אחרת וכן הלאה ( TOR מבצע בעצם ENCRYPTED CIRCUIT בין מספר מחשבים אשר אינו ניתן לזיהוי פרט לכתובת הHOST הקודם וכתובת הHOST הבא בשל יכולות הקריאה של הIP HEADER ) , ואז הוא לא ניתן לגילוי - אבל כך גם לגבי זליגת מידע או שימוש זדוני במשאב הWAN הארגוני. מדובר לכן במשאב מדהים עבור האקרים אשר מעוניינים לבצע פעולות אנונימיות ובמהירות וזמינות, מבלי לאפשר גילוי עקבות.

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

טכנולוגית , המושג המאפיין רשת כזו נקרא Onion Routing כלומר ניתוב בשכבות , לצורך ביצוע פעולה שכזו דרושים לפחות 3 HOSTS בדרך, כאשר הNODE שממנו יוצאת הבקשה לתעבורה מצפין , המידע עובר מוצפן בכל המסלול , ומפוענח רק על ידי הEXIT NODE. כאשר כל HOST אשר משמש למשלוח יודע רק את המקור והיעד אבל לא יודע מה המידע אשר מועבר דרכו. יש לציין גם שטכנולוגיה זו הומצאה על ידי הצי האמריקאי - המטרה המקורית הייתה כמובן למנוע לחלוטין את התקפות ניתוח המידע והSNIFFING ברשת הצבאית, אבל כמו כל דבר טוב - תמיד קמים שימושים רעים לכל דבר.

SPAM NEXT-GENERATION - תזה קצרה :

לדעתי מדובר בתקופה קצרה ביותר , עד שתוקם רשת מקבילה , או שירכיבו על גבי רשת הTOR יכולות מובנות של SMTP , וכן - מאותו רגע כל עולם הRBL יהפוך להיות שולי , חסימות ברמת זיהוי כתובת שרת שולח יהפכו לנושא לא רלוונטי - ולפי כך - כל חברות הANTISPAM ייאלצו לעבור לתצורת HEURISTICS - מה שיהפוך את הפתרונות הקיימים לנחותים מבחינה חומרתית ( מנועים כאלו זוללים משאבי מערכת בשל תצורת הבדיקה המעמיקה ). הרי שמאוו רגע כל משתמש ברשת הבצל - יכול להיות מקור לספאם , והאם נכון לחסום את כל כתובות הIP הפרטיות ? האם הדבר יהפוך את פתרון הSenderBase המעולה של IRONPORT ללא יעיל ? שוב , ייתכן ואני טועה לגבי הניתוח שלי לטכנולוגיה זו - אבל ימים יגידו.

להלן מספר דרכים להתמודד עם התופעה ברמה ארגונית :

1. הקמתו של PROXY עבור כל תעבורה שהיא HTTPS בארגון , ניתן לבצע עם פתרונות קנייניים או עם פתרונות כגון SQUID על שכבת לינוקס. במקביל , יש לחסום את כל תעבורת הHTTPS אשר לא יוצאת מתוך הPROXY כלפי האינטרנט. אגב - זהו פתרון מקובל לכל בעייה שקשורה לאפליקציות מסוג זה , מכיוון שמספיק שאני מעביר את התעבורה המוצפנת לגורם שמבצע PROTOCOL MIDDELING וחותך את התעבורה באמצע - אני יכול לחסום כל דבר ( דוגמת LOGMEIN ) ברמה רשתית.

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

2. במידה וקיים בארגון פתרון כגון HOST IPS ניתן לחסום את האפליקציה עצמה של TOR ושל Vidalia אשר הינה חבילה אשר מכילה את כל הפרטים וההגדרות פעולה וזאת על ידי חסימה ברמת האפליקציה. אפשר לאכוף בקלות באמצעות ISS של IBM או INTEGRITY של צ'קפוינט. אם יש SOFTWARE MANAGMENT בארגון , כגון BIGFIX או PATCHLINK , ניתן להגדיר JOB להסרה קבועה ברגע הגילוי - אבל שוב - אלו מצריכים CLIENT ולכן בעייתי .

3. לארגונים אשר בחרו ליישם NAC ( ברמה רשתית ) ניתן לבדוק הימצאות התוכנה ולנעול את השכבה השניה במידה והתגלה , ולדרוש הסרה. ניתן לשלב עם פתרון הCLIENT מסעיף 2.

קישורים :

- הקישור לTOR ולמידע טכני אודות האפליקציה - בקישור הבא

- מאמר שמתאר זליגת מידע בעקבות שימוש ברשת TOR - בקישור הבא

Labels: , ,

Tuesday, July 10, 2007

Fedora 7 on HP nc2400



all of my hebrew readers . please excuse me , but because i want to make this post handy for other nc2400 users - i will post it in english.

i have got my hands on a new HP NC2400 laptop that replaced my older Dell D620 laptop. and here is how i set up my fedora 7 on it.

first of all ... i must admit - almost everything worked out of the box . which is quite amazing for a branded laptop ... maybe the only 2 things that didnt work were the wireless "Intel IPW945/PRO Wireless (rev 2.0) wireless card , and the AutheTed fingerprint reader . well since i do not use the fingerprint reader - i did not even set it up , so excuse me all of you finger print users.

my set up is quite simple - gnome with beryl , 2.6 kernel and the rest are networking\pentesting tools ... that are not worth mentioning

wifi -
i am thinking of how to give you the easiest way to bring it up ...
well its easy ...

fist esit the file "/etc/modprobe.d/blacklist file and add the following lines :
--
#IPW3945
blacklist iwl3945
blacklist mac80211
--

and reboot it ...
then add the "freshrpms.net" repository ... and run "yum search ipw3945"
install the dkms package , the ipw3945d package and the ipw3945 firmware package ...
reboot and your done .

the 12.1 inch resolution was also automatic , so no use for 915_resolution tool , you may want to install the wpa_supplicant tool in order to connect to wpa2 easier.

i would also recommend running the NetworkManager tool to manage the network connections from within gnome . i personally disabled the eth1 ( the wifi interface ) automatic dhcp via the /etc/sysconfig/network-scripts/ifcfg-eth1 file

thats about it . everytning is running fine , yum update rand perfectly , and its a gogogo from now on.

enjoy linux.

Labels: , ,

Saturday, April 28, 2007

פתרונות חיפוש לעסקים - Google


ובכן , החברה האהובה עליי Google - עושה את זה שוב. [ האזכורים הראשונים למערכת זו הראו לי לפני כשנה וחצי או שנתיים ... אבל לא זכור לי שפורסם באתר של גוגל באופן רשמי ] , אבל אם תיכנסו ל
לינק הזה תוכלו לראות את אחד הפיתוחים היותר מעניינים של גוגל לעולם הLarge Scale Enterprise ולעולם מנועי חיפוש הנתונים וfריית הנתונים העסקיים.

למעשה מה שעשו גוגל ( אגב , Yahoo + IBM וחברות אחרות מפתחים פתרונות מקבילים , וכמו כן יש פתרונות מבית Microsoft אשר זו מטרתם גם כן וכמובן מנוע X1 המושלם מכל בחינה , אבל אני איש של גוגל ... מה לעשות ) הוא לקחת את המנוע האדיר שהם פיתחו , וליצור מערכות INDEXING למידע ארגוני , אשר כל משתמש יכול לרכוש ולנטוע מערכת חיפוש מתקדמת ביותר , בארגון שלו , באתר שלו , או עבור לקוחות שלו. והיתרונות בולטים , מכונת הGOOGLE MINI יכולה ברישוי הכי זול שלה ( 1995$ ) לחפש ולבצע INDEXING למעל 50,000 מסמכים - כלומר זהו פתרון זול וסביר לכל ארגון אשר מעוניין במנגנון לניתוב , סינון פילטור ויצירת מאגר נתונים על סמך מסמכים. והפתרון האולטימטיבי לשילוב בתוך אתר אינטרנט או אינטראנט ארגוני.

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

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

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

אהבתי.

למי שפספס - הנה שוב הלינק אני מציע לשוטט שם קצת.

Labels: , ,

Saturday, December 16, 2006

Blended Threats

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

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

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

הרעיון הוא כזה , אם למשל אני תולעת שמפיצה לינק מסויים לאתר . אני יכול להפיץ עצמי גם באמצעות שכפול דרך רשימת הכתובות של הדואר האלקטרוני , גם דרך הIM , גם דרך הSMS GATEWAY שמוגדר לי על התחנה , גם על ידי עריכת מסמכים וחתימה עם הלינק עליהם וכדומה. בנוסף דרכי השכפול שלי יהיו מרובבות , שכן פעם אחת אשכפל את עצמי דרך אימייל , פעם השניה אתקוף דרך שיתוף הקבצים , בפעם השלישית בIM וכדומה... המצב שנוצר הוא יכולת של תולעת אחת לעבוד בכל החזיתות , גם בשכבות התקשורת וגם בשכבות האפליקציה.

ומה הבעיה בכלל ? הרי יש לי אנטיוירוס ואנטיספאם ואנטי אנטי אנטי ... ובכן תתפלאו , הם לא יתפסו התקפות כאלה במעל 80% מהמקרים. וזאת מפני שכל מנוע שכזה עובד לבד , אנטיוירוס חותם לבד שקובץ נקי , וגם מערכת האנטיספאם , הIPS יעבוד באותה צורה וכן הלאה. ולמעשה כל פתרון UTM שלא יהיה , לא יפתור את הבעיה מאחר והיא מחולקת על יותר מידי שכבות , כאשר באף שכבה אי אפשר לומר במדויק "כן , זו התקפה !". אולי חברה אחת או שתיים פנו לתת מענה אמיתי לבעיה זו ( על ידי כתיבת כל המנגנונים בעצמך , אתה מסוגל לבצע קונסילידציה של החלטות על סמך ניתוח משותף של כל המנועים , ורק כך תוכל לגלות את ההתקפה ).

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


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

בנוסף למאמר שלי בנושא UTM שפורסם באנגלית בבלוג הזה : גילשו למאמר

Labels: , , ,

Saturday, December 09, 2006

SSL VPN Access

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

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

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

הפתרון המוכר ביותר לגישה מוצפנת ( ולכן לא אדבר כאן על PPTP ועל יישומים שלו למרות שחלקם אף כוללים הצפנה ) יהיה להשתמש בפרוטוקול אשר יעטוף את התצורה הרגילה לגישה בפרוטוקול מוצפן ( למשל RDP OVER SSH ) ובכך יאפשר גישה בטוחה. הדרך המוכרת ביותר לבצע זאת היא על ידי IPSec , הצפנת התווך בין שתי נקודות או בין נקודה לרשת.

בשנים האחרונות אנו רואים מספר אלמנטים של שימוש בSSL לצורך הקמת אותו תווך מוצפן, מדובר למעשה בשימוש בSSLv3 ( שהוא בעצם TLS המוגדר בRFC2246 ). למי שלא מכיר - SSL עובד בשכבת הSESSION והומצא על ידי NETSCAPE לפני מספר שנים שלא זכור לי לנקודה זו. ובכן המטרה בשכבת הSESSION הייתה לאפשר לעבוד עם SESSION COOKIES בדפדפנים ( שכן פרוטוקול HTTP אינו תומך בSESSION כלל ) . ובכן , על מנת לאפשר לאפליקציות רשתיות לרוץ על התשתית המוצפנת , עלינו לרדת כמובן שכבה, לכן הומצא הTLS שהוא Transport Layer Security שמאפשר לנו להצפין בשכבה הרביעית .

על ידי כך שהSSL מאפשר כעת לעבוד ברמה הרשתית ולא רק ברמת הWEB BROWSER , אנו יכולים כעת לקיים קישורים מרוחקים מאובטחים ( אפשר להתווכח על זה ) אשר מאפשרים גישה ללא הצורך בהתקנת תוכנת קצה ( לכל מחשב סטנדרטי יש היום דפדפן אשר תומך בSSL ) ולכן מוריד את הOVERHEAD האדיר שפתרונות הACCESS בדרך כלל יוצרים על מחלקות הIT השונות.
למעשה , משתמש מרוחק יכול להתחבר מכל מקום בעולם , ללא התקנה של כל תוכנה , ולהתחבר לארגון בצורה בטוחה ולעבוד מרחוק.

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

מובן שלכל פתרון יש היתרונות והחסרונות שלו , ומאוד תלוי איך אותו VENDOR בוחר ליישם את פתרון הSSL-VPN שלו. מנסיוני אין פתרון אחד שמתאים לכל ארגון , בסביבות מונחות יצרן אחד ספציפי יתכן שיתאים פיתרון אחד , בעוד לארגון אחר אשר דורש ניקוי בAV לתשתית הSSL שלו יתאים פתרון אחר. ישנם פתרונות המהווים PROXY מלא בין נקודת הגישה לאתר עצמו, ישנם פתרונות אשר מסוגלים לבצע בדיקות UTM וניקוי של מזיקים מהתווך המוצפן, וישנם אף פתרונות שמקימים סביבה נפרדת חד פעמית מוצפנת אשר אינה יושבת על הIO אלא בSANDBOX ייעודי. אין כאן כללים מנחים ויש לשקול כל פתרון לגופו.

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


** שימו לב , ישנו המשך שעיקרו טכני בתגובות למאמר זה.

Labels: , , ,

Monday, December 04, 2006

UTM – Antithesis For The Current Concept Technology


The world of IT security technologies has evolved greatly for the last 5 years.
By understanding the structure of the current threats that threatens the IT environment of corporate infrastructure – security vendors have created very highly crafted technologies to deal with these threats. We had some major breakthroughs with IPS technologies that currently serves both signature based and proactive scanning methods, Antivirus and AntiSpam technologies can now inspect information to the deepest levels . and there are more than enough URL filtering mechanisms that serves about every major company that require these kind of services to be implemented on their users surfing habits.

UTM is something pretty fresh In that aspect, we’ve seen it growing In the last
couple of years as a major aspect for creating “All-In-One” solutions. The concept is
brought to life by taking one machine that is taking care of stateful firewalling , advanced routing ,IPSec connectivity, and giving it the extra edge by allowing it to connect to modules such as the IPS, AntiSpam, Antivirus and the URL Filtering mechanism to create a full blown inspection gateway that scans just about everything that passes through it, and decide based on scan results if to pass the traffic or rather stop and log it and that point of entry.
Now lets look at the problem. By the UTM concept – our IT should be “secured”
If we are using a UTM device at our core network environment . but – what about
blended threats ? , what about attack and code mutations?
In the second half of 2005 , many analysts and security engineers have faced new
types of attacks , the blended ones , and the mutated ones. These attacks were crafted to skip from one method to the other , from one technology to the other , and IT security measures where if you had a virus , an antivirus solution would have taken care of it, And if you had a DoS attack , the Firewall would have taken care of it , but when an attack would have begun as an Exploit that injects a virus that later on sends out spam and infects other entities via IM , or via SMB – systems are useless to these attacks.

The problem with the UTM concept today – is that companies that manufacture
these solutions , are applying OEM solutions with other vendors . one could OEM with
the best-of-breed antivirus company for his AV module , and OEM with the best-of-breed IPS company for the IPS module and pass the traffic through the both of them . but ! and here is the problem – the modules of different vendors , could not speak to each other . each module of its own honorable vendor is written as a closed source application and can receive traffic from one end , check it and pass it through , but when the IPS module and AV module co-exist but cannot take mutual decisions on the traffic that passes through – blended threats could not be inspected in any way . mutations of the traffic will pass as if there was nothing there to stop them.

Let me explain further more : when the UTM device is used to establish a layer 3
up to layer 7 connection between two entities , it inspects the traffic . now – if there is a mutation attack of some kind ( here is just an example ) – a session is being established
via VPN between two entities , and runs just http traffic between the two. The
termination of the IPSec is being done by the UTM device , which cannot see up until
now if there was an attack hidden in the traffic that came through the IPSec tunnel . then the data is getting into the http server with a 0day exploit on it , so the IPS does not know it. And sends a file that was previously accepted by the UTM device because of the tunnel access control rules. Contains a virus , and the attacker entity is passing it through an IM service . the new crafted virus is the populating itself not via IM , but via SMB , and when that occurs – the virus manipulates itself to attack the core switch via a simple DDoS attack. no UTM device would stop this attack , no single entity to take care of one module will stop this attack. The solution is being send from one or two vendors today , that have come to
mind that if they write their own antivirus , they can manipulate it , and if the IPS code is their proprietary code , they could manipulate is , and where the URL filter is a service which they own . modifications and alterations could be performed . the main issue here is that if you are the sole vendor for all modules inside your UTM device , you can ask them to speak to each other , you could take access control decisions based o blended results of the traffic that passes through your device , and because of stateful technologies, you could understand the deep behavior of your traffic , and so – have access control decisions done by the deepest analysis available.

By creating a single-vendor solution , one is able to interconnect the different
security modules and create a real UTM device , in my terms – “Real UTM” is applicable only if the device , and the different modules come from the same vendor , so it could sanitize the traffic using decisions based on a matrix check of each packet.

The following diagram ( D01 ) shows how a current concept UTM device actually passes
the traffic :



On current UTM environments , the packet actually has to go through each and every
module as a stage of inspection. What may happen is that one module might not be
certain if the packet contains an attack and so not mark it as attack and pass it on. The attack will pass between the different “Best Of Breed” modules and no decision will be taken to drop the packet , because no module found a specific attack in the mechanism and if it could , it wouldn’t be able to tell the following module about the attack because of different technologies , and vendor code confidentiality.

The following diagram ( D02 )shows exactly what happens to a packet that runs through
what is considered a real utm :



What is clearly visible from this diagram , is that a packet that runs through a real
UTM mechanism , runs through each and every one of the modules . note : if a packet is being intercepted by the IPS mechanism – it will ask for the antivirus to check it too , and so on for the AntiSpam and every UTM module. And later on , the UTM mechanism will decide based on scan checks from all of the modules , if to pass it on , or to drop the packet. It is not session based , but packet based.
Now , what is happening in that environment is that each module can give some
kind of grading to the packet , even if it is not sure it is an attack . next , the UTM consolidation engine can grade the packet based on all of the modules , and have a sophisticated decision to drop or to accept the packet , and that is after a real deep inspection.

A new UTM RFC/Protocol is required.

One cannot realize how major vendors will exchange code parts between them,
But maybe some kind of a consolidation protocol is needed here . we had ICAP in the
past to check for different traffic methods, maybe now is the time to write a new protocol that inspection modules could grade traffic by , and a consolidated decision could be made.

In conclusion , the UTM world is a wonderful and insightful world, the best of the
vendors are doing a great effort in order to give us the best practice results and the solutions we require. But because of misleading assumptions ,that “attacks may be more sophisticated but they still spread in the same ways” the UTM world will not be complete. What should be the concept is “an attack can come In different ways and
blended ways , check them all and never skip a phase”.


Labels: , , ,


About

    My Name is Barry Shteiman, im a devoted tech junkie, and this is my blog.
    E: barry.shteiman -at- gmail.com
    Twitter : bshteiman

Tags & Categories

Mailing List & RSS

Stay Updated  
Add to Technorati Favorites