stealth/pscتشفير E2E لجلسات tty متعددة القفزات أو portshells + إعادة توجيه منافذ TCP/UDP
هذا المشروع - بالإضافة إلى مشروعه الشقيق crash - هو جزء من مجموعتي الأدوات لمكافحة الرقابة والتي تسمح بإعداد شل مشفرة بالكامل وتمرير TCP/UDP في بيئات خاضعة للرقابة العدائية. كما أنه مفيد في التحقيق الجنائي الرقمي لتفريغ البيانات من الأجهزة عبر UART أو adb عندما لا تتوفر وسائل أخرى.
تمرير بحث DNS وجلسة SSH عبر اتصال UART إلى Raspberry Pi
يسمح PSC بتشفير جلسات الشل من طرف إلى طرف (e2e)، عبر قفزة واحدة أو عدة قفزات، بغض النظر عن وسيلة النقل الأساسية، طالما أنها موثوقة ويمكنها إرسال/استقبال بيانات مشفرة بـ Base64 دون تعديل/تصفية. إلى جانب وحدة pty من طرف إلى طرف التي تحصل عليها (مثلاً داخل منفذ شل)، يمكنك تمرير اتصالات TCP و UDP، على غرار معامل -L في OpenSSH. يعمل هذا بشفافية دون الحاجة إلى عنوان IP مخصص محلياً عند نقطة البداية. يتيح ذلك لمحققي الأدلة الجنائية ومختبرّي الاختراق إنشاء اتصالات شبكية عبر سبيل المثال من خلال:
adb shell، إذا كان adbd من OEM لا يدعم تمرير TCPتخيل فقط أن لديك جلسة ppp غير مرئية داخل جلسة الشل الخاصة بك، دون أن يدعم الطرف البعيد ppp فعلياً.
يعمل على Linux، Android، OSX، Windows، FreeBSD، NetBSD و(ربما) OpenBSD.
يتضمن PSC أيضاً دعم وكيل SOCKS4 و SOCKS5 لإجراء جلسات تصفح ويب فعلية عبر منافذ الشل أو اتصالات المودم عن بُعد.
قم بتعديل ملف Makefile ليعكس مفاتيحك المشتركة مسبقاً (pre shared keys)، كما هو محدد في بداية ملف Makefile.
ثم اكتب make على Linux و OSX.
على BSD تحتاج إلى تثبيت GNU make واستخدام gmake بدلاً من ذلك.
على Windows تحتاج إلى تثبيت cygwin واختيار الحزم المناسبة gcc, gcc-g++, make و git.
على Linux، سيستخدم PSC أطرافاً زائفة من نوع Unix98، بينما على الأنظمة الأخرى سيستخدم أطرافاً زائفة من نوع POSIX ولكن ذلك سيكون شفافاً بالنسبة لك. لقد أضفت دعماً لأطراف 4.4BSD و SunOS في العصر الحجري لسبب معين، لذا فقد ينجح البناء أو لا حتى مع Solaris.
برعاية فخورة من:
بسيط ومباشر. على جهازك المحلي، قم بتشغيل pscl، ومرر أي منافذ TCP أو UDP التي ترغب في تمريرها من الموقع البعيد إلى عنوان معين. على سبيل المثال:
linux:~ > ./pscl -T 1234:[192.168.0.254]:22 -U 1234:[8.8.8.8]:53
PortShellCrypter [pscl] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: set up local TCP port 1234 to proxy to 192.168.0.254:22 @ remote.
pscl: set up local UDP port 1234 to proxy to 8.8.8.8:53 @ remote.
pscl: Waiting for [pscr] session to appear ...
linux:~ >
[ UART / SSH / ... login to remote side ... ]
على الموقع البعيد (القفزة الأخيرة) مع جلسة الشل، بغض النظر عما إذا كانت في منفذ شل، SSH، تسجيل دخول طرفية، إلخ، قم بتنفيذ pscr:
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Seen STARTTLS sequence, enabling crypto.
linux:~ >
بمجرد تنفيذ pscr، يقوم كلا الطرفين بإجراء مصافحة تشفير ووضع بروتوكول إضافي فوق جلستك الحالية يكون شفافاً بالنسبة لك. يمكنك بعد ذلك الاتصال بـ 127.0.0.1:1234 على جهازك المحلي للوصول إلى 192.168.0.254:22 عبر TCP أو إلى المحلل 8.8.8.8 عبر UDP. يعمل هذا أيضاً مع عناوين [IPv6]، إذا كان الموقع البعيد يدعم الاتصال بـ IPv6. في الواقع، يمكنك حتى استخدامه لترجمة برامج IPv4 إلى IPv6، لأنك تتصل دائماً بـ 127.0.0.1 على الجانب المحلي.
يمكنك تمرير عدة معاملات -T و -U. إذا فقدت تتبع ما إذا كانت جلستك مشفرة بالفعل من طرف إلى طرف، يمكنك إرسال إشارة SIGUSR1 إلى عملية pscl المحلية، وستخبرك بذلك.
PSC مفيد أيضاً إذا كنت ترغب في استخدام tor من قذيفة SSH بعيدة، حيث يمكنك تمرير منفذ socks5 ومنفذ DNS إلى عنوان 127.0.0.1 للمضيف البعيد. نظراً لأن SSH لا يقوم بتمرير حزم UDP، فعادة ما تستخدم موصلي socat أو ما شابه ذلك للتحليل عبر عقدة tor. يتمتع PSC بميزة الحفاظ على حدود حزم UDP، بينما قد يؤدي socat عبر SSH -L إلى كسر حدود الحزم وإنشاء طلبات DNS غير صالحة.
سيتم تشفير الجلسة باستخدام aes_256_ctr من مفتاح مشترك مسبق (PSK) تختاره في ملف Makefile. هذا المخطط التشفيري قابل للتشكيل، لكن إضافة بيانات AAD أو OAD يؤدي إلى تضخيم حجم الحزمة، حيث أن كل بايت مهم نظراً لأن كل حرف مكتوب في الجلسات التفاعلية وبسبب تشفير Base64 يسبب إرسال المزيد من البيانات.
يمكن استخدام جلسات UART عبر screen ولكن ليس عبر minicom على سبيل المثال لأن minicom ينشئ نوافذ غير مرئية مع خطوط حالة ويتصرف كمرشح يدمر بروتوكول PSC. يحاول PSC اكتشاف التصفية ويمكنه التعامل مع قدر معين من تشويه البيانات، لكن في بعض الحالات لا يمكن استردادها. شيء مماثل مع tmux. يجب تجنب تكديس معالجات pty مع PSC التي تعبث/تتعامل مع بياناتها الواردة كثيراً.
يجب تعيين متغير البيئة SHELL لكل من pscl و pscr لكي يعرف PSC أي شل ينفذه على pty. يتم تعيين SHELL في معظم البيئات بشكل افتراضي، ولكن في حالة عدم تعيينه، يجب تشغيل PSC مثل SHELL=/bin/bash pscl إلخ.
يدعم pscl أيضاً تمرير اتصالات TCP عبر SOCKS4 (باستخدام -4 port) و SOCKS5 (باستخدام -5 port). يقوم هذا بإعداد port كمنفذ SOCKS لاتصالات TCP، لذا يمكنك مثلاً تصفح الشبكات البعيدة من جلسة منفذ شل دون الحاجة إلى فتح أي اتصال آخر أثناء الاختبار. إذا قمت بتمرير -N إلى pscl، فإنه يقوم بتمكين تحليل اسم DNS على الجانب البعيد، لذا يمكنك أيضاً استخدام chrome معه. لكن كن محذراً: هناك مشكلة خصوصية مع المتصفحات التي تحاول تحليل سلسلة من أسماء DNS عند بدء التشغيل خارج نطاق سيطرتك. أيضاً، إذا كان الجانب البعيد لديه إعداد DNS معطل، فقد تتعطل شل الكتابة لديك لعدة ثوانٍ إذا كانت حزم استجابة DNS مفقودة. لا توجد دوال تحليل غير متزامنة جيدة قابلة للتضمين والنقل لذا اضطررت للاعتماد على getaddrinfo() في الخيط الواحد على حساب احتمالية التعطل لعدة ثوانٍ إذا كانت هناك مشاكل في DNS. لذلك يجب تمكين تحليل الأسماء بشكل صريح. يحاول pscr تقليل هذه المشكلة المحتملة من خلال ذاكرة تخزين مؤقت لاستعلامات DNS، لذا في معظم الحالات يجب أن يعمل دون ألم.
إذا قمت بتمرير -X IP-address (يجب أن تكون الوسيطة الأولى)، يمكنك ربط وكيلك المحلي بعنوان مختلف عن 127.0.0.1، لذا يمكنك مشاركة الوكيل في شبكتك المحلية.
تتيح ميزات psc إمكانية تمرير اتصالات TCP أو كتل البيانات الثنائية من/إلى الأجهزة البعيدة عبر قفزات متعددة حتى لو لم يكن من الممكن تثبيت الثنائي pscr على الموقع البعيد. هذا مفيد جداً لأغراض التحليل الجنائي إذا لم يكن لديك أي وسيلة لتنزيل القطع الأثرية من الجهاز (والذي يمكن أن يكون هاتفاً متصلاً بـ UART مثلاً) أو تحتاج إلى تمرير الاتصالات دون لمس نظام الملفات لعدم إتلاف الأدلة على النظام أو عندما يكون نظام الملفات الجذر مثبتاً للقراءة فقط ولا يمكنك تحميل مجموعة أدواتك.
هذه ميزة رائعة حقاً، حيث يمكنك رؤية اتصال TCP الخاص بك يقفز عبر tty المحلي إلى جهاز بعيد دون الحاجة إلى تثبيت أي شيء عن بُعد.
يعمل هذا فقط عن طريق punkrock pty محلي وتسليم أمر ارتداد إلى pscl الذي سيقوم بإسقاطه على القشرة البعيدة (دون تشغيل pscr) وبعض سحر محرك الحالة الذي يقوم بتصفية ومعالجة البيانات على الجانب المحلي. عادةً ما يتطلب ذلك تعيين pty البعيد إلى الوضع الخام أولاً قبل إصدار الأمر الفعلي وبعض التفاصيل الأخرى التي يتم تمريرها إلى -B. يتم تقسيم الوسيطة إلى الأجزاء التالية:
:، مثلاً 1234:.stty -echo raw أو
python -c "import tty;tty.setraw(0)" (احذر من علامات التنصيص، حيث أن -B يحتاج أيضاً
إلى أن يكون مقتبساً) أو أي شيء مماثل.pscl بالبدء في إرسال البيانات لتجنب سباق بين حدوث stty فعلياً وبدء الأمر، مثلاً جملة echo GO مثالية.nc 127.0.0.1 22 لارتداد المنفذ المحلي 1234 إلى خادم SSH البعيدpscl بإعادة تعيين حالة tty الخاصة به.
جملة echo FIN ستفعل. موصى به، وإلا فقد تواجه مشكلة في التعرف على نهاية الأمر.; ومحاطة بأقواس.أمثلة:
إذا كنت ترغب في تمرير اتصال TCP، يتطلب هذا المثال تثبيت stty و nc على الجهاز، ولكن من الناحية النظرية يمكن أن يكون أي شيء آخر يعمل بالمثل.
ابدأ جلسة محلية:
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
سيؤدي هذا إلى إصدار الأمر stty -echo raw;echo GO;nc example.com 22;echo FIN للجهاز البعيد إذا اتصلت محلياً بالمنفذ 1234 ثم يقوم فقط بتمرير أي بيانات يراها ذهاباً وإياباً مع تحديد السرعة بحيث لا تتجاوز سرعة tty للجهاز (115200 هي القيمة الافتراضية).
عند بدء جلسة pscl، اتصل بالجهاز البعيد عبر UART أو ssh -e none ... أو أياً كان، وبمجرد حصولك على قشرة بعيدة، اكتب أيضاً محلياً:
ssh [email protected] -p 1234 لارتداد اتصال SSH من جهازك المحلي عبر الجهاز البعيد إلى وجهة example.com. بالطبع يُفضل استخدام متغير pscr لأن -B يمكنه فقط ارتداد اتصال واحد في كل مرة (على الرغم من أنه يمكنك تمرير عدة أوامر -B لأجهزة إرسال مختلفة) وهناك احتمال لتعليق القشرة بعد جلسة TCP نظراً لأن pty في وضع raw -echo واعتماداً على ما إذا كان الطرف البعيد النهائي سيغلق الاتصال أيضاً، فقد تظل القشرة معلقة بعد ذلك. إذا صادفت إشعار pscl بأن الاتصال قد انتهى ورأيت مطالبة، يجب إعادة تعيينها (reset) حتى يمكن بدء اتصال جديد. أثناء تمرير البيانات، سترى إشعارات ASCII 7 بت < و > في pscl وهي محلية فقط لتسهيل التصحيح واكتشاف التقدم.
لاحظ أن الاتصال بالموقع البعيد يجب أن يكون نظيفاً (8bit clean)، أي أن قناة ssh أو telnet أو UART أو أياً كانت يجب ألا تتعامل مع تسلسلات الهروب (على عكس استخدام pscr). بالنسبة لاتصالات ssh، فهذا يعني أنه يجب عليك استخدام ssh -e none في جلسة pscl.
بعد ذلك، فيما يلي بعض الأمثلة للتعامل مع نقل الملفات الثنائية حيث يشير rfile إلى الملف البعيد و lfile إلى الملف المحلي.
لبدء جلسة لإسقاط ملفات بعيدة، محلياً:
./pscl -B '1234:[stty -echo raw;echo GO;dd of=rfile.bin bs=1 count=7350;echo FIN]'
حيث تحتاج إلى تحديد كمية البيانات التي يتوقعها الجانب البعيد. ستعمل أيضاً بدون (مثلاً cat>...) ولكن بعد ذلك ستتعطل الجلسة بعد انتهاء النقل لأن cat ينتظر الإدخال بلا نهاية. باستخدام dd count=...، ستحصل على خروج نظيف وسيتم إعلامك بذلك من خلال علامة FIN.
ثم، ssh أو أياً كان ضرورياً للحصول على قشرة على الجهاز البعيد من داخل جلسة pscl التي بدأت للتو. على طرفية ثانية محلياً:
dd if=lfile.bin|nc 127.0.0.1 1234
والذي سيتصل بالمنفذ المحلي 1234 لـ pscl ويقوم بتشغيل أمر التفريغ على الجانب البعيد، وتمرير البيانات الثنائية من الملف المحلي lfile.bin إلى الملف البعيد rfile.bin. نظراً لتحديد السرعة، قد يستغرق هذا بعض الوقت وأنت تثق فقط في شاشة تقدم psc لمعرفة ما إذا كان النقل قد اكتمل. سيظهر لك الأمر المحلي dd ...|nc ... الحالة المحلية فقط والتي يمكنها استيعاب ملفات كاملة بالميلي ثانية بسبب المخازن المؤقتة لـ TCP المحلية بينما لا يزال الملف قيد النقل عبر pty. لذا تأكد من الضغط على Ctrl-C فقط عندما تخبرك شاشة pscl بأنه قد اكتمل أو ترى علامة النهاية FIN تُعاد إليك في جلسة dd ...|nc ....
وبالمثل، يمكن استخدام أوامر مماثلة لنقل البيانات الثنائية من جهاز بعيد إلى الجهاز المحلي لأغراض التحليل الجنائي. مرة أخرى، بدء الجلسة محلياً:
./pscl -B '1234:[stty -echo raw;echo GO;dd if=rfile.bin]' أو
./pscl -B '1234:[stty -echo raw;echo GO;cat rfile.bin]'
ثم، ssh للجهاز البعيد للحصول على القشرة، ثم مرة أخرى محلياً:
nc 127.0.0.1 1234|dd of=lfile.bin bs=1 count=7350
للحصول على rfile.bin بحجم 7350 منسوخاً إلى الملف المحلي lfile.bin
إذا لم يكن stty -echo raw متاحاً على الجهاز، فإن شيئاً مثل
python -c "import tty;tty.setraw(0)" يعمل أيضاً. لاحظ أنه على الجهاز البعيد يجب أن يكون لديك tty (وليس مجرد منفذ شل) عند استخدام أوامر الارتداد، لأن أمر stty لتعيين الوضع الخام يتطلب tty حقيقياً.
إذا كان psc يعمل عبر اتصال تسلسلي، فإن البتات المفقودة يمكن أن تقضي على كل المتعة. إذا كنت تعمل بدون HW FC (التحكم في التدفق المادي) فسوف تواجه في النهاية فقدان بت واتصالات معلقة، خاصة عند عدم وجود تحديد للسرعة عندما يرسل الجهاز البيانات في اتجاهك عند استخدام أوامر الارتداد. يعمل تفريغ البيانات إلى الجهاز بشكل أفضل حيث تمر هذه البيانات عبر حدود السرعة لـ pscl.
ومع ذلك، إليك بعض النصائح التي نجحت معي في الظروف التي لا يمكن فيها استخدام pscr على الجهاز و HW FC. ينطبق هذا فقط عند استخدام UARTs، لأنها قناة نقل غير موثوقة محتملة.
pscr على الجهاز حتى تتمكن من تعيين تحديد السرعة للبيانات المرسلة في اتجاهك.
نظراً لأن الاتجاه نحو الجهاز محدد السرعة دائماً، يمكنك استخدام أوامر الارتداد لتفريغ ثنائي pscr مترجم عبر التجميع إلى الجهاز وبدء جلسة محددة السرعة ثنائية الاتجاه معه.tio -o 1 أو -o 2 لإضافة تأخيرات بين وحدات الإخراج المرسلة38400 على الرغم من أن الخط التسلسلي مضبوط على 115200)psc مع -DRESPECT_UART_BUFSIZE=4096، ومع ذلك سيجعل هذا الجلسة بطيئة جداًداخل مجلد contrib ستجد أيضاً تصحيح tio-noprefix لتعطيل معالجة أحرف الهروب، لكن هذا التصحيح ضروري فقط للإصدارات الأقدم، حيث أن upstream قد قبل ودمج هذا التصحيح بالفعل. أوصي بشدة باستخدام tio عند استخدام UARTs.
عند استخدام أوامر الارتداد عبر tio، يجب إضافة ما يلي إلى ملف ~/.tioconfig:
[default]
prefix-ctrl-key = none
والذي يعطل معالجة ESC ويعطيك قناة نظيفة (8bit clean).
يمكنك إرسال SIGUSR1 إلى pscl ليخبرك ما إذا كانت الجلسة مشفرة. إذا مات أو خرج pscr البعيد دون إمكانية الإشارة إلى ذلك للجزء المحلي، فسيبقى pscl في وضع التشفير وبالتالي سيتعطل. في هذه الحالة يمكنك فرض إعادة تعيين إلى وضع النص العادي عن طريق إرسال SIGUSR2، بحيث يمكن بدء جلسة جديدة.
بدءاً من الإصدار 0.64، يدعم psc مقابس النصوص البرمجية (scripting-sockets) بحيث لم تعد بحاجة إلى screen لجلب/وضع الملفات أو تفريغ محتويات الحافظة إلى وحدة التحكم البعيدة. بدلاً من ذلك، تبدأ جلستك المحلية كالتالي:
~ > ./pscl -S ~/psc.script_sock
يمكنك بعد ذلك المتابعة واستخدامها كما في السابق. إذا كنت بحاجة إلى 'لصق' شيء ما، فافعل الآتي:
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
سيؤدي هذا إلى 'كتابة' محتوى script_/helloworld في وحدة التحكم. أثناء النصوص البرمجية، يتم حظر الإدخال القياسي لـ pscl بحيث لا يختلط الإدخال المحقون مع أي كتابة. إذا تم حذف -S في pscsh، فسيتم استخدام ~/psc.script_sock تلقائياً. لأسباب أمنية، يجب أن تبدأ النصوص بالبادئة script_.
كمكافأة، يحتوي pscr الآن على القدرة على ترميز/فك ترميز الملفات بـ Base64، حتى مع الأحرف المضمنة مثل CR لتسهيل الاستخدام. وهو متوافق مع uuencode -m.