সুইডিশ ব্যাংকআইডি-তে জটিল দুর্বলতা ব্যবহারকারীর ডেটা প্রকাশ করে

সুইডিশ BankID হল ডিজিটাল শনাক্তকরণের একটি রূপ যা বেশিরভাগ সুইডিশ বাসিন্দারা একাধিক পরিষেবা যেমন: ইন্টারনেট প্রদানকারী, অনলাইন ব্যাঙ্কিং পরিষেবা, বেটিং ওয়েবসাইট এবং বিশেষ করে সরকারি ওয়েবসাইটগুলিতে প্রমাণীকরণ করতে ব্যবহার করে না।

আমি নিজে সুইডেনে বসবাস করছি, এবং হ্যাকার মানসিকতা সবসময় আমার মস্তিষ্কে গুঞ্জন করে, আমি সিদ্ধান্ত নিয়েছি যে কিছু নিরাপত্তা গবেষণা করা একটি খুব আকর্ষণীয় ক্ষেত্র হবে।

এই পোস্টে আমি একটি নতুন দুর্বলতা উপস্থাপন করব যা আমি বেশিরভাগ সুইডিশ পরিষেবা প্রদানকারীর মধ্যে পেয়েছি যা BankID-এর প্রমাণীকরণ প্রোটোকলের একটি অনিরাপদ বাস্তবায়নের কারণে রয়েছে।

এই ধরনের একটি প্রোটোকল কীভাবে কাজ করে, একটি দুর্বল কনফিগারেশন কেমন দেখায়, কীভাবে এটিকে কাজে লাগাতে হয়, কীভাবে এটির প্রতিকার করা যায় এবং শেষ পর্যন্ত, ইআইডিগুলির সামগ্রিক বাস্তবায়নের জন্য এই ধরনের আক্রমণগুলির অর্থ কী তা আমি সংক্ষেপে বলব৷

BankID প্রমাণীকরণ প্রোটোকল

BankID হল এমন একটি পরিষেবা যা ব্যবহারকারীর ডিভাইসে ইনস্টল করা হয় এবং এটি একটি সুইডিশ ব্যাঙ্ক থেকে অনুরোধ করে প্রাপ্ত হয়, আপনার কাছে একটি সুইডিশ পার্সুনুমার , একটি ব্যক্তিগত আর্থিক কোড রয়েছে। অ্যাপ্লিকেশনটি ব্যবহারকারীর ডিভাইসে ইনস্টল করা হয় এবং তাদের আর্থিক কোডের সাথে সংযুক্ত থাকে, মূলত এই ধরনের একটি অ্যাপ্লিকেশনের সাথে তার পরিচয় সংযুক্ত করে। ইলেকট্রনিক শনাক্তকরণ সিস্টেমগুলি প্রায়শই এইভাবে কাজ করে: একটি সরকার-অনুমোদিত এবং বিশ্বস্ত তৃতীয় পক্ষ সফ্টওয়্যারের একটি টুকরো দেয় যা একটি নির্দিষ্ট ব্যক্তির সাথে সংযুক্ত থাকে এবং তারপর পরিষেবাগুলি সেই সফ্টওয়্যারটির প্রদানকারীর সাথে একীভূত হয় যাতে তাদের ব্যবহারকারীরা তাদের প্রমাণীকরণ করতে পারে৷ প্ল্যাটফর্ম, একটি শেয়ার্ড ট্রাস্ট মডেল যা পরিষেবাগুলিকে সহজে লোকেদের প্রমাণীকরণ করতে দেয়।

BankID আলাদা নয় এবং এটি এই ধরনের পরিষেবাগুলির জন্য ডকুমেন্টেশন প্রদান করে, যা এখন থেকে Relying Party (RP) হিসাবে উল্লেখ করা হবে, যাতে তারা সহজেই BankID এর সাথে তাদের প্রমাণীকরণ প্রবাহকে একীভূত করতে পারে। https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion ।

ব্যাঙ্কআইডির সাথে ব্যবহারকারীকে প্রমাণীকরণ করতে দুটি প্রধান প্রবাহ ব্যবহার করা হয়:

