نمونه‌ای از داده‌هایی که فروشنده‌ای با ادعای در اختیار داشتن دیتابیس صرافی والکس (wallex.ir) منتشر کرده، مورد تحلیل فنی مستقل قرار گرفت. هدف این بررسی، ارزیابی اصالت داده، دامنه افشا، زمان استخراج، روش دسترسی، و ارزیابی ادعای فروشنده درباره حجم واقعی نشت بود.
از همان ابتدا تلاش کردیم پس از بررسی و تأیید از طرف خودمان، پیش از انتشار هر خبری یا گزارشی، این موضوع را مستقیم و به‌طور کامل با والکس در میان بگذاریم. آنچه در ادامه می‌آید، شرح کامل و شفاف این مکاتبات است؛ هر بروزرسانی بعدی نیز از همین‌جا، با تاریخ، به این بخش افزوده خواهد شد.
شنبه، ۲۸ شهریور ۱۴۰۵
ایمیلی به آدرس عمومی پشتیبانی والکس ارسال و موضوع نشت را مطرح کردیم. همان روز یکی از اعضای تیم پشتیبانی پاسخ داد و آدرس [email protected] را برای ارسال مستندات فنی معرفی کرد.
در ادامه همان روز، مستندات کامل یافته‌ها را به این آدرس ارسال کردیم: فهرست فایل‌های در اختیار فروشنده، چند یافته مهم که تیم فنی والکس می‌توانست به‌سرعت راستی‌آزمایی کند، بازه زمانی دقیق استخراج داده برای بررسی گزارش‌های ممیزی، و ارزیابی ما از مسیر احتمالی دسترسی. در این ایمیل تأکید کردیم که آنچه بررسی کرده‌ایم نمونه‌ای از ادعای فروشنده است نه کل مجموعه، و تعیین دامنه دقیق افشا برعهده بررسی داخلی والکس است؛ همچنین اعلام کردیم در صورت نیاز تیم امنیت، نمونه‌های بیشتری از طریق یک کانال امن در اختیارشان قرار می‌گیرد.
تاریخ انتشار عمومی خبر اولیه (دوشنبه، ۶ مهر ۱۴۰۵) و مهلت پاسخ‌گویی پیش از آن را نیز در همین ایمیل مشخص کردیم.
دوشنبه، ۶ مهر ۱۴۰۵
بدون دریافت پاسخ دیگری، همان‌طور که از پیش اعلام کرده بودیم، خبر اولیه این نشت را در کانال تلگرام و توییتر لیکفا منتشر کردیم. ساعاتی بعد، همان آدرس ایمیل دوباره با ما تماس گرفت و درخواست یک مسیر ارتباطی سریع‌تر کرد. یادآوری کردیم که مستندات کامل پیش‌تر، در ۲۸ شهریور ارسال شده بود. در ادامه، والکس شناسه تماس مستقیم یکی از مدیران تیم امنیت خود را در اختیارمان گذاشت.
روزهای بعد
در یک گفتگوی خصوصی و امن، نمونه‌هایی از دو سر جدول هویت کاربران، به‌همراه جزئیات فنی بیشتر، برای راستی‌آزمایی در اختیار تیم امنیت والکس قرار گرفت. اطلاعاتی را هم که درباره هویت احتمالی فروشنده جمع‌آوری کرده بودیم، برای کمک به پیگیری موضوع با آن‌ها به اشتراک گذاشتیم.
یکی از نکات قابل‌توجه در این گفتگو این بود که تیم امنیت والکس احتمال داد فایل‌های پایتون موجود در مجموعه داده (detection.py، ordinal_detectors.py، calculator.py) ممکن است بازمانده یک پروژه تحلیل داخلی باشند، نه ابزار فروشنده. ارزیابی ما در §۴ بر پایه شواهد ساختاری، هم‌جواری این فایل‌ها با فایل کار فروشنده temp.txt، وجود نسخه دوم فهرست پرارزش، و نبود معادلی برای این فایل‌ها در محصول والکس، همچنان همان برداشت فروشنده‌ساخته را محتمل‌تر می‌داند؛ اما تفکیک قطعی این دو احتمال تنها از طریق گزارش‌های دسترسی و لاگ داخلی خود والکس ممکن است، و منتظر نتیجه بررسی آن‌ها در این باره هستیم.
انتظار خودمان را هم به‌روشنی با تیم امنیت والکس در میان گذاشتیم: پذیرش رسمی و عمومی وقوع این نشت، اطلاع‌رسانی به همه کاربران متأثر و به‌ویژه کاربران پرموجودی که ظاهراً از پیش در داده جدا شده‌اند (§۴)، هشدار درباره فیشینگ هدفمند، فعال‌سازی احراز هویت دومرحله‌ای، و تعویض کارت‌های بانکی کاربران متأثر.
پنجشنبه، ۹ مهر ۱۴۰۵
تا لحظه انتشار این گزارش، والکس هیچ اطلاعیه یا واکنش رسمی عمومی‌ای نسبت به این نشت نشان نداده است. آخرین پیگیری ما از تیم امنیت والکس نیز تنها با پاسخ «هنوز بررسی‌ها ادامه داره» روبه‌رو شد. با گذشت بیش از سه روز کاری از تماس با تیم امنیت والکس، تصمیم گرفتیم این گزارش کامل را امروز منتشر کنیم. هر پاسخ یا اطلاعیه‌ای که از سوی والکس دریافت کنیم، به همین بخش، با تاریخ، افزوده خواهد شد.
§۰ خلاصه
مجموعه در اختیار فروشنده، شانزده فایل و نزدیک به دو گیگابایت داده از سامانه‌های والکس است. هسته آن یک جدول احراز هویت مشتری (KYC) است، حساس‌ترین جدولی که یک صرافی تحت نظارت نگهداری می‌کند، که به‌تنهایی ۶۰٪ حجم را می‌سازد. داده با اطمینان بسیار بالا اصیل است.
افشا در سه لایه است. لایه هویتی: نام، کد ملی، تاریخ تولد، شماره همراه و ثابت، نشانی، ایمیل و پیوند اسکن کارت ملی، اقلامی که هیچ‌کدام قابل تعویض نیستند. لایه مالی: شماره کارت بانکی کامل و بدون پوشش، شماره شبا با نام تأییدشده صاحب حساب، نشانی کیف پول‌ها و موجودی‌ها. لایه سازمانی: جدول کامل حساب‌های کارکنان همراه با هش رمز عبور (رمز عبور به‌شکل رمزگذاری‌شده و برگشت‌ناپذیر، نه متن ساده)، به‌علاوه فهرست سیاه و سفید سامانه مبارزه با پول‌شویی.
ساختار داده نشان می‌دهد استخراج از طریق دسترسی مستقیم و احراز هویت‌شده به پایگاه داده یا بک‌اند انجام شده است، نه از راه پیمایش بیرونی (حدس زدن و پیمودن پی‌در‌پی شناسه‌های کاربران از بیرون سامانه، از طریق API عمومی و...)، و در یک نشست واحد در 2022-08-22 برداشته شده. مجموعه شواهد، فرضیه دسترسی داخلی را به محتمل‌ترین توضیح تبدیل می‌کند، اما هیچ‌یک از این شواهد اثبات نیست و تفکیک قطعی «کارمند» از «اطلاعات ورود دزدیده‌شده» تنها با گزارش‌های ممیزی خود والکس ممکن است (§۱۰).
§۱ پایه شواهد
این گزارش بر پنج قلم داده متنی و دو تصویر استوار است. هیچ‌کدام کل مجموعه نیستند؛ همگی نمونه‌اند و این محدودیت در سراسر گزارش صریحاً لحاظ شده است.
دو قلم اصلی، دو فایل جداگانه از همان جدول هویت‌اند: نخست فروشنده فایلی با ۴٬۹۹۹ رکورد از ابتدای جدول، با اولین شناسه‌ها، در اختیار گذاشت؛ سپس، به درخواست ما برای اعتبارسنجی بیشتر، فایل دومی با ۹۴ رکورد از انتهای همان جدول، با آخرین شناسه‌ها، نیز ارسال کرد. در سراسر این گزارش، از این دو فایل با عنوان «بخش ابتدایی» و «بخش انتهایی» یاد می‌شود.
| قلم | حجم | جایگاه در جدول | نقش در تحلیل |
|---|---|---|---|
| بخش ابتدایی پروفایل | 4,999 | اولین شناسه‌های جدول | پایه آمار پوشش و جمعیت‌شناسی |
| بخش انتهایی پروفایل | 94 | آخرین شناسه‌های جدول | تأیید مستقل اصالت؛ ساختار شناسه‌ها |
| رکورد ادمین | 1 | جدول کارکنان | ساختار جدول اطلاعات ورود |
| رکورد شبا | 1 | جدول حساب‌های بانکی | اعتبارسنجی ریاضی؛ حد زمانی |
| رکورد شماره کارت | 1 | جدول کارت‌ها | اعتبارسنجی ریاضی |
| تصویر جدول کارکنان | 29 سطر | جدول کارکنان | برآورد تعداد؛ ساختار نقش‌ها و 2FA |
| تصویر پوشه فروشنده | 16 فایل | — | دامنه افشا؛ برآورد حجم |
فایل‌های پروفایل در واقع CSV نیستند؛ آرایه JSONاند، هر شیء در یک خط. هر ۵٬۰۹۳ رکورد پروفایل بدون حتی یک خطای تجزیه خوانده شد و همگی دقیقاً ۲۶ فیلد یکسان با ترتیب کلید یکسان دارند. همین یکدستی خود یک شاهد است و در §۱۰ به آن بازمی‌گردیم: داده‌ای که با پیمایش وب، دستی، یا از ترکیب چند منبع جمع شده باشد هرگز این‌قدر یکدست نیست.
دو قلم از شواهد، تصویرند، و تصویر را می‌توان ساخت
تصویر را نمی‌توان تجزیه کرد. اما تصویرها عدد می‌دهند (اندازه فایل، شماره آخرین سطر) و عدد را می‌توان در برابر داده‌های متنی مستقل آزمود. در §۸ دقیقاً همین کار انجام شده و هر دو آزمون با خطای زیر یک درصد قبول شده‌اند؛ به همین دلیل تصویرها در این گزارش شاهد شمرده شده‌اند، نه ادعا.
§۲ اصالت داده: آیا واقعی است؟
این نخستین پرسشی است که هر تحلیل نشت باید پاسخ دهد، چون بازار داده‌های نشت‌یافته پر است از مجموعه‌های جعلی یا بازیافتی. شش آزمون مستقل اجرا شد و همگی یک نتیجه دادند. مهم‌تر آنکه چند آزمون روی دو بخش بدون هم‌پوشانی با چهار سال فاصله تکرار شدند.
رقم کنترلی کد ملی در هر دو سر جدول معتبر است قطعی
کد ملی ایرانی رقم کنترلی بر پایه باقی‌مانده بر ۱۱ دارد. در بخش ابتدایی از ۴٬۹۹۹ رکورد: ۴٬۹۹۰ معتبر، ۳ مردود، ۶ بدساخت (۹۹٫۸٪). در بخش انتهایی، ۶۰ رکورد کد ملی دارند و هر شصت مورد معتبرند، نرخ ۱۰۰٪.
عددهای ده‌رقمی تصادفی تنها با نرخ حدود ۹٪ (یک از یازده) این آزمون را می‌گذرانند. احتمال اینکه شصت عدد ساختگی همگی قبول شوند در حدود 1.7 × 10-63 است. این شماره‌ها یا از سوی سازمان ثبت احوال صادر شده‌اند، یا کسی عمداً الگوریتم رقم کنترلی را پیاده کرده، و با توجه به شواهد زیر، احتمال نخست به‌مراتب بیشتر است.
فیلد inquiry پاسخ ذخیره‌شده سامانه استعلام دولتی است تعیین‌کننده
این فیلد در ۸۴٫۹٪ رکوردهای بخش ابتدایی پر است و در ۴٬۱۱۶ مورد دقیقاً برابر first_name و last_name همان رکورد است، یعنی سامانه نام را با منبع دولتی مطابقت داده و پاسخ را نگه داشته.
بخش انتهایی این را از حدس به اثبات می‌رساند: از ۶۰ رکورد دارای inquiry، ۴۲ مورد نام کامل است و ۱۸ مورد باقی یک رشته خطای فارسی است، خطا : (پروفایل تایید نشده است).
این نوع مصنوع جعل‌شدنی نیست. کسی که داده می‌سازد نام جعلی می‌سازد؛ پیام خطای ذخیره‌شده یک سرویس استعلام دولتی نمی‌سازد. این قوی‌ترین شاهد اصالت در کل پرونده است.
داده بانکی از آزمون‌های ریاضی خودش می‌گذرد قطعی
شبا: رقم کنترلی mod-97 برابر ۱ است (معتبر)، و کد بانک در ارقام سوم تا پنجم، 017، دقیقاً با فیلد bank_name همان رکورد می‌خواند. یک سازنده داده باید هم‌زمان الگوریتم mod-97 را پیاده کند و جدول کد بانک‌ها را هم درست نگاشت کند.
شماره کارت: شانزده رقم کامل، از آزمون Luhn می‌گذرد، و BIN آن نیز به همان بانک اشاره می‌کند.
فیلد owners در رکورد شبا، نام صاحب حساب به‌همراه وضعیت «فعال» را نگه می‌دارد، یعنی پاسخ ذخیره‌شده استعلام بانکی، نه ورودی کاربر. همان الگوی inquiry، این‌بار در برابر شبکه بانکی.
هیچ رکورد تکراری در فیلدهای یکتا وجود ندارد قوی
در بخش ابتدایی: ۴٬۹۹۹ کد ملی متمایز، ۴٬۹۹۸ ایمیل، ۴٬۹۸۳ شماره همراه، ۴٬۹۹۹ کد دعوت و ۴٬۹۹۹ نشانی سند، بدون هیچ برخوردی. در بخش انتهایی نیز هر ۹۴ شماره همراه، هر ۹۴ کد دعوت و هر ۶۰ کد ملی متمایزند. این امضای یک جدول زنده تحت قید یکتایی پایگاه داده است، نه فهرستی که دستی گردآوری شده باشد.
ساختار میان دو بخش تکامل یافته، و باگ‌های واقعی را با خود آورده پشتیبان
هر دو بخش همان ۲۶ فیلد و همان ترتیب کلید را دارند (یک جدول، یک استخراج). اما درون فیلد settings رکوردهای تازه، سه کلید افزوده شده: api_key_expiration، choose_trading_type و اعلان price_alert. همچنین یک کلید معیوب "0": "manual_deposit" دیده می‌شود، نشت یک اندیس آرایه به درون شیء تنظیمات، یعنی یک باگ واقعی در کد محصول. داده‌ساز، باگ بازتولید نمی‌کند.
توزیع‌های جمعیتی و شبکه‌ای واقع‌گرایانه‌اند پشتیبان
پیش‌شماره همراه با سهم واقعی اپراتورهای ایرانی هم‌خوان است (همراه اول حدود ۶۷٪، ایرانسل حدود ۳۰٪، رایتل حدود ۳٪). پیش‌شماره تلفن ثابت با مراکز جمعیتی واقعی می‌خواند: تهران ۱٬۶۲۰، اصفهان ۴۳۲، تبریز ۳۷۶، مشهد ۳۴۱. نشانی‌های IP در فضای تخصیصی ایران قرار دارند (تمرکز در 5.112.0.0/12) و هیچ نشانی خصوصی RFC1918 در میان آن‌ها نیست.
ارزیابی: این داده، داده شخصی واقعی متعلق به افراد واقعی است و باید به‌عنوان اطلاعات هویتی زنده با آن رفتار شود، نه یک نمونه آزمایشگاهی. این نتیجه با اعتبارسنجی انسانی بخش §۳ نیز تأیید می‌شود.
§۳ اعتبارسنجی انسانی: تطبیق با روش OSINT
آزمون‌های آماری بخش §۲ فقط می‌توانند بگویند «این کدها ساختاری معتبر و متعلق به یک سامانه واقعی دارند». برای پاسخ به پرسش مهم‌تر، «آیا پشت این رکوردها واقعاً آدم زنده هست؟»، یک دور اعتبارسنجی انسانی هم روی نمونه‌ای تصادفی از هر دو بخش داده انجام دادیم.
تطبیق دستی با شبکه‌های اجتماعی رایج تأیید میدانی
تعدادی رکورد، هم از بخش ابتدایی و هم از بخش انتهایی، به‌صورت کاملاً تصادفی انتخاب شد. برای هر رکورد، ترکیبی از نام و نام خانوادگی، سال تولد و بخشی از شماره همراه در شبکه‌های اجتماعی رایج جست‌وجو شد تا مشخص شود آیا فردی با همین مشخصات و نمایه منطبق پیدا می‌شود یا نه.
در تمام موارد بررسی‌شده، مشخصات هویتی رکورد، نام، سن تقریبی، و در چند مورد شهر یا حرفه، با نمایه‌های عمومی پیداشده هم‌خوانی داشت. هیچ موردی با ناهم‌خوانی آشکار یا نشانه‌ای از داده جعلی/تصادفی مشاهده نشد.
محدودیت‌های این آزمون
این روش، مکمل آزمون‌های آماری بخش §۲ است، نه جایگزین آن. نمونه‌ای کوچک در برابر ده‌ها هزار رکورد کل مجموعه، از نظر آماری برای برآورد دقیق نرخ خطا کافی نیست؛ ارزش آن کیفی است نه کمّی: نشان می‌دهد پشت کدهای ملی معتبر، انسان‌های واقعی و قابل‌شناسایی‌اند، نه ارقام تصادفی‌ای که فقط رقم کنترلی را پاس می‌کنند.
در جریان این بررسی، هیچ داده‌ای از نمونه منتشر یا با شخص ثالث به اشتراک گذاشته نشد و با هیچ‌یک از افراد شناسایی‌شده تماسی گرفته نشد؛ این کار صرفاً برای اعتبارسنجی داخلی اصالت داده و به‌صورت موقت انجام شد و یادداشت‌های آن پس از تکمیل تحلیل حذف شدند.
نتیجه این آزمون انسانی، یافته بخش §۲ را تقویت می‌کند: این یک مجموعه جعلی یا تولیدشده با الگوریتم نیست، رکوردهای آن به افراد واقعی، قابل‌جست‌وجو و قابل‌شناسایی در فضای عمومی اینترنت تعلق دارد.
§۴ دامنه افشا: شانزده فایل
تصویر پوشه کاری فروشنده، فهرست، نام و اندازه دقیق هر فایل را نشان می‌دهد. این تنها قلمی است که دامنه کامل را مشخص می‌کند، بدون آن، تحلیل به یک جدول محدود می‌ماند.
| فایل | اندازه | محتوای استنباطی | شدت |
|---|---|---|---|
| newWallex_User_profiles.json | 1.16 GB | جدول هویت، §۵ | بحرانی |
| newWallex_user_status.json | 282.2 MB | وضعیت حساب‌ها | بالا |
| wallet_ibans.json | 122.9 MB | شبا با نام تأییدشده صاحب حساب | بحرانی |
| wallex_wallet_card_numbers.json | 111.3 MB | شماره کارت کامل | بحرانی |
| trade_new_balances.json | 110.3 MB | موجودی‌ها (فروشنده می‌گوید منسوخ است) | بالا |
| wallet_addresses.json | 92 MB | نشانی کیف پول کاربران | بالا |
| wallet_address_wallet.json | 44.2 MB | نگاشت نشانی به کیف پول | متوسط |
| valuable_addresses.json | 363 KB | فهرست کوتاه نشانی‌های پرارزش | بحرانی |
| wallet_blacklist_addresses.json | 68 KB | فهرست سیاه مبارزه با پول‌شویی | حساس داخلی |
| wallet_white_list_user.json | 65 KB | فهرست سفید برداشت | حساس داخلی |
| admin_users.json | 48 KB | حساب‌های کارکنان، §۶ | بحرانی |
| valuable_addresses_2.json | 34 KB | پالایش دوم فهرست پرارزش | بحرانی |
| temp.txt | 31 KB | فایل کار فروشنده | — |
| detection.py | 4 KB | ابزار خود فروشنده | — |
| ordinal_detectors.py | 2 KB | ابزار خود فروشنده | — |
| calculator.py | 1 KB | ابزار خود فروشنده | — |
فایل‌های valuable_addresses یک فهرست هدف‌گیری‌اند قصد
این دو فایل در محصول والکس معادلی ندارند. نام‌گذاری‌شان، وجود نسخه «۲» (یعنی یک پالایش دوم)، و حضور detection.py، ordinal_detectors.py و calculator.py در همان پوشه نشان می‌دهد خود فروشنده آن‌ها را تولید کرده است، با اجرای کد روی داده‌های خام، برای جداکردن پرموجودی‌ترین کاربران.
اندازه کوچک آن‌ها (۳۶۳ و ۳۴ کیلوبایت، در برابر ۹۲ مگابایت فایل کامل نشانی‌ها) این خوانش را تقویت می‌کند، نه تضعیف: این یک تخلیه انبوه نیست، یک فهرست کوتاه و تصفیه‌شده است. در مقیاس چند ده بایت به ازای هر نشانی، صحبت از چند هزار هدف است، نه چند صد هزار.
این یک تفاوت کیفی است. داشتن داده یک چیز است؛ پالایش داده برای یافتن ثروتمندترین قربانیان چیز دیگری. این کار نگهداری نیست، آماده‌سازی است، و در اولویت‌بندی هشدار به کاربران باید لحاظ شود.
فهرست سیاه و فهرست سفید، اسناد داخلی انطباق‌اند حاکمیتی
این دو فایل هیچ مسیر نمایش به کاربر ندارند؛ مصنوعات سامانه مبارزه با پول‌شویی‌اند. افشای فهرست سیاه به مجرم می‌گوید کدام نشانی‌ها رصد می‌شوند؛ افشای فهرست سفید می‌گوید برداشت به کدام نشانی‌ها بدون اصطکاک انجام می‌شود. هر دو ارزش تهاجمی مستقیم دارند.
وجودشان از نظر مسیر دسترسی هم معنادار است: کسی که فقط به جدول مشتریان دست یافته باشد، به این‌ها نمی‌رسد (§۱۰).
§۵ جدول هویت: چه چیزی در آن است
این جدول ۲۶ ستون دارد و ۶۰٪ حجم مجموعه است. آنچه در آن نیست هم اهمیت دارد: نه رمز عبور مشتری، نه کلید API، نه کلید کیف پول. اما داده هویتی را، برخلاف رمز عبور، نمی‌توان تعویض کرد.
| دسته داده | تعداد | پوشش | توضیح |
|---|---|---|---|
| نام و نام خانوادگی | 4,997 | 100.0% | به خط فارسی |
| کد ملی | 4,999 | 100.0% | شناسه اصلی هویت در ایران |
| تاریخ تولد | 4,994 | 99.9% | ۱۶۴ مقدار پیش‌فرض، §۹ |
| شماره همراه | 4,999 | 100.0% | ۹۹٫۷٪ خوش‌ساخت 09XXXXXXXXX |
| نشانی ایمیل | 4,999 | 100.0% | ۵۹ دامنه متمایز |
| تلفن ثابت و پیش‌شماره | 4,999 | 100.0% | پیش‌شماره، استان را مشخص می‌کند |
| نشانی پستی | 4,997 | 100.0% | ۴٬۷۷۹ مورد متنی آزاد؛ ۱۰ مورد با کد پستی |
| نشانی تصویر کارت ملی | 4,999 | 100.0% | پیوند به اسکن کارت ملی |
| آخرین نشانی IP | 4,948 | 99.0% | ۴٬۷۹۴ مورد متمایز؛ ۲۰۸ مورد IPv6 |
| تصویر یا ویدئوی چهره | 21 | 0.4% | سلفی احراز هویت تصویری |
۹۹٫۹٪ رکوردهای بخش ابتدایی مجموعه کامل سرقت هویت را دارند بحرانی
۴٬۹۹۴ رکورد از ۴٬۹۹۹ هم‌زمان شامل نام، کد ملی، تاریخ تولد، شماره همراه، ایمیل و پیوند اسکن کارت ملی هستند. این ترکیب برای تصرف حساب در سامانه‌های دیگر، کلاهبرداری اعتباری و جعل هویت در برابر هر سرویس ایرانی که با «کد ملی + شماره همراه» احراز هویت می‌کند کافی است.
هیچ‌یک از این اقلام قابل ابطال نیست. رمز عبور لو رفته را در یک دقیقه عوض می‌کنند؛ کد ملی لو رفته برای همیشه لو رفته است.
پوشش، در طول عمر جدول ثابت نیست
ارقام بالا ویژگی قدیمی‌ترین کاربران‌اند. همان اندازه‌گیری روی بخش انتهایی، تصویر متفاوتی می‌دهد، و این تفاوت، دو چیز را هم‌زمان می‌گوید: تعمیم‌های ساده نادرست‌اند، و ساختار جدول در طول زمان تغییر کرده است.
| فیلد | کاربران اولیه | کاربران پایانی | تفسیر |
|---|---|---|---|
| نشانی ایمیل | 100.0% | 4.3% | ایمیل به جدول دیگری منتقل شده است |
| آخرین نشانی IP | 99.0% | 0.0% | ثبت IP در این جدول متوقف شده |
| نشانی پستی | 100.0% | 0.0% | شیء نشانی هست، اما همه فیلدها جز «کشور» تهی‌اند |
| تصویر کارت ملی | 100.0% | 9.6% | سند هنوز بارگذاری نشده، نه اینکه حذف شده باشد |
| کد ملی | 100.0% | 63.8% | پروفایل به‌تدریج پر می‌شود |
| وضعیت تأییدشده | 84.6% | 0.0% | ثبت‌نام‌های ساعات پایانی، هنوز فرصت احراز نداشته‌اند |
سه پیامد برای هر تعمیمی از این اعداد
- نرخ ۱۰۰٪ تصویر کارت ملی را به کل جدول تعمیم ندهید. تعداد واقعی اسناد، جایی میان ۹٫۶٪ و ۱۰۰٪ است و بی‌گمان بسیار کمتر از «یک سند به ازای هر رکورد».
- خالی بودن یک فیلد در رکوردهای تازه به معنای امن بودن آن نیست. ایمیل از این جدول رفته، اما به فایل دیگری در همان پوشه رفته است.
- ترکیب اپراتور هم جابه‌جا می‌شود. سهم ۲۴٫۴ درصدی
0912، بلوک قدیمی و ممتاز تهران، در بخش انتهایی به ۷٫۴٪ می‌رسد و بلوک‌های تازه‌تر (0902،0903،0990) بالا می‌آیند. سوگیری نمونه فرضیه نیست؛ اندازه‌گیری شده است.
تصاویر مدارک هویتی ممکن است هنوز قابل دریافت باشند بررسی فوری
نشانی‌های اسناد دو نسل دارند. نسل قدیم: https://admin-api.wallex.ir/images/national-card/<user_id>/jpg/<توکن ۳۰ نویسه‌ای>. نسل تازه از 2022-01-23 به بعد: همان میزبان با /jpeg/ و شناسه UUIDv4.
هر دو نسل آنتروپی بالایی دارند و قابل حدس یا شمارش نیستند، اما این‌ها نشانی‌های مبتنی بر «داشتن کلید» هستند. هر کسی که یک سطر نشت‌یافته را دارد، توکن آن را هم دارد. اگر آن نقطه پایانی هنوز بدون نشست احراز هویت‌شده فایل تحویل دهد، این نشت دیگر چند صد هزار رکورد متنی نیست؛ چند صد هزار تصویر از مدارک هویتی دولتی است.
هیچ نشانی‌ای آزمایش نشد. فراخوانی آن‌ها دسترسی غیرمجاز به مدارک هویتی اشخاص ثالث است. این بررسی باید توسط خود والکس یا یک مرکز پاسخ‌گویی به رخداد (CERT) که صلاحیت درخواست دارد انجام شود.
درباره نام میزبان admin-api
این نشانی‌ها به admin-api.wallex.ir اشاره می‌کنند، نه به API عمومی. مقدار ذخیره‌شده به یک سطح مدیریتی ارجاع می‌دهد، نکته‌ای که در تحلیل روش دسترسی اهمیت دارد (§۱۰).
§۶ داده بانکی و اطلاعات ورود کارکنان
این بخش از جدول هویت فراتر می‌رود؛ شامل دو دسته داده دیگر هم هست: اطلاعات مالی کامل (شماره کارت و شبا) و هش رمز عبور ۱۴۲ حساب کارمندی. یعنی آنچه از والکس خارج شده، تنها اطلاعات هویتی مشتریان نیست؛ اطلاعات ورود کارکنان هم در میان داده‌های افشاشده است.
شماره کارت و شبا: افشا از «هویت» به «مالی» ارتقا می‌یابد بحرانی
شماره کارت در فایل مربوطه شانزده رقم کامل و بدون پوشش است. رکورد شبا، افزون بر شماره، bank_name و فیلد owners را دارد که نام صاحب حساب به‌همراه وضعیت «فعال» را نگه می‌دارد، یعنی پاسخ ذخیره‌شده استعلام بانکی، نه ورودی خود کاربر.
پیوند «کد ملی + تاریخ تولد + شماره همراه + شماره کارت + شبا + نام تأییدشده بانکی» همان مجموعه‌ای است که برای افتتاح حساب جعلی، مسیردهی پول‌شویی، و مهندسی اجتماعی با پشتوانه بانکی لازم است.
برآورد حجم به روش §۸: ۴۲۱ تا ۴۴۱ هزار سطر شبا و ۴۵۶ تا ۴۷۸ هزار شماره کارت.
هش رمز عبور حدود ۱۴۲ کارمند در مجموعه است بحرانی
جدول کارکنان دوازده فیلد دارد: id، email، first_name، last_name، mobile_number، role_id، status، two_step_verification، settings، password، created_at، updated_at.
فیلد password یک هش bcrypt با پیشوند $2y$ و ضریب هزینه ۱۰ است. این خبر خوب نسبی است، bcrypt انتخاب درستی است و برخلاف MD5 یا SHA-1 شکستن انبوه آن ممکن نیست. اما ضریب ۱۰ در برابر سخت‌افزار امروزی پایین است و رمزهای ضعیف، تکراری یا از پیش نشت‌یافته به‌صورت برون‌خط شکسته می‌شوند. این هش‌ها از اوت ۲۰۲۲ در اختیارند؛ فرصت حمله، سال‌ها بوده است.
دست‌کم یک حساب ادمین بدون احراز هویت دومرحله‌ای بررسی فوری
فیلد two_step_verification سه مقدار می‌گیرد: ۲ (اکثریت روشن)، ۱، و ۰ در دست‌کم یک سطر. اگر ۰ به معنای «غیرفعال» باشد، برای آن حساب هش رمز عبور تنها عامل احراز هویت است و زنجیره «شکستن برون‌خط ← ورود مستقیم به پنل مدیریت» کامل می‌شود.
هر حساب کارمندی که از اوت ۲۰۲۲ رمزش عوض نشده باشد باید در معرض نفوذ فرض شود، مستقل از اینکه هنوز فعال است یا نه، و مستقل از ادعای فروشنده مبنی بر اینکه «اطلاعات ادمین‌ها تغییر کرده».
افشا مرز یک شخصیت حقوقی را رد می‌کند زمینه
تصویر جدول کارکنان (که در این گزارش منتشر نشده؛ دلیلش در ادامه همین بخش آمده) ۲۹ سطر پیاپی را نشان می‌دهد و فایل در سطر ۱۴۳ پایان می‌یابد؛ با اندازه ۴۸ کیلوبایت، حدود ۱۴۲ حساب کارمندی برآورد می‌شود. سه دامنه ایمیل دیده می‌شود: دو دامنه خود والکس، و یک دامنه سوم متعلق به شرکت مرتبط، که دامنه حساب ادمین شماره ۱ هم هست. هرگونه اطلاع‌رسانی و ابطال رمز باید هر سه دامنه را پوشش دهد.
فیلد role_id دست‌کم شش مقدار متمایز می‌گیرد که یکی از آن‌ها پرتکرارترین است، یعنی یک مدل نقش‌محور واقعی، نه دسترسی تخت. برچسب‌های زمانی updated_at در بازه 2022-05-29 تا 2022-08-21T11:34:54Z قرار دارند؛ یعنی این جدول در همان عملیات ۲۲ اوت برداشته شده، نه در نوبتی جداگانه.
چرا تصویر جدول کارکنان در این گزارش منتشر نشده است
تصویر پوشه فروشنده (تصویر ۱) فقط نام و اندازه فایل را نشان می‌دهد و هیچ داده شخصی ندارد؛ به همین دلیل آمده است. تصویر جدول کارکنان اما هش رمز عبور، نشانی کامل ایمیل و نام کارکنان را نشان می‌دهد و منتشر نشده، حتی با پوشاندن، چون جمعیت آن ۱۴۲ نفر است و شناسایی مجدد در چنین جمعیت کوچکی بسیار آسان است.
§۷ خط زمانی و لحظه استخراج
برای تعیین زمان دقیق سرقت نمی‌توان به ادعای فروشنده تکیه کرد، چون صرفاً یک ادعای تبلیغاتی و غیرقابل اعتماد است. تنها منبع قابل اعتماد، برچسب‌های زمانی ثبت‌شده در خود داده‌هاست: جدیدترین برچسبی که در کل مجموعه پیدا شود، نشان می‌دهد سرقت دست‌کم از همان تاریخ به بعد رخ داده است، یعنی یک حد پایین برای زمان سرقت از آن به دست می‌آید.
استخراج در 2022-08-22 13:36:41 UTC یا پس از آن رخ داده است اطمینان بالا
هیچ رکوردی را نمی‌توان پیش از آخرین تغییرش کپی کرد، پس جدیدترین برچسب زمانی در کل مجموعه، حد پایین تخلیه است. آن برچسب روی رکورد شبا است: 2022-08-22T13:36:41Z، حدود ۱۸:۰۶ به وقت تهران، پایان یک روز کاری.
۹۴ رکورد پایانی جدول هویت، همگی در بازه 2022-08-21T20:21 تا 2022-08-22T08:07 ساخته شده‌اند، کمتر از دوازده ساعت پیش از قطع. این تخلیه از یک بایگانی برداشته نشده؛ از یک جدول در حال کار، در همان روز، برداشته شده است.
دو رویداد داخلی قابل تطبیق با سوابق تغییرات زمینه
۲۵ آوریل ۲۰۲۱: ۲٬۴۳۶ رکورد (۴۸٫۷٪ بخش ابتدایی) تاریخ به‌روزرسانی کاملاً یکسان دارند، در حالی که در کل ۶۲۹ روز به‌روزرسانی متمایز وجود دارد. بازنویسی نیمی از یک جدول در یک روز، نشانه مهاجرت ساختار یا پرکردن انبوه داده است، نه فعالیت کاربران.
دی–بهمن ۱۴۰۰ (ژانویه–فوریه ۲۰۲۲): بازسازی بزرگ‌تر سکو، سه شاهد مستقل به این بازه اشاره می‌کنند: نخستین نشانی سند با الگوی UUID در 2022-01-23، ساخته‌شدن رکورد ادمین شماره ۱ در 2022-02-06، و پیشوند newWallex_ در نام فایل‌ها. ساختار شناسه‌ها در §۸ نیز از همین‌جا تغییر می‌کند.
هر دو رویداد باید با سوابق داخلی تغییرات (لاگ مهاجرت یا بازسازی) مطابقت داده شوند تا مشخص شود عملیاتی برنامه‌ریزی‌شده و مجاز بوده‌اند، نه نشانه‌ای غیرعادی.
§۸ معماری شناسه‌ها
فروشنده می‌گوید مجموعه ۷۴۸٬۰۴۸ رکورد دارد. اما شمردن تعداد واقعی رکوردهای جدول هویت فقط با تکیه بر بیشینه کلید اصلی (id) ممکن نیست؛ ساختار خودِ شناسه‌ها نشان می‌دهد چرا.
شناسه‌ها در دو نسل ساخته شده‌اند؛ نسل دوم با گام ۳ یافته ساختاری
در بخش ابتدایی، شناسه‌ها (id) از ۱۱ تا ۵٬۰۵۸ با فاصله ۱ به ۱ پیش می‌روند و تقریباً هیچ شماره‌ای از قلم نیفتاده (چگالی ۹۹٪). اما در بخش انتهایی، شناسه‌ها از 2,000,588,264 تا 2,000,588,543 می‌روند و فاصله هر دو شناسه پیاپی، بدون هیچ استثنایی، دقیقاً ۳ است.
فاصله ثابت ۳ در شماره‌گذاری یک جدول، نشانه شناخته‌شده‌ای دارد: وقتی یک پایگاه داده برای بالابردن قابلیت اطمینان، روی چند سرور به‌طور هم‌زمان اجرا می‌شود، معمولاً هر سرور فقط شناسه‌هایی با فاصله مشخص می‌سازد تا دو سرور هرگز یک شماره تکراری تولید نکنند؛ مثلاً در یک خوشه سه‌سروره، سرور اول شناسه‌های ۱، ۴، ۷ و... را می‌سازد، سرور دوم ۲، ۵، ۸ و... را، و سرور سوم ۳، ۶، ۹ و... را. فاصله دقیقاً سه‌تایی و بدون استثنا در این داده، امضای همین الگو در یک خوشه سه‌سروره است. از طرفی، اینکه همه شناسه‌های بخش انتهایی روی یک باقی‌مانده ثابت می‌افتند (یعنی تقسیم همه آن‌ها بر ۳ یک نتیجه یکسان می‌دهد) نشان می‌دهد در آن بازه، همه نوشتن‌ها فقط روی یکی از این سه سرور انجام شده، نه هر سه.
نکته دیگر: در هر ۹۴ رکورد بخش انتهایی، فاصله بین user_id و id همیشه دقیقاً ۱۲٬۰۴۸ واحد است، یک عدد ثابت و بدون تغییر. این یعنی در دوره تازه، به ازای هر کاربر دقیقاً یک پروفایل ساخته شده است. این با دوره قدیم فرق دارد: آنجا user_id تا ۱۲٬۴۹۷ می‌رسید، در حالی‌که فقط ۴٬۹۹۹ پروفایل واقعی وجود داشت؛ یعنی حدود ۶۰٪ از حساب‌های قدیمی، اصلاً پروفایلی نساخته بودند.
§۹ چه کسانی متأثر شده‌اند
| رده سنی | تعداد | سهم |
|---|---|---|
| زیر ۱۸ سال | 1 | 0.0% |
| ۱۸ تا ۲۴ سال | 362 | 7.5% |
| ۲۵ تا ۳۴ سال | 2,172 | 45.0% |
| ۳۵ تا ۴۴ سال | 1,767 | 36.6% |
| ۴۵ تا ۵۴ سال | 400 | 8.3% |
| ۵۵ سال به بالا | 128 | 2.7% |
میانه سنی ۳۴ سال؛ جمعیتی عمدتاً در سن کار، متمرکز در تهران، اصفهان، تبریز، مشهد و شیراز. جغرافیا به تهران متمایل است (۳۲٫۴٪)، کاربران اولیه یک صرافی بیش از کل جامعه کاربران در پایتخت متمرکزند، پس این نسبت را نباید به کل مجموعه تعمیم داد.
تاریخ تولد در بخشی از رکوردهای دوره قدیم، مقدار پیش‌فرض سیستم است، نه واقعی کیفیت داده
۱۶۴ رکورد بخش ابتدایی سال تولد غیرممکن دارند، ۱۴۴ مورد در سال ۲۰۱۹ (برابر با سال ثبت‌نام خودشان؛ و در ۱۱۳ رکورد تاریخ تولد دقیقاً برابر تاریخ ایجاد حساب است)، به‌علاوه مقادیر ناممکن تا سال ۲۶۴۱ که از خطای تبدیل تاریخ شمسی به میلادی می‌آید. تطابق دقیق تاریخ تولد با تاریخ ثبت‌نام، در ۱۱۳ رکورد جداگانه، نشانه یک مقدار پیش‌فرض خودکار سیستم است، نه ورودی دستی کاربر؛ کاربر واقعی به‌ندرت پیش می‌آید تاریخ تولدی بسازد که دقیقاً با روز ثبت‌نامش یکی باشد، چه رسد به تکرار همین الگو در ده‌ها رکورد جداگانه با همین دقت.
اگر این مقادیر را همان‌طور که هستند بپذیریم، تعداد ظاهری افراد زیر ۱۸ سال به ۱۶۵ می‌رسد. اما پس از کنارگذاشتن مقادیر پیش‌فرض، دقیقاً یک رکورد نشان‌دهنده فرد زیر سن قانونی است. برای هر ارزیابی درباره افشای داده کودکان، این اصلاح تعیین‌کننده است؛ عدد خام، اندازه واقعی موضوع را صدها برابر بزرگ‌تر نشان می‌دهد.
در ۶۰ تاریخ تولد بخش انتهایی، بازه 1972-12-24 تا 2004-02-24 است و حتی یک مقدار ناممکن دیده نمی‌شود: این باگ در بازسازی ۱۴۰۰ رفع شده و ویژگی دائمی داده نیست.
افشای واقعی در رده داده ویژه جای دیگری است: ۲۱ رکورد بخش ابتدایی دارای تصویر یا ویدئوی سلفی برای احراز هویت‌اند (۲۰ تصویر و ۱ ویدئو، همراه با فراداده)، و در بخش انتهایی نیز ۴ تصویر و ۱ ویدئو دیده می‌شود. این نوع داده زیست‌سنجی (تصویر چهره) برخلاف رمز عبور یا حتی شماره کارت، هرگز قابل تعویض یا صدور مجدد نیست؛ برای مقایسه، در بسیاری از چارچوب‌های حقوقی بین‌المللی مانند مقررات GDPR اتحادیه اروپا، این دسته از داده جزو حساس‌ترین رده‌های اطلاعات شخصی شناخته می‌شود و بالاترین سطح حفاظت برایش در نظر گرفته می‌شود.
نرخ وجود این تصاویر در بخش انتهایی (۵٫۳٪) بیش از ده برابر بخش ابتدایی (۰٫۴٪) است. به‌احتمال زیاد، الزام به احراز هویت تصویری (سلفی زنده) پس از ثبت‌نام گروه اولیه کاربران به فرایند ثبت‌نام اضافه شده است؛ پس نرخ واقعی وجود این داده در کل جدول هویت، به‌مراتب بیشتر از نرخ ۰٫۴ درصدی بخش ابتدایی است.
§۱۰ داده چگونه استخراج شده است
ساختار این مجموعه، شواهدی درباره مسیر دسترسی‌ای که آن را تولید کرده در خود دارد.
نشانه‌های دسترسی مستقیم به بک‌اند یا پایگاه داده
- چهار ستون در ۱۰۰٪ رکوردها خالی‌اند،
profession_id،avatar،verifier_id،verified_at. ستون‌های گردش‌کار داخلی خالی، با این حال صادر شده‌اند. این رفتارSELECT *است؛ یک API عمومی فیلدهایی را برمی‌گرداند که کارخواه لازم دارد، نه ستون همیشه‌خالی تخصیص کارمند را. - فیلدهای مخصوص کارکنان حاضرند،
commission(رده کارمزد هر کاربر: ۲۵٫۰ برای ۹۶٫۴٪ کاربران و ۳۰ و ۳۵ و ۴۰ برای بقیه) وverifier_idکه کارمند تأییدکننده پرونده احراز هویت را مشخص می‌کند. هیچ‌کدام در پاسخ سمت مشتری جایی ندارند. - ترتیب کلیدها در هر ۵٬۰۹۳ رکورد یکسان و غیرالفبایی است. این همان ترتیب دلخواهی است که یک ORM یا درایور هنگام سریال‌سازی سطر تولید می‌کند، یک عبور برنامه‌ای، یک جدول مبدأ.
- کلید اصلی یک بلوک پیوسته است. در بخش ابتدایی،
idاز ۱۱ تا ۵٬۰۵۸ می‌رود و تنها ۴۹ مقدار جا افتاده (۹۹٫۰٪ چگالی)؛ در بخش انتهایی، ۹۴ رکورد پیاپی بدون یک پرش اضافی. پیمایش یک API با محدودیت نرخ، شکاف و تکرار و تلاش مجدد تولید می‌کند؛ بازه چگال کلید اصلی چیزی است که از یک پرس‌وجوی بدون صفحه‌بندی روی خود جدول به دست می‌آید. - نشانی‌های ذخیره‌شده به
admin-api.wallex.irارجاع می‌دهند، یک میزبان مدیریتی. - شانزده فایل از جدول‌های پراکنده، همگی با برچسب زمانی یک روز. جدول هویت، جدول کارکنان، جدول‌های بانکی و مصنوعات انطباق، این‌ها نقاط پایانی مختلفی ندارند که بتوان یکی‌یکی پیمایششان کرد؛ در یک پایگاه داده کنار هم می‌نشینند.
سازگار با دسترسی داخلی احراز هویت‌شده، اما تفکیک «کارمند» از «سرقت اطلاعات ورود» از روی فایل‌ها ممکن نیست با دقت بخوانید
نشانه‌های بالا پیمایش بیرونی، پرکردن اطلاعات ورود و سوءاستفاده از API را کنار می‌گذارند. داده از دسترسی ممتاز به بک‌اند آمده است.
اما این اثبات نمی‌کند که یک کارمند مرتکب شده باشد. یک کارمند خاطی، یک مهاجم بیرونی با اطلاعات ورود مدیریتی دزدیده‌شده، یک سرور برنامه در معرض نفوذ، و یک پشتیبان پایگاه داده افشاشده، همگی مصنوعی بایت‌به‌بایت یکسان تولید می‌کنند. فایل نمی‌تواند این‌ها را از هم جدا کند و هر گزارشی که تنها بر پایه این شواهد ادعای بیشتری کند، فراتر از داده سخن گفته است.
تفکیک آن‌ها نیازمند شواهدی است که تنها در اختیار والکس است: گزارش‌های ممیزی و تاریخچه پرس‌وجوی پایگاه داده حول 2022-08-22، سوابق نشست VPN و بستیون (سرور واسط دسترسی امن)، گزارش دسترسی پنل مدیریت، پایش ترافیک خروجی، و زمینه منابع انسانی درباره خروج کارکنان نزدیک به آن تاریخ.
چرا بخش ابتدایی یک «نمونه اثبات» است
آن ۴٬۹۹۹ رکورد، اولین ۵٬۰۴۸ شناسه جدول هستند، قدیمی‌ترین گروه کاربران، برداشته‌شده به‌صورت یک بلوک پیوسته از ابتدای جدول؛ و ۹۴ رکورد دیگر، آخرین سطرهای همان جدول. این شکل کلاسیک نمونه‌ای است که فروشنده منتشر می‌کند تا در اختیار داشتن کل پایگاه داده را نشان دهد بی‌آنکه آن را بدهد. هیچ‌کدام برداشت تصادفی نیستند، و این بر همه آمار این گزارش اثر می‌گذارد (§۵).
§۱۱ توصیه‌ها
تلاش برای اطلاع‌رسانی به والکس
پیش از انتشار این گزارش، یافته‌ها را به‌طور کامل با والکس در میان گذاشتیم. شرح کامل این مکاتبات را در ابتدای همین گزارش آورده‌ایم.
اقدام فوری، ساعت‌ها، نه روزها
- تأیید یا رد کنید که نشانی اسناد هنوز بدون احراز هویت پاسخ می‌دهد. اگر پاسخ می‌دهد، هر دو نسل توکن باید باطل شوند، هم توکن‌های ۳۰ نویسه‌ای دوره قدیم و هم UUIDهای پس از بازسازی ۱۴۰۰، و جای آن‌ها نشانی‌های امضاشده، دارای انقضا و مقید به نشست بنشیند. کهنه‌بودن یک الگو به معنای غیرفعال بودن آن نیست.
- هر رمز عبور کارمندی را که از اوت ۲۰۲۲ عوض نشده باطل کنید و احراز هویت دومرحله‌ای را روی هر ۱۴۲ حساب، فعال و غیرفعال، در هر سه دامنه، اجباری کنید. حساب‌های با
two_step_verification = 0اولویت مطلق دارند. ضریب bcrypt را از ۱۰ بالا ببرید یا به Argon2id مهاجرت کنید. - حساب‌های کارکنان جداشده را در برابر جدول اوت ۲۰۲۲ مقابله کنید. هر حسابی که در آن فایل هست و امروز هم فعال است، یک یافته مستقل است.
- گزارش‌های ممیزی بازه 2022-08-22 08:08Z تا 13:37Z را استخراج کنید. این بازه با دقت ساعت مشخص است و باید حجم بزرگی از خواندن روی دست‌کم شانزده جدول در آن دیده شود.
- کاربران دارای شماره کارت یا شبای ثبت‌شده پیش از شهریور ۱۴۰۱ را مشخص کنید و در هماهنگی با شبکه بانکی، پایش تقلب روی آن کارت‌ها را فعال کنید. شماره کارت، برخلاف کد ملی، قابل تعویض است؛ این تنها بخشی از افشاست که هنوز می‌توان جبرانش کرد.
اقدام کوتاه‌مدت
- عدد ادعایی را با شمارش مستقیم تأیید کنید.
SELECT COUNT(*)روی جدول پروفایل و جدول حساب‌ها. اطلاع‌رسانی نباید تنها بر پایه ادعای یک فروشنده انجام شود. - دو رویداد 2021-04-25 و بازسازی دی–بهمن ۱۴۰۰ را با سوابق داخلی تغییرات مطابقت دهید تا مشخص شود عملیاتی برنامه‌ریزی‌شده و مجاز بوده‌اند، نه نشانه‌ای غیرعادی (§۷).
- فهرست سیاه انطباق را از نو بسازید و فهرست سفید برداشت را بازتأیید کنید، با این فرض که نسخه اوت ۲۰۲۲ هر دو در دست غیر است.
- کاربران پرموجودی را در اولویت اطلاع‌رسانی قرار دهید. فایل‌های
valuable_addressesنشان می‌دهند این گروه از پیش جدا شده‌اند (§۴) و نخستین هدف هر سوءاستفاده‌ای خواهند بود. - به کاربران متأثر و مرجع نظارتی اطلاع دهید. داده هویتی غیرقابل‌ابطال به‌همراه اسکن مدارک و داده بانکی، بنا بر تعریف هر نظام حقوقی، یک نشت پرخطر است.
اقدام ساختاری
- رمزگذاری تصاویر اسناد در حالت سکون با کلید مجزا برای هر شیء.
- توقف بازگرداندن سطرهای کامل احراز هویت در پرس‌وجوهای مدیریتی.
- افزودن آستانه تعداد سطر و هشدار برای خواندن انبوه، و اعمال کم‌ترین سطح دسترسی روی جدول‌های هویت و بانکی.
- مسیر دسترسی را ببندید، نه فقط نشت رخ‌داده را. سازوکاری که به یک حساب اجازه داده شانزده جدول را در یک روز بخواند، اگر تغییر نکرده باشد هنوز همان اجازه را می‌دهد. فرد داخلی‌ای که دسترسی مشروع دارد با پایش و محدودیت حجم مهار می‌شود، نه با کنترل‌های پیرامونی.
برای افراد متأثر
- اگر پیش از شهریور ۱۴۰۱ در والکس شماره کارت یا شبا ثبت کرده‌اید، آن کارت را تعویض کنید. شماره کارت شما به‌صورت کامل و بدون پوشش در این مجموعه است.
- هر تماسی که به حساب والکس، کد ملی یا مدرک هویتی شما اشاره کند احتمالاً کلاهبردارانه است، این مجموعه امکان فیشینگ هدفمند و بسیار باورپذیر را فراهم می‌کند. تماسی که هم‌زمان نام، کد ملی و چهار رقم آخر کارت بانکی شما را بداند نیز همچنان می‌تواند کلاهبرداری باشد؛ دانستن این اقلام دیگر نشانه اصالت تماس‌گیرنده نیست.
- هیچ بانک یا صرافی‌ای رمز پویا، رمز دوم یا CVV2 را تلفنی نمی‌پرسد، حتی وقتی بقیه اطلاعات شما را درست می‌گوید.
- احراز هویت دومرحله‌ای مبتنی بر اپلیکیشن (نه پیامک) را همه‌جا فعال کنید؛ امنیتش به‌طور کلی از پیامک بیشتر است.
- فرض را بر این بگذارید که کد ملی و تصویر کارت ملی شما برای همیشه افشا شده است.
§۱۲ آنچه شواهد نشان نمی‌دهند
اعتبار یک گزارش نشت، به اندازه یافته‌هایش به صراحت محدودیت‌هایش وابسته است.
- تعداد دقیق رکوردها. عدد ۷۴۸٬۰۴۸ ادعای فروشنده است و مستقل تأیید نشده؛ تنها والکس می‌تواند آن را با شمارش مستقیم قطعی کند.
- محتوای یازده فایلی که نمونه‌ای از آن‌ها ندیده‌ایم. برای
valuable_addresses،user_status،trade_new_balancesو بقیه، فقط نام و اندازه داریم. تفسیر محتوا در §۴ استنباط از نام است و باید چنین خوانده شود. - کامل بودن فهرست فایل‌ها. پنجره مدیر فایل در لبه پایین صفحه بریده می‌شود؛ ممکن است فایل‌های دیگری زیر خط برش باشند.
- اینکه آیا داده پیش‌تر فروخته شده است. ادعای فروشنده مبنی بر اینکه «داده را فقط من دارم (فعلاً)» راستی‌آزمایی‌پذیر نیست. پرانتز «فعلاً» را باید جدی گرفت.
- وضعیت فعلی نشانی اسناد. آزمایش نشده و نباید توسط ما یا دیگری آزمایش شود.
- صحت ادعای رخداد اعلام‌نشده. تنها با سوابق خود والکس یا مرجع نظارتی قابل بررسی است.
- هویت واقعی فروشنده. جزئیات مرتبط با این موضوع عمداً از این گزارش عمومی حذف شده و به نهاد صلاحیت‌دار سپرده شده است؛ انتساب نام به یک فرد کار مرجع قضایی است، نه این گزارش.
- اینکه عامل کارمند بوده یا نه. فرضیه محتمل‌تر، فرضیه اثبات‌شده نیست (§۱۰).
تحلیل روی ۵٬۰۹۳ رکورد پروفایل، یک رکورد کارمندی، دو رکورد بانکی و دو تصویر انجام شد. هیچ زیرساخت زنده‌ای فراخوانی نشد، هیچ نشانی مدرک هویتی گشوده نشد، و هیچ اطلاعات ورود، شماره کارت، شماره شبا، نشانی ایمیل کارمندی یا نام شخصی در متن نوشته نشد. یافته‌ها توصیف‌کننده نمونه‌هایند؛ برآوردها و تعمیم‌ها صریحاً برچسب خورده‌اند و آنچه شواهد نشان نمی‌دهند در §۱۲ فهرست شده است.