پس منظر

جون 2026 میں، Arch Linux AUR ایکوسسٹم میں بڑے پیمانے پر سپلائی چین زہریلا ہونے کا واقعہ سامنے آیا، جسے Sonatype نے "Atomic Arch" کا نام دیا۔ اس واقعہ میں Arch Linux کے اصل ریپوزٹری، pacman، AUR ہیلپر یا Arch Linux خود میں کوئی زیرو ڈے کمزوری نہیں تھی، بلکہ حملہ آوروں نے AUR کے بے مالک پیکجز کو دعویٰ کرنے کے مکانیز کا غلط استعمال کیا، جس کے ذریعے وہ لمبے عرصے سے نہ رکھے جانے والے لیکن صارفین کے ذریعہ اعتماد کیے جانے والے پیکجز کو قانونی طور پر قبضہ کر لیا اور ان کے PKGBUILD یا انسٹال سکرپٹس میں تبدیلی کی۔

جب صارف عام AUR انسٹال یا اپ ڈیٹ آپریشن کرتا ہے، تو برے نیت والے اسکرپٹ npm یا Bun کو فراہم کرتا ہے، جس سے حملہ آور کنٹرول کردہ جاوااسکرپٹ پیکیج انسٹال ہوتے ہیں اور npm لائف سائیکل ہُکس کے ذریعے لینکس ELF لوڈ کو انجام دیا جاتا ہے۔ یہ لوڈ بنیادی طور پر لینکس ڈویلپرز کے ورک اسٹیشن اور بِلڈ ماحول کے لیے ہے، جس میں گٹھبب، npm، SSH، ڈاکر/پوڈمن، وولٹ، براؤزر ڈیٹا اور شیل تاریخ جیسی حساس معلومات چوری کرنے کی صلاحیت شامل ہے۔

عوامی اعلان کے مراحل میں، متاثرہ AUR پیکیجز کی تعداد اب تک کے 400 سے زائد سے بڑھ کر تقریباً 1,500 ہو گئی ہے۔ یہ واقعہ ظاہر کرتا ہے کہ اوپن سورس ایکوسسٹم میں "کسی کے ذریعہ نہ رکھے جانے والے لیکن اب بھی قابل اعتماد" کمپوننٹس، حملہ آور کے لیے اسکرپٹس، پیکج مینیجر لائف سائیکل ہُooks اور ڈویلپرز کے لوکل ماحول کو جوڑنے کے لیے نئے سپلائی چین انٹری پوائنٹس بن رہے ہیں۔

یہ مضمون MistEye کے `runescape-launcher`، `atomic-lockfile@1.4.2` اور `js-digest@4.2.2` کے سٹیٹک اینالیسس کے نتائج پر مبنی ہے، جو حملے کے کلیدی ٹیکنیکل ایلیمنٹس کو واضح کرتا ہے۔ اوپر ذکر کردہ نمونے تمام حملہ نمونے نہیں ہیں، بلکہ حملے کے نمونے کو ظاہر کرنے کے لیے ٹیکنیکل پروفائل کے طور پر استعمال کیے گئے ہیں۔

مِسٹ آئی کا جواب

MistEye، SlowMist کا خود ساختہ Web3 خطرات کی معلومات اور ڈائنانک سیکیورٹی مانیٹرنگ سسٹم ہے، جو سیکیورٹی مانیٹرنگ اور معلومات کے اکٹھے کرنے کی صلاحیتیں متحد کرتا ہے تاکہ صارفین کو ریل ٹائم خطرات کی اطلاعات اور اثاثوں کی حفاظت فراہم کی جا سکے۔

اس آرچ لینوکس AUR سپلائی چین زہریلہ حملے میں، مسٹ آئی کے نے متعلقہ خطرناک پیکیجز، npm ڈیپینڈنسیز، ELF لوڈ، C2 کمیونیکیشن اور دوسرے مرحلے کے ڈاؤنلوڈ جیسے حملے کے اجزاء کا تجزیہ اور ربط کیا اور متعلقہ IOC نکالے۔ تجزیہ کے نتائج کے مطابق، مسٹ آئی نے اپنے صارفین کو اعلانات کے ذریعے انتہائی خطرناک خطرات اور تهدید کی معلومات فراہم کی ہیں تاکہ وہ متعلقہ سپلائی چین خطرات کو جلدی پہچان سکیں اور ان کا انتظام کر سکیں۔ معلومات کی تفصیل:

ذیل میں تفصیلی ٹیکنیکل تجزیہ ہے۔

حمل کی سلسلہ کا تجزیہ: AUR انسٹال اسکرپلیٹ سے npm زندگی کے اسکرپٹ تک

اس حملے کی تکنیکی بنیاد تین مرحلہ جاتی ترقی کے ساتھ خلاصہ کی جا سکتی ہے: حملہ آور نے AUR پیکیج کو کنٹرول کرکے بناوٹ/نصب سکرپٹس میں تبدیلی کی، جس سے pacman نصب یا اپ ڈیٹ کے دوران npm install چل گیا جس نے برے پیکیج کو ڈاؤن لوڈ کیا، اور پھر npm زندگی کے دوران سکرپٹس (preinstall) کا استعمال کرتے ہوئے پیکیج میں چھپا ہوا لینکس ELF نیٹو لود کو خودکار طور پر اجراء کیا۔ ذیل میں تینوں مرحلہ جات کو الگ الگ بیان کیا جا رہا ہے۔