• একই ডিভাইসে প্রমাণীকরণ করুন

• অন্য ডিভাইসে প্রমাণীকরণ করুন

  
  

আমরা শীঘ্রই এই দুটিকে আবার দেখব, তবে, উভয় প্রবাহ শুরু হয় RP দ্বারা একটি প্রমাণীকরণ অর্ডার শুরু করার জন্য BankID এর API-কে একটি অনুরোধ পাঠানোর মাধ্যমে। এই পোস্টের অনুরোধে, RP-কে অবশ্যই endUserIp প্যারামিটার নির্দিষ্ট করতে হবে, যে ব্যবহারকারী লগ ইন করার চেষ্টা করছেন তার IP ধারণ করে, এটি রিপোর্টে পরে গুরুত্বপূর্ণ হবে।

/auth API শেষ পয়েন্ট এই মত কিছু সঙ্গে প্রতিক্রিয়া হবে:

 HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" }

• orderRef হল একটি শনাক্তকারী যা RP প্রমাণীকরণের স্থিতি পরীক্ষা করতে /collect endpoint এর বিরুদ্ধে ব্যবহার করতে পারে এবং পরে সেই ব্যক্তির কাছ থেকে ব্যবহারকারীর প্রয়োজনীয় তথ্য আনয়ন করতে পারে।
• autoStartToken হল একটি টোকেন যা RP দ্বারা একটি গভীর লিঙ্ক তৈরি করতে ব্যবহৃত হয় যা ক্লিক করলে BankID অ্যাপটি খুলবে এবং ব্যবহারকারীকে নিজেকে প্রমাণীকরণের জন্য অনুরোধ করবে ( এটি সত্যিই গুরুত্বপূর্ণ হবে )

qrStartToken এবং qrStartSecret নীচে কভার করা হবে কিন্তু নিরাপত্তা গবেষণার জন্য কঠোরভাবে গুরুত্বপূর্ণ নয়।

ব্যবহারকারীর আইপি ছাড়াও, একটি RP প্রমাণীকরণ আদেশের জন্য আরও পরামিতি নির্দিষ্ট করতে পারে, যার মধ্যে BankID অ্যাপ্লিকেশনে প্রদর্শিত পাঠ্য এবং প্রমাণীকরণের প্রয়োজনীয়তা রয়েছে ।

প্রমাণীকরণের প্রয়োজনীয়তাগুলির মধ্যে, এই পোস্টটি যেগুলির উপর ফোকাস করবে তাকে শংসাপত্র নীতি বলা হয়, এইগুলি RP-কে ব্যাঙ্কআইডি-র সাথে যোগাযোগ করতে দেয় যে দুটি প্রবাহের মধ্যে কোনটি ব্যবহারকারী বেছে নিয়েছেন।

একই ডিভাইসে প্রমাণীকরণ

যখন একজন ব্যবহারকারী একই ডিভাইসে BankID ব্যবহার করে প্রমাণীকরণ করা বেছে নেন, তখন RP একটি গভীর লিঙ্ক তৈরি করতে autoStartToken ব্যবহার করে যা দেখতে এরকম হয়: bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login । এই গভীর লিঙ্কটি তারপর ব্যবহারকারীর OS দ্বারা বাছাই করা হয় এবং BankID অ্যাপ্লিকেশনে হস্তান্তর করা হয়।

এই ফ্লোটি তদন্ত করার সময়, একটি ওপেন রিডাইরেক্ট দুর্বলতা পাওয়া গেছে কারণ BankID এর দিক থেকে redirect প্যারামিটারের কোন বৈধতা নেই, কেন এই অতিরিক্ত বাগ সেশন হাইজ্যাকিং আক্রমণটিকে আরও শক্তিশালী করে তোলে তা আমি পরে জানতে পারব।

অন্য ডিভাইসে প্রমাণীকরণ

যখন একজন ব্যবহারকারী অন্য ডিভাইসে BankID ব্যবহার করে প্রমাণীকরণ করা বেছে নেন, তখন RP একটি ডায়নামিক QR কোড তৈরি করতে qrStartToken এবং qrStartSecret ব্যবহার করে (উপরে উল্লিখিত /collect এন্ডপয়েন্ট থেকে পরবর্তী ফ্রেমের ডেটা আনয়ন করে) যা ব্যবহারকারী তার মোবাইল BankID ব্যবহার করে স্ক্যান করতে পারে। আবেদন

সার্টিফিকেট নীতি

একটি প্রমাণীকরণ আদেশ শুরু করার সময় এগুলি RP দ্বারা নির্দিষ্ট করা উচিত , ফিশিং প্রশমিত করার জন্য প্রবাহ মেলে না থাকলে তারা BankID-কে একটি প্রমাণীকরণ প্রচেষ্টা প্রত্যাখ্যান করার অনুমতি দেয়। উদাহরণস্বরূপ, ব্যবহারকারী যদি "একই ডিভাইসে প্রমাণীকরণ" বেছে নেন, তাহলে RP-এর উচিত তা BankID-এর সাথে যোগাযোগ করা যাতে করে যদি প্রমাণীকরণটি মোবাইল BankID এবং/অথবা QR কোড ব্যবহার করে প্রত্যাখ্যান করা হয়, তাহলে আবেদনটি তা প্রত্যাখ্যান করতে পারে।

এগুলি ছাড়াও, একবার প্রমাণীকরণ সম্পূর্ণ হলে, RP ipAddress আনতে পারে যা /collect API এন্ডপয়েন্ট থেকে BankID এর অ্যাপ্লিকেশন খুলতে ব্যবহৃত হয়েছিল। যদি তিনি "একই ডিভাইসে প্রমাণীকরণ" বেছে নেন তাহলে এটি RP-এ ব্যবহারকারীর আইপি ঠিকানার বিরুদ্ধে পরীক্ষা করা উচিত ।

ipAddress সহ সার্টিফিকেট নীতিগুলি নিশ্চিত করার জন্য ব্যবহার করা উচিত যে প্রমাণীকরণ প্রবাহের সাথে টেম্পার করা যাবে না।

তথাপি এই নিরাপত্তা ব্যবস্থাগুলি থাকাকালীন, BankID তাদের গুরুত্বের রূপরেখা দিতে ব্যর্থ হয় এবং তাদের প্রদত্ত উদাহরণ বাস্তবায়নেও সঠিকভাবে প্রয়োগ করে না! https://github.com/BankID/SampleCode

সেশন ফিক্সেশন বাগ

তাই কি হবে যখন এই প্রোটোকল নিরাপদে প্রয়োগ করা হয় না?

যখন আমি প্রথম bankid:/// ডিপ লিঙ্কটি দেখেছিলাম তখন আমি আমার বিশ্ববিদ্যালয়ের আবেদনপত্রগুলি ব্রাউজ করছিলাম যা BankID দিয়ে লগ ইন করে অ্যাক্সেস করা যেতে পারে। প্রথমে, আমি ভেবেছিলাম: আমি যদি কাউকে এই গভীর লিঙ্কটি পাঠাই তবে কী হবে? তাই আমি এটি আমার এক বন্ধুর কাছে পাঠিয়েছিলাম যিনি এটিতে ক্লিক করেছিলেন, এবং তিনি ব্যাংকআইডি খোলার পরে আমার কাছে তার বিশ্ববিদ্যালয়ের সমস্ত আবেদনপত্র আমার সামনে ছিল!

তখনই যখন আমি BankID এর API খতিয়ে দেখা শুরু করি, আমার নিজের RP প্রয়োগ করি, এবং আমি এইমাত্র যে সমস্ত বিষয় উল্লেখ করেছি সেগুলি সম্পর্কে শিখেছি।

কয়েক সপ্তাহের গবেষণার পর, আমি একটি স্ক্রিপ্ট তৈরি করেছি যা স্বয়ংক্রিয়ভাবে bankid:/// 30 RPs-এর জন্য গভীর লিঙ্ক দখল করে, স্ক্রিপ্টটি একটি ওয়েব সার্ভার শুরু করবে এবং প্রতিটি পরিষেবার জন্য একটি পথ তৈরি করবে, যখন একজন ব্যবহারকারী লিঙ্কটি ভিজিট করবে একটি নির্দিষ্ট পরিষেবা যা স্ক্রিপ্ট একটি নতুন লিঙ্ক আনবে এবং ব্যবহারকারীকে এটিতে পুনঃনির্দেশ করবে। এর ফলে ব্যবহারকারীর ডিভাইসটি BankID অ্যাপ খুলবে এবং প্রমাণীকরণের পরে, তাদের পরিবর্তে আমি প্রমাণীকৃত হব।

