नया HTTP/2 'Rapid Reset' DDoS अटैक

 (cloud.google.com)
1 पॉइंट द्वारा GN⁺ 2023-10-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google सेवाओं और Google Cloud ग्राहकों को निशाना बनाने वाला HTTP/2-आधारित Layer 7 DDoS अगस्त 2023 में अपने चरम पर पहुँचा, जिसमें अधिकतम 39.8 करोड़ requests प्रति सेकंड से ज्यादा दर्ज हुए
  • यह अटैक Google के global load balancing infrastructure पर अधिकतर रोक दिया गया, इसलिए outage नहीं हुआ, और बाद में मिलते-जुलते attacks को कम करने के लिए अतिरिक्त सुरक्षा उपाय जोड़े गए
  • Rapid Reset request के तुरंत बाद RST_STREAM frame से केवल stream को cancel करता है और connection को बनाए रखता है, जिससे concurrent stream limit से बचते हुए request generation दोहराया जाता है
  • Server, cancel की गई requests पर भी header decompression, URL mapping, backend proxying जैसे काम कर सकता है, जिससे cost asymmetry बढ़ती है
  • HTTP/2 operators को exposure की जाँच कर patches लागू करने चाहिए, और abuse detect होने पर individual requests के बजाय TCP connection को ही terminate करना मुख्य mitigation बनता है

अटैक का पैमाना और Google की प्रतिक्रिया

  • Google सेवाएँ और Cloud ग्राहक अगस्त 2023 में चरम पर पहुँचे HTTP/2-आधारित Layer 7 DDoS attack के target बने
  • सबसे बड़े attack में 39.8 करोड़ requests प्रति सेकंड से ज्यादा दर्ज हुए, जो पहले report किए गए Layer 7 attacks से कहीं बड़े पैमाने का था
  • Google के global load balancing infrastructure ने network edge पर attack का अधिकांश हिस्सा रोक दिया
    • कोई outage नहीं हुआ
    • impact सीमित स्तर पर रहा
  • Google DDoS Response Team ने attack की समीक्षा के बाद समान attacks को घटाने के लिए अतिरिक्त protection measures लागू किए
  • Google ने industry partners के साथ मिलकर नए HTTP/2 attack vector से निपटने के लिए coordinated disclosure process का नेतृत्व किया

HTTP/2 कहाँ DDoS के लिए फायदेमंद बनता है

  • 2021 के अंत के बाद से Google 1st-party सेवाओं और Cloud Armor से protected Google Cloud projects में देखे गए कई Layer 7 DDoS attacks HTTP/2-आधारित थे
    • attack count के लिहाज से भी अधिक थे
    • peak request rate के लिहाज से भी ऊँचे थे
  • HTTP/2 की efficiency legitimate clients के साथ-साथ DDoS attacks की efficiency भी बढ़ा सकती है

  • Stream multiplexing

    • HTTP/2 endpoints के बीच frames भेजने के लिए stream नाम की bidirectional abstraction का उपयोग करता है
    • stream multiplexing की वजह से एक TCP connection पर कई requests को साथ-साथ process किया जा सकता है
    • Layer 7 DoS attack की मुख्य constraint concurrent transmission connections की संख्या होती है
      • हर connection socket records और buffers के लिए operating system memory इस्तेमाल करता है
      • TLS handshake में CPU time लगता है
      • दोनों तरफ के IP addresses और port pairs से बना unique 4-tuple चाहिए होता है
    • HTTP/1.1 आम तौर पर requests को serially process करता है, जिससे single connection की request rate लगभग round-trip time पर 1 request के करीब होती है
    • HTTP/2 में एक TCP connection पर कई concurrent streams खोले जा सकते हैं, और हर stream एक HTTP request के बराबर होती है
    • real-world environment में client प्रति request 100 streams खोल सकता है और server parallel processing कर सकता है, जिससे single connection का effective throughput प्रति round-trip लगभग 100 requests तक जा सकता है
    • नतीजतन connection utilization HTTP/1.1 की तुलना में लगभग 100 गुना अधिक हो सकता है