runescape-launcher پیکج (ورژن 2.2.12-1) کے ساتھ مثال دیں۔ حملہ آور نے .SRCINFO اور PKGBUILD میں install.sh کا حوالہ شامل کیا اور npm کو رن ڈیپینڈنسی کے طور پر اعلان کیا۔

SRCINFO میں اہم اعلانات:

PKGBUILD میں متعلقہ اعلان:

install.sh ایک pacman انسٹال اسکرپٹل فائل ہے۔ حملہ آور نے اس فائل میں post_install() فنکشن کو تعریف کیا اور post_upgrade() کو اسی فنکشن کی طرف اشارہ کیا:

اہم اجرائی لائن درج ذیل ہے:

SRCINFO کا اعلان کرتا ہے کہ install = install.sh اور depends = npm

→ PKGBUILD میں install="install.sh" اور depends=('npm' ...) کا سینکرونائزیشن

→ makepkg install.sh کو آخری pacman پیکیج میں شامل کرتا ہے

→ پیکمن کو پہلی بار انسٹال کرتے وقت post_install() کو کال کریں

→ pacman کو اپ گریڈ کرتے وقت post_upgrade() کو کال کریں

→ post_upgrade() post_install() کو کال کرتا ہے

→ post_install() /tmp میں داخل ہو جائیں

→ npm install atomic-lockfile commander chalk → npm atomic-lockfile@1.4.2 انسٹال کریں

atomic-lockfile کے preinstall کو ٹرگر کریں

→ Linux x86-64 ELF لوڈ کرنے کے لیے src/hooks/deps کو نفاذ کریں

کچھ نکات پر توجہ دیں: commander اور chalk npm پر قانونی اور مقبول پیکج ہیں، ضروری طور پر برے نہیں؛ ایک ہی post_install() کے اندر موجود/ساتھ والی setcap منطق بھی ہے، برے انداز میں شامل کیا گیا حصہ cd /tmp اور npm install atomic-lockfile commander chalk ہے۔

اس لیئر کا مرکزی ڈیزائن مقصد یہ ہے کہ pacman کے پیکیج انسٹال/اپ گریڈ لائف سائکل کو ایک اسکیل کے طور پر استعمال کیا جائے تاکہ اجراء کا اختیار سسٹم پیکیج مینیجر سے npm کو منتقل کیا جائے، اور یہ پہلی انسٹالیشن اور اپ گریڈ دونوں پر ٹرگر ہوگا۔

atomic-lockfile@1.4.2 اس حملے کی پہلی لہر میں استعمال ہونے والا تصدیق شدہ مضر npm پیکیج ہے۔ یہ پیکیج ظاہری طور پر فائل لوک ٹول لائبریری کے طور پر چھپا ہوا ہے، جس میں مکمل TypeScript/JavaScript لائبریری کی ساخت، main/module/exports انٹری، CLI اور ٹائپ ڈیفینیشنز شامل ہیں۔ لیکن حملہ آور نے package.json کے scripts.preinstall میں انسٹال کے دوران نیٹو بائنری کو خودکار طور پر اجراء کرنے کے لیے ترتیب دی ہے:

src/hooks/deps صرف ایک عام ڈیپینڈنسی انسٹالیشن اسکرپٹ نہیں ہے، بلکہ ایک سمبول ٹیبل کے بغیر کی گئی لینکس x86-64 PIE ELF ایگزیکیبل فائل ہے۔ اہم میٹا ڈیٹا:

• فائل کا راستہ: src/hooks/deps
• فائل کا قسم: ELF 64-bit LSB pie ایگزیکیبل، x86-64، ڈائنامک لینکڈ، اسٹرپڈ
• ELF SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
• سائز: 3,040,376 باٹس
• متحرک منحصری: libbpf.so.1، libm.so.6، libc.so.6
• ایم بیڈڈ eBPF آبجیکٹ SHA-256: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
• ایم بی پی ایف آبجیکٹ کا اسٹیپ: 0x324f9
• اصل tarball SHA-256: 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

ایک ELF لوڈ کی صلاحیتیں ایکونٹ کی تفصیلات کی جمع آوری، مستقل رہنے کی صلاحیت، چینل کے ذریعہ مواصلات/اپ لوڈ، اور روت یا مناسب صلاحیت کے ساتھ eBPF چھپنے والے کمپوننٹس کو فعال کرنے کی کوشش شامل ہیں، جن کی تفصیل درج ذیل ہے۔

ریپیٹڈ XOR دیکوڈنگ اور ٹور ہائڈن سروس C2

atomic-lockfile@1.4.2 کے ELF پیلود میں، اہم C2 کو صاف متن کے طور پر نہیں، بلکہ repeating-XOR کے ذریعے کوڈ کیا گیا اور محفوظ کیا گیا۔ نمونہ میں 0x1aa60 کے آف سیٹ پر 32 بائٹ کی کلید اور 0x2da96 کے آف سیٹ پر 62 بائٹ کا سیفٹیکس محفوظ ہے۔ ڈیکوڈنگ کا طریقہ یہ ہے:

پلین[i] = سائفر[i] ^ کی[i % 32]

ڈیکوڈ کرنے کے بعد ٹور v3 ہائیڈن سروس ایڈریس حاصل ہوتا ہے:

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

