אני אוהב לצפות בהצגות תיאטרון, במיוחד בתיאטרון אבטחה עם D-Bus בלינוקס

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

 

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

 

לדוגמה:

פתחו למשל את מנהל הסיסמאות החביב עליכם (אני משתמש במנהל הסיסמאות של kde)/

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

 

בשביל זה מה שאנחנו נעשה יהי פתיחת המנהל:

qdbus org.kde.kwalletd6 /modules/kwalletd6 open kdewallet 0 akonadi-ews
 

 לאחר מכן נקבל handle או מזהה איתו אנחנו נוכל לבצע פעולות. מדובר במזהה מספרי.

למשל על מנת לצפות בכלל הסיסמאות השמורות במערכת (של כל התוכנות ששמרו סיסמאות ) מספיק לבצע (כאשר ה 12345678 זה מה שקיבלנו בשלב הקודם) :

qdbus org.kde.kwalletd6 /modules/kwalletd6 folderList  12345678   akonadi-ews
 
עכשיו אותנו מעניין רק הסיסמאות של אקונאדי הזה , אז נציג רק את המשאבים השמורים תחתיו ואלו יהיו :

dbus org.kde.kwalletd6 /modules/kwalletd6 entryList   12345678 "akonadi-ews"   akonadi-ews

נבחר אחד מהם ונציג את הסיסמא השמורה בתוכו:

qdbus org.kde.kwalletd6 /modules/kwalletd6 readPassword  12345678 "akonadi-ews" "akonadi_ews_resource_0rc"  akonadi-ews


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

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

באופן כללי אני דוגל בגישה של חלוקה, כלומר מכונת וירטואלית לגלישה לאתרי ממשל, מכונה וירטואלית לצפייה בחומר לימודי, מכונה וירטואלית לIRC , מכונה וירטואלית למטריקס, מכונה וירטואלית לבניית קוד, מכונה וירטואלית לVPN ועוד ועוד, ולדברים קטנים אני משתמש פשוט ב podman (כמו למשל דפדפן FF שעטפתי) .  לגבי הטענה שבגלל dirty frag השימוש במכונות וירטואלית דה פקטו יספק משתמש רוט על המחשב שלי, אני לא מקבל את זה, אני עדיין רוצה להאמין שזה לא ייפרוץ החוצה, אבל בכל מקרה , על מנת שזה ייקרה המכונה עצמה צריכה להיות מלוכלכת ושנפרצה מראש.

בקיצור אז בואו לא נצחק על אחרים , זה לא שאנחנו טובים יותר.

דרך מהירה לעטוף אתר בשביל L5 תחת podman ללא root

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

הדרך שבחרתי היא לייצר פרופיל משתמש של דפדפן רק עבור האתר הזה, ואת הדפדפן להריץ תחת podman בצורה הזאת להפריד אותו חלקית ממערכת ההפעלה. לצערי בגלל שזה wayland לא הצלחתי לבצע ללא שימוש ב userns ולא הצלחתי להעביר קול, אבל במקרה הזה אין לי צורך בקול באתר הזה. ניסתי להעביר את /run/user/1000/pipewire-0 פנימה אבל הקול לא היה נשמע במכשיר (יש pipewire על ה L5 שלי).

מה שעשיתי הייה לייצר טסריט שמכיל את המלל הבא: 

  podman run --rm -e XDG_RUNTIME_DIR=/tmp  -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY -v /home/mobian/pod:/home/  -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY  --userns=keep-id:uid=$(id -u),gid=$(id -g) -t ff-esr:v2

את הפוד עצמו ייצרתי מהקובץ הבא:

FROM debian:bookworm
COPY sources.list /etc/apt/sources.list
RUN apt-get update 
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y -f firefox-esr
ARG user=user
ARG group=user
ARG uid=1000
ARG gid=1000
RUN groupadd -g ${gid} ${group} -f
RUN useradd -u ${uid} -g ${group} -m ${user}

USER ${uid}:${gid}
CMD ["firefox-esr"]

  

לאחר מכן מייצרים קובץ desktop שמפעיל קובץ bash שמכיל את ההפעלה הזאת, את הקובץ צריך לשים תחת 

/home/mobian/.local/share/applications/fafus.desktop

 בתוך הקובץ desktop שמים קישור להפעלה לדוגמא:

 

[Desktop Entry]
Type=Application
Name=Fancy App for Useless Site
Icon=/home/mobian/src/fafus/app.png
Exec=/home/mobian/src/fafus/app.sh
Terminal=false
X-Purism-FormFactor=Workstation;Mobile;

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

 

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

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

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

להפתעתי הגמורה המוסד דרש הרשמה בקישור,  בדר"כ מוסדות מבצעים הרשמה אצלהם במשרדים, אבל בסדר , המאה ה21 והכל. אני פותח את הקישור ומה אני רואה ? טופס של גוגל שאוסף מספרי זהות , שם פרטי , שם משפחה , מייל ,  אני יודע שהטופס אמור אישהוא לבצע סליקה בסוף אבל לא הגעתי לנושא הזה. אני מאוד מקווה שלא היה שם איסוף מספרי כרטיסי אשראי כי אז יהיה מדובר על וואחד פרצת אבטחה ומעבר על PCI-DSS).

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

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

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

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

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

אפרופו סליקה, אני עדיין לא מבין אם יש אפשרות לשלם שם עם דברים כמו  google-pay, האמת זה היה יכול להיות פיטצ'ר די נחמד באתרי מכירות אם תהיה אפשרות לשלם בפתרונות כמו  בgooglepay או אפילו librepay.

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

שמתם לב שרק gitlab.gnome.org עובד והמון מקומות אחרים פשוט לא מתפקדים ? אז מתברר שמדובר ככל הנראה בהתקפות DDOS שתוקפות שרתי קוד פתוח, עכשיו נכון שלא באמת אכפת לי אם יעיפו שרתים כמו codeberg עכשיו עם מה שהם מאחסנים אצלהם, אבל שרתים אחרים ? זה חתיכת סרט.

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

לא רק שחברות ה LLM לא נותנות קרדיט בכל תשובה מהייכן הם השיגו את המידע שלהם, מתברר שבחלק מהמקרים הם פשוט סורקים כל דומיין כל מספר שעות, כן אם יש שרת git הם עושים סוג של DDOS בכל פעם כשהם סורקים, הם עושים מספר בקשות קטן ממקורות שונים ופוף מה קיבלנו ? זה פשוט DDOS.אהה, ואם חוסמים לפי robots.txt או DPI אז הם פשןט מחליפים UA וזהו.

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

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

השתמשתם בסיסמא מול שרת שמוגן בCloudFlare , החליפו אותה מייד, מתברר שאספו ועיבדו שמות משתמש וסיסמאות לאתרים המוגנים ב CF

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

 

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

משתמשי קצה, להחליף את כלל הסיסמאות.

 

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

If you are using Dell's Sonicwall netextender vpn client on linux, do not update the client software ,instead use the the version you have from your router, run it inside a VM, that way even if you upgrade the VPN firmware you could always use the correct version for it

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

המכשירים של Sonicwall כל כך פופלארים, שאפילו רופאי השיניים בשכונה יש להם את זה במשרד, גם למכון טיפולים משמרים יש כאלה, המכשירים האלה היו אמינים, זולים ודי פשוטים שזה היה entry-level למשרדים קטנים.

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

הservice שלי נראה כך:

[Unit]
Description=SSLvpn
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=5s
StartLimitBurst=10

[Service]
#ype=oneshot
RemainAfterExit=yes
ExecStart= screen -Dm /bin/bash -c "echo Y | \
 /home/user/Downloads/netExtenderClient/netExtender\
 -u vpnuser -p SuperSecretPasswordYoushouldNeverKnow \
  -s 142.250.75.193:4433 -d myrtfm.blogspot.com -M 500"
User=user
Group=user
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

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

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

הOpenVpn שרץ על המחשב הוירטואלי אחראי להעביר את כל התעבורה.

במחשב הפרטי שלי אני מפעיל את ה VM , מפעיל לקוח openvpn שמתחבר לVM, ואז יש לי גישה מלאה לרשתות אותם לקוח ה SonicWall נתן.

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

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

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

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

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

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

לפי הקורבן, בבדיקה שנעשתה מול הבנק, הבנק (פועלים) חסם את ניסיון ההעברת הכספים , המלצנו לקורבן להסיר את כלל אפליצקיות הניהול של הכספים והנכסים שלהם מהמכשיר, ולהגיע פיזית כל פעם, כי אם נפלתם בנושא פעם אחת, תיפלו בו בפעם נוספת. כאשר הקורבן הגיע לנקודת תמיכה (לא ברור אם הבנק או מקום בו מתקנים טלפונים) , נאמר לו שמספיק לאפס את הסיסמה בפועלים באינטרנט, מדובר בהמלצה בלתי מקצועית, ברגע שהייתה התקנה של משהוא על המכשיר , כל מה שיש על המכשיר הוא compromised, אפשר להחליף סיסמאות עד מחר, זה לא יעזור כי לתוקפף הייתה גישה שייכל להתקין keyloagger ווכל זבל אחר,  במקרים כאלה הכול אמור להיות מוסר, לכל הפחות factory reset וחזרה מגיבויי לפני ההתקפה, אין גיבויי ? שומרים מספרי טלפון, הודעות והקלטות למדיה חיצונית, בודקים אותם ע"י הכלים החביבים אליכם, חוזרים להגדרות יצרן ומחזירים את התמונות וההודעות.

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

עכשיו, אילו למשל האפליקציות כמו whatsapp ואפליצקיות ניוהל החשבון הבנקאי והניהול הרפואי של האנים היו דורשות רכיב חומרתי בשביל לאמת כל פעם ? אז הבעייה היתה פתורה מלתחילה, והאמת לא באמת חייבים אפליקציות , מספיק שתבנו אתר מספיק טוב, ושם המערכת הזאת כבר קיימת המון זמן, למעשה ניתן להתחבר להרבה מאוד שירותים באמצעות באמצעות רכיבי אימות חומרתי , החל מגוגל דרך Github ואפילו בתוך ebay ! משיטוט באתרי הבנקים הגדולים לא מצאתי אפשרות שהם יוכלו להתשתמש בכרטיס חכם חומרתי לאימות (ולא הודעת SMS או תוכנות OTP למיניהם).

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

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

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

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

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

אז דבר ראשון קצת סדר, לפי מה שאני יודע, בארץ,  ניתן לחטוף (לתמיד או לרגע) רק מספרים סלולארים, לא ניתן לבצע העברה פשוטה למספרי VoIP או מספרי PSTN (מספרי בזק) , לכן לחזור למספר בזק (ואני לא מסבר על כל ה 07X שהם מספרי VoIP/VOB) זו עדיין שיטה יחיסית בטוחה מכיין ש number portability עדיין לא מאפשר החלפת מספרים כאלה למקומות אחרים, ממה שהבנתי מקולגה הLocal Number Portability למספרים נייחים כן עובד היום בצפון אמריקה, אבל החטיפה שם למספרים כאלה היא יותר מורכבת ודורשת הנדסה חברתית. כן , אין שום בעייה לחטוף חשבונות ווצאפ וסיגנל.

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

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

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

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

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

 

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

 

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

המלצה חמה לרופאי משפחה ואיך לצפות בצילומי mri ו ct בדביאן.

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

 

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

לאחר ביצוע ה MRI יכולים להתקבל קבצים במספר תקנים, ראיתי בנתיים את  האפשרויות קובץ dcm בודד,  מספר רב של קבצי dcm ביחד  עם קובץ index  ו xml  , מספר קבצי dcm עם קובץ txt המגדירים את הסביבה , מספר קבצי png וקובץ xml המגדיר את הסביבה. תיקיית dicomdir, וקבצי ה dcm הם פרוסות הסריקה.

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

000002d0              10 00 3f 3f  3f 3f 5e 3f 3f 3f  3f   |..PN..????^???|
000002e0   3f 3f 3f                                        |???           |

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

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

ניתן לצפות בתוכן בשתי גישות:

דורש פחות מקום בדיסק: אם רוצים להסתקל אך ורק על קבצי dcm (בלי לבצע stacking) ניתן להשתמש בAeskulp ושם לבחור ב Open ולסמן את כל קבצי ה dcm ישירות וללחוץ open.

 
דורש יותר מקום בדיסק:

בכלי dicomscope ובכלי xmedcon צריך קודם לאסוף את כל הקבצים לקובץ dicom בודד ע"י שימוש ב medcon

    medcon -f *.dcm -c dicom -stack3d -n -qc 
    

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

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

 

ניתן לקבל  באמצעות פקודות curl משרת ה pacs שלכם, אם למשל משתמשים ב dicom-server זה יהיה בהנחה והממשק נגיש תחת hospital.local :

curl --request GET "https://hospital.local/studies/$study_id/series/$series_id/instances/$instance_id" --header "Accept: application/dicom; transfer-syntax=*" --output "suppressWarnings.txt"

המשתנים $series_id $study_id ו $instance_id ניתן לקבל מהמאפיינים הידועים לנו מראש (אפשר לקבל את זה מכל קובץ dcm קודם שוהרדתם כבר או קיבלתם במייל / הודעה וכו ). במידע ובשרת שלכם הפעילו oauth2 יהיה צריך להעביר גם את ה barrier (כפי שאני מבין, אימות הוא אופציאונאלי).

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

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

דוגמא להצגה בממשק של dicomscope:

 

 דוגמא לממשק של Aeskulap:

 

דוגמא לממשק של xmedcon:

המלצה חמה:

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

חוק צרפתי מאשר למשטרה לפתוח מיקרופנים ואמצעי איתור מרחוק

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

 

העניין, הוא, שאם אתה אדיוט שמסתובב עם מכשיר סלולאר מתקדם שלא מריץ תוכנה חופשית על המודם שלו וכמערכת הפעלה שלו , זה כבר קיים שנים (אפילו דיברנו על זה באוגוסט פינגויין). האפליקציות שאתה מריץ מדווחות הבייתה מה הן רואות (למשל כתובות IP ולפעמים אפילו נתוני ה GPS שלך, פאק אפילו שירות ה AGPS מספק ליצרנית הגדולה בעולם (אני חושב בבעלות Qualcom) את הפרטים שלך בחיבור, לפחות במקרה של geoclue אנחנו יודעים איזה מידע נוסף נשלח לשם. ותודות למוזילה הקקות המון כתובות WiFi והמיקום שלהם עברו לציבור הכללי. עם כל הזבל דיגיטלי שאנשים שמו על הטלפונים שלהם ? אין לכם מושג מה נשלח וכמה נשלח אפילו ע"י מערכות ההפעלה עצמן.

 

האמת , הסיפור של החוק הזה זה נשמע הרבה יותר קריפי, מאשר שזה באמת, נכון לעכשיו פשוט יוזמים שיחת חירום שבהגדרה שלה אנחנו מבקשים ממערכת ההפעלה לקבל מיקום (כולל WiFi , GPS למשל). ממה שאני מכיר בדרך כלל הפעולה הזאת אמורה להיות אך ורק מצד המשתמש (מנכנון שיחת חירום הפותח את המידע הזה), אבל ישנם גם טכנלוגיות שכבר עכשיו אומרות הייכן נמצא כל משתמש ברשת הסלולאריות בשביל זה יש לנו בקשות מסוג LR-MO  , LR-MT  ו LR-NI. הבקשות אמנם לא מבקשות את נתוני הGPS שלכם , אבל הם מספקות את המידע שהתא שלכם יכול לדווח עליכם, עכשיו נניח ואתם משתמשים ב WiFi-Calling אז אנו יודעים את המיקום הגאוגרפי ברמה הרבה יותר מדוייקת (כי אנו יכולים לקבל כתובת לפי כתובות IP מספק השירות).

 

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

 

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

פרטיות וקוד פתוח חשובים לכולם תשובה לכתבה של בר זיק שקישר בין קוד פתוח ופרטיות לבין פעילות פוליטית

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

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

לא משנה באזו מדינה משתמשים , לא משנה מה סוג השימוש, *תמיד* צריכים להצפין את המיילים שלנו, לכל דבר, תמיד צריך להשתמש ב vpn, זה אמור להיות במצב ברירת מחדל. כן , גם המייל לועד הבית צריך להיות מוצפן ב PGP (ואני יודע שכמה אנשים חשובים התעצבנו עלי שאני משתמש ל PGP גם בשביל דברים טריוויאלים). היום כמעט כל מעסיק (שאני מכיר) מספק vpn לעובדים שלו, בהמון מקומות מספקים אפילו רכיבי openpgp ,ובהמון תחומים ישנה דרישה של הסכמים/תקנות ואף החוק למנוע זליגת מידע לגורמים שלישיים, בצורה פשוטה דליפות מידע זה כאב ראש לא קטן.

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

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

 

 אפילו NordVpn היו צריכים להסביר לאנשים מתי ואיך הם מגיבים לדרישות החוק והם נתנו את אחד ההסברים הטובים ביותר לVPNים חוקיים שיש  :

• However, if a court order were issued according to laws and regulations, if it were legally binding under the jurisdiction that we operate in, and if the court were to reject our appeal, then there would be no other option but to comply. The same applies to all existing VPN companies if they operate legally. In fact, the same applies to all companies in the world.

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

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

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

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

 

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

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

משלוח כסף ע"י מספר טלפון או איך יהיו עכשיו המון הונאות לאנשים

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

 

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

מדוע יהיה שמח תשאלו ? מי שעוסק בתקשורת בשלושים השנים האחרונות יודע כי SS7 מאובטח או הודעות SMS עם סיסמה חד פעמית בטוחה כמו שאני זכיתי בפרס נובל לפיזיקה.

 

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

 

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

 

אני מכיר מספר אירגונים , שכל כך התרגלו שיש להם התקפות spear-phishing שהם פשוט לא משתמשים יותר ב SMS ושיחות מטלפוניה קלאסית, הם רק משתמשים בVoIP פנימי וזהוא. בהתקפה הגדולה במוזמביק דובר על תשלום של $15 לכל מספר (כן חמש עשרה דולר).
 

איך זה עובד ?
בחלק מהחברות סוגרים עסקה עם עובד מושחת (זה יוצא די זול במושגים שלנו) , במקומות אחרים יש מספר חברות שמאפשרות לכם לחטוף מספר טלפון במחיר של כמה אלפי אירו ליום (כתבה על הנושא אינני יודע אם השרת שם אמיתי או גם הונאה ויש המון הונאות בתחום), ותוכלו מכל נקודה בעולם לזייף ולחטוף מספר טלפון ב SS7, בארצות הברית למשל חסמו את הבעייה הזאת רק לפני שנתיים, אצלנו אלוהים יודע. בשנת 2021 היו 1600 תלונות של חטיפת מספרים ל FBI (ברור לנו שלא כולם מתלוננים לשם). חתיפות מספרים אפשרית בכל ספק המחובר להרבה מאוד ספקים. בהתקפות בברזיל היו הפסדים של 50K$ פר משתמש למשל. בכל הפתרונות צריך ציוד חיבור ל ספק המוכן לבצע את הפעולה (מספיק עובד אחד מושחת) ובדיוק כמו AS המוכן לבצע את הפעולות חטיפת כתובות BGP גם ב SS7 זה תמיד יכול להתקיים.

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

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

 

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

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

בחלק מהסויטצים ו ה SBCים קיימת הגדרה לחסום את זה, אם אתם משתמשים ב OpenSer צריך לממש זאת לבד, כברירת מחדל במקומות בה זה קיים זה לא מופעל כברירת מחדל (אתה לא חוסם העברת מספר שביצע forwarding כברירת מחדל מהפחד שדברים ישברו).

אפשר גם לשלוח SMS ים ככה עם הספק שלכם מאפשר (בדר"כ כן בתוך המדינה של הספק אבל לא לבן לאומי ) , SMSים ב SIP עוברים תחת SIMPLE ולא כל הספקים תומכים בזה. אינני מכיר ספק אחד שממיר כמו שצריך sip/sigtran. איך אפשר לשלוח SMSים אפשר להשתמש ב yate-qt אבל אפשר אפילו להשתמש ב sipp (או ב sip-tester שמגיע מהמארגים שלכם)

 

קבלת SMS : קיימת אפשרות בצורה כזאת רק בחלק מספקי התשתית ובדר"כ לא .

 

לרוב המכריע של האנשים אין מכשיר דוגמת YubiKey שמאמת עבודה עם חשבון הבנק,עם יש לכם אפשרות להעביר כספים באמצעות אפליקציה או שיחת טלפון מאוד מאוד רצוי שיהיה לכם אימות YubiKey, כי אם לא , לזייף העברה לא  עולה לכם דבר. לצערי הרב yubikey איננה חומרה חופשית, מצאתי אמנם קוד פתוח שלהם github.com/Yubico וגם מצאתי את היצרן SoloKeys שטוען כי הוא גם מכיל firmware פתוח אבל לא הכל מושלם שם.

למעשה הנחיית CISA היא לעבור להשתמש ב FIDO/U2F או לעבור ל PKI לכל אירגון, אבל היום עדיף לכל אדם פשוט לעשות זאת, שימוש בPKI פשוט יותר, אבל לא נתקתי בשום בנק או אירגון שמאפשר זאת למשתמשים שלו.

לדעתי האישית כל מפתח אתרים צריך להכניס flow בו הוא מאפשר שימוש התחברות ע"י U2F או לפחות תעודת לקוח (client certificate) כברירת מחדל , ורק אם אין אז לאפשר שם משתמש וסיסמה.

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

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

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

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

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

פיאסקו פנימי בגלל שינוי הזדהות ל OAUTH2 בשירותי מיקרוסופט (לא ניתן לגשת לשירותי הדואל של המשרדים לexchange).

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

 

ההודעה הייתה כבר די מזמן ויש הודעה למשתמשים בפורום התמיכה של מיקרוספט. 

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

 

לקוחות IMAP ייקבלו את השגיאה הקריפטית :

 

A0000002 NO AUTHENTICATE אם יינסו לעבור אימות באמצעות PLAIN ע"ג SSL/TLS בפורט 993 (תקף לכל תוכנות הדוא"ל).

 

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

 

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

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

מה שנפגע אלו הם לקוחות ה IMAP שביצעו הזדהות שלא באמצעות oauth2,.

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

 

לקוחות MAPI שלא מזדהים ב oauth2 (שאפו לevolution שעשו את העבודה בזמן).

 

נכון לעכשיו כל לקוח דוא"ל (SMTP או POP/IMAP) רצויי מאוד שיממש דחוף תמיכה ב oauth2 , מכיוון שכל הספקים הגדולים עוברים לזה, זו הסיבה מדוע הייתה בעייה להתחבר ל gmail לפני זמן מה.

יש מימוש (כפרוייקט חיצוני) ל mutt שמאפשר oauth2, רק שאני חושב שיהיו מעט משתמשי לינוקס שיעברו ל mutt כלקוח הדוא"ל המועדף עליהם :) 

בK9 פרסמו שהוסיפו תמיכה ב oauth2 כבר ביולי, אז הגיע הזמן לשדרג ;-)

ממה שראיתי המימוש שקיים באקונדאי מקבל תוקן קצר מדי (תוך 24 צריך לבצע זיהוי מחדש).

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

ממשקי הווב ממשיכים לעבוד ללא שום בעייה כלל.

 

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

שלום עולם IPv6

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

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

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

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

מכיוון שיש לי נתב פשוט , ברגע שהופעל ipv6 ברמת הספק , הכל עבד בצורה חלוקה (תודות ל RFC 4861 ו המימוש של Router Advertisment ב NetworkManager). למה זה פשוט עובד? כי IPv6 תוכנן מזמן וכל נתב מסכן שמריץ openwrt כבר מגיע מוכן לתמוך בIPv6 בלי שום התעסקות.

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

עברתי מחשב מחשב וראיתי שבכולם ה privacy mode היה מופעל , שזה המצב התקין  פרט למכונת Win10 בה הגדרתי את המוד. מדוע ה privacy mode של IPv6 חשוב תשאלו ? כי אם לא תפעילו אIP שלכם יכיל את כתובת ה MAC שלכם .

 

בחלק המחובר לנתבים להם יש גישה לאינטרנט מצאתי פדיחה רצינית : 

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

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

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

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

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

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

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

Error running context: An error occurred during SSL communication at /usr/share/perl5/Git/SVN.pm line 148.

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

אחד הדברים שנפגעו מזה זה כל מה שמשתמש ב serf ו tls.

ספקים שדאגו להתכונן לעניין (כמו apache ו github) לא נפגעו ומאפשרים לבצע checkout :

  svn co https://svn.apache.org/repos/asf/subversion/trunk subversion 
A    subversion/build
A    subversion/build/ac-macros
A    subversion/build/generator
A    subversion/build/generator/swig
A    subversion/build/generator/util
A    subversion/build/generator/templates
A    subversion/.editorconfig
A    subversion/build/generator/swig/external_runtime.py
A    subversion/README
.
.
.

אבל יש ספקים אחרים בהם התוצאה היא שאי אפשר לבצע clone / checkout מהם ומקבלים את הדבר הבא :

git svn clone https://cloudservice.com/project/trunk

Initialized empty Git repository in /tmp/svn/trunk/.git/
Can't create session: Unable to connect to a repository at URL 'https://cloudservice.com/project/trunk': Error running context: An error occurred during SSL communication at /usr/share/perl5/Git/SVN.pm line 148.

וגם ב subversion  :

svn checkout https://cloudservice.com/project/trunk .  
svn: E170013: Unable to connect to a repository at URL 'https://cloudservice.com/project/trunk'
svn: E120171: Error running context: An error occurred during SSL communication

לאחר חיפוש גיליתי שהבעיה היא בהצעת הצופן של הספק :

openssl s_client -connect cloudservice.com:443 2>/dev/null |grep 'Cipher is'
New, (NONE), Cipher is (NONE)

אצל ספקים אחרים שאין את הבעיה הזאת כמו github ו apache הפלט יהיה :

openssl s_client -connect github.com:443 2>/dev/null |grep 'Cipher is'
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256

openssl s_client -connect svn.apache.org:443 2>/dev/null |grep 'Cipher is'
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384

השרתים בהם יש בעייה לבצע checkout  ,  כן מספרים שהם תומכים ב TLS 1.2 אבל יש בעייה בהצעה עצמה :

New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000

המעקף היחיד שמצאתי לדבר הזה הוא שימוש בקובץ openssl.cnf מיוחד עבור השירות הזה :

diff openssl.cnf unsecure_openssl.cnf 
361c361,362
< MinProtocol = TLSv1.2
---
> #MinProtocol = TLSv1.2
> MinProtocol = none

והשימוש כך :

$ OPENSSL_CONF=/tmp/unsecure_openssl.cnf git svn clone https://cloudservice.com/project/trunk                                                             
Initialized empty Git repository in /tmp/svn/trunk/.git/
r1 = 50dd6cc1cc8224a37e5bac80a5ba6ad88e01a96a (refs/remotes/git-svn)
        A        ar/messages/extragear-pim/kmobiletools.po
.
.
.

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

מתקפת מניעת שירות

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

בערך מה-20 לחודש פברואר 2018 התחילה מתקפת לוחמה אלקטרונית הפוגעת בשידור אלחוט שפוגע בשירותי 3G ו LTE.

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


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

מכייון שמצד המקבל כמעט ולא תהיה לנו אינדיקציה שיש בעיית שירות (הקליטה נמוכה אבל קיימת), די קשה להיות מודע שיש איזה בעייה.

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

• כישלון שיחות נכנסות:

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

• בעיות גלישה כגון RTT מאוד גבוהה (זמן פינג?) :

למעשה כאשר אנו היינו במצב מחובר (ppp הצליח להתחבר ) אנו לא נידע שיש בעייה עד אשר התוכנות שהיו מחוברות ייכשלו.

לדוגמה הkeep alive שלי זיהה זמני RTT הזויים :

64 bytes from 8.8.8.8: icmp_seq=100 ttl=63 time=90147 ms
64 bytes from 8.8.8.8: icmp_seq=101 ttl=63 time=89123 ms
64 bytes from 8.8.8.8: icmp_seq=102 ttl=63 time=88128 ms
64 bytes from 8.8.8.8: icmp_seq=103 ttl=63 time=87109 ms
64 bytes from 8.8.8.8: icmp_seq=105 ttl=63 time=85121 ms
64 bytes from 8.8.8.8: icmp_seq=104 ttl=63 time=86145 ms
64 bytes from 8.8.8.8: icmp_seq=106 ttl=63 time=84109 ms
64 bytes from 8.8.8.8: icmp_seq=107 ttl=63 time=83095 ms
64 bytes from 8.8.8.8: icmp_seq=108 ttl=63 time=82106 ms
64 bytes from 8.8.8.8: icmp_seq=109 ttl=63 time=81086 ms
64 bytes from 8.8.8.8: icmp_seq=110 ttl=63 time=80061 ms
64 bytes from 8.8.8.8: icmp_seq=111 ttl=63 time=79090 ms
64 bytes from 8.8.8.8: icmp_seq=112 ttl=63 time=78089 ms
64 bytes from 8.8.8.8: icmp_seq=113 ttl=63 time=77064 ms
64 bytes from 8.8.8.8: icmp_seq=114 ttl=63 time=76046 ms
64 bytes from 8.8.8.8: icmp_seq=115 ttl=63 time=75024 ms

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

• הודעות (SMS) :

הודעות SMS הגיעו בין 30 דקות לשעה ליעדן

נבדק ע"י :

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

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

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

• הודעות (MMS) - MMS בדומה ל גלישת דאטא משתמש באפיק אחר מאפיק הקול (כאשר לא משתמשים ב VoLTE).

נבדק ע"י :

נבדקו שני חברות שונות , באחת היה איחור של 10 דקות בשני היה פשוט כישלון מוחלט לבצע שליחת MMS ליעד.

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


לסיכום  -

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

מתארח באתר בו יש נתב מספק האינטרנט ? תחזיק שרת DNS משלך

יש לך נתב/ מודם המסופק ע"י ספק האינטרנט ולא החלפת סיסמאות - צא מנקודת ההנחה שיש לך maleware על הנתב.

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

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

היום אני אישית מחזיק שרת DNS משלי, שלדאבוני אינו מוגדר לעבודה אל מול dnscrypt עדיין, הסיבה העיקרית שלא הגדרתי dnscrypt + bind9 היא עצלנות נטו.

מה שצריך לעשות זה:

להתקין dnssec resolver 
להתקין dnscrypt ולהגדיר את proxy_resolver_name למשהוא שיהיה נגיש (תחת /etc/default/dnscrypt-proxy)

ולחכות ליום בו הספקים המקומיים יתחילו לתמוך ב dnssec.

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

הגדרת ברירת מחדל

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

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

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

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

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

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

• 2650U
• 2740
• 2760

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

כמו כן מצאתי שדילנק עשו עבודה כמו שצריך ואפילו פרסמו את התיעוד (בשונה מהספק שנתן לו את הנתב)  שאפילו מסביר את הגדרות ה TR069. 

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

והחלק הכי חשוב שמות משתמש וסיסמא ברירת מחדל : Admin/admin  , support/support , user/user

התקנת חותמת לציתות

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

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

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

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

לדעתי האישית עדיף היה אם היו משתמשים ב sslstrip אבל זה עניין של טעם וריח.

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

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

עבור דביאן :

לדוגמה אם יש לנו צורך להתקין את החותמת של Netspark  נוריד את הקובץ הזה) נקרא לו מקומית כ netpark.crt):

wget http://www.netsparkmobile.com/support/myca.crt -O netspark.crt

אפשר להוריד את אותו הקובץ מספקי השירות שמשתמשים בשרות שלהם (אינטרנט רימון , T4G ,אוניברסיטאות וכו') או מהשרת הראשי של netspark.

עבור fortinet הספק שלכם צריך לתת את הCA שלו (הסבר כאן).
עבור sonicwal אפשר להוריד את החותמת ברירת המחדל.


 את הקובץ נשים ב : 

/usr/share/ca-certificate

ונתקין לכל המערכת ע"י 

sudo dpkg-reconfigure ca-certificates

עכשיו יש לבחור אם אנו סומכים על האישור.

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

לצערי העוד יותר יותר מדי "vpn"ים אינם מותקנים ע"י חבילות התקנת deb ומכילים טסריטים שידחפו את החותמות שלהם ל /etc/ssl ישירות מה שמקשה לבצע שידרוג או אחזקה של המכונה.

VoLTE בקוד חופשי

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

מדוע זה יענה על הצורך משרד התקשורת ? מכיוון ש EGAN מגדיר את ה WiFI כתשתית הרדיו שלו לאספקת שירות (RAN). הדרישה של משרד התקשורת לכיסויי ולאחזקה של אנטנות תענה. ועל הדרך גולן יקבל פריסת דור 4 ואפילו תמיכה ב VoLTE (שאני לא חושב שיש מישהוא שמספק את זה בארץ).

VoLTE הוא דרך (שיטה?) להעביר את המידע שבדר"כ עבר דרך circuit switch תחת תקשורת IP. כלומר דברים כמו קול , SMS ו הודעות broadcast עוברים באפיק הנתונים. כאשר עוברים להשתמש באפיק נתונים מקצה אל קצה הדבר מאפשר לתמוך באיכות קול גבוהה יותר (במקום להשתמש ב 3.5 קילו הרץ אנו משתמשים ב 16), לספק יותר שירותים חכמים ולייצר רווח על שירותים בהשקעה נמוכה.

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

לשם ההתחלה ספק הטלפוניה יצטרך להקים תמיכה ב VoLTE בצד השרת, להקים שרתי דיאמטר,שרתי DNS ,  SIP ו XCAP.

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

מה שנזדקק לו זה:

1. משהוא שיודע לבצע EAP-AKA לקוח ההזדהות שאנו משתמשים לו wifi הידוע כ wpa_supplicant יודע לבצע את זה בלי שום בעייה.
   
   קובץ ההגדרות יכול את ההגדרה הבאה עבור הרשת GolanOverWifi אם היא תתמוך בהזדהות EAP-AKA:
   
   

   #this may be added into /etc/wpa_supplicant.conf
   network={
    ssid="GolanOverWifi"
    key_mgmt=WPA-EAP
    eap=AKA
    pin="1234"
    pcsc="" # define as empty to allow pcsc usage (you are allowed to add args inside)
   }
   



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

PC/SC device scanner
V 1.4.26 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.8.15
Scanning present readers...
0: Gemalto PC Twin Reader (70D7E2EE) 00 00

Fri Apl 29 11:47:42 2016
Reader 0: Gemalto PC Twin Reader (70D7E2EE) 00 00
  Card state: Card inserted, 
  ATR: 3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
ATR: 3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
+ TS = 3B --> Direct Convention
+ T0 = 7E, Y(1): 0111, K: 14 (historical bytes)
  TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU
    43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
  Category indicator byte: 00 (compact TLV data object)
    Tag: 6, len: A (pre-issuing data)
      Data: 11 63 54 05 48 05 02 C6 01
    Mandatory status indicator (3 last bytes)
      LCS (life card cycle): 22 (Proprietary)
      SW: 9000 (Normal processing.)

Possibly identified card (using /home/user/.cache/smartcard_list.txt):
3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
3B 7E 13 00 00 00 6A 11 63 54 05 48 .. .. .. 01 22 90 00






3. לקוח SIP בעל הדרישות הבאות  :
   
   
   
   • לתמוך ב IPv4 ו IPv6
     
   • להחזיק לקוח XCAP  - לצערי linphone ו yate-qt אינם יודעים אבל jitsi יודע.
     
   • לקוח ה XCAP צריך לדעת לעבוד ללא chalange (לא יודע jitsi יודע או לא ) , לקוח ה SIP צריך לדעת להחליף את הזהות לזהות אותה קיבל לאחר ביצוע ה Register.
     
     
   • צריך לדעת לבצע register מחדש לאחר איבוד תקשורת (לא ראיתי את זה קורה ב yate-qt).
     
   • צריך לדעת לתמוך ב SIMPLE ו הודעות SM-IP  (למעשה מדובר על מקרה פרטי של 3428) )
     
   • צריך לדעת להוסיף את הכותרות  הבאות:
     
     phone-context  ו P-Aasserted-Identity ו P-Called-Party-ID. ולדעת להקים שיחה עם SIP-URI בצורה של MSISDN או של TEL.
     
     דוגמאות:
     
     sip:alphanumericusername@operator.tld
     
     sip:+33123456@free.fr;user=phone
     
     tel:+33123456;phone-context=free.fr
     
     
   • צריך לדעת להוסיף את ערך ה ICSI לשדה ה contact עם הכתובת הנגישה לרשת הסלולאר.דוגמא:
     
     

     Contact:sip:<+33123456@172.16.10.1:5060&gt

     ;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gppservice.ims.icsi.mmtel"
     

     
     
     
   • צריך לדעת לתמוך בשירותים הבאים (מינימום) :
     
     

     Originating Identification Presentation 3GPP TS 24.607 [23]
     Terminating Identification Presentation 3GPP TS 24.608 [24]
     Originating Identification Restriction 3GPP TS 24.607 [23] (Note 1)
     Terminating Identification Restriction 3GPP TS 24.608 [24] (Note 1)
     Communication Forwarding Unconditional 3GPP TS 24.604 [20] (Note 1)
     Communication Forwarding on not Logged in 3GPP TS 24.604 [20] (Note 1)
     Communication Forwarding on Busy 3GPP TS 24.604 [20] (Note 1)
     Communication Forwarding on not Reachable 3GPP TS 24.604 [20] (Note 1)
     Communication Forwarding on No Reply 3GPP TS 24.604 [20] (Note 1)
     Barring of All Incoming Calls 3GPP TS 24.611 [26] (Note 1)
     Barring of All Outgoing Calls 3GPP TS 24.611 [26] (Note 1)
     Barring of Outgoing International Calls 3GPP TS 24.611 [26] (Note 2)
     Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611 [26] (Note 2)
     Barring of Incoming Calls - When Roaming 3GPP TS 24.611 [26] (Note 1)
     Communication Hold 3GPP TS 24.610 [25]
     Message Waiting Indication 3GPP TS 24.606 [22] (Note 1)
     Communication Waiting 3GPP TS 24.615 [27] (Note 1)
     Ad-Hoc Multi Party Conference 3GPP TS 24.605 [21] (Note 1)
     

     
     למרות  שאני לא מכיר לקוחות SIP חופשיים שתומכים ב Bearing , אני לא חושב שזה יהיה נורא אם תהיה הצגה לא טובה של שם המשתמש המתקשר או אני אקבל הודעה שגויה אם לא הצלחתי להתקשר.
     
     
   • לקוח ה SIP צריך לדעת לתמוך בזימון אנשים להוסיף לשיחת וועידה (כבר קיים היום ) ב yate-qt לא יודע לגבי אחרים.
     
     
   • לקוח ה SIP רצוי שיידע לבצע פעולות כמו העברת שיחה ו History-Info.
     
     
   • לקוח ה SIP צריך לדעת לתמוך ב DTMF לפי נספח G
     
   • לקוח SIP שיודע לעבוד עם הקודקים AMR (כולל wideband).

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

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


שיטת ההזדהות לא שונה ממה שיש כיום והיא תראה בערך כך :

UE                   Bezeq Free Access Point     Bezeq Radius server              Translator        GT HSS
|<----WLAN registration--->|                            |                              |                 |
|                          |                            |                              |                 |
| --------EAP-AKA-------------------------------------->|                              |                 |
|                          |                            | ---Radius proxy the request->|                 |
|                          |                            |                              | ---Rad2Diam---->|
|                          |                            |                              |<--USIM register-|
|                          |                            |<--- USIM registration request|                 |
| <-------EAP-AKA---AUTH ACTIONs----------------------> |                              |                 |

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

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