ProFTPD भेद्यता POCs

CVE-2026-42167 के लिए प्रूफ-ऑफ-कॉन्सेप्ट प्रदर्शन, ProFTPD के mod_sql लॉगिंग पाइपलाइन में एक SQL इंजेक्शन भेद्यता जो एक अप्रमाणित हमलावर को मनमाना SQL निष्पादित करने — और FTP प्रमाणीकरण डेटाबेस में बैकडोर उपयोगकर्ताओं को इंजेक्ट करने या डेटाबेस होस्ट पर रिमोट कोड निष्पादन प्राप्त करने — की अनुमति देती है।

सभी POCs PostgreSQL-विशिष्ट हैं, लेकिन बैकडोर उपयोगकर्ता वाले MySQL और sqlite बैकएंड के साथ इंजेक्ट किए गए क्वेरी में कुछ संशोधनों के साथ काम करते हैं (जिसे हम पाठक के लिए एक अभ्यास के रूप में छोड़ रहे हैं)।

• यह भेद्यता ZeroPath Research द्वारा खोजी गई थी। हमारे तकनीकी ब्लॉग में अधिक विवरण हैं।

भेद्यता

mod_sql SQLLog में is_escaped_text() बायपास (CVE-2026-42167, CWE-89)

ProFTPD का mod_sql हर FTP कमांड को SQLLog / SQLNamedQuery तंत्र के माध्यम से लॉग करता है। %U (मूल उपयोगकर्ता नाम) या %{basename} (फ़ाइलनाम घटक) जैसे फॉर्मेट वेरिएबल्स को हल करते समय, फ्रेमवर्क यह तय करने के लिए is_escaped_text() को कॉल करता है कि एस्केपिंग आवश्यक है या नहीं — और किसी भी ऐसे मान के लिए एस्केपिंग को पूरी तरह से छोड़ देता है जो सिंगल कोट से शुरू और समाप्त होता है और जिसमें कोई आंतरिक सिंगल कोट नहीं होता (जैसे '|| (SELECT 1) ||')। यह जाँच पूरी तरह से वाक्यात्मक है और FTP सत्र से कच्चे, हमलावर-नियंत्रित इनपुट पर चलती है, इसलिए यह "विश्वसनीय कोड द्वारा पूर्व-एस्केप किया गया" और "हमलावर द्वारा पूर्व-एस्केप दिखने के लिए तैयार किया गया" के बीच अंतर नहीं कर सकता।

मानक प्रलेखित पैटर्न SQL सुरक्षा के लिए फॉर्मेट वेरिएबल्स को सिंगल कोट्स में लपेटता है:

SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log
SQLLog        *           log_activity
SQLLog        ERR_*       log_activity

जब कोई हमलावर '<payload>' रूप का मान प्रदान करता है, तो प्रतिस्थापन अंतिम SQL में ''<payload>'' उत्पन्न करता है — खाली स्ट्रिंग लिटरल आसपास के कोट्स को बंद कर देते हैं और पेलोड कच्चे SQL के रूप में चलता है। PostgreSQL (PQexec) या SQLite (sqlite3_exec) के साथ स्टैक्ड-क्वेरी समर्थन का अर्थ है कि पेलोड पूर्ण INSERT, UPDATE, CREATE TABLE, या COPY TO PROGRAM स्टेटमेंट हो सकता है।

सर्वर कब शोषणीय होता है?

कमजोर कोड contrib/mod_sql.c (साझा SQL फ्रेमवर्क) में है, किसी विशेष बैकएंड में नहीं, इसलिए सभी SQL बैकएंड प्रभावित हैं — लेकिन हमले की सतह इस बात पर निर्भर करती है कि एडमिन ने लॉगिंग को कैसे कॉन्फ़िगर किया है। एक सर्वर शोषणीय होता है जब निम्नलिखित दोनों सत्य हों:

1. एडमिन ने एक SQLNamedQuery INSERT (या UPDATE) परिभाषित किया है जिसकी फॉर्मेट स्ट्रिंग इन हमलावर-नियंत्रणीय वेरिएबल्स में से एक को सिंगल कोट्स में लपेटकर इंटरपोलेट करती है — जैसे "'%U', '%m'"। हमलावर इनपुट से आने वाले वेरिएबल्स हैं:

%f, %F, और %D हमलावर-नियंत्रित लगते हैं लेकिन हमेशा / से शुरू होने वाले निरपेक्ष पथों में हल होते हैं, इसलिए वे is_escaped_text() की '-से-शुरू आवश्यकता को पूरा नहीं कर सकते।