62 بائٹس کی لمبائی بالکل 56 کریکٹرز کے Tor v3 onion ہوسٹ نام کے ساتھ .onion سافکس کو ظاہر کرتی ہے۔ C2 ہوسٹ کے علاوہ، نمونہ ایجنٹ شناخت اور ورژن کو بھی اسی طرح کوڈ کرتا ہے:

• ایجینٹ نام: atomic، کی آفسیٹ 0x1bc60، سائفر آفسیٹ 0x3fddf
• ایجینٹ ورژن: 0.8.2، کی آفسیٹ 0x1c900، سائفر آفسیٹ 0x3fde5

یہ ڈیزائن یہ یقینی بناتا ہے کہ مکمل C2 عام strings آؤٹ پٹ میں نہیں آتا۔ اس لیے، صرف strings | grep .onion، صاف متن YARA قواعد یا آسان IOC اکٹھا کرنے کے عمل پر انحصار کرنا، اس hidden service C2 کو دریافت کرنے میں ناکام ثابت ہو سکتا ہے۔

ٹور/سوکس کمیونیکیشن لینک

اگرچہ C2 ہوسٹ XOR کوڈنگ کے ذریعہ چھپایا گیا ہے، لیکن ELF میں ابھی بھی SOCKS/Tor سے متعلق واضح اسٹرنگز نظر آتے ہیں، جیسے:

ان اسٹرنگز کو ڈیکوڈ کردہ .onion ایڈریسز کے ساتھ ملا کر یہ ظاہر ہوتا ہے کہ اس پیلود میں SOCKS/Tor کے ذریعے ہائیڈن سروس C2 تک رابطے کا فریم ورک شامل ہے۔

اسی طرح، ELF میں HTTP درخواست کی تعمیر اور اپ لوڈ سے متعلق تاریں بھی موجود ہیں، جن میں POST، GET، HTTP/1.0، HTTP/1.1، Host:، Content-Length:، Content-Type: application/json، Content-Type: application/octet-stream، POST /upload HTTP/1.1 اور Content-Type: multipart/form-data شامل ہیں۔ POST /upload اور multipart ٹیمپلیٹ سے پتہ چلتا ہے کہ payload میں اپ لوڈ کی تعمیر کی صلاحیت ہے، لیکن کیا یہ temp.sh سروس سے متعلق ہے اور کیا اس کا حقیقی طور پر باہر بھیجنا ہوا ہے، اس کی تصدیق صرف ڈائنامک ٹریفک، پروکسی لاگ یا ہوسٹ فارنسک گواہی سے ممکن ہے۔

کرڈنشلز اور ڈیولپمنٹ ایونٹ کی جمع کاری

ایل ایف کے کریڈنشلز کی جمع کاری کا دائرہ جدید ڈویلپرز کے ورک اسٹیشن کے کئی اہم کریڈنشل اسٹوریج پوائنٹس کو کور کرتا ہے۔

راکٹ کے حوالے سے، لوڈ میں گٹہب ٹوکن کی تصدیق اور ریپوزیٹری کی فہرست کے متعلق تار شامل ہیں — GET /user، GET /user/repos، Authorization: Bearer، Accept: application/vnd.github+json؛ npm ٹوکن کی تصدیق کے تار — GET /-/whoami، registry.npmjs.org، _authToken=؛ اور وولٹ کے حوالے سے تار — /.vault-token، X-Vault-Token:۔

ایمیج کمیونیکیشن اور کولابوریشن ٹولز کے حوالے سے، Slack کے متعلق اسٹرینگز میں auth.test، conversations.list، users.info API پاتھز اور %.slack.com کے لیے کوکی SQL کوئریز شamil ہیں؛ Teams/Skype کے حوالے سے X-Skypetoken:، authsvc.teams.microsoft.com اور %teams.microsoft.com کے لیے کوکی کوئریز شamil ہیں؛ Discord سے متعلق اسٹرینگز جیسے discord: بھی ظاہر ہوئے ہیں۔

لوڈ کے حوالے سے، مقامی اور کنٹینر ماحول میں .ssh، known_hosts، PRIVATE KEY، PuTTY-User-Key-File جیسے SSH اعتماد کی فائلیں، اور .bash_history، .zsh_history، .env، اور Chromium سیریز براؤزرز کے کوکیز اور لوکل اسٹوریج کے راستے شامل ہیں۔ Docker/Podman اور DevOps ٹولز سے متعلق تاریں — جیسے docker login، docker push، docker pull، docker build، docker run، docker tag، docker-compose، podman login، podman push — ELF میں ظاہر ہوتی ہیں، لیکن ابھی تک یہ صرف سٹیٹک تاروں کے طور پر نشانات ہیں، مکمل ڈیٹا جمع کرنے کی سلسلہ واری کی تصدیق نہیں ہوئی ہے۔ claude: تاروں کو AI ٹولز سے متعلق نشانات کے طور پر بھی استعمال کیا جا سکتا ہے، لیکن یہ الگ طور پر Claude ڈیٹا جمع کرنے کا ثبوت نہیں ہے۔

اپ لوڈ اور دوسرے مرحلے کی ڈاؤن لوڈ

