DETECTION OF MALICIOUS INVOCATION OF APPLICATION PROGRAM INTERFACE CALLS

• US 20160371484A1
• Filed: 01/22/2015
• Published: 12/22/2016
• Est. Priority Date: 01/22/2015
• Status: Active Grant

• Current Assignee: McAfee, LLC
• Original Assignee: McAfee, Inc. (McAfee, LLC)
• Inventors: Bhattacharjee, Rajbir, Mehta, Kunal, Singh, Balbir
• Granted Patent: US 10,339,303 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 21/52 during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
• CPC Class Codes: G06F 21/54 by adding security routines or objects to programs
• CPC Class Codes: G06F 2221/033 Test or assess software

Abstract

Particular embodiments described herein provide for an electronic device that includes a binder kernel driver. The binder kernel driver can be configured to receive an application program interface (API) call, extract metadata from the API call, determine that the API call should be hooked based on the extracted metadata, and hook the API call.

Claims

1. At least one computer-readable medium comprising one or more instructions that when executed by at least one processor, cause the process to:

receive an application program interface (API) call at a kernel driver;

extract metadata from the API call;

determine that the API call should be hooked based on the extracted metadata; and

hook the API call.

2. The at least one computer-readable medium of claim 1, wherein the kernel driver is a binder kernel driver.

3. The at least one computer-readable medium of claim 2, wherein an interceptor in the kernel driver intercepts the API call.

4. The at least one computer-readable medium of claim 2, wherein a policy manager inside the kernel driver determines that the API call should be hooked based on the extracted metadata.

5. The at least one computer-readable medium of claim 2, wherein the extracted metadata is compared to a security policy to determine that the API call should be hooked.

6. The at least one computer-readable medium of claim 5, wherein the security policy is located in the kernel driver.

7. The at least one computer-readable medium of claim 2, further comprising one or more instructions that when executed by the at least one processor, further cause the processor to:

communicate the API call and the extracted metadata to a security module, wherein the security module determines if the API call should be allowed or denied.

8. The at least one computer-readable medium of claim 7, further comprising one or more instructions that when executed by the at least one processor, further cause the processor to:

allow the API call if a response from the security module is not received after a predetermined amount of time has passed from when the API call and the extracted metadata was communicated to the security module.

9. An apparatus comprising:

a kernel driver, wherein the kernel driver is configured to;

receive an application program interface (API) call;

extract metadata from the API call;

determine that the API call should be hooked based on the extracted metadata; and

hook the API call.

10. The apparatus of claim 9, wherein the kernel driver is a binder kernel driver.

11. The apparatus of claim 10, wherein an interceptor in the kernel driver intercepts the API call.

12. The apparatus of claim 10, wherein a policy manager inside the kernel driver determines that the API call should be hooked based on the extracted metadata.

13. The apparatus of claim 10, wherein the extracted metadata is compared to a security policy to determine that the API call should be hooked.

14. The apparatus of claim 13, wherein the security policy is located in the kernel driver.

15. The apparatus of claim 10, wherein the kernel driver is further configured to:

communicate the API call and the extracted metadata to a security module, wherein the security module determines if the API call should be allowed or denied.

16. The apparatus of claim 15, wherein the kernel driver is further configured to:

allow the API call if a response from the security module is not received after a predetermined amount of time has passed from when the API call and the extracted metadata was communicated to the security module.

17. A method comprising:

receiving an application program interface (API) call at a kernel driver;

extracting metadata from the API call;

determining that the API call should be hooked based on the extracted metadata; and

hooking the API call.

18. The method of claim 17, wherein the kernel driver is a binder kernel driver.

19. The method of claim 18, wherein an interceptor in the kernel driver intercepts the API call.

20. The method of claim 18, wherein a policy manager inside the kernel driver determines that the API call should be hooked based on the extracted metadata.

21. The method of claim 18, wherein the extracted metadata is compared to a security policy in the kernel driver to determine that the API call should be hooked.

22. The method of claim 18, further comprising:

communicating the API call and the extracted metadata to a security module, wherein the security module determines if the API call should be allowed or denied

23. The method of claim 22, further comprising:

allowing the API call if a response from the security module is not received after a predetermined amount of time has passed from when the API call and the extracted metadata was communicated to the security module.

24. A system for detecting and mitigating malicious invocation of sensitive code, the system comprising:

a binder kernel driver, wherein the binder kernel driver is configured to;

receive an application program interface (API) call;

extract metadata from the API call;

determine that the API call should be hooked based on the extracted metadata; and

hook the API call.

25. The system of claim 24, wherein a policy manager inside the binder kernel driver compares the extracted metadata to a security policy in the binder kernel driver and determines that the API call should be hooked based on the extracted metadata.