یک کیبانای باز پشتهٔ معاملاتی native.org را افشا کرد

افشای هماهنگ، با حسن نیت و بدون هیچ پاداش یا پرداختی گزارش شد. native.org مشکل را برطرف کرد و انتشار این نوشته را تأیید نمود. نشانی میزبان آسیب‌دیده افشا نمی‌شود.

خلاصه

• 207الگوی نمایه که افشا شد
• 21کلید API فعال بازیابی‌شده
• 8,700+ورودی لاگ هر 15 دقیقه

یک نمونهٔ Kibana از native.org زیرساخت معاملاتی شرکت را در محیط‌های staging و UAT، در مجموع 207 الگوی نمایه، فهرست‌گذاری می‌کرد و دروازهٔ API پشت آن کلیدهای API فعال را به‌صورت متن آشکار در لاگ ثبت می‌کرد.

‏native.org یک پلتفرم نقدینگی در حوزهٔ دیفای (DeFi) است. سامانهٔ RFQ زنجیره‌ای (on-chain) آن قیمت‌ها را از بازارسازان خصوصی می‌گیرد و آن‌ها را به معامله‌گران در زنجیره‌های مختلف عرضه می‌کند، و جریان حاصل در صرافی‌های متمرکز پوشش ریسک (hedge) می‌شود. نمونهٔ افشاشده بخشی از یک محیط UAT بود. native.org تأیید کرد که هیچ‌یک از کلیدهای نشت‌یافته در محیط تولید استفاده نشده، احراز هویت را به نمونه افزود، و کلیدها را چرخاند.

نمونه‌های Kibana افشاشده رایج‌اند. اما دو چیز در اینجا سزاوار توجه بیشترند: یک پشتهٔ مشاهده‌پذیری (observability) باز چه چیزی را لو می‌دهد، و اشتباهی که پشت نشت کلیدها بود چقدر معمولی بود.

نکات کلیدی

• نمونه هیچ احراز هویتی نمی‌خواست. رابط Kibana بارگذاری می‌شد، هر نمایه قابل پرس‌وجو بود، و اشیای ذخیره‌شده شمارش می‌شدند، همه بدون هیچ اعتبارنامه‌ای.
• ۲۰۷ نام نمایه نقشه‌ای از کل عملیات بودند: قیمت‌گذاری، پوشش ریسک، ریسک، تسویه اجباری، تسویه، پایش زنجیره‌ای، یکپارچگی با صرافی‌های متمرکز، میخکوب‌های (peg) بین‌زنجیره‌ای، و کنترل‌های توقف اضطراری. می‌شد معماری را بدون باز کردن یک سند خواند.
• دروازهٔ API کلیدهای API خام را در خروجی خود ثبت می‌کرد، که به Elasticsearch سرازیر می‌شد. ما 21 کلید را از جریان زندهٔ لاگ‌ها بازیابی کردیم. در آن زمان، یک نمایه بیش از 8,700 ورودی لاگ در هر 15 دقیقه دریافت می‌کرد، پس سامانه آشکارا فعال بود.

آنچه یک داشبورد باز لو می‌دهد

نام‌های نمایه قرار است لوله‌کشی عملیاتی باشند، نه یک سطح حمله. فهرستی کامل و نام‌دار از هر سرویس دقیقاً به مهاجم می‌گوید سامانه چگونه ساخته شده است. در مورد native.org، نام‌ها پشتهٔ معاملاتی را از ابتدا تا انتها توصیف می‌کردند: quote-order-task و order-manager برای جریان سفارش‌ها، pricer و quote-ticker برای قیمت‌گذاری، risk-manager و liquidation-price-task برای ریسک، trade-hedger-task و hedge-signer برای پوشش ریسک، cex-monitor و cex-position-monitor برای یکپارچگی با صرافی‌های متمرکز، settlement برای پایاپای، وظایف میخکوب نرم (soft-peg) در چند زنجیره، و emergency-stop-task و emergency-paused-task برای کلیدهای توقف.