لوڈ میں HTTP multipart اپ لوڈ ٹیمپلیٹ اور /var/tmp، /secrets جیسے ڈیٹا اسٹوریج پاتھ شامل ہیں۔ نمونہ onion C2 کے ذریعے ٹاسک/نتیجہ کمیونیکیشن اور multipart اپ لوڈ درخواستوں کو تشکیل دینے کی صلاحیت رکھتا ہے؛ کیا یہ temp.sh سروس سے متعلق ہے، یا کیا اس نے مخصوص شکار ہوسٹ پر اپ لوڈ کیا یا ڈیٹا بھیجا، اس کی تصدیق صرف ڈائنامک اجرا، پروکسی لاگ، یا ہوسٹ فارنسک گواہی سے ممکن ہے۔ دوسرے مرحلے کی ڈاؤن لوڈ لائن بھی واضح سٹیٹک نشانات چھوڑتی ہے: /bin/sha256/ اور sha256 fetch: سٹرنگس دوسرے مرحلے کے hash چیک پاتھ کو ظاہر کرتی ہیں؛ server returned empty binary اور tmp 200 headers too large سے پتہ چلتا ہے کہ دوسرے مرحلے کی ڈاؤن لوڈ ناکامی کے لیے ایرر ہینڈلنگ منطق موجود ہے۔ Tor bundle کو کش کرنے کے نشانات /tor-expert-bundle- اور SOCKS ٹرانسمیشن لائنک کا ترکیب staging ڈاؤن لوڈ کے لیے راستہ فراہم کرتے ہیں۔

مشتبہ کرپٹومائنر کے اشارے

atomic-lockfile کے ELF میں /usr/bin/monero-wallet-gui سٹرنگ ظاہر ہوتی ہے۔ دوسرے مرحلے کے ڈاؤنلوڈ لینک کے ساتھ مل کر، یہ اندازہ لگایا جاتا ہے کہ لوڈ کیا گیا ٹول Monero مائننگ سے متعلقہ بائنری کو دوسرے مرحلے میں حاصل کر سکتا ہے۔ موجودہ نمونے میں xmrig، randomx، stratum، مائننگ پول ڈومین یا والٹ ایڈریس جیسی مضبوط مائنر خصوصیات تصدیق نہیں ہوئی ہیں، اس لیے داخلی مائنر کے وجود کو مستقیم طور پر نہیں کہا جا سکتا۔

پائیدار

نمونے میں systemd سروس سے متعلق ٹیمپلیٹس ظاہر ہوئے ہیں، جو صارف سطح اور سسٹم سطح دونوں شروع ہونے کے مناظر کو کور کرتے ہیں۔ اس سے ظاہر ہوتا ہے کہ لوڈ کا مقصد اپنے آپ کو سسٹم سروس کے طور پر رجسٹر کرنا اور ری سٹ یا صارف کے سیشن کے شروع ہونے کے بعد بھی جاری رکھنا ہے۔

eBPF چھپنا اور ڈیجیٹل فارنسکس کے خلاف

eBPF (وسع یافتہ بیرکلے پیکٹ فلٹر) لینکس کرنل کی فراہم کردہ ایک تکنیک ہے جو صارفین کو کرنل سورس کو تبدیل کیے بغیر، محدود کسٹم پروگرامز کو کرنل میں لوڈ کرنے اور چلانے کی اجازت دیتی ہے۔ عام استعمال میں یہ نیٹ ورک فلٹرنگ، قابل مشاہدہ صلاحیت اور سیکورٹی مانیٹرنگ کے لیے استعمال ہوتا ہے، لیکن اس نمونے میں eBPF کا کمپوننٹ الٹی طرف سے ڈیزائن کیا گیا ہے — نہ کہ سسٹم کو "دیکھنے" کے لیے، بلکہ خود کو "چھپانے" کے لیے۔

atomic-lockfile@1.4.2 کا ELF لوڈ کرنے والا جزو src/hooks/deps libbpf.so.1 کے لیے انحصار رکھتا ہے اور bpf_object__open_mem، bpf_object__load، bpf_program__attach، bpf_map__pin جیسے API کے ذریعے اندرونی eBPF قابل ریلوکیٹ کنندہ آبجیکٹ لوڈ کرنے کی کوشش کرتا ہے۔ یہ منطق شرطی طور پر نہیں چلتا: نمونہ پہلے geteuid() کو بلاتا ہے تاکہ یہ جانچے کہ کیا صارف root ہے، پھر /proc/self/status پڑھتا ہے، CapEff: فیلڈ کو تجزیہ کرتا ہے، اور CAP_BPF، CAP_SYS_ADMIN کے متعلقہ صلاحیت بٹس کو ٹیسٹ کرتا ہے۔ زیادہ درست طور پر، صرف جب اجازت کی شرائط پوری ہوتی ہیں، تو نمونہ eBPF لوڈ کرنے کے راستے میں داخل ہوتا ہے۔ یعنی، یہ زیادہ تر ایک شرطی طور پر پوشیدہ ماڈول کی طرح ہے؛ موجودہ اسٹیٹک ثبوت اس بات کا ثبوت نہیں دیتے کہ اس نے خود کو اپگریڈ کر لیا ہے۔

ڈی کمپائلیشن سے پتہ چلتا ہے کہ میزبان پروگرام 0x324f9 کے آف سیٹ سے 0xce28 لمبائی کا ایم بیڈڈ آبجیکٹ پڑھتا ہے، جو ایک 52,776 بائٹس کا eBPF آبجیکٹ ہے۔ اس آبجیکٹ کا SHA-256 ہے：

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