2. एडमिन ने उस SQLNamedQuery को एक SQLLog निर्देश से बाँधा है जो किसी FTP कमांड (या कमांड क्लास) के लिए है जिस तक हमलावर पहुँच सकता है। व्यापक रूप से प्रलेखित SQLLog * और SQLLog ERR_* वाइल्डकार्ड सबसे व्यापक मामला हैं और जो %U पथ को प्री-ऑथ बनाते हैं: ERR_* एक असफल USER पर सक्रिय होता है, इसलिए कोई क्रेडेंशियल आवश्यक नहीं होते। SQLLog STOR जैसे प्रति-कमांड निर्देश किसी भी प्रमाणित उपयोगकर्ता को कवर करते हैं।

एक हमलावर क्या कर सकता है?

बायपास लॉगिंग पथ को बैकएंड पर एक मनमाना-SQL प्रिमिटिव में बदल देता है। दो सबसे अधिक प्रभाव वाले परिदृश्य:

• किसी भी विशेषाधिकार के साथ बैकडोर उपयोगकर्ता इंजेक्ट करें (ऑथ बायपास)। ProFTPD का SQL ऑथ बैकएंड उपयोगकर्ता नाम, पासवर्ड हैश, uid, gid, homedir, और shell उसी users तालिका से पढ़ता है जिसमें लॉगिंग INSERT अब लिख सकता है। एक स्टैक्ड INSERT INTO users हमलावर द्वारा चुना गया खाता स्थापित करता है — uid=0, homedir=/, सादा-पाठ पासवर्ड — और फिर हमलावर FTP डेमन के माध्यम से पूर्ण फ़ाइलसिस्टम पहुँच के साथ सामान्य रूप से लॉग इन करता है। %U + SQLLog ERR_* पथ के माध्यम से प्री-ऑथ, या किसी भी हमलावर-नियंत्रित वेरिएबल के माध्यम से पोस्ट-ऑथ जो किसी ऐसी कमांड से बंधा है जिसे हमलावर जारी कर सकता है (जैसे %{basename} + SQLLog STOR)। PostgreSQL और SQLite पर काम करता है (दोनों स्टैक्ड क्वेरी का समर्थन करते हैं)।

• COPY TO PROGRAM के माध्यम से डेटाबेस होस्ट पर रिमोट कोड निष्पादन। PostgreSQL का COPY (SELECT …) TO PROGRAM '<cmd>' <cmd> को डेटाबेस सर्वर पर एक शेल के माध्यम से चलाता है। एक स्टैक्ड-क्वेरी इंजेक्शन जो जारी करता है, postgres OS उपयोगकर्ता के रूप में मनमाना OS कमांड निष्पादन देता है, जो क्रेडेंशियल एक्सफिलट्रेशन, पार्श्व गति और स्थायी पहुँच के लिए पर्याप्त है। बैकडोर मामले के समान ट्रिगर पथों के माध्यम से पहुँचा जा सकता है (प्री-ऑथ के माध्यम से या पोस्ट-ऑथ आदि के माध्यम से)। PostgreSQL-विशिष्ट, और आवश्यक है कि ProFTPD DB भूमिका के पास सुपरयूज़र विशेषाधिकार हों ( के लिए पूर्वापेक्षा) — सिंगल-टेनेंट परिनियोजनों में सामान्य जहाँ भूमिका DB स्वामी होती है।

POC विकल्प

इस रिपॉजिटरी के POCs विशेष रूप से PostgreSQL को लक्षित करते हैं — सबसे मजबूत मामला, क्योंकि PQexec() स्टैक्ड क्वेरी का समर्थन करता है और COPY TO PROGRAM सीधा OS कमांड निष्पादन प्रदान करता है। बायपास स्वयं साझा SQL फ्रेमवर्क में है और सभी बैकएंड को प्रभावित करता है:

• PostgreSQL (यहाँ कवर किया गया): PQexec के माध्यम से स्टैक्ड क्वेरी, COPY TO PROGRAM के माध्यम से RCE।
• SQLite: sqlite3_exec के माध्यम से स्टैक्ड क्वेरी, proftpd वर्कर में PRIVS_ROOT के अंतर्गत चलता है — बैकडोर इंजेक्शन उसी तरह काम करता है; RCE प्रिमिटिव भिन्न है (COPY TO PROGRAM के समकक्ष नहीं, लेकिन रूट-प्रोसेस SQL बैकएंड पर लिखने योग्य users तालिका पर्याप्त है)।
• MySQL: बायपास उसी तरह सक्रिय होता है, लेकिन एकल लॉगिंग INSERT के अंदर से users तालिका या OS निष्पादन तक पहुँचना कठिन है। एकल-स्टेटमेंट हेरफेर (VALUES स्लॉट में सबक्वेरी एक्सफिल, समय-आधारित ब्लाइंड, त्रुटि-आधारित ब्लाइंड) सीधा है; उसे अलग तालिका में लिखने में बदलने के लिए कई बाधाओं से पार पाना आवश्यक है:
  • mod_sql_mysql CLIENT_MULTI_STATEMENTS के बिना mysql_real_query() को कॉल करता है, इसलिए एक अनुगामी ; INSERT INTO users … कनेक्शन द्वारा अस्वीकार कर दिया जाता है।

PostgreSQL सेटअप के भीतर, POCs दो प्रतिनिधि ट्रिगर पथ प्रदर्शित करते हैं। उपरोक्त तालिका के अन्य संयोजन सिद्धांत रूप में समतुल्य हैं:

• %U + USER के माध्यम से प्री-ऑथ। SQLLog ERR_* इसे पूर्ण रूप से अप्रमाणित बनाता है।
• %{basename} + STOR के माध्यम से पोस्ट-ऑथ। किसी भी FTP क्रेडेंशियल की आवश्यकता होती है लेकिन फ़ाइल अपलोड करने की क्षमता से परे कोई विशेषाधिकार नहीं।

रिपॉजिटरी सामग्री

• setup/ — स्वचालित वातावरण सेटअप। ProFTPD सोर्स ट्री को क्लोन करता है जो उस कमिट पर पिन किया गया है जिसके विरुद्ध ये निष्कर्ष रिपोर्ट किए गए थे, mod_sql + mod_sql_postgres के साथ डेमन को बिल्ड करता है, और सीड डेटा और कमजोर SQLLog कॉन्फ़िगरेशन के साथ एक Docker Compose क्लस्टर (ProFTPD + PostgreSQL) खड़ा करता है।

• pocs/ — पाँच एक्सप्लॉइट स्क्रिप्ट। सभी स्व-निहित Python स्क्रिप्ट हैं जिन्हें केवल मानक पुस्तकालय की आवश्यकता होती है।

  • preauth_user_backdoor.py — प्री-ऑथ %U ट्रिगर → ऑथ DB में इंजेक्ट किया गया बैकडोर उपयोगकर्ता (uid=0, homedir=/). कोई क्रेडेंशियल नहीं, कोई DB सुपरयूज़र आवश्यक नहीं। यह POC PostgreSQL-विशिष्ट है, लेकिन इस समस्या का शोषण mysql या sqlite बैकएंड के साथ भी किया जा सकता है।
  • preauth_user_rce.py — प्री-ऑथ %U ट्रिगर → COPY TO PROGRAM के माध्यम से PostgreSQL होस्ट पर RCE। कोई क्रेडेंशियल नहीं। आवश्यक है कि ProFTPD DB भूमिका PostgreSQL सुपरयूज़र हो।
  • postauth_stor_backdoor.py — पोस्ट-ऑथ ट्रिगर → बैकडोर उपयोगकर्ता इंजेक्ट किया गया। किसी भी प्रमाणित FTP उपयोगकर्ता की आवश्यकता है। यह POC PostgreSQL-विशिष्ट है, लेकिन इस समस्या का शोषण mysql या sqlite बैकएंड के साथ भी किया जा सकता है।

निर्देश

पूर्वापेक्षाएँ: Docker, Git, Python 3.10+, और uv।

cd setup
./setup.sh

पहला रन ProFTPD स्रोत को क्लोन करता है और सर्वर को बिल्ड करता है (~2-3 मिनट)। बाद के रन बिल्ड कैश का पुन: उपयोग करते हैं और सेकंडों में शुरू होते हैं।

जब सेटअप पूरा हो जाता है, यह पूर्ण वातावरण विवरण (FTP और DB एंडपॉइंट, परीक्षण क्रेडेंशियल, और पेस्ट-करने-के-लिए-तैयार POC कमांड) प्रिंट करता है। POCs चलाने के लिए उन निर्देशों का पालन करें।

टियर डाउन करने के लिए:

cd setup
./teardown.sh