هیچ‌یک از این‌ها به سند یا اعتبارنامه نیاز نداشت. فهرست نام‌های نمایه به‌تنهایی یک بازبینی طراحی است. برای هرکس که حمله‌ای را برنامه‌ریزی می‌کند، این یعنی بیشترِ کارِ مقدماتی از پیش انجام شده است.

نشت فراتر از معماری می‌رود. همان نام‌ها استراتژی را نیز هجی می‌کنند: نمایه‌هایی برای آربیتراژ، معاملهٔ جفتی، برآورد اثر بازار، و میخکوب بین‌زنجیره‌ای، که به یک رقیب می‌گویند شرکت چگونه می‌کوشد پول دربیاورد، که اغلب نیمهٔ ارزشمندترِ ماجراست. خوشه فقط دادهٔ معاملاتی هم نداشت. همچنین تله‌متری امنیتی خودِ شرکت را در خود داشت، لاگ‌های ممیزی میزبان، شبکه و نقاط پایانی، و هشدارهایی که برای گرفتن یک نفوذگر طراحی شده بودند. هرکس آن را بخواند می‌بیند مدافعان چه چیزی را می‌توانند تشخیص دهند و چه چیزی را نه.

حتی جزئیات عملیاتی کوچک‌تر هم از طریق نام‌گذاری بیرون می‌تراوند: منطقهٔ میزبانی، ارائه‌دهندهٔ ابر، مؤلفه‌هایی که در میانهٔ بازنویسی به زبانی جدیدند، و پروتکل‌های داخلی در حال استفاده. هر یک به‌تنهایی یک جزئیات بی‌اهمیت است. اما در کنار هم، شناسایی‌ای را که مهاجم وگرنه باید خودش انجام می‌داد، دو دستی تقدیمش می‌کنند.

خودِ نام‌ها اشکالی ندارند. آن‌ها از همان گونهٔ روشن و منطقی‌اند که هر تیمی به کار می‌برد. آنچه اشتباه پیش رفت این بود که داشبوردی که در آن زندگی می‌کنند برای همه باز بود.

کلیدها در لاگ‌ها

مشکل مستقیم‌تر در لاگ‌های دروازهٔ API بود. تابع جست‌وجوی کلیدِ دروازه در هر جست‌وجوی موفق کل شیء کلید را در لاگ ثبت می‌کرد، و آن خطوط لاگ مانند هر چیز دیگری در Elasticsearch فرود می‌آمدند. باز کردن نمایهٔ دروازه و فیلتر بر اساس آن تابع جریانی از ورودی‌ها مانند این را برمی‌گرداند:

[refreshApiKey] auth.GetByApiKey success, apiKey:
{"id": 9, "api_key": "faa79a…362f1f", "name": "[redacted]", "rate_limit": 20}

به این شیوه 21 کلید مجزا بازیابی کردیم. این یکی از رایج‌ترین اشتباهات لاگ‌گیری موجود است: ثبت کل درخواست یا شیء احراز هویت هنگام اشکال‌زدایی، و سپس فراموش کردن اینکه به مخزنی می‌رود که کسِ دیگری می‌تواند بخواند. اعتبارنامه و جایی که لاگ‌هایتان را نگه می‌دارید به یک چیز بدل می‌شوند.

پیامد، به‌اندازه

این یک محیط UAT بود، و native.org تأیید کرد که کلیدها در محیط تولید استفاده نشدند. این مهم است، و ما آن را همچون یک فاجعهٔ نزدیک‌ازدست‌رفته روی یک میز معاملاتی زنده نخواهیم آراست. چنین نبود.

با این حال جدی بود. یک نمونهٔ زنده، رو به اینترنت و بدون احراز هویت، اعتبارنامه‌های واقعی را به‌صورت متن آشکار در لاگ ثبت می‌کرد و کل طراحی یک پلتفرم پول‌گردان را افشا می‌نمود. کلیدها کلیدهای UAT بودند، اما نمایه هر چند دقیقه هزاران خط لاگ دریافت می‌کرد، پس ترافیک واقعی بود، و معماری‌ای که افشا کرد همان معماری‌ای است که سامانهٔ تولید اجرا می‌کند. شکاف میان «فقط UAT است» و «روی اینترنت عمومی است و کلیدهای زنده را در لاگ ثبت می‌کند» همهٔ ماجراست.