استخراج شدہ eBPF آبجیکٹ ایک الگ کمپائلڈ پروڈکٹ ہے، جس کا فائل ٹائپ ELF 64-bit LSB relocatable ہے، جس میں debug_info / BTF معلومات ہیں اور اسے stripped نہیں کیا گیا ہے۔ اس کی ڈیبگ معلومات میں سورس کوڈ کا راستہ بھی لیک ہو گیا ہے:

/cloud/scales/agent/../ebpf/scales.bpf.c

یہ eBPF آبجیکٹ BPF میپس (حالت محفوظ رکھنے کے لیے ڈیٹا ٹیبلز) اور ٹریسپوائنٹس (کرنل واقعات کے ہکس) کے استعمال سے متعدد اقسام کی چھپی ہوئی اور ڈیجیٹل فارنسکس کے خلاف ثبوت کے نشانات تیار کرتا ہے۔ اس کی ڈیبگنگ معلومات اور سمبولز میں hidden_pids، hidden_names، hidden_inodes، net_fds، diag_fds، getdents64، ptrace، recvmsg اور bpf_probe_write_user جیسے نام شامل ہیں، جو اس کا ڈیزائن مقصد پروسیسز کو چھپانا، ڈائرکٹری ایلمنٹس کو چھپانا، نیٹ ورک کنکشن سے متعلق سوکٹ/اینود کو چھپانا اور ڈیبگرز کو جوڑنے میں رکاوٹ ڈالنا شامل ہے۔

خود کو دیکھتے ہوئے، اس eBPF آبجیکٹ کے فنکشنل نشانات تین قسموں میں تقسیم ہو سکتے ہیں:

1. پروسیس اور ڈائریکٹری آئٹمز کو چھپائیں: hidden_pids کو چھپانے کے لیے ضروری PID محفوظ کرنے کے لیے استعمال کیا جاتا ہے؛ sched_process_exec متعلقہ منطق نئے پروگرام کے اجرا کے دوران hidden_names کے مطابق پروسیس نام کو میچ کرے گا اور میچ ہونے والے PID کو چھپائے گئے مجموعے میں شامل کرے گا۔ getdents64 متعلقہ منطق ڈائریکٹری پڑھنے کے نتائج کے معالجہ کے لیے ہے، جس سے بری خطرہ /proc جیسی ڈائریکٹری فہرستوں سے مخصوص PID یا ڈائریکٹری آئٹمز کو چھپا سکتا ہے۔
2. نیٹ ورک کنکشن کی فہرست کو متاثر کرنے والے عوامل: recvmsg، socket، hidden_inodes، net_fds، diag_fds جیسے اشارے نیٹ ورک کنکشن کی فہرست کے نتائج کو متاثر کر سکتے ہیں، جس سے ss، netstat جیسے ٹولز کو socket/inode معلومات نظر نہیں آ سکتیں۔
3. ڈیبگنگ اور جعلی نتائج کو روکنا: ptrace، PTRACE_ATTACH، PTRACE_SEIZE اور bpf_send_signal(9) کا ظہور ڈیبگر کو جوڑنے سے روکنے والے اینٹی-فورنسک ڈیزائن کو ظاہر کرتا ہے؛ کئی bpf_probe_write_user سٹرنگز یہ بتاتی ہیں کہ یہ آبجیکٹ صارفی حالت کے بفرز کو تبدیل کرنے کا عمل رکھتا ہے، جو ڈائریکٹری اور نیٹ ورک ایٹم کو چھپانے کا ایک اہم طریقہ ہے۔

چونکہ یہ ایک سٹیٹک تجزیہ تھا، اور نمونہ کو ڈائنامک طور پر نہیں چلایا گیا، اس لیے یہ تصدیق نہیں کی جا سکتی کہ یہ eBPF آبجیکٹ کسی خاص ہوسٹ پر کتنی کامیابی کے ساتھ لوڈ ہوا، اور نہ ہی یہ کہا جا سکتا ہے کہ اس نے حقیقت میں پروسیسز، ڈائرکٹری ایلمنٹس یا نیٹ ورک کنکشنز کو چھپایا ہے۔ تاہم، اجازتوں کے چیک منطق، میپ سٹرکچر، ٹریسپوائنٹ کے دائرہ کار اور bpf_probe_write_user کے استعمال کے نشانات کے مطابق، اس کا مقصد روت یا متعلقہ کرنل صلاحیتیں رکھنے والے صارفین کے لیے پروسیسز، ڈائرکٹری ایلمنٹس اور نیٹ ورک کنکشنز سے متعلق سوکٹ/اینوڈ نشانات کو چھپانا اور ڈائنامک تجزیہ کے لیے رکاوٹیں پیدا کرنا ہے۔

js-digest@4.2.2 اس حملے کے بعدلی موج کے لیے استعمال کیا جانے والا تصدیق شدہ خطرناک npm پیکج ہے۔ یہ پیکج جاوااسکرپٹ خلاصہ/اینکرپشن ٹول لائبریری کا دعویٰ کرتا ہے اور aes.js، sha256.js، hmac-sha512.js، index.js جیسے معمولی سروں کے فائلز پر مشتمل ہے۔ حملہ آور نے package.json میں preinstall ایںٹری بھی ترتیب دی ہے:

اٹومک-لوکفائل کے ساتھ بنیادی فرق لوڈ کے نامکردن کی پالیسی میں ہے۔ install-deps.mjs کا سفکس .mjs یہ ظاہر کرتا ہے کہ یہ ESM JavaScript ماڈول ہے، جس سے انسانی جانچ کرنے والے اور فائل کے ایکسٹینشن پر مبنی ڈیٹیکشن رولز کی احتیاط کم ہو جاتی ہے۔ لیکن سٹیٹک فائل ٹائپ شناخت سے پتہ چلتا ہے کہ یہ دراصل Linux x86-64 PIE ELF ہے۔ بنیادی میٹا ڈیٹا:

• فائل کا راستہ: lib/install-deps.mjs
• سافٹ ویئر کا پس منظر: ESM JavaScript ماڈیول
• حقیقی فائل کا قسم: ELF 64-bit LSB pie ایگزیکیبل، x86-64، ڈائنا مکلی لنکڈ، اسٹرپڈ
• ELF SHA-256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
• سائز: 3,193,176 باٹس
• متحرک منحصری: libbpf.so.1، libm.so.6، libc.so.6
• ایم بیڈڈ eBPF آبجیکٹ SHA-256: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
• ایم بی پی ایف آبجیکٹ کا ترتیب: 0x37d91
• اصل tarball SHA-256: 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

js-digest بھی C2 کو repeating-XOR کوڈنگ کے ذریعے چھپاتا ہے۔ 0x1cba0 کے آف سیٹ پر 32 بائٹ کی کلید شامل ہے، اور 0x32bcb کے آف سیٹ پر 62 بائٹ کا کرپٹو ٹیکسٹ محفوظ ہے، جس کی ڈیکوڈنگ نتیجہ atomic-lockfile کے مکمل طور پر مطابق ہے:

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

اس کا ایجینٹ شناخت اور ورژن ہے:

• ایجینٹ نام: cryjs (کلید آف سیٹ 0x1d740، سائفر آف سیٹ 0x45ec2)
• ایجینٹ ورژن: 0.8.4 (کی آفسیٹ 0x1ec40، سائفر آفسیٹ 0x45ec7)

دونوں ایجنٹ کے نام (atomic vs cryjs) اور ورژن (0.8.2 vs 0.8.4) مختلف ہیں، لیکن وہ ایک ہی onion C2 ایڈریس اور ایک ہی انڈر بیڈ eBPF آبجیکٹ کو شیئر کرتے ہیں۔

js-digest، کریڈنشل کلیکشن متعلقہ سٹرنگز، SOCKS/Tor ٹرانسمیشن چین، multipart اپ لوڈ ٹیمپلیٹس، systemd پرسسٹنٹ ٹیمپلیٹ سٹرنگز اور دو مرحلہ ڈاؤن لوڈ ٹکڑوں (/bin/sha256/، sha256 fetch:) کے حوالے سے atomic-lockfile کے ساتھ انتہائی مطابقت رکھتا ہے۔ اس کے Docker/Podman اور @reboot متعلقہ اشارے atomic-lockfile کے مقابلے میں کم واضح ہیں، اور /usr/bin/monero-wallet-gui کو js-digest میں تصدیق شدہ نہیں کیا گیا ہے۔

.mjs سفیک کا دھوکہ اس حملے میں ایک قابل توجہ چھپانے کا طریقہ ہے: یہ ڈیفرنشل ڈیٹیکشن کے اندھے نکات کا فائدہ اٹھاتا ہے — اسٹرینگ اور فائل نام کے مطابق پیٹرن میچنگ قواعد .mjs فائلز کو "JavaScript ماڈیول" سفید فہرست میں شامل کر سکتے ہیں، لیکن ان کا حقیقی MIME قسم یا ELF ہیڈر چیک نہیں کرتے۔

متعلقہ نمونہ: onion C2 اور eBPF آبجیکٹ کے ساتھ دوہری سخت ثبوت

دو بری نیٹ پیکیجز atomic-lockfile@1.4.2 اور js-digest@4.2.2 کے درمیان دو الگ الگ نسبت دیے جانے والے سخت ثبوت موجود ہیں:

سخت ثبوت ایک: شیئرڈ ٹور ہائڈن سروس C2۔ دو ELF لوڈز، جو الگ الگ ہوسٹس، الگ الگ ایجینٹ نامز (اٹومک vs کرائی جے ایس) اور الگ الگ ورژنز (0.8.2 vs 0.8.4) استعمال کرتے ہیں، اور ہر ایک کے پاس الگ ریپیٹنگ-XOR کلید اور شفرڈ ٹیکسٹ ہے، لیکن ڈیکوڈ کرنے کے بعد دونوں ایک ہی ٹور ہائڈن سروس ایڈریس olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion کی طرف اشارہ کرتے ہیں۔ دو الگ طور پر ترقی دیے گئے برے ویئر فریم ورکس نہیں ہو سکتے کہ وہ C2 کے طور پر ایک ہی 56 حروف کے v3 onion ایڈریس کو صرف مصادفہ سے منتخب کر لیں۔

سخت ثبوت دو: شیئرڈ eBPF آبجیکٹ باٹس مکمل طور پر ایک جیسے ہیں۔ دونوں ELF فائلوں میں اندرا گھلے گئے eBPF قابل ری لوکیٹ کردہ آبجیکٹ کا SHA-256 مکمل طور پر ایک جیسا ہے:

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