আমি এটি করতে সক্ষম হয়েছিলাম কারণ:

• RPs শংসাপত্রের নীতিগুলি BankID-তে পাঠায়নি, যার ফলে আমার পক্ষে একটি গভীর লিঙ্ক আনা এবং এটি একটি মোবাইল BankID অ্যাপে রিলে করা সম্ভব হয়েছে

• RPs প্রমাণীকরণ সম্পন্ন করা আইপি ঠিকানার সাথে লিঙ্কের অনুরোধ করা আইপি ঠিকানার তুলনা করেনি

• "অন্য ডিভাইসে প্রমাণীকরণ" বিকল্পটি বেছে নেওয়ার পরেও RPs লিঙ্কটি প্রদান করে

  
  

যা সেশন ফিক্সেশন দুর্বলতার দিকে পরিচালিত করে।

আক্রমণ

আসুন কল্পনা করি AmazingSevice AB নামক একটি দুর্বল পরিষেবা, তারা প্রদত্ত নমুনা কোড অনুসরণ করে BankID ফ্লো বাস্তবায়ন করেছে এবং https://amazingservice.se/login/bankid এ এই ধরনের বাস্তবায়ন হোস্ট করছে।

একজন হুমকি অভিনেতা AmazingSevice AB-তে সংরক্ষিত ব্যবহারকারীর ডেটাতে আগ্রহী এবং তার শিকারকে দেখা যায়। তাকে bankid:/// লিংক গ্র্যাবিং স্বয়ংক্রিয় করতে হবে, এটি তার সার্ভারে হোস্ট করতে হবে এবং তারপর তার ক্ষতিগ্রস্থদের কাছে তার ক্ষতিকারক সার্ভারে লিঙ্কটি পাঠাতে হবে। পছন্দের ফিশিং ডেলিভারি (এসএমএস, ইমেল, ইত্যাদি) বেছে নেওয়ার পরে তিনি অ্যামেজিংসেভিস এবি হিসাবে বার্তায় লিঙ্কটি এম্বেড করবেন এবং ভিকটিমকে লগ ইন করার জন্য অনুরোধ করবেন।

এই ধরনের অ্যাকাউন্ট টেকওভারে খুব কম সোশ্যাল ইঞ্জিনিয়ারিং জড়িত কারণ একবার ভুক্তভোগী লিঙ্কটিতে ক্লিক করলে, তাকে অবিলম্বে ব্যাঙ্কআইডি খুলতে বলা হয়, আক্রমণকারীর সাইটের "অজানা অঞ্চল" ছেড়ে অনেক বেশি পরিচিত ইন্টারফেস, BankID এর জন্য। উপরন্তু, ব্যাঙ্কআইডি অ্যাপ্লিকেশনে ভিকটিম যে প্রমাণীকরণের অনুরোধটি দেখতে পাবে তা AmazingSevice AB দ্বারা অনুরোধ করা হয়েছে, যা প্রতারণামূলক আচরণ সনাক্ত করা অসম্ভব করে তোলে।

একবার ভিকটিম প্রমাণীকরণ করলে, আক্রমণকারীর সেশন শিকারের অ্যাকাউন্টে প্রমাণীকরণ করা হয়, ব্যাঙ্কআইডি-তে উপস্থিত ওপেন রিডাইরেক্ট দুর্বলতাকে কাজে লাগিয়ে ভিকটিমকে আরও বোকা বানানো যেতে পারে, আক্রমণকারীকে redirect পরামিতিটিকে https://amazingservice.se/login/bankid হিসাবে নির্দিষ্ট করার অনুমতি দেয়। https://amazingservice.se/login/bankid এটি শিকারকে বৈধ পরিষেবার ওয়েবসাইটে পুনঃনির্দেশিত করতে পরিচালিত করবে, তাকে কেবলমাত্র প্রমাণীকরণটি সফল হয়নি ভেবে রেখে যাবে।

