0

I'm trying to send a hash as a payload for the Safebrowsing API to detect if the file is suspicious/malicious, but i'm having trouble sending the correct payload apparently.

My payload:

curl --location --request POST 'https://safebrowsing.googleapis.com/v4/threatMatches:find?key=myKey' \
--header 'Content-Type: application/json' \
--data-raw '{
    "hash": "YzIyZDM4NDA="
}'

https://developers.google.com/safe-browsing/v4/lookup-api states the I need to use the ThreatEntry object (see screenshot below) ThreatEntry notice

And this is how the threatEntry object should look like https://developers.google.com/safe-browsing/v4/reference/rest/v4/ThreatEntry . It says I only need to use one of the options, so I went for hash as seen above in my payload, but this error is returned to me.

{
    "error": {
        "code": 400,
        "message": "Invalid JSON payload received. Unknown name \"hash\": Cannot find field.",
        "status": "INVALID_ARGUMENT",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.BadRequest",
                "fieldViolations": [
                    {
                        "description": "Invalid JSON payload received. Unknown name \"hash\": Cannot find field."
                    }
                ]
            }
        ]
    }
}

What am I doing wrong?

Phillip
  • 49
  • 1
  • 9

1 Answers1

0

Per the Safe Browsing API v4, you are missing some values to allow this to work. Also You need to better understand the different threat entries.

API DOCUMENTATION: https://developers.google.com/safe-browsing/v4/reference/rest

API ENDPOINT: POST https://safebrowsing.googleapis.com/v4/threatMatches:find?key=YOURKEYHERE

HEADERS: Content-Type: application/json

BODY:

{
    "client": {
        "clientId": "NothingTooSeeHereInc",
        "clientVersion": "1.5.2"
    },
    "threatInfo": {
        "threatTypes": [
            "MALWARE",
            "SOCIAL_ENGINEERING",
            "THREAT_TYPE_UNSPECIFIED",
            "UNWANTED_SOFTWARE",
            "POTENTIALLY_HARMFUL_APPLICATION"
        ],
        "platformTypes": [
            "ANY_PLATFORM"
        ],
        "threatEntryTypes": [
            "EXECUTABLE"
        ],
        "threatEntries": [
            {
                "digest": "OTAwMTU2N2UyMDI1ZjgzYzkzNmI4NzQ2ZmQzYjAxZTQ0NTcyZjcwZDhkZGVjMzliNzViOTQ1OWY3ZTUwODljOA=="
            }
        ]
    }
}

REASONING: In your code you attempted to just pass a hash in a hash field in json. The API requires proper structure for the request to be processed. In your example you wanted to pass a base 64 encoded hash for a malicious file. To perform that action referring to my example below you can see that you need to pass a client object and a threatInfo object. Within the threatInfo object you need the threatTypes, platformTypes, threatEntryTypes, and threatEntries. In your example even if you had the proper structure like my example above your entry would have still failed because you attempted to pass an executable digest as a hash type. I attached the API reference link. Hope this helps. PS: You will only return a non empty dataset if there is a match.

Cheers.

Dave
  • 602
  • 5
  • 18
  • Thank you. I eventually managed to figure it out and used an identical payload as you've shown, but my next issue is that the browsers flag a file but the API never does - which is bugging my head. Either way you provided me with the correct answer, so the bounty will of course be awarded to you. Very keen to know if you know more about the API and browser response to a file that doesn't match. – Phillip Feb 18 '22 at 18:22
  • Great to hear! As for your issue with the API never flagging a particular file, are you running it against all threat types, platform types, and operating systems? – Dave Feb 18 '22 at 21:22
  • Yes, `ANY_PLATFORM` and all threat types. Empty result is returned from the safebrowsing API. I'm wondering if it's something in the way I hash things? I ran `shasum -a 256 -b mybinary.msi` and base64 encoded the output and sent it to the safebrowsing API as a `digest` . Do you see any particular issue with this? – Phillip Feb 18 '22 at 21:37