מישהו כותב לDATABASE SQL שלנו

[duplo2]

מישהו כותב לDATABASE SQL שלנו

שלום
ברשותינו אתר אינטרנט הכתוב בASPNET מאוחסן על גבי שרת יעודי עם IIS והדטה בייס שלו מוגדר כקובץ MDF של SQL EXPRESS - השרת SQL מוגדר לא לאפשר חיבור מרחוק
הקבצי MDF יושבים בתוך ספריית APP_DATA ויש למשתמש הדיפולטי של IIS הראשת כתיבה אליהם כדי לאפשר כתיבה של נתונים לדטה בייס
באופן תמוהה מישהו מצליח להוסיף נתונים (לינקים לכל מיני אתרי פרסום) בתוך השדות של הדטה בייס ובזה לדפוק לנו את כל התוכן של האתר
אין סיכוי שמישהו מתחבר לניהול של האתר כי זה לא אפשרי

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

 

[SysAdmin1]

לפי התיאור שלך, רוב הסיכוים שמדובר על התופעה של ...

לפי התיאור שלך, רוב הסיכוים שמדובר על התופעה של sql injection . בסוג התקפה המדוברת, התוקף מנצל את חולשות בקוד האתר. למשל תיבות קלט שלא קיימת בהם בקרה וניתוח של קלט מהמשתמש, מה שמאפשר לבצע שאילטות SQL לא מתוכננות ( לא מורשות ) . Input boxes ללא בקרה בשילוב עם אפשרות של שאילתות SQL ישירות מהקוד של האתר לבסיס נתונים ללא שימוש בפרמטרים מוגדרים מראש (sqlParameter) מהוות פרצה בשביל התקפת sql injection . מנגנון שני שמאפשר את sql injection הוא שימוש ב Query Strings [GET] בצורה לא מבוקרת.
צירפתי מספר קישורים שמסבירים את הנושא בפשטות ואיך להתמודד איתו :
http://www.codeproject.com/Articles/813965/Preventing-SQL-Injection-Attack-ASP-NET-Part-I
https://www.owasp.org/index.php/SQL_Injection
http://www.c-sharpcorner.com/Upload...njection-can-be-possible-in-asp-net-websites/
http://www.w3schools.com/sql/sql_injection.asp
http://aspalliance.com/1703_sql_injection_in_classic_asp_and_possible_solutions.3
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
וגם דוגמה פשוטה שנותנת אפשרות לראות אך התהליך מתבצע:
http://www.webblogsforyou.com/sql-injections-what-is-sql-injection-and-how-to-prevent-it/
דבר נוסף שכדאי לבצע זה הפעלה והגדרה של LOGGING מורחב בשרת IIS . כך ניתן יהיה לזהות מה בידיוק התוקף מבצע , מהיכן הוא מגיע וכו'.

 

[duplo2]

תודה על התגובה אבל

לדעתי לא מדובר בגישה לDB דרך הקוד של האתר
בעיקר כי באתר יש רק שדה של תגובה שבו יש קלט של טקטס מהמשתמש ולכאורה השינוי על הדטה בייס היה אמור להיות רק בטבלה של התגובות - אבל השינוי שהתוקף מצליח לבצע הוא בטבלה של המאמרים עצמם - שם בצד של המשתמש אנחנו לא מקבלים שום קלט
&nbsp
וגם למיטב ידיעתי - בASPNET כבר מובנת יכולת בסיסית של מניעת SQL INJECT על יד ENCODEING של הקלט (לא כך ?)
&nbsp
יש לוגים של השרת IIS - אבל הלוגים הרגילים - לא מוצא דרך להפריד תוקף מגולשים תמימים - ההאם יש לך המלצה ללוגים אחרים ? האם יש לוגים של השרת SQL EXPRESS שאפשר לנתח כדי לראות עדכון רוחבי כזה בכל השדות ?
&nbsp
כל זה לוקח אותי למסקנה שאיכשוה הוא מצליח לעבוד ישירות מול ה-DB ושאני מפספס משהו בהגדרה של ההרשאות (כאמור ההרשאות הם ברמת הווינדוס לתקייה APP_DATA)
&nbsp
האם בקוד ASPNET של התוקף יש דרך להגדיר קובץ MDF מרוחק כזה שיושב בלינק של האתר שלנו ולבצע עליו מניפולציות ?
&nbsp
השינוי היחיד שעשיתי כרגע הוא לשנות את השם שם הקובץ SQL מהשם הגנרי DATABASE.MDF למשהו שהוא פחות גנרי וניתן לניחוש - למרות שאין לי מושג איך גם כשאתה יודע את השם הדטה בייס אתה יכול להשתמש בו בצורה מרוחקת

 

