آیا می توان از آسیب پذیری "Ghostcat" (CNVD-2020-10487 / CVE-2020-1938) به طور غیرمستقیم بیش از mod_proxy_ajp استفاده کرد؟

من در هنگام هدف قرار دادن درگاه AJP Tomcat من توانستم با موفقیت سوء استفاده از اثبات مفهوم (https://www.exploit-db.com/exploits/48143) را امتحان کنم. با این حال ، نمونه Tomcat من مستقیماً در دسترس خارجی نیست ، بلکه در پشت پروکسی معکوس آپاچی از طریق mod_proxy_ajp قرار دارد. آیا در این مورد از حملات خارجی Ghostcat در امان هستم؟

به عنوان آزمایشی برای بهره برداری غیرمستقیم ، من یک درخواست HTTP GET را ارسال کردم که هدف من از آپاچی من باشد که به پورت Tomcat AJP حمله می کند ، و سرصفحه زیر HTTP را تنظیم کردم: 19659004] req_attribute: javax.servlet.include.quest_uri = /، javax.servlet.include.path_info = WEB-INF / web.xml، javax.servlet.include.servlet_path = /

من انواع دیگری از این هدر را امتحان کردم ، مانند استفاده از نیم ستون ها به عنوان تعیین کننده به جای کاما ، و همچنین داشتن چندین هدر req_attribute برای هر کلید ، جفت ارزش در یک خط جداگانه.

خوشبختانه ، بدن پاسخ HTTP پرونده WEB-INF / web.xml من را خالی نکرد ، بنابراین این تلاشهای سوءاستفاده غیر مستقیم انجام نشد. پس از بازرسی بیشتر با tcpdump ، می بینم که این عناوین req_attribute به فرمت AJP برای استفاده از یک بایت واحد (0x0a) برای نشان دادن req_attribute رمزگذاری نمی شوند. بنابراین به نظر می رسد که سرفصل های درخواست HTTP ASCII به عناوین درخواست باینری AJP تبدیل نمی شوند. بنابراین معتقدم که آسیب پذیری از طریق درخواست های HTTP که به mod_proxy_ajp منتقل می شود ، قابل استفاده نیست ، درست است؟ یا آیا روش هوشمندانه ای برای ایجاد درخواست HTTP وجود دارد که بتواند mod_proxy_ajp را در امتداد عناوین req_attribute با فرمت باینری AJP عبور دهد تا از این آسیب پذیری غیرمستقیم استفاده کند؟