ডেমো

সুস্পষ্ট কারণে আমি যে কোম্পানির কাছে রিপোর্ট করেছি তার একটি ব্যবহার করতে পারিনি, তাই এর পরিবর্তে ডেমো দেখায় যে BankID এর ডেমো পরিষেবা এটির জন্য দুর্বল!

ডান কোণে ভিকটিম থেকে লিঙ্কটি প্রাপ্তির ভিউ রয়েছে, এখানে আক্রমণকারীর ওয়েবসাইট পরিদর্শন করে সিমুলেট করা হয়েছে। একবার ভিকটিম লিংকটি ভিজিট করলে, আক্রমণকারীর সার্ভার হেডলেস ব্রাউজারটি খোলে এবং bankid:/// লিঙ্কটি বের করে যা তারপর শিকারের ফোনে রিলে করা হয়। BankID-এর অ্যাপে, আপনি "Test av BankID" দেখতে পারেন যা BankID-এর ডেমো সাইটের বৈধ উৎস। অতিরিক্তভাবে, ভিডিওর শুরুতে, প্রমাণীকরণের সময় কোনও আইপি ঠিকানা চেক করা হচ্ছে না তা দেখতে একটি ভিপিএন চালু করা হয়েছে। শেষ পর্যন্ত, এটি দেখা যায় যে আক্রমণকারীর ল্যাপটপে, সে শিকার হিসাবে লগ ইন করেছে (জোহান জোহানসন)।

প্রভাব

সেশন ফিক্সেশন বাগ যেকোন অ্যাপ্লিকেশনে 1-ক্লিক অ্যাকাউন্ট টেকওভারের দিকে নিয়ে যায় যেটি একটি প্রমাণীকরণ প্রদানকারী হিসাবে সুইডিশ BankID ব্যবহার করে এবং ভুলভাবে (বা একেবারেই নয়) শংসাপত্র নীতিগুলি এবং ipAddress চেকগুলি প্রয়োগ করেছে৷ এটি বেশ গুরুতর কারণ প্রায়শই যে পরিষেবাগুলি তাদের ব্যবহারকারীদের প্রমাণীকরণের জন্য BankID ব্যবহার করে তাদের বেশ সংবেদনশীল ডেটা এবং অ্যাকশনগুলিতে অ্যাক্সেস থাকে। 30 টিরও বেশি অ্যাপ্লিকেশন এই আক্রমণের জন্য ঝুঁকিপূর্ণ পাওয়া গেছে, যতটা সম্ভব অনেকের সাথে যোগাযোগ করা হয়েছে যার ফলে প্রধান প্ল্যাটফর্ম জুড়ে 11টি বাগ বাউন্টি রিপোর্ট গ্রহণ করা হয়েছে।

সমস্যাটি কতটা বিস্তৃত এবং গুরুতর হওয়ার কারণে আমি যে পরিষেবাগুলির মধ্যে এই দুর্বলতার কথা জানিয়েছি তার মধ্যে একটি আমাকে সুইডেনের জাতীয় CSIRT-এর সাথে যোগাযোগ করতে সক্ষম করেছে। কথাবার্তা সবে শুরু হয়েছে তাই আপনি যদি আপডেট হতে চান তাহলে আমাকে টুইটারে অনুসরণ করুন (X) @m4st3rspl1nt3r

প্রতিকার

আপনি যদি একটি সুরক্ষিত BankID RP API বাস্তবায়ন কেমন হয় তার উদাহরণ খুঁজছেন, আমি এমন একটি তৈরি করেছি যা আপনি একটি গোলং লাইব্রেরি হিসাবে ব্যবহার করতে পারেন বা একটি মাইক্রোসার্ভিস হিসাবে কাস্টমাইজ এবং স্থাপন করতে পারেন। আপনি এখানে যে খুঁজে পেতে পারেন ।

BankID এর প্রতিক্রিয়া