Rapid Reset कैसे काम करता है

  • HTTP/2 client को RST_STREAM frame भेजकर server को पिछली stream cancel करने की सूचना देने देता है
  • cancellation के लिए client और server के बीच अलग coordination की जरूरत नहीं होती
    • client unilateral तरीके से cancel कर सकता है
    • यह माना जा सकता है कि RST_STREAM frame पाने वाला server उसी TCP connection के दूसरे data से पहले cancellation लागू करेगा
  • Rapid Reset request frame भेजने के तुरंत बाद RST_STREAM frame भेजने के तरीके पर निर्भर करता है
    • दूसरे endpoint से काम शुरू करवाने के बाद request को जल्दी reset करता है
    • request cancel हो जाती है, लेकिन HTTP/2 connection खुला रहता है
  • attack process सरल है
    • standard HTTP/2 attack की तरह एक बार में बहुत सारी streams खोलता है
    • server या proxy response का इंतजार नहीं करता
    • हर request को तुरंत cancel करता है
  • अगर तुरंत reset संभव हो, तो हर connection वास्तव में अनिश्चित समय तक बड़ी संख्या में requests को in-progress state में बना सकता है
    • attacker concurrent open stream limit को स्पष्ट रूप से पार नहीं करता
    • in-progress requests की संख्या round-trip time (RTT) के बजाय उपलब्ध network bandwidth पर निर्भर करती है
  • आम HTTP/2 server implementations को cancel की गई requests पर भी काम करना पड़ सकता है
    • नई stream data structure allocate करना
    • query parsing
    • header decompression
    • URL को resource से map करना
  • reverse proxy implementations में RST_STREAM frame process होने से पहले request backend server तक proxy हो सकती है
  • client request भेजने की cost लगभग नहीं चुकाता, इसलिए server और client के बीच exploitable cost asymmetry बन जाती है
  • अगर response लिखे जाने से पहले request cancel हो जाए, तो reverse proxy server response नहीं भेजता, जिससे server या proxy से attacker की ओर जाने वाली downlink bandwidth भी घटती है

देखे गए variant attacks

  • शुरुआती DDoS के बाद कुछ हफ्तों तक Rapid Reset variants देखे गए
  • ये variants शुरुआती तरीके जितने efficient नहीं हैं, लेकिन standard HTTP/2 DDoS attacks से फिर भी अधिक efficient हो सकते हैं

  • Batch cancellation variant

    • पहला variant streams को तुरंत cancel नहीं करता; streams का batch खोलकर थोड़ी देर इंतजार करता है और फिर एक साथ cancel करता है
    • cancellation के तुरंत बाद streams का नया बड़ा batch फिर खोलकर attack जारी रखता है
    • यह तरीका केवल inbound RST_STREAM frame ratio पर आधारित mitigation को bypass कर सकता है
      • उदाहरण: प्रति connection प्रति सेकंड अधिकतम 100 RST_STREAM ही allow करने और exceed होने पर close करने की policy
    • connection utilization maximize नहीं हो पाता, इसलिए cancellation attack का मुख्य फायदा कम हो जाता है
    • फिर भी implementation के स्तर पर यह standard HTTP/2 DDoS attack से अधिक efficient हो सकता है, इसलिए केवल stream cancellation ratio limit से काम चलाने के लिए काफी strict limits चाहिए

  • Non-cancelling variant

    • दूसरा variant streams को बिल्कुल cancel नहीं करता
    • इसके बजाय server द्वारा advertise की गई concurrent stream count से ज्यादा streams optimistic तरीके से खोलने की कोशिश करता है
    • request pipeline को लगातार भरा रख सकता है, जिससे client-proxy RTT bottleneck घट सकता है
    • अगर target HTTP/2 server ऐसे resource का हो जो तुरंत response देता है, तो proxy-server RTT bottleneck भी हट सकता है
    • मौजूदा HTTP/2 RFC, RFC 9113, बहुत अधिक streams खोलने की कोशिशों पर पूरे connection के बजाय केवल limit से अधिक streams को invalidate करने का सुझाव देता है
    • अधिकांश HTTP/2 servers की ऐसी architecture में जहाँ excess streams process नहीं होतीं, पिछली stream response के तुरंत बाद नई stream लगभग तुरंत accept और process की जा सकती है, जिससे non-cancelling variant संभव हो जाता है