[SysAdmin1]

מספר דברים בנושא של בסיסי נתונים...

דבר ראשון לצורך הביצוע של sql injection מספיק גם שדה קלט בודד שלא נבנה ותוכנן בצורה מאובטחת כמו שכבר הסברתי בתגובה הקודמת, ושגם ניתן למנוע את הבעייה בכלים מובנים ופשוטים שאותם גם פירטתי מקודם. דבר נוסף כל הראיון של sql injection הוא כתיבה לטבלאות שבונה האתר לא רצה שאליהם הנתונים ירשמו. גם כדאי להוסיף שלצורך הביצוע של הזרקת SQL תיבת קלט לא חייבת כלל מראש להיות כזו שאמורה להוסיף פרטים לבסיס נתונים, אלה מספיק שתיהיה מקושרת למנגנון השאילתות, גם אם המתכנן האתר התכוון בעזרת תיבה הזו רק לשלוף נתונים מהבסיס הנתונים ( למשל שדות קלט של הזדהות באתר או כל פנייה אחרת לבסיס נתונים שהאתר עושה בו שימוש ) . נקודה נוספת היא שלא קיים מנגנון מובנה ב ASP.NET שאמור למנוע את תופעה המדוברת, כי הוא רק יגביל את החופש פעולה של המתכנת, המנגנונים הם ברמת המתכנת שאותם כבר מניתי בתגובה הקודמת.
בקשר לתקשורת והזדהות מול שרת SQL , ברוב המקרים עדיף להגדיר את השרת שניתן יהיה להזדהות מולו רק דרך SQL Server Autentication ולהגדיר ברת SQL משתמשים נפרדים . אופצייה זו נותנת אפשרות לבודד את ההרשאות ומשתמשים של שרת SQL מההשאות והמשתמשים של שרת Windows ושרת IIS , ובקשר לתקשורת לשרת SQL , תמיד כדאי לבדוק שהיא מוגדרת בדרך של תקשורת SQL מאובטחת במקום קיצורי דרך שנועדו לצורך של בדיקות בלבד. צירפתי קישור שמסביר את הנושא:
https://www.studiocoast.com.au/know...-using-sql-server-instead-of-aspnetdbmdf.aspx
http://www.asp.net/web-forms/overvi...ing-web-site-projects/deploying-a-database-cs
דבר נוסף שצריך להבין זה שקובץ MDF זה לא קובץ שכותבים עיליו ישירות, כמו למשל לקובץ טקסט, אלה מדובר על הקובץ אמור להיות בשימוש על ידי שאילתות שעוברות דרך שרת SQL ואם הכל מוגדר בצורה תקינה לא ניתן לתקשר איתו מרחוק. כמובן שכדאי לבדוק דברים סטנדרטיים כמו למשל אם פורט 1433 של שרת SQL לא פתוח לכיוון האינטרנט, אם לא קיימות הרשאות מיותרות בסיפריות מפורסמות על ידי IIS למשל Directory Browsing וכו .

 

[Y. Welis]

עבור לשרת אפאצ'י עם PERL.

תמיד ימצאו חורים ב-MS

 

[SysAdmin1]

כל מי שמעורה בתחום של אבטחת מידע בכלל ובנושאים של WEB בפרט..

