[DISCUSSION] Root Fire HD (2017) with a Kernel Exploit... - Fire HD 8 and HD 10 General

I'm trying to find a root exploit for Fire HD 8 (2017) as many others are doing. I found a vulnerability by X-Ray, the Linux kernel exploit CVE-2014-4943 which allows privilege escalation by a flaw found in the implementation of PPP over L2TP sockets. When I searched in Google for it, I found that it is done by 'leveraging data-structures between an L2TP socket and an INet socket'. There MUST be a way to escalate privileges because there is a closed-source method used in Immunity CANVAS in Linux systems. Let's collaborate with this and we will be able to root those locked-out devices!
Resources and ideas are welcome!
Some links you might be interested in,
CVE-2014-4943 - PPPoL2TP DoS Analysis
CVE-2014-4943 - Red Hat Customer Portal
CVE-2014-4943 - (cve.mitre.org)
Linux Kernel 3.15.6 - PPP-over-L2TP Socket Level Handling Crash (PoC)

Related

android hacking tool

android hacking tool was released at Defcon's hacker conference, on friday. it was, in order to warn OEM.... that hackers can easily hack into.. read this
https://www.defcon.org/html/defcon-18/dc-18-speakers.html#Percoco1
It's a rootkit
We have developed a kernel-level Android rootkit in the form of a loadable kernel module. As a proof of concept, it is able to send an attacker a reverse TCP over 3G/WIFI shell upon receiving an incoming call from a 'trigger number'. This ultimately results in full root access on the Android device.
Click to expand...
Click to collapse
Always a way
Is that really that easy to root an android device? Even from a remote point? That means I should never be worried about updating my phone, there’s always a way to obtain root access after that.

Details about Local root vulnerability in Android 4.4.2

I'm interested by the recently fixed path traversal vulnerability in the VolumeManager::createAsec() function.
Though it seems to be a well known issue for peoples in the field, my entry point was the article "Local root vulnerability in Android 4.4.2", available at blog.cassidiancybersecurity.com: as I'm learning, and know the right way to learn isn't to only read but also to practice, I felt it could be a good exercise to implement an exploit that leverage this vulnerability to get a "root shell".
AFAIK:
On Android 4.4+, to get a useful "root shell" does not mean just to acquire ruid=euid=0 and spawn /system/bin/sh, due to SE Linux restrictions: this requires to setup some kind of su system daemon, that will execute su client requests in a privileged context.
A common way to get this system daemon running privileged enough is to have it started by the kernel as a response to a hot plug event, which involves writing to /sys/kernel/uevent_helper
The API related to the vulnerability (VolumeManager/IMountService) isn't published to user applications, which should rather rely upon the StorageManager system service or the media framework
Getting the su daemon/client programs should be quite easy (a classic shell bind/reverse tcp daemon and a netcat client will be ok for the PoC, though local adb usage would benefit from using un*x domain sockets instead of inet ones).
But, starting from the beginning, I need to find a way to trigger the vulnerability, which I haven't achieved yet: that's why I'm here, hoping someone will be both clever and charitable enough to give a few clues.
The material at hand till now:
The article from cassidiancybersecurity.
The working exploit from jcase (Pie for Motorola devices): thanks to him, I can use a temporary root shell, which helps a lot to see what's happening; it's also there that I've borrowed the /sys/kernel/uevent_helper trickery
SDK/AOSP source code (notably VolumeManager.h/cpp, CommandListener.h/cpp, IMountService.java, MediaFormat.java)
SDK/NDK documentation
I've tried to access the IMountService API through a reference I fetch with something equivalent to:
Code:
IMountService service =
IMountService.Stub.asInterface(ServiceManager.getService("mount"));
I say "something equivalent to" because the API is not public and you have to use reflection.
The acquired proxy seems ok, but invoking the API leads to errors related to missing ASEC_CREATE or MOUNT_UNMOUNT_FILESYSTEMS system permissions/capabilities. Trying to directly write to the IPC un*x sockets also lead to permission errors, which is consistent.
Thus my first question: does exploiting the path traversal vulnerability involve another exploit to set the permissions that allow to access the vulnerable API ?
Reading the related thread, it seems to me that jcase's exploit (Pie for Motorola devices):
relies upon the setup being done under the shell user identity, perhaps to belong to the mount group: can someone confirm this ?
should work mostly for Motorola devices, but not for others: is this stated because successful exploitation also relies upon Motorola specific parts (drivers,customization,...), or because most other vendors have already backported the fix ?
The above questions will certainly sound naive to most of you, but some answers to these would greatly help me not running toward a completely wrong direction.
I'm neither waiting for another binary exploit (I have a Moto G that I boot on a KitKat 4.4.2 rom, and jcase's Pie greatly addresses my current user needs), nor expecting clean source code with build files. I'd just appreciate any relevant direction, pointer, snippet.
For example, I was not aware of the /sys/kernel/uevent_helper trick to execute privileged processes, and discovered it while trying to reverse engineer jcase's implementation. Later on, I've seen it at various places, including the public source of the Cyanide project, which tells me that this is not a secret that must remain secret, but a rather well known (and documented) kernel behavior. That's the kind of things I wish to learn, hopefully with community advice.
Thanks, have a good day.
thanks

Top Five Android Apps for the Hacking(sniffing,pentest and scanning)

# 1 Nethunter Framework
Kali Linux NetHunter for Nexus and OnePlus. The Kali Linux NetHunterproject is the first Open Source Android penetration testing platform for Nexus devices, created as a joint effort between the Kali community member “BinkyBear” and Offensive Security.
The Kali Linux NetHunter project is the first Open Source Android penetration testing platform for Nexus devices, created as a joint effort between the Kali community member “BinkyBear” and Offensive Security. NetHunter supports Wireless 802.11 frame injection, one-click MANA Evil Access Point setups, HID keyboard (Teensy like attacks), as well as BadUSB MITM attacks – and is built upon the sturdy shoulders of the Kali Linux distribution and toolsets. Whether you have a Nexus 5, Nexus 6, Nexus 7, Nexus 9, Nexus 10 or OnePlus One we’ve got you covered. Our freely downloadable images come with easy to follow installation and setup instructions to get you up and running in no time at all.
802.11 Wireless Injection and AP mode support with multiple supported USB wifi cards.
Capable of running USB HID Keyboard attacks, much like the Teensy device is able to do.
Supports BadUSB MITM attacks. Plug in your Nethunter to a victim PC, and have your traffic relayed though it.
Contains a full Kali Linux toolset, with many tools available via a simple menu system.
USB Y-cable support in the Nethunter kernel – use your OTG cable while still charging your Nexus device!
Software Defined Radio support. Use Kali Nethunter with your HackRF to explore the wireless radio space.
As an experienced penetration tester or security professional, it is imperative that you trust the tools you work with. One way to achieve this trust is by having full transparency and familiarity with the code you are running. You are free to read, investigate, and change our build scripts for the NetHunter images. All of this goodness from the house of Offensive Security and developers of Kali Linux!
HID Keyboard and ‘BadUSB’ Attacks
Our NetHunter images support programmable HID keyboard attacks, (a-la-teensy), as well as “BadUSB” network attacks, allowing an attacker to easily MITM an unsuspecting target by simply connecting their device to a computer USB port. In addition to these built in features, we’ve got a whole set of native Kali Linux tools available for use, many of which are configurable through a simple web interface.
Configuration Management
The Kali NetHunter configuration interface allows you to easily configure complex configuration files through a local web interface. This feature, together with a custom kernel that supports 802.11 wireless injection and preconfigured connect back VPN services, make the NetHunter a formidable network security tool or discrete drop box – with Kali Linux at the tip of your fingers wherever you are!
#2 Hackode
Hackode : The hacker’s Toolbox is an application for penetration tester, Ethical hackers, IT administrator and Cyber security professional to perform different tasks like reconnaissance, scanning performing exploits etc.Hackode : The hacker's Toolbox is an application for penetration tester, Ethical hackers, IT administrator and Cyber security professional to perform different tasks like reconnaissance, scanning performing exploits etc.
This Application contains different tools like:
* Reconnaissance
* Google Hacking
* Google Dorks
* Whois
* Scanning
* Ping
* Traceroute
* DNS lookup
* IP
* MX Records
* DNS Dig
* Exploits
* Security Rss Feed
#4 APKInspector
APKinspector is a powerful GUI tool for analysts to analyse the Android applications. The goal of this project is to aide analysts and reverse engineers to visualize compiled Android packages and their corresponding DEX code.
Read Also:Hacking for beginners
#6 Burp Suite
Burp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application’s attack surface, through to finding and exploiting security vulnerabilities.
#7 zANTI
zANTI is a comprehensive network diagnostics toolkit that enables complex audits and penetration tests at the push of a button. It provides cloud-based reporting that walks you through simple guidelines to ensure network safety.

[Solved, not possible] Help me test eBPF support on modern Android devices

UPD: It turns out bpf() syscall is blocked by seccomp.
From what I understand, Android seccomp whitelists all syscalls listed in bionic SYSCALLS.TXT, and then blacklists some of them, or whitelists missing in SYSCALLS.TXT.
Since bpf() is missing from SYSCALLS.TXT and not whitelisted for applications, we can't use bpf() on stock Android settings.
That sucks.
I want to implement IP-level packet filtering utility for Android which won't require root privileges.
Since RAW sockets or iptables require CAP_SYS_ADMIN/CAP_NET_ADMIN capability which is not available without root, I want to understand if it's possible to attach eBPF program to TCP/UDP socket on modern Android devices.
BPF is a filtering framework with virtual machine which executes bytecode inside Linux kernel. BPF could be used for many subsystems, but I'm interested only in sockets. Non-root BPF should be supported since vanilla Linux 4.4, and I want to check if BPF support is enabled on modern Androids, is available for non-root user, has it been backported to older Android kernels by SoC vendors and how many devices are shipped with BPF support enabled.
I'm asking the owners of Android 7+ devices to perform eBPF support test:
Download Termux terminal emulator (F-Droid, APK). Please use only Termux, it has minimal Linux environment and proper busybox, other terminal emulators likely won't work.
Run the following command inside terminal session (copy&paste):
Code:
wget -O - http://valdikss.org.ru/bpftest/bpf.sh | bash
Copy the output or take a screenshot and upload it here or send it to me using PM.
Source code for those who interested: https://valdikss.org.ru/bpftest/bpftest.c
Note the script is downloaded using unencrypted http. This is because Termux wget does not support https. I assume that developer section of the forum understands all concerns and will take precautions before executing it.
Thanks.
Click to expand...
Click to collapse
Dec 2, 2021
Allow bpf() syscall
…
Allowing the bpf() syscall is safe as its usage is still gated by selinux and regular apps are not allowed to use it.
Allow bpf() syscall · aosp-mirror/[email protected]
The implementation of FUSE BPF requires the FUSE daemon to access BPF functionalities, i.e., to get the fd of a pinned BPF prog and to update maps. In Android the FUSE daemon is part of MediaProvid...
github.com

Local Privilege Escalation: Linux kernel vulnerability sighted

'Mutagen Astronomy' Linux kernel vulnerability sighted
A new Linux kernel vulnerability that can only be locally exploited is nonetheless proving a bit of a nuisance.
The CVE-2018-14634 vulnerability relates to a local privilege escalation bug in the Linux kernel, and creates a means to obtain root (administrator) privileges on a hacked system.
Security researchers at cloud security firm Qualys discovered the vulnerability, which stems from an integer overflow in the Linux kernel's create_elf_tables() function. It's not remotely exploitable, thanks heavens, but on a vulnerable 64-bit system, a "local attacker can exploit this vulnerability via a SUID-root binary and obtain full root privileges," Qualys warns.
Security researchers at Qualys explain: "Even though all Linux kernels are technically vulnerable, this issue is mitigated by a one-year-old patch that was backported to most long-term kernels and makes exploitation impossible."
Click to expand...
Click to collapse
Just thought you guys would want to take a look at this. Not sure if it applies to our tablets, but it looked interesting.
DragonFire1024 said:
'Mutagen Astronomy' Linux kernel vulnerability sighted
Just thought you guys would want to take a look at this. Not sure if it applies to our tablets, but it looked interesting.
Click to expand...
Click to collapse
In order to exploit this bug, a system must have 32GB of RAM to allocate in false pointers according to Qualys' analysis of an implementation. It also requires that a normal user have access to call a root-owned binary that has this method in it. It's possible that one could be found in the files of some of the tablets, but it could also be locked away. Regardless, we don't have 32GB of RAM in any Fire tablets
Cool find though!

Categories

Resources