Mitigation strategy

  • इस attack family में केवल individual requests block करना व्यावहारिक mitigation बनना मुश्किल है
  • abuse detect होने पर पूरे TCP connection को close करना चाहिए
  • HTTP/2 GOAWAY frame type के जरिए connection termination support करता है
  • RFC एक gradual shutdown process define करता है: पहले informational GOAWAY भेजना, जो new stream opening limit set नहीं करता, और एक round-trip बाद ऐसा GOAWAY भेजना जो additional stream opening को रोकता है
  • लेकिन यह gradual GOAWAY process अक्सर malicious clients के लिए पर्याप्त robust नहीं होता
    • connection Rapid Reset attack के लिए बहुत देर तक exposed रहता है
    • inbound requests को रोक नहीं पाता
  • mitigation के उद्देश्य से GOAWAY को stream creation तुरंत limit करने के लिए configure किया जाना चाहिए

  • abusive connection की पहचान

    • client द्वारा request cancel करना अपने आप में हमेशा abuse नहीं है
    • HTTP/2 की cancellation capability request processing को बेहतर manage करने के लिए है
      • जब user page छोड़ देता है और browser को अब requested resources की जरूरत नहीं रहती
      • client-side timeout वाली long polling approach इस्तेमाल करने वाली applications
    • mitigation का focus connection statistics track करने और कई signals व business logic से हर connection की usefulness का आकलन करने पर होता है
    • उदाहरण के लिए, अगर किसी connection में 100 से ज्यादा requests हैं और उनमें से 50% से अधिक cancel हो चुकी हैं, तो वह mitigation candidate हो सकता है
    • response का आकार और प्रकार platform-specific risk पर निर्भर करता है
      • forced GOAWAY frame
      • TCP connection का तुरंत termination
    • non-cancelling variant को mitigate करने के लिए HTTP/2 server को concurrent stream limit से अधिक जाने वाले connections close करने की सलाह दी जाती है
      • तुरंत close किया जा सकता है
      • या थोड़े repeated violations के बाद close किया जा सकता है

HTTP/3 पर लागू होने की संभावना

  • Google protocol differences की वजह से नहीं मानता कि यह attack method सीधे HTTP/3 (QUIC) पर लागू होता है
  • फिलहाल Google को HTTP/3 के बड़े पैमाने के DDoS attack vector के रूप में इस्तेमाल होने की स्थिति नहीं दिख रही
  • फिर भी HTTP/3 server implementations को proactive तरीके से ऐसे mechanisms implement करने की सलाह दी जाती है जो एक single transport connection द्वारा किए जाने वाले work की मात्रा limit करें
    • दिशा ऊपर discuss किए गए HTTP/2 mitigations जैसी ही है

Industry coordination और CVE

  • Google DDoS Response Team की investigation की शुरुआत से ही साफ हो गया कि यह attack type HTTP/2 serve करने वाली सभी services पर व्यापक impact डाल सकता है
  • Google ने मौजूदा coordinated vulnerability disclosure groups का उपयोग करते हुए coordinated vulnerability disclosure process का नेतृत्व किया
  • disclosure process का focus बड़े HTTP/2 implementers को inform करने पर था
    • infrastructure companies
    • server software providers
  • advance notice का लक्ष्य mitigations develop करना और coordinated disclosure timeline के हिसाब से तैयार रहना था
  • पहले भी ऐसे approach से service providers द्वारा broad protection rollout या कई packages और solutions में software updates उपलब्ध कराए गए हैं
  • coordinated disclosure process के दौरान कई HTTP/2 implementations में fixes track करने के लिए CVE-2023-44487 reserve किया गया