כל מי שמעורה בתחום של אבטחת מידע בכלל ובנושאים של web security בפרט מודע לזה שלאבטח שרת LINUX שמריץ Apache ועוד בשילוב עם Perl CGI ו SQL כלשהו, למשל mysql יהיה בדרך כלל משימה קשה ביותר ולפעמים גם בלתי אפשרית בגלל מספר רב של גורמים ושבניגוד לשרתי Microsoft IIS ששם רוב הבעיות נובעות מבוני האתרים שלא מבינים בנושאים של אבטחת מידע והבעיות מערכתיות שמתגלות זוכות לפתרון מיידי על ידי ההפצה ויישום אוטומטי של ה hotfixes . מצד שני בשרתי Apache שעושים שימוש ב PERL ו CGI יכולות להיות פרצות אבטחה שידועות כבר יותר מעשרים שנה ועוד לא קיבלו מענה , למשל מקרה המדובר : https://news.ycombinator.com/item?id=8813479
לזה אפשר להוסיף את הבעייה שמנגנון ה CGI זה תמיד מטרה רכה שכל תוקף תמיד יעדיף לבחור בה: [URL]http://www.governmentsecurity.org/_/articles/hacking-cgi.html[/URL] .
גם אפשר להזכיר את הבעיות של תקיפת שרת ישירות, וזה שלכל סוג של חולשה בשרת Apache ישר מתפרסמים שלל כלים שנותנים אפשרות לנצל את הפרצה גם על ידי גורמים שרק צריכים לדעת להריץ את הקובץ בלי להבין יותר מדי :
http://www.networkworld.com/article...bushed-by-sophisticated-backdoor-attacks.html
ואפשר להוסיף עוד מספר רב של ההיבטים על הנושא.

 

[duplo2]

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

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

 

[Y. Welis]

אגב פרצות של 20 שנה - גם ל-MS יש כאלה.

ועובדה היא שרוב השרתים מבוססי לינוקס, ועמידים יחסית.

 

[SysAdmin1]

בשרתים של Microsoft לא קיימות פרצות שמוכרות מסיבה אחת ...

בשרתים של Microsoft לא קיימות פרצות מוכרות כמו כאלה שהזכרתי מקודם ב Linux מסיבה אחת פשוטה לכל הפרצות המוכרות של Microsoft מייד נבנים HotFixes שפותרים את הבעייה . ב Linux המצב שונה לגמרי , המקרה המפורסם ביותר מהשנים האחרונות , שגם מי שלא נמצא בתחום מכיר אותו זה מקרה של heartbleed .
http://tech.firstpost.com/news-anal...ook-and-yahoo-passwords-right-now-221526.html
שבמקרה המדובר כל מי שהשתמש במודול של openssl , ( שירותי HTTPS , SSH ,SSLVPN, מרכזיות טלפון , שרתי RADIUS , נתבים של CISCO , JUNIPER , ומוצרים רבים אחרים ) ושהדבר המשותף ביניהם הייה שכולם היו שרתים על בסיס של LINUX היו חשופים במשך מספר שנים לחולשה ידועה שניתן הייה לנצל אותה בקלות וגם אחרי שהתפרסמו מספר גרסאות חדשות של מודול OPENSSL כל פעם הייה מסתבר שהבעייה לא נפתרה .
כל זה לא אומר שלא ניתן להשתמש כלל בפתרונות מבוססים LINUX , אלה רק שצריך לדעת בידיוק מה הסיכונים ואיך לנהל אותם ובאיזה מקרים פיתרון ספציפי מתאים ואיך ניתן לאבטח אותו.

 

[Y. Welis]

גם במקרה הזה תיקון נוצר מהר מאוד

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

 

[SysAdmin1]

מהר מאוד במוסגי LINUX , רק כשנתיים מאז שהבעייה נוצרה...

