je internetový portál zaměřený na počítačovou bezpečnost, hacking, anonymitu, počítačové sítě, programování, šifrování, exploity, Linux a BSD systémy. Provozuje spoustu zajímavých služeb a podporuje příznivce v zajímavých projektech.


IoT chickens come home to roost

Sophos Naked Security - 25 min 36 sek zpět
October was convulsed by the heft of a few billion IoT chickens coming home to roost.

Vyděračské viry na vzestupu, patří mezi nejrozšířenější hrozby na světě - bezpečnost - 43 min 8 sek zpět
Škodlivé kódy z rodiny ransomware, jak jsou označovány vyděračské viry, se vůbec poprvé dostaly na přední příčky žebříčku nejrozšířenějších počítačových hrozeb. To jinými slovy znamená, že kyberzločincům se daří tyto nezvané návštěvníky propašovávat do cizích PC stále častěji. Vyplývá to z analýzy antivirové společnosti Check Point.
Kategorie: Hacking & Security

Hacking Firmware from Mobile Phone Hacking Company Leaked Online

The Hacker News - 2 hodiny 57 min zpět
The Israeli firm Cellebrite, which provides digital forensics tools and software to help law enforcement access mobile phones in investigations, has had its firmware and software leaked online. Yes, you heard that right. Cellebrite's most sensitive in-house capabilities have been made public by one of its products' resellers, who is now distributing copies of Cellebrite's firmware and
Kategorie: Hacking & Security

Nuclear plants leak critical alerts in unencrypted pager messages

Ars Technica - 11 hodin 37 min zpět


A surprisingly large number of critical infrastructure participants—including chemical manufacturers, nuclear and electric plants, defense contractors, building operators and chip makers—rely on unsecured wireless pagers to automate their industrial control systems. According to a new report, this practice opens them to malicious hacks and espionage.

Earlier this year, researchers from security firm Trend Micro collected more than 54 million pages over a four-month span using low-cost hardware. In some cases, the messages alerted recipients to unsafe conditions affecting mission-critical infrastructure as they were detected. A heating, venting, and air-conditioning system, for instance, used an e-mail-to-pager gateway to alert a hospital to a potentially dangerous level of sewage water. Meanwhile, a supervisory control and data acquisition system belonging to one of the world's biggest chemical companies sent a page containing a complete "stack dump" of one of its devices.

Other unencrypted alerts sent by or to "several nuclear plants scattered among different states" included:

Read 6 remaining paragraphs | Comments

Kategorie: Hacking & Security

Phishing by Numbers – Phishing Infographic

InfoSec Institute Resources - 12 hodin 36 min zpět
Try out SecurityIQ – our phishing simulator for free.   Phishing by Numbers The manipulation of human behaviour for criminal intent is nothing new. Age old scams which tricked people into handing over their hard earned cash have been going since humans came down for the trees. The modern equivalent of these old scams is […]
Kategorie: Hacking & Security

How one rent-a-botnet army of cameras, DVRs caused Internet chaos

Ars Technica - 25 Říjen, 2016 - 22:45

Enlarge / We're also mad you're connected to the Internet, toaster et al. (credit: Disney)

Welcome to the Internet of Evil Things. The attack that disrupted much of the Internet on October 21 is still being teased apart by investigators, but evidence thus far points to multiple "botnets" of Internet-connected gadgets being responsible for blocking access to the Domain Name Service (DNS) infrastructure at DNS provider Dyn. Most of these botnets—coordinated armies of compromised devices that sent malicious network traffic to their targets—were controlled by Mirai, a self-spreading malware for Internet of Things (IoT) devices.

in a blog post on the attack, Dyn reported "tens of millions" of devices were involved in the attack

But other systems not matching the signature of Mirai were also involved in the coordinated attack on Dyn. "We believe that there might be one or more additional botnets involved in these attacks," Dale Drew, CSO of Level 3 Communications, told Ars. "This could mean that they are 'renting' several different botnets to launch an attack against a specific victim, in which multiple other sites have been impacted."

Read 29 remaining paragraphs | Comments

Kategorie: Hacking & Security

Dyn DDoS Work of Script Kiddies, Not Politically Motivated Hackers

