জাভাতে প্রধান ক্রিপ্টো ভুল “মানসিক কাগজ” জালিয়াতি সক্ষম করে

জাভাতে প্রধান ক্রিপ্টো ভুল

গেটি ইমেজ

ওরাকলের জাভা ফ্রেমওয়ার্কের নতুন সংস্করণ ব্যবহারকারী সংস্থাগুলি বুধবার একটি উদ্বেগজনক পরামর্শের জন্য জেগে উঠেছে: একটি গুরুতর দুর্বলতা বিরোধীদের পক্ষে TLS শংসাপত্র এবং স্বাক্ষর, দ্বি-ফ্যাক্টর প্রমাণীকরণ বার্তা এবং বহুল ব্যবহৃত খোলা একটি পরিসর দ্বারা তৈরি অনুমোদনের প্রমাণপত্র জাল করা সহজ করে তুলতে পারে মান

দুর্বলতা, যা ওরাকল মঙ্গলবার প্যাচ করেছে, কোম্পানির জাভা সংস্করণ 15 এবং তার উপরে উপবৃত্তাকার কার্ভ ডিজিটাল স্বাক্ষর অ্যালগরিদমের বাস্তবায়নকে প্রভাবিত করে। ECDSA হল একটি অ্যালগরিদম যা বার্তাগুলিকে ডিজিটালভাবে প্রমাণীকরণ করতে উপবৃত্তাকার বক্ররেখা ক্রিপ্টোগ্রাফির নীতিগুলি ব্যবহার করে। ECDSA-এর একটি প্রধান সুবিধা হল RSA বা অন্যান্য ক্রিপ্টো অ্যালগরিদমের তুলনায় এটি তৈরি করা কীগুলির ছোট আকার, এটিকে FIDO-ভিত্তিক 2FA, সিকিউরিটি অ্যাসারশন মার্কআপ ল্যাঙ্গুয়েজ, OpenID, এবং JSON সহ মানগুলিতে ব্যবহারের জন্য আদর্শ করে তোলে।

ডাক্তার কে এবং সাইকিক পেপার

নিরাপত্তা সংস্থা ForgeRock-এর গবেষক নিল ম্যাডেন, যিনি দুর্বলতা আবিষ্কার করেছিলেন, তিনি এটিকে ফাঁকা পরিচয়পত্রের সাথে তুলনা করেছেন যা সাই-ফাই শোতে নিয়মিত উপস্থিত হয় ডাক্তার কে. কার্ডগুলি যে সাইকিক কাগজ দিয়ে তৈরি করা হয় তার কারণে ব্যক্তি এটির দিকে তাকাচ্ছেন যা নায়ক তাদের দেখতে চায়।

“এটি দেখা যাচ্ছে যে জাভা-এর কিছু সাম্প্রতিক রিলিজ ব্যাপকভাবে ব্যবহৃত ECDSA স্বাক্ষর বাস্তবায়নে একই ধরনের কৌশলের জন্য ঝুঁকিপূর্ণ ছিল,” ম্যাডেন লিখেছেন। “আপনি যদি দুর্বল সংস্করণগুলির মধ্যে একটি চালান তবে আক্রমণকারী সহজেই কিছু ধরণের SSL শংসাপত্র এবং হ্যান্ডশেক (যোগাযোগের বাধা এবং পরিবর্তনের অনুমতি দেয়), স্বাক্ষরিত JWT, SAML দাবি বা OIDC আইডি টোকেন এবং এমনকি WebAuthn প্রমাণীকরণ বার্তাও জাল করতে পারে৷ সবই একটি ফাঁকা কাগজের সমতুল্য ডিজিটাল ব্যবহার করে।”

সে অবিরত রেখেছিল:

