You can check if your device can be rooted before running our software. CHECK ROOT AVAILABILITY. Our live rooting support team will be happy to manually root your device. Our rooting experts have rooted nearly every Android device out there today – from the most popular models to the most obscure models. Let’s say I want to drop the App’s main mach-o file in a folder where only root has access, e.g.: /opt (folders protected by SIP, like /System won’t work, as even root doesn’t have access there). Here are the steps to reproduce it: Step 1-2 is the same as in the previous case. Z4 Root App is a simple Root app for android with the ability to inject the exploit temporarily, permanently or remove the codes. The App interface is simple three options to choose from. The App is able to root any device up to Android 4.5+. Z4 App can do your job easily without any issues. Download Z4 App APK.
Download and Install Odin for Mac
Odin for mac is now available and if you want to Download and Install Odin for Mac? then you are at right place. We are here with the tutorial on How to Install Odin on Mac. In this Guide, we will tell you the easiest way using which you will be able to Install Odin in Mac.
If you are a Samsung Smartphone or Tablet user, then chances are you must have heard about Odin as this is the tool using which almost everyone tweaks their Samsung devices with things like Root, Custom ROMs, Custom Recoveries, Stock ROM etc. While for a long time Odin was only available for Windows PC, we finally have a working Odin for Mac and thus today in this guide we will show how you can easily download and install Odin for Mac in minutes by following this guide, so make sure to stick around till the end.
In our quick and short guide, we will show you how you can easily install Odin on your Mac, the files required for this procedure and the prerequisites for a working copy of Odin for apple Mac as well as the actual detailed steps that will take you through how you can successfully install Odin in any Mac os x.
Jodin3 For Mac: What is It?
By now some of you might be wondering that what is Odin and what does it do? And to put it simply, Odin is a software for those who own a Samsung Galaxy device as Odin for Mac allows you to connect your Samsung Galaxy device to your Mac and then simply do things like rooting your device, restoring stock ROM, installing Custom ROMs and TWRP Recovery and much more via the Odin that utilizes the Download Mode that comes inside of all Samsung Galaxy Smartphone.
Uses of Odin for Mac
Apart from this, Odin’s major usage, as well as the feature, is that Odin for Mac is the easiest and fastest thing to use when you are installing stock firmware on any Samsung Galaxy Device whether it is for personal use or anything else, Odin will allow you to do it directly from your Mac without using a PC even once throughout the process of installing stock firmware or anything else.
The greatest thing about Odin for Macbook is that it will allow you to successfully Root your Samsung devices via the CF-Auto-Root method which is one of the safest methods to root your Samsung Galaxy devices. if you are a Mac user and thus because of all these features and uses we will recommend you to Install Odin on Mac Pc
One more thing that we would like to mention about Odin is that it is not by the same developers of the original Odin, rather it is a port for Mac Devices but it works equally good. Odin for Mac is also called Jodin3 by some people for Mac devices, but if you install Odin, you will be able to use it exactly like any other windows pc user would use their Odin.
Also Read:
Guide to Download and Install jodin3 for Mac
Now that you know almost everything about the Odin software, we are finally here to tell you how you can also easily download and install Odin for Mac on your Mac by following the given steps down below. But before that, we highly recommend that you should first go through the given prerequisites section as these points are highly important for using Mac Odin.
Prerequisites for using Odin for Mac
Steps To Install Odin for Mac
We have updated the Version for this tool, Incase if you want to use this in 2020 then also you can use without any problem as all of the Odin for mac in 2020 Are now working.
We hope that we were able to successfully install Odin on your Mac and if yes then let us know which Samsung smartphone are you using right now for which you needed Odin down in the comments section. If you liked this post share it on social media and consider checking out our other blog posts to stay updated with the latest Tech Content.
This writeup is intended to be a bit of storytelling. I would like to show how I went down the rabbit hole in a quick ’research’ I wanted to do, and eventually found a local privilege escalation vulnerability in macOS. I also want to show, tell about all the obstacles and failures I run into, stuff that people don’t talk about usually, but I feel it’s part of the process all of us go through, when we try to create something.
If you prefer to watch this as a talk, you can se it here:Csaba Fitzl - macOS: Gaining root with Harmless AppStore Apps - SecurityFest 2019 - YouTube
Slides are here:Getting root with benign app store apps
DYLIB Hijacking on macOS
This entire story started with me trying to find dylib hijacking vulnerability in a specific application, which I can’t name here. Well, I didn’t find any in that app, but found plenty in many others.
If you are not familiar with dylib hijacking on macOS, read Patrick Wardle’s great writeup:Virus Bulletin :: Dylib hijacking on OS Xor watch his talk on the subject:DEF CON 23 - Patrick Wardle - DLL Hijacking on OS X - YouTube
I would go for the talk, as he is a great presenter, and will explain the subject in a very user friendly way, so you will understand all the details.
But just to sum it up here, in very short, there are 2 type of dylib hijackings possible:
Finding vulnerable apps
It couldn’t be easier, you go download Patrick’s DHS tool, run the scan and wait. Link: Objective-See There is also a command line version: GitHub - synack/DylibHijack: python utilities related to dylib hijacking on OS X
The vulnerability is with Tresorit’s FinderExtension:
And you can place your dylib here:
DHS will only show you the first hijackable dylib, but there can be more. Set the DYLD_PRINT_RPATHS variable to 1 in Terminal, and you will see which dylibs the loader tries to load. You can see below that we can hijack two dylibs.
Additionally it’s a good idea to double check if the App is compiled with the library-validation option (flag=0x200). That would mean that the OS will verify if all dylibs are signed or not, so you can’t just create anything and use that. Most of the apps are not compiled this way, including Tresorit (but they promised to fix it):
Utilizing the vulnerability
It’s also something that is super easy based on the talk above, but here it is in short. I made the following POC:
The constructor will be called upon loading the dylib. It will print you a line, create a syslog entry, and also start Terminal for you. If the app doesn’t run in sandbox you get a full featured Terminal. Compile it:
Then run Patrick’s fixer script. It will fix the dylib version for you (the dylib loader will verify that when loading) and also will add all the exports that are exported by the original dylib. Those exports will actually point to the valid dylib, so when the application loads our crafted version, it can still use all the functions and won’t crash.
Once that is done, you can just copy the file over and start the app.
Other apps
Considering the amount of vulnerable apps, I didn’t even take the time to report all these issues, only a few. Beside Tresorit I reported one to Avira, and they promised a fix but with low priority as you had to get root for utilising this, and the others were in MS Office 2016, where MS said they don’t consider this as a security bug as you need root privileges to exploit it, they said I can submit as a product bug. I don’t agree, cause this is a way for persistence, but I suppose I have to live with it.
Mac Os RootThe privilege problem
My original ‘research’ was done, but this is the point where I went beyond what I expected in the beginning.
There is a problem in case of many apps, in theory you just need to drop your dylib into the right place, but there can be a two main scenarios in terms of privileges required for utilising the vulnerability.
Typically applications you drag and drop to the
/Application directory will fall into the first category. All applications from the App Store will fall into the 2nd category, it’s because they will be installed by the installd daemon which is running as root . Apps that you install from a package will typically also fall into the 2nd category, as typically those require elevation of privilege.
I wasn’t quite happy with all vendor responses, and also didn’t like that exploitation is limited to root most of the times, so I started to think: Can we bypass root folder permissions? Spoiler: YES, otherwise this would be a very short post. :)
Tools for monitoring
Before moving on, I want to mention a couple of tools, that I found useful for event monitoring.
FireEye - Monitor.app
This is a procmon like app created by FireEye, it can be downloaded from here: Monitor.app | Free Security Software | FireEyeIt’s quite good!
Objective-See’s ProcInfo library & ProcInfoExample
This is an open source library for monitoring process creation and termination on macOS. I used the demo project of this library, called ProcInfoExample. It’s a command line utility and will log every process creation, with all the related details, like arguments, signature info, etc… It will give you more information than FE’s Monitor app. It’s output is like:
Built-in fs_usage utility
The
fs_usage utility can monitor file system event very detailed, I would say even too detailed, you need to do some good filtering if you want to get useful data out of it. You get something like this:
Bypassing root folder permissions in App Store installed apps
How to install unauthorized apps on mac. The goal here is to write any file inside an AppStore installed application, which is by default only accessible for root. The bypass will only work if the application was installed already at least once (since when you buy it, you need to authenticate to the AppStore even if it’s free or if the user checked in ‘Save Password’ for free apps, you can get those as well. What I ‘noticed’ first is that you can create folders in the “/Applications” folder - obviously as you can also drag and drop apps there. But what happens if I create folders for the to-be-installed app? Here is what happens and the steps to bypass the root folder permissions:
At this point the app will be installed and you can use it, and you have your files there, which you couldn’t place there originally without root permissions.
This was fixed in Mojave 10.14.5, I will talk about that later.
To compare, it’s like having write access to the “Program Files” folder on Windows. Admin users do have it, but only if they run as HIGH integrity, so that means you need to bypass UAC from the default MEDIUM integrity mode. But in Windows, MEDIUM integrity Admin to HIGH integrity Admin elevation is not a security boundary, but in macOS admin to root is a boundary.
Taking it further - Dropping AppStore files anywhere
At this point I had another idea. Since installd runs as root, can we use it to place the app somewhere else or certain parts of it? The answer is YES. Let’s say I want to drop the App’s main mach-o file in a folder where only root has access, e.g.:
/opt (folders protected by SIP, like /System won’t work, as even root doesn’t have access there). Here are the steps to reproduce it:Step 1-2 is the same as in the previous case.3. Create the following folder structure: /Applications/Example.app/Contents 4. Create a symlink ‘MacOS’ pointing to /opt :ln -s /opt /Applications/Example.app/Contents/MacOS The main mach-o file is typically in the following folder: /Applications/Example.app/Contents/MacOS and now in our case we point this to /opt5. Install the App
What happens at this point, is that the App will install normally, except that any files under
/Applications/Example.app/Contents/MacOS will go to /opt . If there was a file with the name of the mach-o file, that will be overwritten.Essentially what we can achieve with this is to drop any files that can be found in an AppStore app to a location we control.
What can’t we do? (Or at least I didn’t find a way)
Mac Root AccessIdeas for using this for privilege escalation
Based on the above I had the following ideas for privilege escalation from admin to root:
Reporting to Apple
I will admit that at this point I took the lazy approach and reported the above to Apple, mainly because:
So I reported and then Apple came back at one point for my privilege escalation ideas:“The App Review process helps prevent malicious applications from becoming available on the Mac and iOS App Stores.“
Obviously Apple didn’t understood the problem for first, it was either my fault not explaining it properly or they didn’t understood it, but it was clear that there was a misunderstanding between us, so I felt that I have to prove my point if I want this fixed. So I took a deep breath and gone the “Try Harder” approach and decided to develop an App and submit it to the AppStore.
Creating an App
After some thinking I decided that I will create an application that will have a crontab file for root, and I will drop it to the
/usr/lib/cron/tabs folder. The app had to do something meaningful in order to submit it, and to be accepted, so I came up with the idea of creating a cronjob editor app. It’s also useful, and would also explain why I have a crontab files embedded. Here is my journey:
Apple developer ID
In order to submit any App to the store you have to sign up for the developer program. I signed up with a new Apple ID for the Apple developer program just because I had the fear that they will ban me, once I introduce an app that can be used for private escalation. In fact they didn’t. It’s 99$/ annum.
Choosing a language
I had no prior knowledge of either Objective C or Swift, but looking on the following syntax for Obj-C, freaked me out:
This is how you call methods of objects and pass parameters. It’s against every syntax I ever knew and I just didn’t want to consume this. So I looked at Swift which looked much nicer in this space and decided to go with that. :)
Learning Swift
My company has a subscription to one of the big online training portals, where I found a short, few hour long course about introduction to Cocoa app development with Swift. It was an interesting course, and it turned out to be sufficient, basically it covered how to put together a simple window based GUI. It also turned out that there is Swift 1 and 2 and 3 and 4, as the language evolved, and the syntax is also changed over time a bit, so you need to pick up the right training.
Publishing to the store - The Process
Publishing to the store - The error problem
Developing the App was pretty quick, but publishing it was really annoying, because I really wanted to see that my idea is indeed works. So once I pushed it, I had to wait ~24 hours for it being reviewed. I was really impatient and nervous about if I can truly make it to the store :) The clock ticked, and it was rejected! :( The reason was that when I clicked the close button, the app didn’t exit and the user had now way to bring back the window. I fixed it, resubmit, wait again ~24 hours. Approved! I quickly went to the store, prepared the exploit, and clicked install. Meanwhile during the development I upgraded myself to Mojave, and never really did any other tests with other apps. So it was really embarrassing to notice, that in Mojave this exploit path doesn’t work :( No problem, I have a High Sierra VM, let’s install it there! There I got a popup, that the minimum version required for the App is 10.14 (Mojave), and I can’t put it on HS… :( damn, it’s an easy fix, but that means resubmit again, wait ~24 hours. Finally it got approved again, and the exploit worked on High Sierra! :) It was a really annoying process, as every time I made a small mistake, fixing it meant 24 hours, even if the actual fix in the code, took 1 minute.
The App
The application I developed, is called “Crontab Creator”, which is actually very useful for creating crontab files. It’s still there and available, and as it turns out, there are a few people using it.Crontab Creator on the Mac App Store
The application is absolutely benign! However it contains different examples for crontab files, which are all stored as separate files within the application. The only reason I didn’t store the strings embedded in the source code is to be able to use it for exploitation :) Among these there is one called ‘root’, which will try to execute a script from the _Applications_Scripts folder.
Privilege Escalation on High Sierra
The Crontab Creator app contains a file named ‘root’ as an example for crontab file, along with 9 others. The content is the following:
Obviously this script doesn’t exists by default, but you can easily create it in the
/Application folder, as you have write access, and at that point you can put anything you want into it.
The steps for the privilege escalation are as follows. First we need to create the app folder structure, and place a symlink there.
Then we need to create the script file, which will be run every minute, I choose to run Terminal.
Mac Terminal Root
Then we need to install the application from the store. We can do this either via the GUI, or we can do it via the CLI if we install
brew , and then mas .
Commands:
![]()
In summary utilizing the previous vulnerabilities we can drop the file into the crontab folder, create the script with starting Terminal inside it, and in a minute we got a popup and root access.
The fix
As noted before, Apple fixed this exploit path in Mojave. This was in 2018 October, my POC didn’t work anymore, and without further testing I honestly thought that the privilege escalation issue is fixed - yes you could still drop files inside the app, but I thought that the symlink issue is solved. I couldn’t have been more wrong! But this turned out only later.
Infecting installers without breaking the Application’s signature
The next part is where we want to bypass root folder permission for manually installed apps. We can’t do a true bypass / privilege escalation here, as during the installation the user have to enter his/her password, but we can still apply the previous idea. However here I want to show another method, and that’s how to embed our custom file into an installer package. If we can MITM a pkg download, we could replace it with our own one, or we can simply deliver it to the user via email or something.
As a side note, interestingly AppStore apps are downloaded through HTTP, you can’t really alter it, as the hash is downloaded via HTTPS and the signature will also verified.
Here are the steps, how to include your custom file in a valid package:
The package’s digital signature will be lost, so you will need a method to bypass Gatekeeper. The embedded App’s signature will be also broken, as these days every single file inside an .app bundle must be digitally signed. Typically the main mach-o file is signed, and it has the hash of the _CodeSignatures plist file. The file will contain all the hashes for the other files. If you place a new file inside the .app bundle that will invalidate the signature. How to get facebook app on macbook pro. However this is not a problem here, as if you can bypass Gatekeeper for the .pkg file, the installed Application will not be subject to Gatekeeper’s verification.
Redistributing paid apps
Using the same tool as in the previous example we can grab the installer for a given application. If you keep a paid app this way, it will still work somewhere else even if that person didn’t pay for the app. There is no default verification in an application if it was purchased or not, it also doesn’t contain anything that tracks this. With that, if you buy an application, you can easily distribute it somewhere else.In-App purchases probably won’t work as those are tied to the Apple ID, and if there is another activation needed, that could be also a good countermeasure. But apps that doesn’t have these can be easily stolen.Developers should build-in some verification of Apple IDs. I’m not sure that it’s possible but would be useful for them.
Privilege escalation returns on MojaveThe fix
This year (2019) I’ve been talking to a few people about this, and it hit me, that I didn’t do any further checks if symlinks are completely broken (during the installation) or not. It turned out that they are still a thing.
The way the fix is working is that
installd has no longer access to the crontab folder (/usr/lib/cron/tabs ) even running as root, so it won’t be able to create files there. I’m not even sure that this is a direct fix for my POC or some other coincidence. We can find the related error message in /var/log/install.log (you can use the Console app for viewing logs):
The problem
The
installd process had still access to other folders, and can drop files there during the redirection, and those could be abused as well. I tested and you could redirect file writes to the following potentially dangerous folders:
/var/root/Library/Preferences/
Someone could drop a file called
com.apple.loginwindow.plist , which can contain a LoginHook, which will run as root.
/Library/LaunchDaemons/
Dropping a plist file here will execute as root
/Library/StartupItems/
Dropping a file here will also execute as root.
You can also write to
/etc .
Dropping files into these locations are essentially the same idea as dropping a file to the crontab folder. Potentially many other folders are also affected, so you can craft malicious dylib files, etc… but I didn’t explore other options.
The 2nd POC
With that, and now being an ‘experienced’ :D macOS developer, I made a new POC, called StartUp. It’s this:StartUp on the Mac App Store
It is really built along the same line as the previous one, but in this case for LaunchDaemons.
The way to utilize it is:
Here you can create a sample.sh script that will run as root after booting up. For myself I put a bind shell into that script, and after login, connecting to it I got a root shell, but it’s up to you what you put there.
Reporting to Apple
I reported this around February to Apple, and tried to explain again in very detailed why I think the entire installation process is still broken, and could be abused.
Mac Root PasswordThe security enhancementRoot App For Mac
Apple never admitted this as a security bug, they never assigned a CVE, they considered it as an enhancement. Finally this came with Mojave 10.14.5, and they even mentioned my name on their website.
I made a quick test, and it turned out that they eventually managed to fix it properly. If you create the App’s folder, place there files, those will be all wiped. Using FireEye’s Monitor.app we can actually see it. The first event shows that they move the entire folder.
Being in Game Of Thrones mood I imagine it like this:
Mac Root Folder
The following event shows that they install the application into its proper location:
So you can no longer drop there your files, etc…
I like the way this got fixed eventually, and I would like to thank Apple for that.
I would like to also thank for Patrick Wardle who was really helpful whenever I turned to him with my n00b macOS questions.
Root Apps For Moto G5 PlusTo be continued…
The story goes on, as I bypassed Apple’s fix. An update will follow once they fixed the issue.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |