ssh(1) में keystroke timing obfuscation जोड़ा गया

 (undeadly.org)
3 पॉइंट द्वारा GN⁺ 2023-08-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Damien Miller ने ssh(1) client में keypresses के बीच के समय की जानकारी छिपाने वाला obfuscation फ़ीचर commit किया
  • interactive traffic में भेजा जाने वाला डेटा कम होने पर यह fixed-interval transmission का उपयोग करता है, और default interval 20ms है
  • आख़िरी वास्तविक keypress के बाद यह कुछ random समय तक fake chaff keystrokes भेजता है ताकि timing pattern और धुंधला हो जाए
  • इसका व्यवहार नए ssh_config keyword ObscureKeystrokeTiming से नियंत्रित होता है
  • implementation में SSH transport layer के नए PING/PONG extension का उपयोग होता है, और बाद में openssh-portable के ज़रिए यह दूसरे systems तक भी पहुँच सकता है

ssh(1) client में keypress timing छिपाना

  • Damien Miller ने ssh(1) में keystroke timing obfuscation support commit किया
  • यह फ़ीचर keypresses के बीच के time interval को छिपाने के लिए कम डेटा वाले interactive traffic को fixed interval पर भेजने की कोशिश करता है
    • default transmission interval 20ms है
    • आख़िरी वास्तविक keypress के बाद कुछ random समय तक fake chaff keystrokes भेजे जाते हैं
  • नए ssh_config keyword ObscureKeystrokeTiming से इसका व्यवहार नियंत्रित होता है

SSH protocol extension और deployment path

  • implementation SSH protocol में जोड़े गए transport layer के दो नए messages का उपयोग करती है
    • SSH2_MSG_PING
    • SSH2_MSG_PONG
  • ये messages local extensions number space का उपयोग करते हैं, और "ping@openssh.com" ext-info message तथा string version "0" के साथ advertise किए जाते हैं
  • इस बदलाव को “security by trickery” के एक उदाहरण के रूप में पेश किया गया है, और इसे अगली OpenBSD release का इंतज़ार करने की वजहों में गिना गया है
  • दूसरे systems में यह फ़ीचर जल्द openssh-portable के माध्यम से दिखाई दे सकता है

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

1 टिप्पणियां

 
GN⁺ 2023-08-30
Hacker News की राय

  • की-इनपुट टाइमिंग 1980 के दशक से ही टर्मिनल input/output में चिंता का विषय रही है, और उस समय भी stelnet या Kerberos जैसे शुरुआती encrypted environments में इस पर ध्यान दिया जाता था
    ज़्यादातर terminal apps password input के लिए buffered input/output का उपयोग करते हैं, और यह अब भी एक महत्वपूर्ण security feature है
    इस mode में user के Enter दबाने से पहले दूसरी ओर कुछ भी भेजा नहीं जाता, इसलिए padding हो तो man-in-the-middle attacker के लिए password की लंबाई तक का अंदाज़ा लगाना मुश्किल होता है
    कुछ समय तक वे apps आसान निशाना थे जो user के हर input पर * दिखाने के लिए password को unbuffered mode में लेते थे
    देखने में यह अच्छा लगता है और feedback भी देता है, लेकिन password input में जिस key input speed को सबसे ज़्यादा छिपाना चाहिए, वही leak कर देता है
    password input के लिए buffered input/output बनाए रखना चाहिए, और मुझे लगता है कि यह तरीका SSH की obfuscation के बावजूद उसका पीछा करना मुश्किल बना देने जितना बेहतर है
    फिर भी SSH ने यह feature जोड़ा, यह अच्छी बात है, और shell या editor input जैसी ऐसी चीज़ों की सुरक्षा में मदद करेगा जिन्हें buffer नहीं किया जा सकता

    • आजकल इस्तेमाल होने वाला तरीका, जिसमें password की लंबाई से स्वतंत्र fixed number of asterisks दिखाए जाते हैं, users के लिए काफ़ी भ्रमित करने वाला है
      वे सोच सकते हैं कि “लंबाई गलत है, इसलिए शायद password गलत है” और saved password के फायदे को खत्म करते हुए खुद “सही” password फिर से type करने की कोशिश कर सकते हैं
      पहले शायद 2-character hash और smiley जैसे visual hash दिखाने के तरीके भी थे, लेकिन shoulder-surfing attacks में वे उल्टा मदद कर सकते हैं
    • 1990 के दशक में Visual Basic आधारित AI add-on से कुछ मिनट typing करवाकर सिर्फ typing pattern देखकर पता लगाया जा सकता था कि keyboard कौन चला रहा है, और तब login process असल में बेमानी हो जाता था
      अब इसे touchscreen login पर भी लागू किया जा सकता है, जैसे finger pressure, contact area और shape को user से जोड़ना
      swipe या mouse movements तक को desktop OS context में शामिल करें, तो ऐसी security app भी संभव है जो तब system lock कर दे जब कोई ऐसा user इस्तेमाल कर रहा हो जो अपने device या account पर नहीं है
      कम से कम यह तो record किया जा सकता है कि मेरी partner ने मेरा phone कब खंगाला
    • password-based SSH authentication लगभग कभी इस्तेमाल नहीं करना चाहिए, यही सही है
    • सोचता हूँ कि क्या कोई SSH client है जो input को line-by-line buffer करता हो
      यानी input तब तक transmit न हो जब तक Enter या send button न दबाया जाए
      पहले जब मैं MUD बहुत खेलता था, तब ऐसे Telnet client इस्तेमाल करता था, लेकिन उसके बाद जिन SSH clients का इस्तेमाल किया, उनमें ऐसा कभी नहीं देखा
      SSH key input timing leak रोकने के बचाव के रूप में यह ठीक लगता है, और कुछ use scenarios में article में बताए गए 20ms delay method से बेहतर भी हो सकता है
      हालांकि सोचने पर लगता है कि Linux shell autocomplete के लिए Tab दबाने पर भी transmit हो तो और ideal होगा
    • अगर “ज़्यादातर terminal apps password input के लिए buffered input/output इस्तेमाल करते हैं”, तो यह patch मौजूद है इसका मतलब क्या यह है कि OpenSSH ऐसा behave नहीं करता, यह जानना चाहूँगा

  • Pro Bridge याद आ गया
    teamों को दीवार से अलग कर दिया जाता है और cards को खिड़की से एक साथ आगे बढ़ाया जाता है, ताकि timing के ज़रिये communication रोका जा सके
    https://youtube.com/watch?v=RVZLNRmO3vo

    • फिर भी screen के ज़रिये cheating करते हैं
      https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
      https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
      https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
      और ये तो सिर्फ वे मामले हैं जिनके बारे में हमें पता है
      कभी एक interview में मैंने Bridge को सचमुच इस्तेमाल किया था
      Bridge में Active Ethics rule होता है कि अगर partner bidding के अलावा किसी तरीके से hint दे, तो logically possible होने पर आपको ज़रूर विपरीत direction चुननी चाहिए
      debugging interview में interviewer मुझे answer की ओर बहुत साफ़ तौर पर खींचने की कोशिश कर रहा था, इसलिए उसने जैसा कहा वैसा करने से पहले मेरे मन में आने वाली हर चीज़ रोककर check की
      interview के बाद मैंने बताया कि मैंने ऐसा क्यों किया, और कहा कि अगर और explanation चाहिए तो Active Ethics खोज लें
      और मैं select हो गया
    • अगर लोगों को बस human state machine की तरह fixed automaton ही चलाना है और उससे हटने पर penalty मिलनी है, तो बेहतर है coin toss से winner तय कर दें और game छोड़ दें
      यह वैसा ही है जैसे कहना कि catcher pitcher को signal नहीं दे सकता
      information transfer game में एक dimension जोड़ने वाली मानवीय skill है, और जो इसे सबसे अच्छी तरह करता है उसे जीतने देना चाहिए
    • red-team perspective से देखें तो इसमें exploit की जा सकने वाली मानवीय irregularities बहुत ज़्यादा हैं
      1–2 bits जितनी information पास करना इतना मुश्किल नहीं लगता
    • Bridge सचमुच अजीब game है
      partner के साथ secret communication ही core है, लेकिन वह communication secret नहीं होना चाहिए
      communication कर सकते हैं, पर communication नहीं करना चाहिए—कुछ ऐसा, इसलिए बहुत अजीब है
    • अब भी information transmit करने की संभावना दिखती है
      उदाहरण के लिए, छोटी table को barrier के पार हल्का धक्का देकर या धीरे-धीरे धकेलकर कुछ संकेत दिया जा सकता है
      video के top right वाला व्यक्ति first और second hand में ऐसा ही कर रहा था

  • ऐसे timing attacks पर 2001 के paper का परिचय कराने वाला 2008 का एक article है: https://lwn.net/Articles/298833/
    quoted paper “Timing analysis of keystrokes and timing attacks on SSH” है, और यह analyze करता है कि key input timing information typed key sequence के बारे में information leak करती है
    और detailed analysis में कहा गया है कि हर pair of keystrokes के लिए content के बारे में लगभग 1 bit information leak होती है, और password entropy प्रति character लगभग 4–8 bits होती है, इसलिए यह information काफी meaningful हो सकती है
    मुझे लगा था कि यह बहुत पहले fix हो चुका है, और 2012 के आसपास fix आया था, ऐसा सोचता था, इसलिए यह जानकर काफ़ी हैरानी है कि अब तक हल नहीं हुआ

  • कभी न कभी की-इनपुट छिपाने के लिए random data से पहले से भरे हुए packets इस्तेमाल करने पड़ सकते हैं
    यह steganography तो नहीं है, लेकिन काफी करीब की चीज़ है, और लगता है कि traffic analysis को और कठिन या असंभव बनाने में भी इस्तेमाल हो सकता है

    • NSA वगैरह दशकों पहले से ऐसे तरीके इस्तेमाल करते आए हैं
      dedicated line हो तो line को हमेशा maximum utilization पर पूरी तरह encrypted data से बहाते रखना, और जरूरत पड़ने पर ही असली data उस पर चढ़ा देना, इतना मुश्किल नहीं है
    • इस तरीके से steganography भी संभव है
      इसमें harmless cover text को language model से rewrite कराया जाता है, लेकिन word sampling में इस्तेमाल होने वाले probability distribution को key से निकले minimal entropy distortion से बदल दिया जाता है—ऐसी research मौजूद है
      receiving side पर वही model और key इस्तेमाल करने पर cover text को फिर से ciphertext में decrypt किया जा सकता है, और यह images पर भी लागू होता है
      https://openreview.net/forum?id=HQ67mj5rJdR
    • numbers stations याद आती हैं
      वे लगातार पूरी दुनिया में numbers broadcast करती रहती हैं, और उन numbers का अर्थ तभी बनता है जब वे किसी के लिए meaningful हों
      दुनिया की intelligence agencies सुन रही हैं, यह साफ पता होने के बावजूद वे ऐसा करती हैं
    • कुछ messaging protocols इसी तरह काम करते हैं
    • SSH traffic encrypted होता है, इसलिए observer को packets पहले से ही random data जैसे दिखते हैं

  • macOS के Warp जैसे modern terminal emulators याद आते हैं
    उदाहरण के लिए, सोचता हूं कि क्या वे सारी input local पर लेकर remote host को एक ही chunk में भेजते हैं
    ऐसा करने पर remote host पर चलने वाली कोई raw mode input टूट सकती है, लेकिन शायद ऐसी स्थिति detect करके raw keystroke stream पर switch भी किया जा सकता है
    [1]: https://warp.dev

    • आम तौर पर SSH से connect करने पर connection खुद हमेशा raw mode में होता है, और remote host सामान्य तरीके से pty handle करता है
      remote pty line mode में भी हो सकता है और raw mode में भी
      special shell integration वाले terminals में आम तौर पर remote host पर भी वही integration install होना जरूरी होता है, और कुछ इसे काफी transparent तरीके से handle करते हैं
      इसलिए high-latency connections पर mosh, pure SSH से बेहतर व्यवहार दिखा सकता है
      हालांकि यह feature mosh पर लागू नहीं होगा
    • “terminal के लिए AI” का दावा करने वाला app standard Unix tools से ज्यादा secure और private होगा, यह कल्पना करना मुश्किल है
      कुछ खास security features, जैसे timing attack defense, नए tools बेहतर तरीके से रोक सकते हैं और पुराने standard tools में शायद न हों
      लेकिन नए tools में दूसरे security features के छूट जाने की संभावना कहीं ज्यादा है, और “AI” जोड़ने से attack surface भी बहुत बढ़ जाता है
      Warp के privacy claims पर भी ईमानदारी से भरोसा करना मुश्किल है
      आजकल natural language processing tools लगभग cloud solutions की तरफ झुके हुए हैं, और तब privacy की संभावना लगभग तुरंत 0 के करीब पहुंच जाती है
    • अगर इसे किसी खास baud rate पर data receive करने के लिए design किया गया है, तो क्या एक chunk में भेजी गई input भी उसी speed के हिसाब से stream होकर नहीं आएगी?

  • जानना चाहता हूं कि यह किस threat को mitigate करता है

    • eavesdropper key input का content तो नहीं देख सकता, लेकिन पहले वह देख सकता था कि हर key input कब transmit हुआ
      अगर target का typing pattern पता हो, तो उस data से content reconstruct किया जा सकता है
      target से JavaScript enabled browser में मेरे control वाली website पर type करवाकर, या typing sound record करके pattern collect किया जा सकता है
      हाल ही में कुछ online streamers पर ऐसे attacks भी हुए हैं, जिनमें keyboard typing sounds पर trained AI model से passwords चुराए गए
    • अगर याद सही है, तो लगभग 2005 में एक paper था, जिसमें encrypted SSH session से packet timing collect करके उसे human typing statistics से correlate कर input content पता किया जा सकता था
      यह feature शायद उसे रोकने के लिए noise add करता है
    • मूल vulnerability concern Viterbi algorithm के इस्तेमाल को लेकर था
      http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
      machine learning जुड़ने के बाद audio decryption accuracy काफी बेहतर हो गई है, इसलिए physically unsafe जगहों पर quiet keyboard इस्तेमाल करना बेहतर है
      https://arstechnica.com/gadgets/2023/08/type-softly-research...
    • basic तौर पर typing speed analyze करके कुछ अनुमान लगाए जा सकते हैं
      उदाहरण के लिए user आम तौर पर password को बाकी input से ज्यादा तेजी से type करता है, इसलिए sudo जैसी operations में एक बार में भेजी गई key inputs की संख्या देखकर password length का अंदाजा लगाया जा सकता है
    • हाल में keystroke timing और deep learning से user को fingerprint की तरह identify करने, और इस paper में authentication में इस्तेमाल करने पर research आई है: https://www.usenix.org/system/files/usenixsecurity23-piet.pd...
      इस paper का use case अपने-आप में security threat नहीं है, लेकिन इसे information leakage के रूप में समझा जा सकता है

  • जानना चाहता हूं कि latency कितनी add होती है
    खासकर unpredictable latency software development work में stress के सबसे बड़े कारणों में से एक है

    • text में सीधे लिखा है
      जब केवल थोड़ी मात्रा में data transmit होता है, तो interactive traffic को fixed interval पर भेजा जाता है, और default 20ms है
    • ऊपर latency वाली बात शायद user experience की latency, यानी key press करने के बाद result दिखने तक की delay, के बारे में है
      [1]
      Mosh जैसे tools perceived latency घटाने में काफी मदद करते हैं
      Mosh user keystroke local पर register होते ही उसे दिखा देता है, और round trip पूरा नहीं हुआ है यह बताने के लिए उसे faded color में दिखाता है
      मैंने आखिरी बार जब देखा था तो ऐसा ही था, और शायद underline भी हो सकता है
      round trip पूरा होने पर character normal दिखने लगता है
      [1] अगर software development में सबसे बड़ा stress factor key input latency है, तो यह काफी lucky स्थिति लगती है
      [2]: https://mosh.org
    • क्या यह delay design के हिसाब से predictable नहीं है?

  • वास्तविक commit लिंक: https://github.com/openssh/openssh-portable/commit/7603ba712...

  • लगता है कुछ लोग packet timing मापकर network पर hands-on-keyboard shell detect करते हैं; सोच रहा/रही हूँ कि यह बदलाव ऐसी detection को कितना बाधित करेगा

    • उम्मीद है ऐसी approach भी “security” के नाम पर encryption तोड़ने या backdoor डालने की दूसरी enterprise-style कोशिशों जैसी ही राह पर जाए
      security को लेकर यह तरीका मुझे सच में गलत लगता है
      यह जानना अच्छा हो सकता है कि कोई automation script किसी device में login कर रही है या नहीं, लेकिन बेहतर design में उस जानकारी को मायने नहीं रखना चाहिए
    • इसके लिए non-malicious use cases क्या हो सकते हैं?