Threatpost - 25 Říjen, 2016 - 21:00
Researchers at Flashpoint said Friday's DDoS attack against DNS provider Dyn was likely the work of script kiddies and not advanced attackers.
Kategorie: Hacking & Security

WhatsApp Video Calling for Android – Download Beta Version Here

The Hacker News - 25 Říjen, 2016 - 20:37
WhatsApp is, no doubt, the largest end-to-end encrypted messaging network that allows over billion of its users to send messages, photos, videos, voice messages, documents, and calls that are secure from falling into the wrong hands. And now it seems like WhatsApp is rolling out a much-awaited feature for the new beta versions of its Android app: Video Calling. New beta version 2.16.318 of
Kategorie: Hacking & Security

Following Lull, New Campaigns Pushing Retooled ‘Pumpkin’ Locky

Threatpost - 25 Říjen, 2016 - 19:13
Researchers said they observed three separate spam campaigns pushing an updated version of Locky on Monday.
Kategorie: Hacking & Security

Apple Patches iOS Flaw Exploitable by Malicious JPEG

Threatpost - 25 Říjen, 2016 - 18:47
Apple on Monday rolled out dozens of patches including ones for its recently released Sierra operating system, OS X, iOS 10.1, watchOS, and Apple TV’s tvOS, along with fixes for Safari.
Kategorie: Hacking & Security

DirtyCOW Linux hole works on Android too – “root at will”

Sophos Naked Security - 25 Říjen, 2016 - 17:58
Turns out that the DirtyCOW Linux exploit can be used on Android, too. Rooters will be delighted, sysadmins might not be.

task_t considered harmful

