- यूक्रेनी हैकर समूह ने सैन्य खुफिया एजेंसी के साथ मिलकर रूस की प्रमुख ड्रोन निर्माता कंपनी Gaskar Integration के IT इंफ्रास्ट्रक्चर को ठप कर दिया
- 47TB से अधिक महत्वपूर्ण डेटा और बैकअप सामग्री मिटा दी गई, जिससे मुख्य बिज़नेस ऑपरेशन रुक गए
- फैक्टरी के आंतरिक सिस्टम, अकाउंटिंग और प्रोडक्शन प्रोग्राम सभी पूरी तरह निष्क्रिय हो गए
- उत्पादन फैक्टरी के प्रवेश द्वार तक बंद हो गए, जिससे कर्मचारियों को आपातकालीन निकास का उपयोग करना पड़ा
- चुराए गए डेटा में कर्मचारियों की निजी जानकारी और ड्रोन तकनीकी दस्तावेज़ शामिल थे, जिन्हें यूक्रेन के रक्षा मंत्रालय को सौंपा गया
मुख्य बातें
- यूक्रेनी साइबर एक्टिविस्ट्स ने सैन्य खुफिया एजेंसी के साथ मिलकर रूस की सेना को ड्रोन सप्लाई करने वाली सबसे बड़ी निर्माताओं में से एक Gaskar Integration के नेटवर्क और सर्वर इंफ्रास्ट्रक्चर पर हमला किया
- इस हमले में 47TB से अधिक तकनीकी जानकारी और 10TB बैकअप डेटा तक नष्ट कर दिया गया; इस डेटा में रूस और चीन के बीच करीबी सहयोग के संकेत भी शामिल थे
- हैकिंग के कारण इंटरनेट, प्रोडक्शन प्रोग्राम, अकाउंटिंग प्रोग्राम सहित कंपनी के सभी सिस्टम ठप हो गए, जिससे Gaskar का R&D सेंटर भी सामान्य रूप से संचालित नहीं हो सका
- सभी ड्रोन उत्पादन फैक्ट्रियों के अंदर के प्रवेश द्वार ब्लॉक हो गए, जिससे कर्मचारियों को बाहर निकलने और आने-जाने के लिए आपातकालीन निकास का उपयोग करना पड़ा
- चुराई गई जानकारी में कर्मचारियों की गोपनीय प्रश्नावलियाँ और ड्रोन उत्पादन से जुड़े तकनीकी दस्तावेज़ शामिल थे, और यह जानकारी यूक्रेन के रक्षा मंत्रालय के अधीन विशेषज्ञों को सौंप दी गई
अतिरिक्त पृष्ठभूमि
- सैन्य खुफिया निदेशालय से जुड़े साइबर विशेषज्ञ पहले भी रूस की रेलवे वेबसाइट को एक बड़े हमले के जरिए निष्क्रिय कर चुके हैं
- अतीत में रूस की Regiontransservice पर हमला भी सफलतापूर्वक किया गया था, जिससे उसकी सभी सेवाएँ बंद हो गई थीं
1 टिप्पणियां
Hacker News की राय
मैं घर पर एक छोटा-सा लैब चलाता हूँ, करीब 30 services हैं
एक दिन main disk बदलते समय backup का इस्तेमाल करके सब कुछ शून्य से फिर बनाया, और एक घंटे में सब फिर चालू हो गया
लेकिन उसके बाद एक हफ़्ते तक इधर-उधर सुधार करने और यह याद करने में बहुत मेहनत लगी कि मैंने कुछ चीज़ें इस तरह क्यों configure की थीं
यह एक व्यक्ति द्वारा मैनेज किया जाने वाला simple Docker-based lab है, और मैं खुद भी IT में काम करता हूँ
लेकिन कई लोगों द्वारा कई सालों तक मैनेज की गई पूरी infrastructure को शून्य से restore करना सचमुच बहुत बड़ा काम है
पास के एक hospital पर ransomware attack हुआ था, तब मैंने volunteer के रूप में recovery में मदद की थी; वहाँ के दो IT कर्मचारी को बिल्कुल समझ नहीं था कि क्या करना है, और official support उम्मीद से बहुत खराब था
बड़े enterprise के ransomware incidents में भी मदद की है, और यह याद करने में बहुत मेहनत लगी कि systems ऐसे क्यों बने थे
documentation और testing मौजूद होने पर भी, असली हालात में reality check मिल ही जाता है
एक बार हमारे घर पर police raid हुई थी और वे desktop, laptop, NAS, hard drive वगैरह मिलाकर लगभग $10k का equipment ले गए थे
अपनी पिछली नौकरी में backup और disaster recovery planning संभालने की वजह से मैंने पहले से तैयारी कर रखी थी
एक-दो दिन में ज़्यादातर चीज़ें restore हो गईं और data loss करीब दो दिन का था; अच्छी बात यह थी कि यह घर की चीज़ें थीं, इसलिए जानलेवा नुकसान नहीं था
इस अनुभव के बाद मैंने कई structural improvements किए, और आगे ऐसी घटनाओं से नुकसान और कम होने लगा
(और 8 महीने बाद police ने निष्कर्ष निकाला कि मैं निर्दोष हूँ और मेरा equipment लौटाने को कहा, लेकिन बच्चों को trauma हो गया था)
documentation सच में बहुत ज़रूरी है, software architecture के स्तर पर भी
कुछ महीनों बाद ही अक्सर याद नहीं रहता कि मैंने कोई फ़ैसला क्यों लिया था
जैसे "मैंने ORM/SQL tool के लिए Kysely क्यों चुना", "Deno/Bun क्यों इस्तेमाल कर रहा हूँ", "folder structure feature-based क्यों है", "library fork क्यों किया और उसे कैसे maintain करना है", "AWS/GCP/Azure/Docker क्यों चुना", "Kubernetes distribution क्यों चुना", "यह project क्यों शुरू किया/इसका goal क्या है" वगैरह
इसलिए मैं README.md में # Decisions section बनाकर इसे document करता हूँ
इसकी वजह से अपने ही फ़ैसलों पर बार-बार शक करके docs में अंतहीन खोजबीन करने से मुक्ति मिली
90s के mainframe इतने stable और redundant होते थे कि कई बार 10 साल से ज़्यादा reboot नहीं होते थे, और kernel तक का upgrade बिना downtime के हो जाता था
लेकिन एक कंपनी में power outage हुआ, backup generator भी fail हो गया, और जब बिजली वापस आई तो यह समझने में महीनों लग गए कि वह machine असल में कर क्या रही थी और उसे कैसे शुरू करना है
उसके बाद ज़्यादातर कंपनियों ने हर 6 महीने में mainframe को जानबूझकर reboot करके restart test करना शुरू किया
आधुनिक IT practices में disaster recovery को लगभग ध्यान में ही नहीं रखा जाता
जो organizations backup बहुत सख्ती से करती हैं, वे भी अक्सर actual recovery test नहीं करतीं
manpower कम होने की वजह से बस जल्दी-जल्दी चीज़ें खड़ी की जाती हैं
आसानी से दोबारा बनाई जा सकने वाली infrastructure design करना, सिर्फ install कर देने से लगभग दोगुनी मेहनत माँगता है
hospital ransomware volunteer वाली बात दिलचस्प है
healthcare IT में access permissions बहुत सख़्ती से संभाली जाती हैं, इसलिए पहले PHI training या background check के बिना system access मिलना मुश्किल था; जानना चाहता हूँ कि emergency होने के कारण क्या कोई fast-track temporary onboarding process अपनाया गया था, या hospital के अंदर के किसी contact के ज़रिए volunteer बनकर मदद की गई थी
मैं एक German company में काम कर रहा हूँ
production management अभी 3 महीने पहले की planning Excel में print करके चला रहा है
ERP system migration fail हो गया, और किसी को नहीं पता कि इसे कैसे ठीक किया जाए
production management department यह बात छिपा रहा है और engineering department को भी नहीं बता रहा
लगता है यह स्थिति सालों चलेगी; consultants इसी से रोज़ी कमाते हैं
यह साबित करता है कि manufacturing के लिए IT infrastructure अनिवार्य नहीं है; उसके बिना भी काम चल जाता है, बस हो तो अच्छा है
90s के आख़िर से 2000s की शुरुआत में Danish Ministry of Defence ने SAP पर बना नया procurement system DeMars लाने की कोशिश की थी
procurement में काम करने वाले मेरे एक दोस्त ने DeMars लागू होने से ठीक पहले अपने ज़िम्मे की supplies बहुत बड़ी मात्रा में order कर दी थीं, और उस पर fraud का शक करके पूछताछ भी हुई थी
वजह यह थी कि उसे DeMars पर भरोसा नहीं था और उसने inventory stock बनाए रखना ज़रूरी समझा
सच में, DeMars लागू होने के बाद procurement का काम लगभग एक साल तक ठप हो गया
आखिरकार, मेरे दोस्त के ज़िम्मे वाले items ही नए system rollout के दौरान stock में बने रहे
90s के आख़िर में मैं एक manufacturer में firmware developer था
वह ऐसा दौर था जब सब कुछ अब भी कागज़ पर दर्ज किया जाता था
कंपनी ने Oracle-based ERP सफलतापूर्वक खड़ा किया और सब खुश थे, लेकिन 6 महीने बाद किसी ने machine room की दीवार में forklift दे मारी, UPS में आग लग गई, और Oracle server सहित equipment के तीन racks जल गए
क्योंकि किसी को भी system पर पूरा भरोसा नहीं था, सब अब भी कागज़ पर रिकॉर्ड रखते रहे; इसलिए 6 साल बाद नौकरी छोड़ने तक भी हम paper + Excel reports से काम करते रहे
नतीजा यह निकला कि paper-based तरीका forklift के सामने भी ज़्यादा मज़बूत साबित हुआ
Excel को बहुत से office workers सहज रूप से समझ और बदल सकते हैं
अगर IT infrastructure के ज़्यादातर हिस्सों में ऐसी आसान accessibility हो, तो वह कहीं ज़्यादा practical होगा
दूसरी तरफ, जब IT automation पूरी तरह production में जम जाती है और पुराने manual तरीकों के जानकार लोग नहीं बचते, तब manual mode में लौटना सचमुच बहुत मुश्किल हो सकता है
हालाँकि यह order/workflow की complexity पर निर्भर करेगा
software के बिना drones भी बेकार हैं
अगर inventory याद हो तो manual operation के लिए quadcopter assemble करना शायद संभव हो, लेकिन 3D-printed parts का production, stable flight, autonomous operation, surveillance, और दूसरे advanced use असंभव होंगे
remote control भी मुश्किल होगा
यूक्रेन में cyberwarfare एक नए स्तर पर पहुँच रही है, यह साधारण cyber attack से आगे की चीज़ है
इस बार निशाना बने Russian drone manufacturing facility जैसे मामले दिखाते हैं कि इस युद्ध की दिशा बदलने में drones कितने अहम रहे हैं
drones ने reconnaissance, disruption, ammunition interception जैसी innovations दी हैं
material के मुकाबले इनकी destructive power बहुत बड़ी है, और video recognition technology के विकास की वजह से कुछ systems signal jamming के बावजूद काम करते हैं
लगता है जैसे spy movie की दुनिया सच हो रही हो
इससे पता चलता है कि Ukraine asymmetric warfare में कितनी माहिर है
long-range bombers को नष्ट करना, drone production hubs को पंगु बनाना—इनसे Russia की मुख्य combat capability हिल रही है
युद्ध कैसे खत्म होगा यह नहीं पता, लेकिन Ukraine का resistance जारी रहेगा, यह साफ़ है
उपन्यास Ministry of the Future में ऐसा भविष्य दिखाया गया है जहाँ drones इतने आगे बढ़ जाते हैं कि कोई भी सुरक्षित नहीं रहता, और पारंपरिक युद्ध का अर्थ ही खत्म होने लगता है
छोटे समूह भी दुनिया में कहीं भी किसी की भी हत्या कर सकेंगे
विचार दिलचस्प है, लेकिन कहानी कमज़ोर है, इसलिए किताब की बहुत सिफ़ारिश नहीं करूँगा
“ऐसे drones जो electronic jamming के बावजूद काम करते हैं” पर, आजकल ऐसे drones भी हैं जो radio waves के बजाय fiber optic cable से नियंत्रित होते हैं; यह और भी डरावनी हक़ीक़त है
इस युद्ध में drones की जो अहम भूमिका है, क्या वह आगे दूसरे युद्धों में भी लागू होगी, यह अभी देखना बाकी है
Russia की वह खास स्थिति—जहाँ वह भारी जनहानि सहते हुए भी धीरे-धीरे आगे बढ़ रहा है—FPV drones की value बढ़ा रही है
ज़्यादातर देश ऐसा नुकसान सहना नहीं चाहेंगे, इसलिए शायद यह युद्ध का standard form न बने
हो सकता है सस्ते long-range jet drones ज़्यादा महत्वपूर्ण भूमिका निभाएँ
लेख में दी गई जानकारी में बहुत-सी assumptions मिली हुई हैं
हम सिर्फ एक पक्ष की कहानी सुन रहे हैं, और propaganda value की वजह से इसमें बढ़ा-चढ़ाकर कहा गया हो सकता है
version control ठीक हो, और हर developer code और CAD files की local copies रखता हो, तो यह सामान्य बात है
email और office files खो गए हों, लेकिन संभव है कि वह घातक नुकसान न हो
website भी अब भी चल रही है
इस बार निशाना बनी कंपनी drone community में कोई बहुत मशहूर जगह नहीं रखती, इसलिए यह किसी विशाल model production shutdown जैसा नहीं लगता
version control जैसी बुनियादी बातों से वे अनजान नहीं होंगे; और comment की writing style देखकर यह भी लगा कि शायद इसे ChatGPT ने लिखा हो
मैं Switzerland की एक mid-sized company में काम करता हूँ
हम अपना खुद का ERP बना रहे हैं, और stack किसी nightmare से कम नहीं है
हम इसे खुद ही ‘security through chaos’ कहते हैं
अगर कोई attacker अंदर घुस भी जाए, तो बाहर निकल नहीं पाएगा
90% code नष्ट हो जाए तो भी service पर असर नहीं होगा, क्योंकि 95% तो वैसे ही बेकार code है
मैंने बड़े enterprises के लिए MRP systems खुद develop किए हैं, इसलिए यह तरीका कहाँ जाएगा, इसको लेकर जिज्ञासा है
मैं आम तौर पर recommended security/disaster recovery तरीकों के ऊपर OTP-hash-based key authentication layer भी जोड़ देता हूँ
मुझे लगता था कि मैं कुछ ज़्यादा ही extreme हूँ, लेकिन यह system तो लगभग end-of-days survival scenario जैसा लग रहा है
यह evolutionary process से पैदा हुई resilience जैसा लगता है
यह असली दुनिया की ICE wall जैसा मज़ेदार है
डरावना भी है, और किसी तरह प्रशंसनीय भी
ज़्यादातर कंपनियाँ इस बात की स्पष्ट तैयारी नहीं करतीं कि कंपनी के भीतर के लगभग सभी data stores पूरी तरह मिट जाएँ और सब कुछ 0 से फिर deploy करना पड़े
अगर आपने सचमुच 0 से recovery करके नहीं देखा है, तो deploy dependencies में circular loops होने की पूरी संभावना है
Jenkins/Puppet/Ansible से config pusher deploy करते-करते एक समय ऐसा आता है कि Jenkins खुद भी config pusher पर निर्भर हो जाता है, और फिर चीज़ों को सीधी क्रमवार तरीके से बनाना संभव नहीं रहता; आपको अतीत के सारे बदलाव फिर से दोहराने पड़ते हैं
IT में लगभग हर हिस्से में circular dependencies होती हैं
SSO लगभग हर system की dependency बन जाता है, और SSO के भीतर network और तरह-तरह के system management में भी circular structure बनता है
पूरी तरह fresh boot करना हमेशा मुश्किल और समय लेने वाला होता है
जब तक पूरी तरह अलग dual infrastructure न बनाई जाए, इस समस्या को पूरी तरह हल करना लगभग असंभव है
मेरी जानकारी में एक कंपनी ने भी एक साल पहले यही झेला था
जिस main storage cluster पर सब निर्भर था, वही मर गया
आखिर में एक Dev laptop से सब कुछ फिर deploy करके recover किया गया
black start (पूरी initial-state recovery) बहुत कठिन समस्या है
Facebook ने भी कभी data center के door locks drill करके अंदर घुसकर recovery की थी
सोचता हूँ, ऐसी स्थिति में आखिर recovery कैसे की जाए
अगर paper documentation बची हो, तो क्या उससे bootstrap किया जा सकता है, या मान लेना चाहिए कि वह भी गायब है?
construction industry में भी ऐसी ही समस्या है
products की lifespan 50 साल से ज़्यादा, कभी-कभी सैकड़ों साल होती है, लेकिन 30 साल पुराने design files आज file format compatibility issues की वजह से खोले नहीं जा सकते
digitalization की बात दशकों से हो रही है, लेकिन आखिर में पुराने 2D drawings (या आजकल जिसे ‘digital paper’ कहा जाता है, यानी PDF) भविष्य में काम आ सकते हैं
असली कागज़ का इस्तेमाल कम होता जा रहा है, लेकिन file compatibility issues की वजह से आख़िरकार paper फिर उपयोगी साबित हो सकता है
लेख के title में attackers को ‘cyber activists’ कहा गया है, लेकिन body में उन्हें ‘cyber criminals’ कहा गया है
इससे sailship era के quasi-official pirates, जैसे privateers या letters of marque, याद आते हैं
fourth-generation warfare के सिद्धांत में भी civilian-military boundary के धुंधले होने की बात थी
rules of engagement धीरे-धीरे और अस्पष्ट होते जा रहे हैं
Russia हर दिन drones से civilians को मार रहा है
यह कोई grey-zone hybrid warfare जैसा अस्पष्ट मामला नहीं है; यह बस अपने पड़ोसियों को drone attacks का शिकार होने से बचाने की कोशिश है
यह translation issue जैसा लगता है
वह site Ukraine के पक्ष में काफ़ी झुकी हुई है, इसलिए हो सकता है कि hackers को नकारात्मक न दिखाने के लिए ‘cyber criminal’ का इस्तेमाल सिर्फ ‘hacker’ के अर्थ में किया गया हो
वास्तव में सबसे उचित संभावना यही लगती है कि यह Ukraine military के भीतर व्यवस्थित रूप से किया जा रहा हो
इसलिए इन्हें criminal न मानना ज़्यादा सही है
यह Robin Hood जैसी स्थिति है
किसी के लिए hero, किसी के लिए criminal
शायद article कई लेखों को जोड़कर बना है, इसलिए terminology मिल गई होगी
अच्छा होता अगर cyberwarfare में पक्षों को अलग बताने के लिए कोई अलग शब्द होता
“cyberactivist” से तो बस online protesters जैसा एहसास आता है; फ़िल्मों वाले घिसे-पिटे शब्द के बजाय “cybersoldier” या “network militia” जैसा कुछ बेहतर लगता
लेख की photo की date Unix epoch की शुरुआत से एक दिन अलग है, यह देखकर मुझे अकेले में मज़ा आया
वह website बहुत ही अजीब है
Russian government ने उसे block कर रखा है, इसलिए TLS errors आते हैं; उससे निकल भी जाएँ तो Cloudflare का "blocked" page मिलता है, और article का original text (Russian में) देखने के लिए VPN चाहिए
linked page English में है, लेकिन हो सकता है Russia के local readers असल target ही न रहे हों
Russia में language issue संवेदनशील है, लेकिन Ukraine में वास्तव में Russian भी बहुत इस्तेमाल होती है और Russian में articles भी छपते हैं
archive.today, archive.org (Internet Archive) जैसी archive sites का ज़रूर इस्तेमाल करना चाहिए
archive link भी किसी ने हाल ही में save किया है
यह उस website की समस्या नहीं भी हो सकती, बल्कि government block या CloudFlare side की issue हो सकती है
TLS error की मूल वजह के कारण भी Cloudflare block कर रहा हो सकता है
सोचता हूँ क्या दोनों पक्ष drones के firmware को लेकर भी चिंतित हैं
दुश्मन के इस्तेमाल वाले drones में छेड़छाड़ किया हुआ firmware छिपाकर डाल देना रणनीतिक रूप से काफ़ी मूल्यवान हो सकता है
दिलचस्प है, लेकिन risk बड़ा है (आसानी से पकड़ा जा सकता है और पूरी operation को बेकार कर सकता है)
आख़िरकार hardline approach ही सबसे तर्कसंगत लगती है
drones में आमतौर पर mission से ठीक पहले firmware flash किया जाता है
असल में factory बंद करवाने से ज़्यादा असरदार यह हो सकता है कि drones चुपके से कुछ और करने लगें (जैसे launch के समय अपने base पर हमला करना या remote control ले लेना)
एक दिलचस्प strategy यह भी सुनी है कि drone की SD card में virus डाल दिया जाए, ताकि drone दुश्मन के इलाके में गिरने के बाद जब वे उसे computer में लगाएँ तो वह machine संक्रमित हो जाए
“यूक्रेनी cyber activists military intelligence के साथ cooperation में…”
यानी मतलब यह हुआ कि foreign intelligence agencies ने सिर्फ signal दिया, और यह direct cyberwarfare नहीं है
“foreign intelligence agencies ने सिर्फ signal दिया, इसलिए यह direct cyberwarfare नहीं” इस राय पर
Russian intelligence agencies पहले से ही NATO देशों पर सीधे हमले कर रही हैं, इसलिए बचाव में कहने को लगभग कुछ नहीं है
Ukraine और Russia के बीच कई सालों से युद्ध चल ही रहा है, इसलिए plausible deniability की भी कोई ख़ास ज़रूरत नहीं रह गई है
‘foreign intelligence agencies’ से क्या मतलब है, यह जानने की जिज्ञासा है; और यह भी कि दुनिया भर में लगातार attacks चलते रहते हैं, इसलिए भोले मत बनो
इशारा किया गया कि article में “foreign intelligence agencies” लिखा ही नहीं है
उसमें साफ़ तौर पर Ukraine military intelligence लिखा है