שווה פיסת נייר?

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

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

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

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

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

.

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

PayPal donation form reveals beneficiary's email address

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

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

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

אז הכנתי Advisory לנושא וניסיתי לשלוח ל-BugTraq אבל הם, למרות שזה לא רשום ב-FAQ שלהם, לא אישרו את הפרסום כי הם טוענים שהם לא מפרסמים פגיעויות הנוגעות לאתרים ספציפיים. שוין, לא נעלבתי ופרסמתי את זה ב-Full-disclosure.

אם תרצו דוגמאות ישראליות (לא שזה באמת משנה לנושא, סתם בשביל "הנקודה היהודית"…), אפשר לדוגמא לחפש את שתי המילים paypal תרומה בחודש האחרון ובדפים עם עברית בלבד:

http://www.google.com/search?hl=en&safe=off&rlz=1B3GGGL_enIL269IL269&q=paypal+and+%D7%AA%D7%A8%D7%95%D7%9E%D7%94&as_qdr=m&btnG=Search&lr=lang_iw

או כנ"ל רק עם המילים paypal לתרום

http://www.google.com/search?hl=en&safe=off&rlz=1B3GGGL_enIL269IL269&q=paypal+%D7%9C%D7%AA%D7%A8%D7%95%D7%9D&as_qdr=m&btnG=Search&lr=lang_iw

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

Suggested severity level: Low-to-Medium.

Type of Risk: Information Disclosure (PayPal account authentication (partial) and private email address).

Local / Remote activated: Remote.

Affected Software: PayPal web site, Donation form.
Access was tested and verified using Internet Explorer 8.0, Firefox 3.0.10 and Opera 9.64.