מהר מאוד במוסגי LINUX , רק כשנתיים מאז שהבעייה המדוברת נוצרה. גם ההמשך הוא הייה אופייני וצפוי מראש לטיפול בבעיות אבטחה ב LINUX , ההמשך הוא שבמשך שנה מאז שהפרצה התפרסמה בכל מקום אפשרי יצאו כעשרה מהדורות תיקון לבעייה הראשונית במודול של OPENSSL וכל מה שמשותף לכל הגרסאות, זה שכל אחת מהן הביאה איתה בעייה יותר חמורה מהקודמת. גרסה האחרונה לעכשיו התפרסמה בשבוע שעבר והיא אמורה לטפל בבעייה בשם OpenSSL “FREAK” vulnerability
http://www.symantec.com/connect/blogs/new-openssl-vulnerability-could-facilitate-dos-attacks
http://www.infoworld.com/article/28...nssl-versions-vulnerable-to-freak-attack.html
והגרסה הבעייתית הקודמת היתה אמורה לטפל בבעייה שנוצרה על ידי גרסה אחת לפני זה, שכולם הכירו אותה בשם POODLE
http://www.symantec.com/connect/blogs/poodle-vulnerability-old-version-ssl-represents-new-threat
https://www.us-cert.gov/ncas/alerts/TA14-290A
אפשר לראות את כל הרשימה של הפרצות שהתגלו רק במודול המדובר :
https://www.openssl.org/news/vulnerabilities.html
לזה אפשר גם להוסיף שבניגוד למערכות של Microsoft ששם הפתרון לבעיות הוא על ידי הפצה אוטומטית, במקרה של LINUX לא קיימת הפצה של התקונים אוטומטיים ולפעמים גם לא ניתן לעדכן את המודול הבעייתי וצריך לקמפל את כל המערכת מחדש ולפעמים גם זה לא אפשרי וצריך להמתין עד שמי שמפתח את התוכנה יואיל בטובו לכלול בגרסה החדשה את התיקון הנדרש. דבר נוסף ב LINUX קשה מאוד ולפעמים גם בילתי אפשרי למפות את כל המערכות שדורשות טיפול בבעייה, בגלל שהתיעוד של השימוש במודולים שונים לא תמיד קיים, כמו למשל שהסתבר עכשיו שהבעייה הנוכחית ב OPENSSL משפעיה גם על מערכות ויישומים של IOS ו Android . כל המדובר הייה בהקשר של מערכות SSL ששם אבטחה היא השיקול העיקרי. במערכות יותר מורכבות כמו Apache , בעייות אבטחה הם הרבה יותר סבוכות והניצול שלהם הוא הרבה יותר נרחב . צירפתי רשימה מתומצתת מהאתר הרשמי של Apache
http://httpd.apache.org/security/vulnerabilities_22.html
לרוב האנשים שלא באים מהתחום מדובר על רשימה של אותיות ומספרים, אבל למי שמתעסק בנושאים האלה יום יום ויודע מה הסיכונים העומדים מאחורי כל האותיות ומספרים האלה, מדובר על סימן אזהרה אדום מהסוג של "מוקשים הזהר" שמספיק בשביל לא להתקרב לצרות מהסוג המדובר או לעשות את רוב המאמצים לצורך הסבה של השרתים האלה למערכת אחרת יותר מוגנת, צפוייה, מתועדת ונתמכת, ואפילו שהרישוי שלה הוא לא בחינם, אבל לטווח ארוך השיכול הכולל יוצא פי כמה וכמה יותר זול.

 

[orell]

בקשר ל SQLI

מצורף מאמר על שאילתות פרמטריות בSQL שזה למעשה אחד המיטיגציות המרכזיות ל SQLI :
https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

בהצלחה

 

[Javali]

בוא נראה

Schannel - ספריית ההצפנה של מיקרוסופט.

• 2007 - ביצוע קוד מרחוק.
• 2009 - התחזות.
• 2010 - מניעת שירות.
• 2010 - ביצוע קוד מרוחק.
• 2010 - מניעת שירות.
• 2012 - זליגת מידע.
• 2013 - עקיפת תכונות אבטחה.
• 2014 - ביצוע קוד מרוחק
• 2015 - עקיפת תכונות אבטחה

לתשומת לבך, האחרון מטפל באותה בעיית FREAK שאתה טוען שהתיקון האחרון לheartbleed הביא.

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

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

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

 

[orell]

לא הייתי ממהר ואומר

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

 

[Javali]

סטטיסטיקות

http://news.netcraft.com/archives/2015/03/19/march-2015-web-server-survey.html
https://secure1.securityspace.com/s_survey/data/201502/index.html
http://w3techs.com/technologies/overview/operating_system/all

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

 

[Y. Welis]

הרוב עדיין. השאלה המעניינת היא מי נפרצים יותר