বেশিরভাগ ক্ষতিগ্রস্ত পরিষেবা, বিশেষ করে BBPs এবং VDP-এর সাথে, আমার রিপোর্টে সাড়া দেওয়ার ক্ষেত্রে বেশ গ্রহণযোগ্য এবং দ্রুত ছিল। তবে, BankID এর প্রতিক্রিয়া একটু ভিন্ন ছিল। বিভিন্ন চ্যানেলের মাধ্যমে একাধিকবার তাদের সাথে যোগাযোগ করার পরে আমি একটি ইমেল পেয়েছি, তারা ব্যাখ্যা করেছে যে তারা সমস্যাটি সম্পর্কে সচেতন কিন্তু তারা মনে করেছে যে RP-এর জন্য "একীকরণের সহজতা" রাখার জন্য এটি সম্পর্কে খুব বেশি কিছু করা সম্ভব নয়। পরিকল্পিত প্রশমন, যা দুর্ভাগ্যবশত এখনও RPs দিকে পরিবর্তন করতে হবে, আমাকে জানানো হয়েছিল (কিন্তু কিছু কারণে তাদের ডকুমেন্টেশনে কোথাও পাওয়া যায়নি):

একটি অতিরিক্ত প্রয়োজনীয়তা RP সেট করতে সক্ষম হবে তা হল ঝুঁকি। এটি লেনদেনের জন্য গ্রহণযোগ্য ঝুঁকির স্তর নির্ধারণ করবে। যদি লেনদেনের ঝুঁকি প্রয়োজনীয় সীমার চেয়ে বেশি হয় তবে লেনদেনটি "নিম্ন" অবরুদ্ধ করা হবে - শুধুমাত্র কম ঝুঁকির আদেশ "মধ্যম" গ্রহণ করুন - যদি এটি সেট করা থাকে তবে নিম্ন এবং মাঝারি ঝুঁকির আদেশগুলি গ্রহণ করুন৷ আমরা অন্যান্য জিনিসগুলির মধ্যে আমাদের পক্ষে আইপি-চেক সম্পাদন করব যদি এটি RP দ্বারা সরবরাহ করা হয়। রেফারিংডোমেন, ইউজার এজেন্ট এবং ডিভাইস আইডেন্টিফায়ার প্রদান করা হলে অন্যান্য ঝুঁকির পরামিতি ঝুঁকি পর্যবেক্ষণ করা হবে।

উপরন্তু, ওপেন রিডাইরেক্ট দুর্বলতা ঠিক করার একটি পরিকল্পনাও রয়েছে।

এই বিষয়ে আমার ব্যক্তিগত মতামত হল যে আপনি যদি এমন একটি সমালোচনামূলক এবং অত্যন্ত গৃহীত প্রমাণীকরণ প্রদানকারী তৈরি করেন এবং পরিচালনা করেন, যা প্রায়শই খুব সংবেদনশীল ব্যবহারকারীর তথ্য রক্ষা করার জন্য ব্যবহৃত হয়, তাহলে আপনার নিরাপত্তা ব্যবস্থা সঠিকভাবে নথিভুক্ত করা উচিত যাতে RPs নিরাপদে এটিকে সংহত করতে পারে। ঐচ্ছিক সুরক্ষা বৈশিষ্ট্যগুলি সম্পূর্ণরূপে অকেজো, যদি একজন বিকাশকারী নির্দিষ্ট বৈশিষ্ট্য/পরামিতাগুলি বাস্তবায়ন না করে সময় বাঁচাতে পারে তবে যা ঘটবে এবং আমরা RP পক্ষকে দোষ দিতে পারি না। "একীকরণের সহজতা" বজায় রাখতে ব্যাঙ্কআইডি-র যথাসাধ্য চেষ্টা করা উচিত তাদের পক্ষে যতগুলি অ্যান্টি-ফ্রাড এবং সুরক্ষা বৈশিষ্ট্যগুলি নিয়ে যাওয়া, তবে RP-এর বাস্তবায়নের জন্য প্রয়োজনীয় অতিরিক্ত সুরক্ষা বৈশিষ্ট্যগুলি যথাযথভাবে নথিভুক্ত করাও নিশ্চিত করা উচিত; প্রয়োজনের উপর নোট ঐচ্ছিক নয়।