“এই বাগটির তীব্রতা বাড়াবাড়ি করা কঠিন। আপনি যদি এই নিরাপত্তা ব্যবস্থার জন্য ECDSA স্বাক্ষর ব্যবহার করেন, তাহলে একজন আক্রমণকারী তা করতে পারে তুচ্ছ এবং সম্পূর্ণরূপে তাদের বাইপাস যদি আপনার সার্ভার এপ্রিল 2022 ক্রিটিকাল প্যাচ আপডেট (CPU) এর আগে জাভা 15, 16, 17 বা 18 সংস্করণ চালায়। প্রেক্ষাপটের জন্য, বাস্তব বিশ্বের প্রায় সমস্ত WebAuthn/FIDO ডিভাইস (ইউবিকি সহ ECDSA স্বাক্ষর ব্যবহার করে এবং অনেক OIDC প্রদানকারী ECDSA- স্বাক্ষরিত JWTs ব্যবহার করে।”

CVE-2022-21449 হিসাবে ট্র্যাক করা বাগটি সম্ভাব্য 10 এর মধ্যে 7.5 এর তীব্রতার রেটিং বহন করে, কিন্তু ম্যাডেন তার মূল্যায়নের ভিত্তিতে বলেছেন, এর উপর বিস্তৃত প্রভাবের কারণে তিনি তীব্রতাকে নিখুঁত 10-এ রেট দেবেন অ্যাক্সেস ম্যানেজমেন্ট প্রসঙ্গে ভিন্ন কার্যকারিতা।” এর সবচেয়ে খারাপ আকারে, বাগটি কোনো যাচাই ছাড়াই দুর্বল নেটওয়ার্কের বাইরের কেউ ব্যবহার করতে পারে।

অন্যান্য নিরাপত্তা বিশেষজ্ঞদেরও তীব্র প্রতিক্রিয়া ছিল, একজনের সাথে এটা ঘোষণা “বছরের ক্রিপ্টো বাগ।”

একটি প্রশমিত কারণ হল জাভা সংস্করণ 15 এবং তার উপরে আগের সংস্করণগুলির মতো ব্যাপকভাবে ব্যবহৃত হয় বলে মনে হয় না। নিরাপত্তা সংস্থা Snyk থেকে ফেব্রুয়ারি এবং মার্চ 2021 সালে সংগৃহীত ডেটা দেখায় যে জাভা 15, সেই সময়ের সর্বশেষ সংস্করণ, স্থাপনার 12 শতাংশের জন্য দায়ী। যদিও ম্যাডেন বলেছেন যে নির্দিষ্ট ECDSA বাস্তবায়নে শুধুমাত্র জাভা 15 এবং উচ্চতর ত্রুটি রয়েছে, ওরাকল 7, 8 এবং 11 সংস্করণগুলিকে দুর্বল হিসাবে তালিকাভুক্ত করেছে। ম্যাডেন বলেছেন যে আগের রিলিজে স্থির করা পৃথক ক্রিপ্টো বাগগুলির কারণে এই পার্থক্য হতে পারে।

a/0 = বৈধ স্বাক্ষর

ECDSA স্বাক্ষরগুলি একটি ছদ্ম-এলোমেলো নম্বরের উপর নির্ভর করে, সাধারণত K হিসাবে উল্লেখ করা হয়, যেটি দুটি অতিরিক্ত সংখ্যা, R এবং S বের করতে ব্যবহৃত হয়। একটি স্বাক্ষরকে বৈধ হিসাবে যাচাই করতে, একটি পক্ষকে অবশ্যই R এবং S, স্বাক্ষরকারীর সর্বজনীন কী জড়িত সমীকরণটি পরীক্ষা করতে হবে, এবং বার্তাটির একটি ক্রিপ্টোগ্রাফিক হ্যাশ। সমীকরণের উভয় দিক সমান হলে, স্বাক্ষরটি বৈধ।

বুধবার প্রকাশিত একটি লেখায়, নিরাপত্তা সংস্থা সোফোস প্রক্রিয়াটি আরও ব্যাখ্যা করেছে:

S1. 1 এবং N-1 এর মধ্যে একটি ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম পূর্ণসংখ্যা K নির্বাচন করুন।
S2. উপবৃত্তাকার বক্ররেখা গুণ ব্যবহার করে K থেকে R গণনা করুন।
S3. R শূন্য হওয়ার সম্ভাবনা কম হলে, ধাপ 1 এ ফিরে যান এবং আবার শুরু করুন।
S4. K, R থেকে S কম্পিউট করুন, স্বাক্ষর করতে হবে হ্যাশ এবং ব্যক্তিগত কী।
S5. S শূন্য হওয়ার সম্ভাবনা কম হলে, ধাপ 1 এ ফিরে যান এবং আবার শুরু করুন।

প্রক্রিয়াটি সঠিকভাবে কাজ করার জন্য, R বা S উভয়ই শূন্য হতে পারে না। এর কারণ হল সমীকরণের একটি দিক হল R, এবং অন্যটি R দ্বারা গুণ করা হয় এবং S থেকে একটি মান। যদি উভয় মানই 0 হয়, তাহলে যাচাইকরণ চেক 0 = 0 X (ব্যক্তিগত কী থেকে অন্যান্য মানগুলি) অনুবাদ করে এবং হ্যাশ), যা অতিরিক্ত মান নির্বিশেষে সত্য হবে। এর মানে একটি প্রতিপক্ষকে শুধুমাত্র যাচাইকরণ চেক সফলভাবে পাস করার জন্য একটি খালি স্বাক্ষর জমা দিতে হবে।