یہ eBPF آبجیکٹ 52,776 بائٹس کا ہے، فائل کا قسم ELF 64-bit LSB ریلوکیٹیبل ہے، جس میں debug_info موجود ہے اور stripped نہیں ہے، اور سورس کوڈ کا راستہ scales.bpf.c کے طور پر نشان زد ہے۔ اہم میپس (hidden_pids، hidden_names، hidden_inodes)، ٹریسپوائنٹس (getdents64، sched_process_exec، ptrace، openat، recvmsg وغیرہ) اور مرکزی فنکشنز (walk_dirent، name_to_pid، bpf_probe_write_user) دونوں نمونوں میں مکمل طور پر مطابقت رکھتے ہیں۔ eBPF آبجیکٹ کمپائلڈ پیداوار ہے، اور بائٹ لیول پر مکمل مطابقت کا مطلب ہے کہ دونوں ELF فائلوں کو تعمیر کرتے وقت ایک ہی eBPF C سورس کوڈ استعمال کیا گیا تھا۔

اس کے علاوہ، دونوں ELF لوڈز کے حوالے سے ایک جیسے ڈیزائن کے خیالات کو اس بات سے بھی ثابت کیا جا سکتا ہے کہ وہ شناختی معلومات جمع کرنے سے متعلق اسٹرنگز، SOCKS/Tor ٹرانسمیشن آرکیٹیکچر، ملٹی پارٹ اپ لوڈ ٹیمپلیٹس، اور systemd پر سسٹم ٹیمپلیٹ اسٹرنگز جیسے انجینئرنگ صلاحیتوں میں بہت مشابہ ہیں۔ یہ اتفاقات معاون مشاہدے ہیں جو دونوں نمونوں کے ایک جیسے ماخذ کے نتیجے کو مزید تائید دیتے ہیں۔

دو نمونوں کے درمیان بنیادی فرق درج ذیل ہیں: میزبان ELF ہیش مختلف ہے، ایجنٹ کا نام اور ورژن مختلف ہے (atomic / 0.8.2 مقابل cryjs / 0.8.4)، لوڈ کا نام دہندہ حکمت عملی مختلف ہے (src/hooks/deps مقابل .mjs کا جھوٹا استعمال)، /usr/bin/monero-wallet-gui صرف atomic-lockfile میں ظاہر ہوتا ہے، اور ExecStart=@reboot بھی صرف atomic-lockfile میں سٹیٹک طور پر ہٹ جاتا ہے۔ یہ فرق یہ ظاہر کرتے ہیں کہ دونوں نمونے ایک ہی آپریشنل انفراسٹرکچر، ایک ہی بِلڈ چین یا ایک ہی سرگرمی کے کلسٹر سے شدید طور پر متعلق ہیں، صرف ریپیکیج کرنے کے بجائے۔

خلاصہ

یہ Arch Linux AUR سپلائی چین زہریلا کردار، اوپن سورس سافٹ ویئر ایکوسسٹم کے دو ساختی کمزوریوں کے اشتراکی استعمال کو ظاہر کرتا ہے: ایک تو AUR کے بے مالک پیکجز کے دعویٰ میکنزم میں دعویداروں کے لیے اعتماد کی جانچ کا فقدان، اور دوسرے، پیکج مینیجر (pacman اور npm) کے انسٹالیشن مرحلے میں قابل اجراء اعتماد کے سرحدیں جو جڑ گئی ہیں—حملہ آور کسی بھی سافٹ ویئر خامی پر انحصار نہیں کرتا، بلکہ صرف اوپن سورس ایکوسسٹم کے مینٹیننس میکنزم اور پیکج مینیجر کے ڈیزائن کے استعمال سے مکمل حملہ چین تعمیر کرتا ہے۔

اس حمل کی تکنیکی خصوصیات کو درج ذیل تین سطحوں میں خلاصہ کیا جا سکتا ہے:

AUR کی ورثہ کی بے نقاب استعمال۔ حملہ آور نے نئے پیکیج بنائے یا سافٹ ویئر کی خامی کا فائدہ نہیں اٹھایا، بلکہ غیر محفوظ AUR پیکیجز کو دعویٰ کرکے موجودہ صارفین کی بنیاد کو ورثہ میں لے لیا۔ runescape-launcher کے مثال کے طور پر، حملہ آور نے قانونی AUR دعویٰ عمل کے ذریعے پیکیج پر قبضہ کر لیا، install.sh میں npm install atomic-lockfile حکم شامل کیا، اور post_upgrade() کے ذریعے post_install() کو بلایا تاکہ اپ گریڈ کے دوران بھی یہ عمل چل جائے۔ متاثرہ صارفین عام طور پر yay -S یا paru -S کام کرتے ہیں، لیکن انہیں یہ توقع نہیں ہوتی کہ PKGBUILD اور .install اسکرپٹس تبدیل ہو چکے ہیں۔