اثبات مفهوم (PoC)

نمونه به درخواست‌های بدون احراز هویت روی پورت HTTP خود پاسخ می‌داد. تأیید آن سه گام برد، که هیچ‌کدام ابزاری عجیب‌تر از curl یا یک مرورگر نخواست:

• GET /api/status نسخهٔ Kibana و نام گره را بدون اعتبارنامه برگرداند.
• GET /api/saved_objects/_find?type=index-pattern&per_page=500 تمام 207 الگوی نمایه را برگرداند.
• باز کردن نمایهٔ دروازه در Discover و فیلتر بر اساس تابع جست‌وجوی کلید، کلیدهای ثبت‌شده در لاگ را نشان داد.

یک گواهی TLS روی پورت 443 میزبان (CN=*.native.org، صادرشده توسط Cloudflare Origin CA) تأیید کرد که نمونه به native.org تعلق دارد.

گاه‌شمار افشا

• 2 ژوئن 2026نمونهٔ افشاشده را در جریان پژوهش هوش تهدید یافتیم و آن را به native.org گزارش کردیم، همراه با نقطهٔ پایانی آسیب‌دیده، فهرست نمایه‌ها، نمونه‌ای ویرایش‌شده از کلیدهای ثبت‌شده، و گام‌های ترمیم.
• 18 ژوئن 2026‏native.org افشا را تأیید کرد. آن‌ها احراز هویت را به نمونه افزودند، کلیدهای آسیب‌دیده را چرخاندند، تأیید کردند که نمونه و کلیدها به یک محیط UAT بدون دخالت کلیدهای تولید تعلق دارند، و ویرایش‌هایی را که برای انتشار می‌خواستند مشخص کردند.
• 19 ژوئن 2026با مشارکت native.org و با اعمال ویرایش‌هایی که خواستند منتشر شد.

‏native.org سریع پاسخ داد، مشکل را برطرف کرد، و روی نوشته با ما کار کرد. ما این را علامت زدیم چون افشا جدی بود و آن‌ها باید می‌دانستند، نه در ازای چیزی. افشای هماهنگ باید دقیقاً همین‌گونه کار کند.

برای تیم‌هایی که همین پشته را اجرا می‌کنند

• ‏Kibana و Elasticsearch را پشت احراز هویت قرار دهید. xpack.security.enabled را فعال کنید و پورت HTTP را بیرون از اینترنت عمومی نگه دارید. یک پشتهٔ ELK بدون احراز هویت یک پایگاه داده با رابط وب باز به روی جهان است.
• مخزن لاگ خود را خواندنی برای هرکس که می‌تواند به آن برسد در نظر بگیرید. اگر اعتبارنامه‌ای بتواند در یک خط لاگ فرود آید، فرض کنید خوانده خواهد شد.
• اشیای کامل احراز هویت یا درخواست را در لاگ ثبت نکنید. یک شناسه را ثبت کنید، هرگز خودِ راز را. مسیر جست‌وجوی کلید دقیقاً جایی است که این اشتباه پیش می‌رود.
• به یاد داشته باشید که نام‌های نمایه و سرویس شما سامانه‌تان را توصیف می‌کنند. جایی را که در آن زندگی می‌کنند خصوصی نگه دارید.
• از محیط‌های قدیمی‌تان فهرست‌برداری کنید. نام‌ها در اینجا برچسب‌هایی مانند uat-v1، uat-v2، staging و shadow داشتند، لایه‌هایی از برپایی‌های آزمایشی که با گذر زمان انباشته شده‌اند. آن فراموش‌شده معمولاً همان است که در نهایت افشا می‌شود.

سپاسگزاری

سپاس از تیم native.org برای پاسخی سریع و حرفه‌ای، و برای کار با ما روی آنچه می‌توانست و آنچه نمی‌توانست وارد این گزارش شود.