رمزی که رمز نیست: بکاند مشترک اپهای شهری چین
هوش مصنوعیخلاصهٔ کاملتر
این یادداشت بخشی از یه سری پژوهشیه دربارهٔ صحنهٔ «پشمچینی» (薅羊毛) در چین: اسکریپتهایی که روی کرون اجرا میشن تا امتیاز، کوپن و جایزهٔ قرعهکشی اپها رو خالی کنن. نویسنده تأکید میکنه همهٔ یافتههاش از خوندن مخزنهای عمومی و متنبازِ گیتهاب به دست اومده — هیچ endpointی رو صدا نزده و هیچ اسکریپتی رو اجرا نکرده.
ماجرا از یه اپ شهری کوچیک شروع شد؛ همون چیزی که یه شهرداری برای تعامل با شهروندها، آموزش و نظرسنجی راه میندازه: ورود روزانه، خوندن چند مقاله، گرفتن چند امتیاز و شاید یه قرعهکشی. ولی وقتی نویسنده اپ دوم و سوم شهرهای مختلف رو باز کرد، همون endpointها رو دید — حتی با همون غلط املایی مشترک تو مسیر یکی از APIها. اینجا بود که فهمید اینها اپ سفارشی نیستن، مستأجرن.
پشت این اپها چهار ارائهدهندهٔ B2B «بازاریابی تعاملی» نشستن: tmuyun (天目云) برای حساب کاربری و تعامل با محتوا، aihoge برای فعالیت و قرعهکشی، jinhua (金华云) برای آزمون و گردونهٔ شانس، و Duiba (兑吧) بهعنوان سامانهٔ جایزهٔ شخصثالث. هر اپ چندتاشون رو به هم زنجیر میکنه، و تنها چیزی که مستأجرها رو از هم جدا میکنه یه client_id و یه کد منطقهست.
قلب ماجرا اما طرح امضاست. به گفتهٔ نویسنده، درخواستهای کمپین دو جور امضا میشن و هیچکدوم راز واقعیِ مخصوص هر مشتری ندارن. امضای GET یه SHA-256 روی ترتیب ثابتی از فیلدهاست که همهٔ ورودیهاش برای مهاجم شناختهشدهست، و «نمک» (salt) اون یه رشتهٔ ثابت و عمومیه که عیناً تو اسکریپتهای متنباز هر فارمر هاردکد شده. امضای ورود هم HMAC-SHA256ه، ولی کلیدش تو کلاینت نیست — کلاینت اون رو از یه endpoint اولیه با پاسدادن client_id درخواست میکنه و سرور تحویلش میده.
رمزنگاری RSA-1024 روی رمز عبور هم به تعبیر نویسنده فقط رمزنگاری انتقاله، نه احراز هویت: جلوی شنود روی سیم رو میگیره ولی مانع جعل امضا نمیشه. ضمن اینکه RSA-1024 بیش از یک دههست ضعیف حساب میشه و NIST از ۲۰۱۳ برای کلیدهای جدید کنارش گذاشته. نتیجهگیری او روشنه: چیزی «نفوذ» نشده، خود طراحی همهچیز رو دستیدستی تحویل میده.
پیامدش اینه که سطح حملهٔ واقعی، ارائهدهندهست نه هیچ اپ خاصی. اگه به API فعالیت یک ارائهدهنده برسی، همهٔ مشتریهاش رو با هم پوشش دادهای. همین طرح امضا جلوی endpointهای حساب و عضویت هم قرار داره، پس نویسنده احتمال میده اطلاعات هویتی شهروندها هم پشت همین ضعف باشه — هرچند صریح میگه این نیمهٔ ماجرا رو هرگز آزمایش نکرده و صرفاً استنتاج از کده. این هم فقط کار یه نفر نیست: همون بکاند مشترک تو اسکریپتهای اپراتورهای بیارتباط در دستکم دو شهرستان استان ژهجیانگ و حتی تا گوانگدونگ پیدا میشه.
خودِ کمپینها مکانیک وفاداری معمولیان و سرتاسر خودکار شدن: خوندن مقاله برای امتیاز با یه زمان توقف هاردکدشده، لایک و اشتراک، ورود روزانه، تکمیل آزمون و شرکت در قرعهکشی. کپچای جلوی قرعهکشی هم با یه OCR یادگیریعمیق متنباز حل میشه، و برداشت پول مستقیم به یه حساب Alipay میره که تو کانفیگ خود اسکریپت نشسته.
اما دو شاخهست که به نظر نویسنده این ماجرا رو از کلاهبرداری تجاری ساده فراتر میبره. اول، تعامل ساختگی روی محتوای رسانههای دولتی: عددهای تعامل صرفاً آمار تزئینی نیستن، بلکه به تصمیمهای واقعی خوراک میدن — اینکه کدوم خبر ترویج بشه، کدوم موضوع فصل بعد منابع بیشتری بگیره، کدوم روایت «گرفته». وقتی پرخوانندهترین مقالهٔ هفته با یه کرون هدلس باد شده، تحریریه داره برای سلیقهٔ یه ربات بهینه میکنه؛ و یه اپراتور میتونه عمداً مقالهٔ خاصی رو بالا بکشه.
شاخهٔ دوم عجیبتره: سه اسکریپت، برنامههای خدمات اجتماعی شهرداری پکن رو هدف گرفتن که آزمونهای آموزش شهروندی برگزار میکنن و جایزهشون شرکت در قرعهکشی نقدیه. اسکریپت مطلب رو یاد نمیگیره؛ سؤال رو از API میخونه، به یه مدل زبانی — Spark شرکت iFlytek، اون هم ارزونترین ردهٔ خانواده — میده و جواب تکحرفی رو ثبت میکنه، بعد قرعهکشی رو برمیداره. کل این حلقه حدود صد و پنجاه خط پایتونه. تعبیر خود نویسنده اینه که هیچکس تو این زنجیره کاری رو که فکر میکنه نمیکنه: برنامه فکر میکنه داره آموزش میده، فروشندهٔ هوش مصنوعی فکر میکنه داره دستیار میفروشه، و سامانهٔ قرعهکشی فکر میکنه داره شهروند فعال رو پاداش میده.
نویسنده در پایان محدودیتهای کارش رو صادقانه فهرست میکنه: معلوم نیست دو ارائهدهندهٔ اصلی یه شرکتان، لایسنس فروختن یا از یه SDK وایتلیبل مشترک استفاده میکنن؛ ادعای اینکه endpoint اولیه به یه فراخوان کاملاً تازه هم کلید میده استنتاجه نه چیزی که روی سیم اثباتش کرده؛ و کل بازسازی طرح امضا از روی اسکریپتهای متنی فارمرهاست. عمداً هم ابزار آمادهٔ امضاسازی منتشر نکرده، چون به گفتهٔ خودش «میشه دستور پخت رو خوند» با «اینم یه بستهٔ آمادهٔ نشانهرفته به پروداکشن» دو چیز متفاوته.
نکات کلیدی:
- اپهای شهری چند شهرستان چین مستأجرهای چند SaaS مشترکان و فقط با یه client_id از هم جدا میشن
- نمک امضای GET یه رشتهٔ ثابت و عمومیه که تو اسکریپتهای متنباز هاردکد شده
- کلید HMAC ورود تو کلاینت نیست؛ سرور اون رو موقع درخواست تحویل میده
- رمزنگاری RSA-1024 روی رمز عبور فقط لایهٔ انتقاله و احراز هویت نمیسازه
- سطح حملهٔ واقعی ارائهدهندهٔ SaaSه، نه تکتک اپهای شهری
- همون بکاند در اسکریپتهای اپراتورهای بیارتباط در چند استان دیده شده
- دو پیامد جدی: تعامل ساختگی روی محتوای رسانهٔ دولتی و پاسخ خودکار آزمونهای شهروندی با مدل زبانی برای جایزهٔ نقدی
- همهٔ یافتهها از خوندن مخزنهای عمومی به دست اومده؛ نویسنده هیچ درخواستی به سرویسهای زنده نزده