Project Zero - 25 Říjen, 2016 - 17:54
Posted by Ian Beer, Project Zero
This post discusses a design issue at the core of the XNU kernel which powers iOS and MacOS. Apple have shipped two iterations of mitigations followed yesterday by a large refactor in MacOS 10.12.1/iOS 10.1. We’ll look at the bugs, how they can be exploited to escape sandboxes and escalate privileges, and how we can defeat each of the mitigations. Every step is accompanied by a working exploit.Some background on mach portsMach ports are multiple-sender, single-receiver message queues maintained by the kernel. Some special mach ports provide the same message-passing API to userspace but messages sent to them are handled synchronously by kernel message handlers. In this sense messages sent to these ports are quite a lot like syscalls.
Task ports are an example of this kind of port. They handle messages which allow senders to manipulate the virtual memory of a task and gain access to its threads. Each task (process) has its own task port. MIG is the name of the tool used to generate the serialization code used by these kernel-owned message ports.A low-level look at IOKitWhen you create a new IOKit user client in userspace you normally call this method from IOKitLib:
kern_return_tIOServiceOpen(  io_service_t service,  task_port_t owningTask,  uint32_t type,  io_connect_t *connect );
IOServiceOpen calls the MIG generated serialization code for the io_service_open_extended IPC method and sends that serialized message to the provided IOService port. The mach_msg mach trap notices that this port is owned by the kernel and calls the correct kernel MIG handler for this message rather than queuing it onto the port’s message queue.
The task port passed here is called owningTask; the same name is used throughout the userspace and kernel code. This name was the first thing which made me suspicious. OwningTask implies an ownership relationship which might lead kernel extension developers to believe that behind the scenes IOKit is actually maintaining an ownership relationship which will ensure that the lifetime of this userclient will always be dominated by the lifetime of the owningTask. This is a dangerous assumption, and this blog post is really the fallout from questioning this assumption. Let’s keep following the flow of this code into the kernel. Here’s a snippet from the kernel-side MIG deserialization code for io_service_open_extended:
mig_internal novalue _Xio_service_open_extended(  mach_msg_header_t *InHeadP,  mach_msg_header_t *OutHeadP){...  owningTask = convert_port_to_task(In0P->;
 RetCode = is_io_service_open_extended(              service,              owningTask,              In0P->connect_type,              In0P->ndr,              (io_buf_ptr_t)(In0P->properties.address),              In0P->propertiesCnt, &OutP->result, &connection);
The kernel has already copied-in all the rights contained in the message so In0P-> is actually a pointer to a struct ipc_port and not the mach port’s name as seen from userspace.
Here’s convert_port_to_task:
task_tconvert_port_to_task(  ipc_port_t port){  task_t task = TASK_NULL;
 if (IP_VALID(port)) {    ip_lock(port);    if (ip_active(port) &&        ip_kotype(port) == IKOT_TASK)    {      task = (task_t)port->ip_kobject;      assert(task != TASK_NULL);      task_reference_internal(task);    }    ip_unlock(port);  }
 return (task);}
This checks that the port argument really is a task port object then takes a reference on the task by calling task_reference and returns the task_t pointer. task_t is a typedef for a pointer to a struct task and as you can see from the code it’s a reference-counted object.
is_is_service_open_extended doesn’t do anything with owningTask other than passing it to ::newUserClient:
 res = service->newUserClient(    owningTask,    (void *) owningTask,    connect_type,    propertiesDict,    &client );
newUserClient is an IOService method which can be overridden by an IOService if they want to offer multiple userclient types. Otherwise the default implementation will look up the IOService’s IOUserClient subclass class name in the IOKit registry, allocate it via IOKit’s reflection API and call its ::initWithTask method. The default implementation of ::initWithTask also doesn’t do anything with owningTask.
Having looked through the code this far it looks like it’s not the case that by default the owningTask is going to hold a reference on the userclient (which would prevent the userclient taking a reference on the task and causing a reference cycle.) In fact it’s clearly quite the opposite; the userclient must take a reference on the owningTask if it wishes to keep a reference to the owningTask - there’s no implicit ownership relationship at all.Checking the docsThere aren’t a whole lot of resources for writing OS X kernel extensions. Apple does publish a sample kext on their developer site called AppleSamplePCI which provides examples of various IOKit design patterns. Here’s the AppleSamplePCI.kext implementation of initWithTask:
bool SamplePCIUserClientClassName::initWithTask(  task_t owningTask,  void* securityID,  UInt32 type,  OSDictionary* properties){  bool success = super::initWithTask(owningTask,                                     securityID,                                     type,                                     properties);  fTask = owningTask;  fDriver = NULL;
 return success;}
The sample userclient stores the owningTask argument in the fTask member variable without taking a reference. Without that reference there’s no guarantee that the task struct pointed to by fTask hasn’t been freed after this method returns. Looking through the rest of the sample kext we can see that some external methods use the fTask pointer to create memory descriptors - if we can get the task struct pointed to by fTask to be freed these will be using a dangling pointer.
Opening up a handful of other OS X kexts in IDA it’s pretty clear that lots of them follow this anti-pattern of holding a task_t pointer without taking a reference.Creating a dangling task_tMach messages provide very flexible and powerful IPC building blocks. One of the neat things you can do is send other processes send-rights to mach ports for which you hold send or receive rights.
Because task ports give you complete control over other tasks the api to request the task port for another task (task_for_pid) is privileged but since all tasks have send rights to their own task ports if we have code execution in two tasks we can send a send-right to the second task’s task port to the first.
In this case we’ll use the technique outlined by Robert Sesek to create a shared mach port between a parent and forked child by stashing a send-right in the bootstrap_port special port slot. After the fork the child can recover this stashed port, restore the bootstrap port and set up a bi-directional IPC channel over which it can send its task port back to the parent.
Triggering the UaF in the vulnerable anti-pattern looks like this:
  • parent forks off a child
  • child sends its task port back to its parent
  • child spins
  • parent receives child’s task port and creates a vulnerable IOKit userclient passing the child’s task port as owningTask
  • parent destroys its send right to the child’s task port
  • parent kills child, freeing the task struct of the child
  • parent has a userclient with a dangling task struct pointer
A first exploitLooking through the IOKit drivers which had this bug, one jumped out as being particularly interesting - IOSurfaceRootUserClient. Here’s what the Apple developer docs have to say about IOSurface:
The IOSurface framework provides a framebuffer object suitable for sharing across process boundaries. It is commonly used to allow applications to move complex image decompression and draw logic into a separate process to enhance security.
In reality IOSurfaces are just wrappers around shared memory buffers. On OS X we can talk to the IOSurface kernel extension from inside the Safari renderer sandbox and the Chrome GPU sandbox, amongst others.
The IOSurfaceRootUserClient class has exactly the same anti-pattern as we saw in the AppleSamplePCI client where the userclient stores a copy of the owningTask pointer as a member variable without taking a reference. Some reversing tells us that external method 0 of IOSurfaceRootUserClient is create_surface which takes a dictionary of key-value parameters used to create a shared memory object that other processes can map into their address spaces. By passing the following keys and values we can get IOSurfaceRootUserClient to wrap existing userspace pages in an IOSurface rather than allocating a new buffer:
 IOSurfaceAddress:   base_address  IOSurfaceAllocSize: size  IOSurfaceIsGlobal:  true
The IOSurface object actually just wraps an IOMemoryDescriptor which is allocated in IOSurface::allocate by calling:
IOMemoryDescriptor *IOMemoryDescriptor::withAddressRange(  mach_vm_address_t address,  mach_vm_size_t length,  IOOptionBits   options,  task_t         task);
The final task_t task argument to IOMemoryDescriptor::withAddressRange defines which task’s virtual memory the descriptor should be created for. IOSurface passes the member variable storing its copy of owningTask here, on which it doesn’t hold a reference! If we can get that task struct memory to be freed (by the original task exiting), reallocated (by another task starting) and used as the task struct for a more privileged task then this IOMemoryDescriptor will believe it’s wrapping a portion of the current process’s address space when it’s actually wrapping a portion of that other more privileged task’s virtual memory in the IOMemoryDescriptor which backs this IOSurface.
Setting IOSurfaceIsGlobal=true makes that surface available to other processes so that by calling external method 6 (lookup_surface) on another IOSurfaceRootUserClient created with our own legitimate task port as the owningTask we can build a primitive which allows us to map arbitrary portions of other process’s address spaces into our own :-)
Since the IOMemoryDescriptor is actually creating shared memory mappings of those pages we can write to them and those writes will also be reflected in the other process. IOSurfaceRootUserClient doesn’t allow us to map executables pages from the victim but we can still map for example the __DATA segment of libraries. This is made easier by the shared library cache being at the same virtual address in all processes.Putting the exploit togetherWe need a way to get the task struct reused by a more privileged process and then we need something to overwrite in the target to get code execution.
Task structs are allocated from their own kernel heap zone which greatly simplifies things. We can just kill the child and fork and exec a few suid-root binaries and they are very likely to re-use the same memory pointed to by the dangling task_t.
For the overwrite target I chose to target the __cleanup pointer in libc. This will be called when the process exits.  We can play a few tricks to block the binary just before it exits by setting its stderr file descriptor to a full pipe and forcing it to write an error message giving us plenty of time to exploit the bug in the parent process and overwrite the __cleanup pointer before emptying the pipe in the parent. I chose to point the function pointer to a gadget which adds a large constant to RSP and returns. Doing this moves the stack pointer up into argv and since we exec’ed this binary I put a simple ROP stack there to call setuid(0) and execve /bin/bash. The ROP payload is prefixed with a large number of ret-slide gadgets so it should be stable across most versions of OS X.
You can download this exploit and check out the original bug report.
Since this bug also allows us to gain any entitlements we want as well as root it’s easy to use it to defeat kernel code signing on OS X and load an unsigned kernel extension. See the exploit for CVE-2016-1757 for one way to do this.
Although this exploit uses fork and execve they aren’t actually required - the only prerequisite for triggering the bug is that you need code execution in two co-operating processes which can send mach messages to each other, and for this particular bug to be able to talk to IOSurface. Damien DeVille has a blog post discussing ways of achieving this from within the app sandbox on iOS using application groups. It’s also not necessary to exec a suid-root binary: we could cause the freed task struct to be reused by another more privileged task by looking up a mach service via launchd or deliberately crashing and causing launchd to run the CrashReporter.
Many individual instances of this bug were fixed in OS X 10.11.6/iOS 9.3.3 and Apple shipped a mitigation to prevent passing other task’s task ports to certain IOKit methods.Stepping backThis use-after-free bug is quite fun but it obscures a far deeper and more concerning issue. If the IOSurfaceRootUserClient now calls task_reference() on owningTask, and owningTask has to be the original creator of the userclient, is there still a bug?
Earlier this year osxreverser@ and I both independently published research about a problem with the execve syscall. In that case there was a race condition due to the order in which execve performed certain operations when loading a suid binary which left a small race window between the new memory map being created and the old task port being invalidated.
There’s a far more fundamental problem: the execve syscall doesn’t actually create a new task struct, even when it executes a more privileged suid binary. It just modifies the existing task struct in-place and any objects which previously had a task_t pointer now have one to a more privileged task.
This isn’t temporal memory safety - there’s no use-after-free involved. Lets look in detail at why that’s such a large problem for XNU.XNU’s Neither Unix Nor MachIn a pure Mach microkernel invalidating the old task port would be sufficient to prevent any other process from maintaining control of a task across a privilege-escalating exec, but XNU isn’t a microkernel. Earlier we looked at the kernel function convert_port_to_task which takes a mach task port and converts it into a task struct pointer. This pointer can then be used and passed around within the kernel without all the overhead of sending messages. For example when IOKit wants to manipulate the virtual memory of a process, rather than having to send a mach message to the mach_vm MIG subsystem (which it could theoretically do) it instead directly calls the responsible kernel function.
Another way to think of this is that all the MIG subsystems which live in the kernel (IOKit, mach_vm, tasks, threads, semaphores etc) are directly linked against each other. They can simply call the target functions rather than going via the MIG IPC layer. This is obviously massively faster, but comes at a cost.Every task_t pointer is a potential security bugThe tradeoff is that now there’s no central point where access to a resource can be cut off. In the kernel they can’t just invalidate the task port when a privileged exec happens and expect that to work because the kernel-internal MIG subsystems don’t use task ports, they just translate between task ports and task struct pointers once at the user/kernel boundary. The kernel has no idea where all the kernel pointers to a task’s task struct are; it can’t hope to invalidate them.
This is a much bigger problem than the original reference counting bug. When a privilege-escalating exec takes place execve doesn’t create a new process; the task struct stays the same, just the privileges change. This means that every single task_t pointer in the kernel is a potential security bug - there’s no locking mechanism to let you assert that the privileges of a task struct haven’t changed since you got access to it and just because kernel code got access to a task struct at one time doesn’t mean it should have access later.On the heap: rewriting the IOSurface exploitWe actually only need to slightly tweak the original IOSurface exploit to work even with the correct task_reference(owningTask) call. Instead of the child passing its task port back to the parent we’ll instead create the IOSurfaceRootUserClient in the child (correctly using the child’s own task port) and pass that userclient port back to the parent.
The child can then execve a suid-root binary which will set the EUID of the task to 0 without freeing the task struct. The parent still has a send right to the IOSurfaceRootUserClient, and that userclient’s owningTask now has EUID 0. The parent can then proceed as before, blocking the child, mapping the target’s libc __DATA segment, overwriting a function pointer and unblocking the child so that it tries to exit and executes the ROP stack. This new exploit also defeats the mitigation added in 10.11.6 which stops the creation of userclients with other task’s task ports.
Note that there are no failure cases for this exploit - there’s no race to win and no use-after-free which could go wrong. The exploit should work on all OS X versions <= 10.11.6.
This primitive is slightly less powerful than the use after free, which could break you out of very restrictive sandboxes, as you do need to call execve. These IOKit objects which store task_t pointers on the heap are really just the top of the iceberg though.On the stack: exploiting task_threadsBack closer to the user/kernel boundary as soon as convert_port_to_task has converted a task port received from userspace into a task struct pointer, that task could exec a suid-root or entitled binary and increase its privileges. Even if that task struct pointer isn’t stored on the heap there could still be an exploitable bug. Once case of this is the kernel MIG task_threads method:
kern_return_ttask_threads(  task_t target_task,  thread_act_array_t *act_list,  mach_msg_type_number_t *act_listCnt );
Given a send right to a task port this method returns send rights to the thread ports for each of the threads in that task. Here’s a snippet from MIG auto-generated code in the kernel:
 target_task = convert_port_to_task(    In0P->Head.msgh_request_port); // (1)  RetCode = task_threads(              target_task,              (thread_act_array_t *)&(OutP->act_list.address),              &OutP->act_listCnt);  task_deallocate(target_task);
Here we see that the task port is converted into the underlying task struct pointer which is then stored in the target_task local variable which lives for the duration of this function call.
Here’s the relevant code from task_threads:
 task_threads(    task_t task,    thread_act_array_t *threads_out,    mach_msg_type_number_t *count)  {    ...    for (thread = (thread_t)queue_first(&task->threads);         i < actual;         ++i, thread = (thread_t)queue_next(&thread->task_threads)) {      thread_reference_internal(thread);      thread_list[j++] = thread;    }
     for (i = 0; i < actual; ++i)        ((ipc_port_t *) thread_list)[i] = convert_thread_to_port(thread_list[i]); // (2)      }    ...  }

This code iterates through the list of threads collecting the struct thread pointers then converts those struct threads to thread ports and returns. There are a handful of locks in the code but they’re not relevant.
What happens if that task is exec-ing a suid root binary at the same time?
The relevant parts of the exec code are these two points in ipc_task_reset and ipc_thread_reset:
 void  ipc_task_reset(    task_t    task)  {    ipc_port_t old_kport, new_kport;    ipc_port_t old_sself;    ipc_port_t old_exc_actions[EXC_TYPES_COUNT];    int i;
   new_kport = ipc_port_alloc_kernel();    if (new_kport == IP_NULL)      panic("ipc_task_reset");
   old_kport = task->itk_self;
   if (old_kport == IP_NULL) {      itk_unlock(task);      ipc_port_dealloc_kernel(new_kport);      return;    }
   task->itk_self = new_kport;    old_sself = task->itk_sself;    task->itk_sself = ipc_port_make_send(new_kport);    ipc_kobject_set(old_kport, IKO_NULL, IKOT_NONE); // (3)
This is followed by a call to ipc_thread_reset:
 ipc_thread_reset(    thread_t  thread)  {    ipc_port_t old_kport, new_kport;    ipc_port_t old_sself;    ipc_port_t old_exc_actions[EXC_TYPES_COUNT];    boolean_t  has_old_exc_actions = FALSE;    int      i;
   new_kport = ipc_port_alloc_kernel();    if (new_kport == IP_NULL)      panic("ipc_task_reset");
   old_kport = thread->ith_self;
   if (old_kport == IP_NULL) {      thread_mtx_unlock(thread);      ipc_port_dealloc_kernel(new_kport);      return;    }
   thread->ith_self = new_kport; // (4)
Let's call the process which is doing the exec process B and the process calling task_threads() process A and imagine the following interleaving of execution:
A:  target_task = convert_port_to_task(    In0P->Head.msgh_request_port); // (1)  A gets pointer to process B's task struct on the stack
B:  ipc_kobject_set(old_kport, IKO_NULL, IKOT_NONE); // (3)  B is execing a suid binary and invalidates the old task port so that it no longer has a task struct pointer
B:  thread->ith_self = new_kport; // (4)  B allocates new thread ports and sets them up
A:  ((ipc_port_t *) thread_list)[i] = convert_thread_to_port(thread_list[i]); // (2)  A reads and converts the new thread port objects for B’s privileged threads giving A a privileged thread port
Send rights to a thread port give you complete register control. The exploit proceeds in a similar fashion to the previous two except that once it’s got the thread port it can directly point RIP to the gadget address rather than overwriting a function pointer. This race window is quite tight as is requires a very particular interleaving of execution but it does work. Check out the exploit and the original bug report.Mitigations round 2The release of iOS 10/MacOS 10.12 brought another round of mitigations to defeat.Firstly on the IOKit side userclient lifetime is now directly tied to that of the creating task. Secondly there’s a mitigation in ipc_kobject server to detect when a MIG kernel method has raced an execve syscall and force the method to fail if a race was detected:
/* * Check if the port is a task port, if its a task port then * snapshot the task exec token before the mig routine call. */ipc_port_t port = request->ikm_header->msgh_remote_port;if (IP_VALID(port) && ip_kotype(port) == IKOT_TASK) {  task = convert_port_to_task_with_exec_token(port, &exec_token);}
(*ptr->routine)(request->ikm_header, reply->ikm_header);
/* Check if the exec token changed during the mig routine */if (task != TASK_NULL) {  if (exec_token != task->exec_token) {    exec_token_changed = TRUE;  }  task_deallocate(task);}
There are three flaws with this mitigation:
  1. It only inspects the first argument, there are kernel MIG methods which take a task port in a different position.
  2. It only checks for task ports, these issues also affect thread_ports in a similar way
  3. It only mitigates cases of the bug where we need to get the resources which are returned by the MIG call (eg ports.) There are plenty of other methods which actually directly modify the process state rather than returning new ports.
Exploiting the 2nd round mitigationsAlthough we can no longer directly get a new thread port via task_threads there are still some more roundabout ways to get it. We just need an API which modifies state rather than directly returning something useful (like a task port) to us.
task_set_exception_port allows us to set a the exception port for a task. When an exception is raised (for example by accessing invalid memory) the kernel will send an exception message to the registered exception handler. Importantly for us that exception message contains the task and thread ports for the thread which caused the exception.
Like almost all places in the kernel with a task_t on the stack this api has a vulnerable race condition. In process A we’ll keep calling task_set_exception_ports() passing B’s task port while B execve’s a suid binary:
mig_internal novalue _Xtask_set_exception_ports(  mach_msg_header_t *InHeadP,  mach_msg_header_t *OutHeadP) {...  task = convert_port_to_task(In0P->Head.msgh_request_port); // (1)
 OutP->RetCode =    task_set_exception_ports(task,                             In0P->exception_mask,                             In0P->,                             In0P->behavior,                             In0P->new_flavor);  task_deallocate(task);...

kern_return_ttask_set_exception_ports(  task_t                task,  exception_mask_t      exception_mask,  ipc_port_t            new_port,  exception_behavior_t  new_behavior,  thread_state_flavor_t new_flavor){...  itk_lock(task); // (2)
 for (i = FIRST_EXCEPTION; i < EXC_TYPES_COUNT; ++i) {    if ((exception_mask & (1 << i)) ) {      old_port[i] = task->exc_actions[i].port;      task->exc_actions[i].port = ipc_port_copy_send(new_port); // (3)      task->exc_actions[i].behavior = new_behavior;      task->exc_actions[i].flavor = new_flavor;      task->exc_actions[i].privileged = privileged;    }...  itk_unlock(task);...
Process B calls execve to exec a privileged suid binary:
ipc_task_reset(  task_t  task){...  itk_lock(task); // (4)...  ip_lock(old_kport);  ipc_kobject_set_atomically(old_kport, IKO_NULL, IKOT_NONE); // (5)  task->exec_token += 1;  ip_unlock(old_kport);
 ipc_kobject_set(new_kport, (ipc_kobject_t) task, IKOT_TASK);
 for (i = FIRST_EXCEPTION; i < EXC_TYPES_COUNT; i++) {...    if (!task->exc_actions[i].privileged) {      old_exc_actions[i] = task->exc_actions[i].port;      task->exc_actions[i].port = IP_NULL; // (6)    }  }
 itk_unlock(task); //(7)
We’re looking for the following interleaving:
A:task = convert_port_to_task(In0P->Head.msgh_request_port); // (1)
B:itk_lock(task); // (4)
ipc_kobject_set_atomically(old_kport, IKO_NULL, IKOT_NONE); // (5)
task->exc_actions[i].port = IP_NULL; // (6)
itk_unlock(task); //(7)
A:itk_lock(task); // (2)
task->exc_actions[i].port = ipc_port_copy_send(new_port); // (3)
This race condition is far easier to win than the task_threads case as the locks make sure that everything lines up nicely for us. We just need to call task_set_exception_ports in a loop and hope that (1) gets called by A just before B takes the task lock at (4). In practise the exploit wins the race in a few milliseconds.
The final trick is to actually make sure that if we win the race we force the child to cause an exception and send us its task and thread ports. We can do this by calling setrlimit(RLIMIT_STACK) with a very small value just before execing the suid target. This means that the binary will be run with a tiny stack and will almost immediately segfault.
In the parent once the task_set_exception_port call has failed we try to receive on the exception port with a short timeout. If a message is received then we won the race and that message contains the task and thread ports for an euid 0 process. In this case the exploit allocates some RWX memory in the task and copies a shellcode stub into there which does this:
 struct rlimit lim = {0x1000000, 0x1000000};  setrlimit(RLIMIT_STACK, lim);  setuid(0);  char* argv[2] = {"/bin/bash", 0};  execve("/bin/bash", argv, 0);
This shellcode sets the stack size back to a large value, does a setuid(0) to prevent bash dropping privileges and executes a shell.
This exploit should work reliably on all versions of MacOS/OS X 10.12.0 and below.The final fixThis isn’t an easy bug class to fix. Due to the design of XNU there are task_t pointers everywhere and the underlying issue affects more than just task_t; threads suffer from the same issue. Apple decided to refactor the execve code to allocate new task and thread structures when loading a binary which should fix the underlying issue. This is a considerable amount of work, kudos to Apple for the engineering effort they put into fixing these bugs and I look forward to the release of the MacOS 10.12.1 XNU source to see the new code.
Kategorie: Hacking & Security

Apple iOS users taste Android anxiety with nasty CoreGraphics image flaw

Sophos Naked Security - 25 Říjen, 2016 - 17:52
Apple's latest round of patches is a reminder that mobile platforms aren't very different to one another: they all run software and they are all fragile

Dirty COW — Critical Linux Kernel Flaw Being Exploited in the Wild

The Hacker News - 25 Říjen, 2016 - 17:07
A nine-year-old critical vulnerability has been discovered in virtually all versions of the Linux operating system and is actively being exploited in the wild. Dubbed "Dirty COW," the Linux kernel security flaw (CVE-2016-5195) is a mere privilege-escalation vulnerability, but researchers are taking it extremely seriously due to many reasons. First, it's very easy to develop exploits that
Kategorie: Hacking & Security

Joomla Joomla! Two Critical Flaws Discovered — Update to Protect Your Site

The Hacker News - 25 Říjen, 2016 - 16:50
Joomla – the world's second popular open source Content Management System (CMS) software packages, has just released the latest version of its CMS, which includes patches for two critical security vulnerabilities and a bug fix. <!-- adsense --> The two critical flaws, both exist in the Joomla Core functionalities, include Account Creation Vulnerability (CVE-2016-8870) and Elevated Privileges
Kategorie: Hacking & Security

Election Leaks Failed to Move Needle on Polls

Threatpost - 25 Říjen, 2016 - 16:20
The barrage of information leaks, state-sponsored espionage and hacktivism related to the U.S. presidential election has had a mixed bag of effects on the race and voter confidence.
Kategorie: Hacking & Security

Nejlepší antivirové nástroje pro rychlou kontrolu souborů na webu - bezpečnost - 25 Říjen, 2016 - 15:14
** Podezřelá příloha e-mailu nebo neznámý spouštěcí soubor jsou kandidáty na online kontrolu ** Ta nemusí probíhat pouze v rámci běžného antivirového balíku ** Na webu existuje několik služeb, kam stačí soubor pouze nahrát a vyčkat na analýzu
Kategorie: Hacking & Security

Find Your Keys, Lose Your Privacy

Threatpost - 25 Říjen, 2016 - 15:05
Small Bluetooth-enabled trackers from TrackR, iTrack and Nut are the latest connected devices to pose a privacy risk to users.
Kategorie: Hacking & Security

Útočníci obejdou i autorizační SMS z banky. Stačí jim k tomu Facebook - bezpečnost - 25 Říjen, 2016 - 14:57
Česká spořitelna varuje před útočníky, kteří využívají Facebook pro získání autorizačních kódů internetového bankovnictví. Ty jsou standardně doručovány formou textové zprávy. Pokud se například díky phishingu dostanou přes přihlašovací formulář do správy účtu, stále jim budou scházet potvrzovací ...
Kategorie: Hacking & Security

How hackers broke into John Podesta, DNC Gmail accounts

Sophos Naked Security - 25 Říjen, 2016 - 14:07
At the heart of enormous breaches lies a tiny thing: rigged Bitly shortened URLs.
Syndikovat obsah