পাবলিক বিপদে প্রাইভেট কোম্পানি

আমার কাছে, এই দুর্বলতা একটি উদাহরণ যা একটি প্রাইভেট কোম্পানিকে একটি দেশের জনসংখ্যার জন্য গুরুত্বপূর্ণ এমন একটি সিস্টেমের সম্পূর্ণ নিয়ন্ত্রণে থাকতে দেওয়ার বিপদগুলি দেখায়। আমি বিশ্বাস করি যে এটি একটি সফ্টওয়্যার কোম্পানীর অন্য একটি দুর্বলতার চেয়ে গুরুতর কারণ হল BankID এমন একটি জিনিস যা 8.5 মিলিয়নেরও বেশি সুইডিশ বাসিন্দাদের দ্বারা ব্যবহৃত হয়, এটি আপনার ব্যাঙ্ক, বীমা প্রদানকারী, বিদ্যুৎ প্রদানকারী এবং অন্যান্য সংবেদনশীল প্ল্যাটফর্মগুলিতে লগ ইন করতে ব্যবহৃত হয়। বাস্তব বিশ্বের পরিণতি আছে.

যদি কেউ Facebook-এ একটি অ্যাকাউন্ট টেকওভার খুঁজে পায়, তাহলে আপনি কিছু ছবি হারিয়ে ফেলতে পারেন, যদি কেউ আপনার দেশের eID প্রদানকারীতে (প্রায়শই ব্যক্তিগত) একটি ভলন খুঁজে পান, তাহলে কারো জীবনের উপর এর প্রভাব অকল্পনীয় হতে পারে।

আরও বেশি করে ইউরোপীয় দেশগুলি ইআইডি গ্রহণ করছে এবং ইইউ আগামী বছরগুলিতে তাদের নিজস্ব একটি ইইউ ইআইডি চালু করার পরিকল্পনা করছে (আপনি এখানে এই সম্পর্কে আরও পড়তে পারেন)।

আমার আশা হল যে নিয়ন্ত্রকগণ eID প্রদানকারীকে সম্পূর্ণরূপে বিকশিত এবং পাবলিক প্রতিষ্ঠানের দ্বারা নিয়ন্ত্রিত করার জন্য চাপ দেবেন, সম্ভবত এই ধরনের সিস্টেমগুলিকে ওপেন সোর্স হতে হবে এবং নিরাপত্তা ত্রুটির জন্য নিয়মিত অডিট করতে হবে।

আমরা কিভাবে নিরাপদে আমাদের সমাজে সফ্টওয়্যারের এই ধরনের সমালোচনামূলক টুকরা গ্রহণ করতে পারি যদি সেগুলি একটি প্রাইভেট কোম্পানি দ্বারা তৈরি করা হয়?

আরও গবেষণা

যদিও এই ব্লগ পোস্টের মূল বিষয় ছিল BankID-তে সেশন ফিক্সেশন আক্রমণ, আমি দেখেছি যে অন্যান্য অনেক প্রমাণীকরণ/পরিচয় প্রদানকারী একই ত্রুটির সাথে ডিজাইন করা হয়েছে। প্রমাণীকরণ প্রবাহ সম্পূর্ণ করতে অন্য ডিভাইস (প্রায়শই একটি মোবাইল ফোন) ব্যবহার করার প্রয়োজন হয় এমন সরবরাহকারীদের মধ্যে একটি নতুন দুর্বলতা শ্রেণী পাওয়া যেতে পারে।

গবেষণা চলমান আছে, এবং শীঘ্রই আমি আশা করি যে আমার আরও অনুসন্ধান এবং আমি কাজ করছি এমন একটি টুল যা এই ধরনের দুর্বলতাগুলিকে স্বয়ংক্রিয় এবং শোষণ করতে ব্যবহার করা যেতে পারে। আমার পরবর্তী বিষয়ের জন্য সাথে থাকুন ডিজাইন দ্বারা সেশন ফিক্সেশন - ক্রস-ডিভাইস প্রমাণীকরণ দুঃস্বপ্ন

ততক্ষণ পর্যন্ত গ্রহকে হ্যাক!