Summary: By clicking a recent version (so I believe, I can't trace and test various versions) of a PayPal Donation button, the beneficiary's primary email address is displayed in the header of the donation form, and of course, in the form's source code.
This email address is also the one used by the beneficiary to login into its account in PayPal and manage it operatively and financially.
The email address is displayed although in the process of creating the donation button – PayPal enable to choose an option to hide the email address, and this option is not working even if used (see the following "Self Reproduction" section for details).

Possible Abuses:  Phishers may use the beneficiary's email address to send him/her an attack email to try and break into this person's PayPal account using a phishing email and a malicious web page.
Other attackers can simply use the email address to brute force the beneficiary's PayPal account since the PayPal authentication is based on two values – the beneficiary's email address and a password, so now only the password is the unknown.
Spammers may simply harvest the beneficiary's email address to add it to the list of their spamming targets.

Reproduction:
1. Perform a search of any newly created donation buttons on web sites. For example search using Google for "donate via PayPal" or "donate using PayPal" pages indexed by Google in the last month (you may also try this queries without time limitation, it may also work):
a. http://www.google.com/search?hl=en&lr=&safe=off&rlz=1B3GGGL_enIL269IL269&q=%22donate+via+paypal%22&as_qdr=m&btnG=Search
b. http://www.google.com/search?hl=en&lr=&safe=off&rlz=1B3GGGL_enIL269IL269&q=%22donate+using+paypal%22&as_qdr=m&btnG=Search

2. Find in the search results sites which ask for a donation and click any link that leads to such site.

3. At the donation request page you landed at – click the donation button or link (If you use the Firefox security add-on "NoScript" (http://noscript.net) – turn it off (or temporary allow the beneficiary's site) before clicking the PayPal button or link, or you will be redirected away from the donation form to a main PayPal page).
Prefer pages with a more recent donation icons originated from  https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif (with logos of credit card firms)

paypal1

or https://www.paypal.com/en_US/i/btn/btn_donate_LG.gif (without the credit card firms logos).

paypal2

4. Read the beneficiary's primary email address at the top of the donation form in PayPal (located in the "h1" section of the HTML code of the form).

Self Reproduction (making your own button and clicking it):
1. Create a PayPal account at https://www.paypal.com/us/cgi-bin/webscr?cmd=_registration-run . A "Personal" account type will do.

2. After completing the creation of your account at PayPal, browse to a page made for creating the donation button – https://www.paypal.com/cgi-bin/webscr?cmd=_button-designer&factory_type=donate .

3. At this page, at the "Email address to receive payments" field, click the "Log in" link. You will go via the regular PayPal authentication process and then will be redirected back to the button creation page, this time as an authenticated PayPal customer.

4. In the "Merchant ID for purchase transactions" field choose the option of "Secure merchant account ID".

paypal3

Next to this field there will be a link titled "Why is this secure?" (https://www.paypal.com/il/cgi-bin/webscr?cmd=xpt/Merchant/popup/BDSecureMerchantId) which states: "A secure merchant account ID is a number that only PayPal can match to your real email address in your profile. Your primary e-mail address is never displayed, so it cannot be used by spammers.
If you choose a plain text e-mail address, however, it will be displayed in the button code. Anyone, including spammers, can copy this address for their own use."

paypal4

5. Click "Create Button" and then copy the code created for the donation button and place it as part of the HTML code of any web page you own.

6. Load the web page you just created to be displayed using a web browser and click the "Donate" button (see the above note about "NoScript"). You will be directed to the PayPal donation form where you will be able to read the primary email address of your PayPal account on the top of form (located in the "h1" section of the HTML code of the form).

paypal5

Exploit Code: There is no need for an exploit code.

Direct solution: Not any that I am aware of at the time of writing this advisory. I guess the solution can only be made by PayPal since its their web site form.

Workarounds: Not any that I am aware of at the time of writing this advisory.
I can only advise PayPal donation users to stop using the donation button until PayPal solves this issue, and thus to remove any PayPal donation buttons and links from their site until this issue is fixed.

Vendor response:
PayPal was notified by email on the 25-April-2009 (sitesecurity@paypal.com , found at https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/ReportingSecurityIssues-outside).
Two days later, after some email exchange, the following final response was given by PayPal:
"
I’ve discussed with the product team and there is probably some language cleanup needed on the signup forms.  The intent of the feature is not to prevent showing the email address during a payment flow, but to prevent the harvesting of the email address from the site hosting the donation button.  The bug, if any, is in the language describing the feature not in the feature itself.  Thank you for bringing it to our attention.  The product team is filing a change request to adjust the language and make it clearer.
"
So the mentioned above security option is for making a more secure button code for the beneficiary's web site, but still PayPal did not answer about the issue of their own form exposing the beneficiary's email address at their own web site.

Credit:
Eitan Caspi
Israel
Email: eitancaspi (at) yahoo (dot) com

Past security advisories:

1.
http://www.microsoft.com/technet/security/bulletin/MS02-003.mspx
http://support.microsoft.com/kb/315085/en-us
http://online.securityfocus.com/bid/4053

2.
http://support.microsoft.com/?kbid=329350
http://online.securityfocus.com/bid/5972

3.
http://www.securityfocus.com/archive/1/301624
http://online.securityfocus.com/bid/6280

4.
http://online.securityfocus.com/archive/1/309442
http://online.securityfocus.com/bid/6736

5.
http://www.securityfocus.com/archive/1/314361
http://www.securityfocus.com/bid/7046

6.
http://www.securityfocus.com/archive/1/393800

7.
http://www.securityfocus.com/archive/1/archive/1/434704/100/0/threaded

8.
http://www.securityfocus.com/archive/1/archive/1/446220/100/0/

9.
http://www.securityfocus.com/archive/1/459140/30/90/threaded
http://www.securityfocus.com/bid/22413

10.
http://www.securityfocus.com/archive/1/460664/30/60/threaded

11.
http://www.securityfocus.com/archive/1/472216/30/0/threaded

Eitan Caspi
Israel

Security blogs (Hebrew) – http://security.caspi.org.il

"Technology is like sex. No hands on – No fun." (Eitan
Caspi)

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

הבלש של מיקרוסופט

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

אז כן, היו אלו אירועי DHCP Discovery, אולם הפרטים שלהם כללו שלושה מאפיינים מטרידים:

1. כתובות ה-MAC היו מזויפות בעליל ולא שייכות לשום יצרן תקשורת. למשל, 4d:c8:43:bb:8b:a6 או 45:3b:13:0d:89:0a שלא העלו שום שם יצרן באתר חיפוש התאמות MAC ליצרן.
2. הכתובות הנ"ל התחלפו בתוך 3 שניות…
3. שם ה-Domain היה DETECTIVE… (שכמובן לא היה קיים ברשת המדוברת)
אופס, חשבתי לעצמי, יש כאן מישהו או משהו רע…

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

פניתי לעובד שאחראי על ה-VLAN בו התרחשה הפעילות והוא אמר שבתאריך ובשעה המדוברים הוא עבד על שרת מסוים, מבוסס "חלונות 2003‏". בדקתי את כתובות ה-MAC של השרת ולא מצאתי את הכתובות שהופיעו ב-IPS, ניסיתי למצוא תהליכים רצים לא מוכרים או משהו שעולה באתחול – ולא מצאתי שום דבר חריג.
בשל חוסר יכולת להמשיך הלאה בחקירה, תייקתי את המקרה כוודו ממוחשב והמשכתי הלאה.

אבל לאחר כחודש בערך, התופעה חזרה במדויק. שוב אותו עובד, שוב שרת 2003 אבל שרת אחר.
הפעם, אמרתי לעצמי, הולכים עד הסוף.
תחקרתי לעומק את העובד, שמוכר לי כמבין עניין ואחראי, והוא אמר לי שהוא חושב שבשני המקרים הוא הפעיל את ה-Configure Your Server Wizard של 2003.
אם כך, אמרתי לעצמי, נעלה בשרשרת המזון.

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

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

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

ואז, סוף סוף, הארה! פול מתמיכת הפרמייר באנגליה, שיש לו, למזלי, גישה לקוד המקור של המוצרים, אישר, כבר במייל הראשון שלו, כי המילה Detective נמצאת רק פעם אחת ורק בקוד של "חלונות 2003‏" ובדיוק ביישום Configure Your Server Wizard…
בקיצור, הוא אישר את הממצאים שלי ושל אלו שנמצאו ברשת, ואמר שזו דרכו של ה-Wizard לאתר שרתי DHCP פעילים ברשת, להתחזות ללקוח "לא קיים" רק לצורך הבדיקה.
הסברתי לו שהשיטה הזו יכולה לגרום לכמה אנשי אבטחת מידע או מנהלי רשתות התקף לב, לראות MACים מזויפים ברצף מהיר בתוספת דומיין בשם DETECTIVE… ולכן כדאי שמיקרוסופט תפרסם מאמר KB על הנושא, בכדי שלקוחות יקבלו "צפירת ארגעה" מהיצרן עצמו. הוא הסכים איתי, ואמר שהוא ידאג לכך.
תענוג. זו תמיכה.

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

אז לקח להם מספר חודשים טובים, והגרסה הראשונה הייתה טכנית ומבולבלת, אבל בסוף הם התאזנו עם גרסה סבירה אם כי לא מאוד ידידותית או תואמת לבעיה, ב-KB מספר 945948, שגם מופיע כאפשרות הראשונה אם מחפשים ע"י גוגל את המילה DETECTIVE באתר התמיכה של מיקרוסופט, כך שהסיכון להתקפי לב ירד, וכל המציל נפש Security Admin אחד

אני את שלי עשיתי.

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