HTTP/2 service operators को क्या करना चाहिए

  • यह attack किसी भी scale की service पर significant impact डाल सकता है
  • HTTP/2 services देने वाले सभी providers को इस issue के प्रति अपने exposure का assessment करना चाहिए
  • common web servers और programming languages के लिए software patches और updates अभी या निकट भविष्य में उपलब्ध हो सकते हैं
  • उपलब्ध fixes को जितनी जल्दी संभव हो apply करने की सलाह दी जाती है
  • Google Cloud ग्राहकों को software patches के साथ Application Load Balancer, Google Cloud Armor इस्तेमाल करने की सलाह दी जाती है
    • Google Cloud Armor ने Google और मौजूदा Google Cloud Application Load Balancing users की सुरक्षा की है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-11
Hacker News की राय

  • संबंधित चल रहे थ्रेड:
    अब तक का सबसे बड़ा DDoS हमला, जो प्रति सेकंड 398 मिलियन से ज़्यादा requests तक पहुंचा - https://news.ycombinator.com/item?id=37831062
    HTTP/2 zero-day vulnerability से रिकॉर्ड DDoS हमला हुआ - https://news.ycombinator.com/item?id=37830998

  • HAProxy टीम ने शायद HTTP/2 में इस तरह की समस्या को 2018 में ही पहचानकर mitigate कर दिया था, यह देखकर अच्छा लगा: https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...

    • बढ़िया। मैं HAProxy के बारे में ऐसी जानकारी ढूंढ रहा था, और इससे नए QUIC फीचर पर मेरा भरोसा काफी बढ़ गया
    • अगर कोई जानना चाहता हो, तो Nginx इस समस्या के प्रति vulnerable है
      https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...

  • सामान्य HTTP/2 server implementation में canceled requests के लिए भी काफी काम करना पड़ता है, जैसे नया stream data structure allocate करना, query parse करना, headers decompress करना, और URL को resource से map करना
    reverse proxy implementation में, RST_STREAM frame process होने से पहले request backend server तक proxy हो सकती है। दूसरी ओर client को request भेजने में लगभग कोई लागत नहीं लगती, इसलिए server और client के बीच exploit की जा सकने वाली cost asymmetry बन जाती है
    हैरानी की बात है कि HTTP/2 design करते समय इसका अनुमान नहीं लगाया गया। दूसरे protocols में amplification attacks पहले से ही अच्छी तरह जाने जाते थे। यह भी उतना ही हैरान करने वाला है कि यह attack इतना देर से सामने आया, हालांकि शायद हाल तक HTTP/2 इतना व्यापक रूप से deployed नहीं था कि वह एक मूल्यवान target बनता

    • सख्ती से कहें तो यह amplification attack नहीं है। यह बस TCP connection को कहीं ज़्यादा efficiently इस्तेमाल करने के तरीके जैसा है
    • मैं भी हैरान था, लेकिन timeline देखें तो RST_STREAM SPDY के शुरुआती versions में पहले से था, और SPDY लगता है कि मोटे तौर पर 2009 के आसपास design हुआ था
      Slowloris जैसे हमले भी लगभग उसी समय आए थे, लेकिन तब वे व्यापक रूप से जाने-पहचाने नहीं थे। दूसरी ओर SYN cookies 1996 में आई थीं, इसलिए ऐसे attacks का ऐतिहासिक उदाहरण साफ मौजूद है जिनमें victim Y cost चुकाता है और attacker X
    • ऐसी चीज़ों में आम तौर पर होता यही है कि बहुत से महत्वहीन लोगों ने इसे पहले ही report और test कर लिया होगा
      खास बात यह है कि इसे Google के खिलाफ गंभीरता से आज़माया गया

  • लगता है HTTP/2 की ज़रूरत ads, trackers और भारी-भरकम frontend frameworks को तेज़ी से deliver करने के लिए थी। अब यह attacks भी तेज़ी से deliver करता है

    • HTTP/2 high-latency connections पर browsing experience को कहीं ज़्यादा सहनीय बनाता है। आम तौर पर web pages loading को भी तेज़ करता है
      अच्छी बात है कि HTTP/1.1 अब भी काम करता है। अगर वह protocol आपको पसंद नहीं है, तो browser settings और web server में कभी भी HTTP/1.1 enable कर सकते हैं
    • मतलब HTTP/2 की ज़रूरत नहीं थी? अगर ऐसा है, तो realistic alternative क्या है?

  • base protocol को छोटा रखने की यह एक और वजह है। HTTP/2, SPDY को मिलाकर, 10 साल से ज़्यादा समय से मौजूद है, और यह attack type पहली बार सामने आया है
    HTTP/3 और QUIC में कौन-से surprises छिपे होंगे, यह जानने की उत्सुकता है

    • DNS एक छोटा protocol है, फिर भी दुनिया भर के DDoS attackers इसे relay attacks में abuse करते हैं
    • QUIC के design में amplification attacks को ठीक से ध्यान में नहीं रखा गया, और शुरुआत में इसे मुद्दा उठाने वाले लोगों को ignore किया गया
    • HTTP/2 काफी छोटा ही है

  • “cancellation” को भी “कठिन computer science problems” की सूची में डालना चाहिए
    उस सूची की दूसरी चीज़ों, जैसे off-by-one errors या cache invalidation की तरह यह वास्तव में बेहद कठिन नहीं है, लेकिन इसे कम आंका और नज़रअंदाज़ किया जाना आसान है। अगर creation, constructors और initialization पर लगाए समय का आधा भी destruction, cleanup, teardown और cancellation design पर लगाया गया होता, तो खासकर resource exhaustion bugs काफी कम होते

    • Rust का async सच में अच्छा है, क्योंकि वह individual calls के cooperation के बिना भी किसी भी await point पर Future को तुरंत cancel कर सकता है और पूरी call stack को साथ में cancel कर सकता है
    • C libraries में यह बात बिल्कुल सही है। POSIX thread cancellation ऐसी feature है जिसका सिर्फ मौजूद होना ही उसके implications को हर जगह फैला देता है

  • मैं सभी को याद दिलाना चाहता हूं कि Google ही HTTP/2 बनाने वाली company है
    अब वे ऐसे बात करते हैं जैसे वे अपनी ही बनाई समस्या से हमें heroically बचा रहे हों, लेकिन यह हिस्सा नहीं बताते कि इसे बनाया भी उन्होंने ही था। इन tech companies की बेशर्मी देखिए। Microsoft भी दशकों से ऐसा ही करता आया है

    • वे ऐसी समस्या हल करने की कोशिश कर रहे थे जो थी ही नहीं

  • क्या कोई समझा सकता है कि इस attack में साधारण request flood से अलग नया क्या है?

    • यह इस पर निर्भर करता है कि आप “request flood” attack किसे मानते हैं
      HTTP/1.1 में round trip time प्रति एक request भेजी जा सकती थी[0]। HTTP/2 multiplexing में round trip time प्रति 100 भेजी जा सकती हैं। इस attack में round trip time प्रति वस्तुतः अनंत requests भेजी जा सकती हैं। उम्मीद है इस article के diagrams अंतर दिखाते हैं, लेकिन हो सकता है आप ऊपर से अलग किसी प्रकार के attack की बात कर रहे हों
      [0] HTTP/1.1 pipelining को ध्यान में रखें तो एक round trip time factor कम किया जा सकता है, लेकिन असली clients लगभग कभी HTTP/1.1 pipelining का इस्तेमाल नहीं करते, इसलिए उसका इस्तेमाल अपने-आप malicious traffic का बहुत साफ संकेत बन जाता है
    • बताई गई नई technique उस maximum limit से बच निकलती है जितनी requests प्रति सेकंड प्रति client attacker server से process करा सकता है
      एक ही connection के अंदर request और stream reset साथ भेजने से पहले की तुलना में प्रति connection/client ज़्यादा requests भेजी जा सकती हैं, जिससे attack cost कम हो सकती है या blocking कठिन हो सकती है

  • blog header बार-बार उछलकर सामने आ जाता है और page पढ़ना असंभव बना देता है