পাগল লিখেছেন:

অনুমান করুন কোন চেক জাভা ভুলে গেছেন?

সেটা ঠিক. জাভা-এর ECDSA স্বাক্ষর যাচাইকরণের বাস্তবায়ন R বা S শূন্য ছিল কিনা তা পরীক্ষা করেনি, তাই আপনি একটি স্বাক্ষর মান তৈরি করতে পারেন যেখানে তারা উভয়ই 0 (যথাযথভাবে এনকোডেড) এবং জাভা এটিকে যেকোনো বার্তা এবং যেকোনো জনসাধারণের জন্য বৈধ স্বাক্ষর হিসাবে গ্রহণ করবে। চাবি একটি ফাঁকা আইডি কার্ডের ডিজিটাল সমতুল্য।

নীচে একটি ইন্টারেক্টিভ JShell সেশন ম্যাডেন তৈরি করা হয়েছে যা একটি বার্তা এবং সর্বজনীন কী যাচাই করার সময় একটি ফাঁকা স্বাক্ষরকে বৈধ হিসাবে গ্রহণ করে একটি দুর্বল বাস্তবায়ন দেখায়:

|  Welcome to JShell -- Version 17.0.1
|  For an introduction type: /help intro
jshell> import java.security.*
jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> [email protected]
jshell> var blankSignature = new byte[64]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update("Hello, World".getBytes())
jshell> sig.verify(blankSignature)
$8 ==> true
// Oops, that shouldn't have verified...

যে সংস্থাগুলি স্বাক্ষরগুলি যাচাই করতে Java এর যে কোনও প্রভাবিত সংস্করণ ব্যবহার করছে তাদের প্যাচিংকে উচ্চ অগ্রাধিকার দেওয়া উচিত। অ্যাপ এবং পণ্য প্রস্তুতকারকদের কাছ থেকে পরামর্শের জন্য নজরদারি করাও গুরুত্বপূর্ণ হবে যে তাদের কোন পণ্যগুলি দুর্বল করা হয়েছে কিনা। যদিও CVE-2022-21449 থেকে হুমকিটি নতুন জাভা সংস্করণের মধ্যে সীমাবদ্ধ বলে মনে হচ্ছে, এর তীব্রতা সতর্কতা নিশ্চিত করার জন্য যথেষ্ট।

Related Posts