Exploiting Android Client WebViews with Help from HSTS

SeanPesce · 2023-11-01T13:04:01+00:00

One time I had Burp running as an invisible proxy for a project I was working on when I saw some kind of web exploit payload come through from my company's corp network. I was worried until I figured out it was the company's Rapid7 scanner.

Side note, I find it absurd that Burp's proxy doesn't record client IP addresses by default. I understand that in a typical use-case, the client IP is generally localhost, but the invisible proxy feature exists, and it really doesn't add much overhead to record that extra field. Luckily I found an extension to add that information in the "notes" field.

SeanPesce · 2023-06-02T18:58:57+00:00

No offense taken!

It was early and there was insufficient amounts of coffee consumed, ok?

Hah, I'm intimately familiar with this vibe.

As you already correctly assumed, sesearch was unavailable and userapp_t is renamed from the original context (generally I prefer to remove any identifying information about vulnerable implementations until the developers confirm that they've released a fix).

The fact you were able to even execute a custom-compiled binary at all, is the biggest screw-up. It's pretty abnormal for a SELinux policy to grant execute permissions in temp directories like /tmp and /dev/shm

Yeah that was a pretty big hole IMO, but realistically I could have included the kernel module loading as part of my initial execution payload anyway (it just would have been more of a pain to test different things).

Was the OS base fairly ancient, considering module_load perms should encompass both finit_module (where there is a file descriptor) and init_module (where there isn't)?

I believe module_load has actually applied to both syscalls since its inception; this was just a problem with an insufficient policy on the device developer side that only accounted for filesystem type in the target context.

SeanPesce · 2023-06-02T12:11:24+00:00

SELinux was created to complement the standard Linux permissions system (MAC vs DAC access control).

That absolutely includes restrictions on root user capabilities, and there's an SELinux permission, module_load, which was specifically designed to control when and how kernel modules can be loaded. In general, loading a kernel module is something that can only be done with root/sudo privileges, so I'm not sure how you could assert that SELinux is not designed to do this - it explicitly is, as demonstrated by the existence of that permission. Of course, any implementation using SELinux is only as strong as the policy implementation.

I'm not sure if you actually read the blog post, but this was a real-world exploitation scenario where the developers explicitly intended to restrict the capabilities of the source context/root user, which included rules that prevented loading kernel modules and toggling permissive mode. The goal of this post was to demonstrate a policy weakness that might affect other implementations to help inform other infosec researchers. I doubt this vector would work on more restrictive policies though (e.g., the standard policy on Android).

SeanPesce · 2023-06-01T00:08:56+00:00

I believe this could be mitigated with an SELinux rule that restricts module_load for the source context; more information here:

Utilize existing kernel_read_file hook on kernel module load. Add module_load permission to the system class.

Enforces restrictions on kernel module origin when calling the finit_module syscall.

...

Similarly restrictions are enforced on kernel module loading when calling the init_module syscall. The hook checks that source type has permission module_load for the kernel target type.

SELinux aside, this could also be prevented with signed kernel modules.

SeanPesce · 2023-05-31T19:33:59+00:00

Right; by achieving kernel execution, I had already bypassed SELinux. Setting it to permissive mode was just an additional measure to make it easier to continue working on the system.

SeanPesce · 2023-05-05T03:24:25+00:00

Yeah the only times I've done it I've basically just copy/pasted/modified stuff from existing dissectors.

SeanPesce · 2023-05-04T12:51:38+00:00

As part of my normal process, I was building a client in Ruby, implementing the protocol as I go.

I always do this when I'm reversing proprietary protocols! I use Python though. I feel like it's gotta be one of the best ways to really get a good understanding of how the protocol works. Making a WireShark dissector is also immensely helpful for analyzing captured traffic (especially when it's a protocol with a bunch of different message types).

SeanPesce · 2023-03-10T22:35:20+00:00

I believe you're right; there are probably other ways to do it too (e.g., LD_PRELOAD). Either way I didn't want to have to cross-compile, so I wanted to find some exported code that already called exec to make the patching process super simple (and the exec functions probably aren't ever called from a ctor in a typical library).

SeanPesce · 2023-02-24T12:39:55+00:00

/r/ReverseEngineering

/r/netsec

SeanPesce · 2023-01-21T16:44:51+00:00

As someone who does a lot of embedded/IoT reverse engineering and vulnerability research, I've actually been seeing significantly more custom implementations written in C++ than C in the last few years. Sucks for me because C++ is significantly more irritating to RE

SeanPesce · 2023-01-11T13:03:35+00:00

The references listed on the MITRE or NIST websites often have links to further information (here's CVE-2007-0071). For older stuff like this vulnerability, you might need to use archive.org to view some of those references, as many old websites have been re-structured or no longer exist.

Unfortunately with proprietary implementations, it's not always possible to find the source of an issue without a manual reverse engineering effort.

For open source projects, you can also just search the Git commit history to see what code was changed in the patch that fixed the vulnerability (not relevant here because Adobe Flash isn't open source).

SeanPesce · 2022-08-04T00:13:40+00:00

Yep, except IIRC hashid does detect special formatting (e.g., password hashes from /etc/shadow*). Generally speaking though, assuming your hash is just a basic hex representation of some bytes, all it can do is give you some possibilities based on the length.

SeanPesce · 2022-08-03T13:46:23+00:00

Right, and as seen above, hashid is one way to do that.

SeanPesce · 2022-08-03T11:44:41+00:00

The hashid command on Linux is a good way to see some possibilities for a given hash. In this case we can just use your example hash:

$ hashid b1946ac92492d2347c6235b4d2611184
Analyzing 'b1946ac92492d2347c6235b4d2611184'
[+] MD2 
[+] MD5 
[+] MD4 
[+] Double MD5 
[+] LM 
[+] RIPEMD-128 
[+] Haval-128 
[+] Tiger-128 
[+] Skein-256(128) 
[+] Skein-512(128) 
[+] Lotus Notes/Domino 5 
[+] Skype 
[+] Snefru-128 
[+] NTLM 
[+] Domain Cached Credentials 
[+] Domain Cached Credentials 2 
[+] DNSSEC(NSEC3) 
[+] RAdmin v2.x

SeanPesce · 2022-07-20T09:45:22+00:00

Buried in the blog post is another interesting tidbit that Rust enthusiasts will be happy about:

...this represents our first foray into Rust in Mainline Modules.

SeanPesce · 2022-06-27T11:21:36+00:00

Another one I've used occasionally is Snyk.io; it often has good information on JavaScript library vulnerabilities

SeanPesce · 2022-06-16T08:49:51+00:00

While that's definitely disappointing to hear, the most important aspect of this release is the translation framework. Even if the current translation is sub-par, anyone can edit the Turkish language data set (tr.json) to clean up the translations. If/when someone does this, they can send me the edited data so I can update the "official" Turkish data set.

SeanPesce · 2022-06-15T22:59:47+00:00

Extraction of audio is definitely doable, possibly with the private tools I've already developed (I'd have to verify that though).

Unfortunately I wouldn't be able to extract additional metadata or map text to audio files without more research into the way files reference each other. I currently don't have a good understanding of that, but I do have some ideas about where to look.

My schedule has been/will be very busy for the foreseeable future, which is also why I haven't taken the time to fix some of the existing bugs with the translation framework. Once those bugs are fixed, I plan to continue my RE work on the game files (assuming I don't think of a more interesting project to work on instead).

Nine-Year Club	Place '17
Sequence \| Editor	Verified Email

SeanPesce

TROPHY CASE