دوہری زندگی کے دوران سلسلہ بندی اور C2 چھپانا۔ حملہ آور AUR پیکیج کے نصب/اپ گریڈ کے دوران pacman کے post_install()/post_upgrade() اسکرپٹلیٹ کو داخلہ بنا کر npm install کو ٹرگر کرتا ہے، اور phm کے preinstall لائف سائکل کا استعمال کرتے ہوئے Linux ELF لوڈ کو نفاذ کرتا ہے۔ لوڈ کا C2 پتہ repeating-XOR کوڈنگ کے ذریعے چھپایا گیا ہے، جس کی وجہ سے عام strings/grep .onion سے اسے براہ راست استخراج نہیں کیا جا سکتا۔ onion C2 کو زیادہ بہتر طور پر کام، نتائج اور حالت کے مواصلاتی چینل کے طور پر بیان کیا جا سکتا ہے؛ لوڈ کے پاس multipart اپ لوڈ درخواست بنانے کی صلاحیت بھی ہے۔ کیا یہ temp.sh سروس سے مطابقت رکھتا ہے، اور کیا اس نے مخصوص شکار ہوسٹ پر کامیابی سے اپ لوڈ کیا، اس کی تصدیق صرف ڈائنا مک یا لاگ ثبوت سے ممکن ہے۔

لوڈ کمبینیشن متعدد مراحل کے حملوں کی صلاحیت کو کور کرتا ہے۔ ELF لوڈ اسٹیٹک صلاحیتوں میں اہلیت کی جمع آوری (گٹہب/اے ایم پی/اسلاک/ڈسکورڈ/ٹیمز/ولٹ/ایس ایس ایچ/براؤزر، اور ڈوکر/پوڈمن جیسے ڈیوآپس سٹرینگ کے نشانات)، چینل کے ذریعہ مواصلات اور تعمیر کا اپ لوڈ (آنین C2 + ملٹی پارٹ اپ لوڈ ٹیمپلیٹ)، مستقل رہنے کا ٹیمپلیٹ (سسٹم ڈی ایم ایس صارف/سسٹم سروس جو WantedBy=multi-user.target اور WantedBy=default.target کے ساتھ مطابقت رکھتے ہیں)، اور شرطی دفاع سے بچنے کی صلاحیت (اجازت ملنے پر eBPF کے ذریعہ پروسیس، فائل نام اور سوکٹ/انوڈ کو چھپانے کی کوشش، bpf_send_signal(9) کے ذریعہ ptrace ڈیبگنگ کو روکنا) شامل ہیں۔ js-digest نے .mjs سفکس کو جعلی بنانے کے لیے مزید شامل کیا ہے، جس سے اضافہ کے بنیاد پر ڈیٹیکشن کی موثر صلاحیت مزید کم ہو جاتی ہے۔

سجھائش:

1. فوری طور پر نصب شدہ AUR پیکیجز میں npm install atomic-lockfile، bun install js-digest یا اس جیسے npm/Bun ڈاؤنلوڈ کمانڈس والے PKGBUILD یا .install اسکرپٹس کی تلاش کریں۔ اگر متاثرہ پیکیجز مل جائیں، تو فوری طور پر انہیں علیحدہ ماحول میں فارینسک تحقیق اور اعتماد کے اثباتات کا تبدیل کریں۔
2. ~/.config/systemd/user اور /etc/systemd/system کے تحت غیر معمولی systemd service/timer کی جانچ کریں، اور /sys/fs/bpf/ کے تحت hidden_pids، hidden_names، hidden_inodes جیسے غیر معمولی BPF maps کی جانچ کریں۔
3. متاثرہ ڈیولپر ہوسٹس کے لیے گٹہب PAT/GITHUB_TOKEN، npm ٹوکن، اسلاک/ڈسکورڈ/ٹیمز سیشن، وولٹ ٹوکن، ایس ایچ ایس پرائیوٹ کی، ڈاکر/پوڈمن کریڈنٹیلز اور .env میں محفوظ تمام کلیدیں بدل دیں۔
4. CI/CD بِلڈ ماحول کو صرف node_modules کو صاف کرنے یا ایک منفرد بری بات والے پیکج کو ہٹانے کے بجائے، قابل اعتماد بنیادی امیج سے دوبارہ تعمیر کرنے کی تجویز کی جاتی ہے۔
5. AUR صارفین کو تجویز کیا جاتا ہے کہ وہ کسی بھی حالیہ دعویٰ کیا گیا یا لمبے عرصے سے نا فعال پیکج کو انسٹال کرنے سے پہلے PKGBUILD اور .install اسکرپٹ کو لائن بہ لائن جانچیں، خاص طور پر npm install، bun install، curl، wget جیسے باہری کمانڈ کے استعمال پر توجہ دیں۔

IOC

ڈومین نیم

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid[.]onion

مالیاتی انحصار

npm:atomic-lockfile@1.4.2

npm:js-digest@4.2.2

npm:nextfile-js@1.4.2

npm:lockfile-js@1.4.2

مالیانہ فائل

فائل کا نام: src/hooks/deps SHA256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

فائل کا نام: lib/install-deps.mjs SHA256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316

فائل کا نام: atomic-lockfile-1.4.2.tar.gz SHA256: 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

فائل کا نام: js-digest-4.2.2.tar.gz SHA256: 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

فائل کا نام: ایمبدڈ eBPF آبجیکٹ SHA256: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

یہ مضمون SlowMist خطرہ اطلاعات ٹیم نے MistEye خطرہ اطلاعات سسٹم اور SlowMist Agent AI ڈرائیون اینالیسس کے ساتھ تیار کیا ہے، اگر کوئی سوال ہو تو براہ راست رابطہ کریں۔

حوالہ لنک

1.https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency