Shodan is a search engine which does not index web sites or web contents, but vulnerable devices on the internet. To set up this index and to keep it up to date, Shodan uses at least 16 scanners with different AS numbers and different physical locations.
In case you want to block those scanners, this guide might help.
Set up host definitions
First, set up host definitions in the firewall menu and put in the following hosts (it might be useful to put in the rDNS name as a hostname):
Known Shodan scanners (last updated 2022-02-16)
rDNS name
IP address
Location
shodan.io ((it is unclear if this is a scanner IP))
208.180.20.97
US
census1.shodan.io
198.20.69.74
US
census2.shodan.io
198.20.69.98
US
census3.shodan.io
198.20.70.114
US
census4.shodan.io
198.20.99.130
NL
census5.shodan.io
93.120.27.62
RO
census6.shodan.io
66.240.236.119
US
census7.shodan.io
71.6.135.131
US
census8.shodan.io
66.240.192.138
US
census9.shodan.io
71.6.167.142
US
census10.shodan.io
82.221.105.6
IS
census11.shodan.io
82.221.105.7
IS
census12.shodan.io
71.6.165.200
US
atlantic.census.shodan.io
188.138.9.50
DE
pacific.census.shodan.io
85.25.103.50
DE
rim.census.shodan.io
85.25.43.94
DE
pirate.census.shodan.io
71.6.146.185
US
ninja.census.shodan.io
71.6.158.166
US
border.census.shodan.io
198.20.87.98
US
burger.census.shodan.io
66.240.219.146
US
atlantic.dns.shodan.io
209.126.110.38
US
blog.shodan.io ((it is unclear if this is a scanner IP))
104.236.198.48
US
hello.data.shodan.io
104.131.0.69
US
www.shodan.io ((it is unclear if this is a scanner IP))
162.159.244.38
US
The additional following entries have been added on September, 2019:
rDNS name
IP address
Location
battery.census.shodan.io
93.174.95.106
SC
cloud.census.shodan.io
94.102.49.193
SC
dojo.census.shodan.io
80.82.77.139
SC
flower.census.shodan.io (PTR only)
94.102.49.190
SC
goldfish.census.shodan.io
185.163.109.66
RO
house.census.shodan.io
89.248.172.16
SC
inspire.census.shodan.io (PTR only)
71.6.146.186
US
mason.census.shodan.io
89.248.167.131
SC
ny.private.shodan.io
159.203.176.62
US
turtle.census.shodan.io (PTR only)
185.181.102.18
RO
sky.census.shodan.io
80.82.77.33
SC
shodan.io (PTR only)
216.117.2.180
US
The additional following entries have been added on February, 2022:
rDNS name
IP address
Location
einstein.census.shodan.io
71.6.199.23
US
hat.census.shodan.io
185.142.236.34
NL
red.census.shodan.io
185.165.190.34
US
soda.census.shodan.io
71.6.135.131
US
wine.census.shodan.io
185.142.236.35
NL
The additional following entries have been added on 21st September, 2022:
rDNS name
IP address
Location
wall.census.shodan.io
66.240.219.133
US
floss.census.shodan.io
143.198.225.197
US
dog.census.shodan.io
137.184.95.216
US
draft.census.shodan.io
64.227.90.185
US
can.census.shodan.io
143.198.238.87
US
pack.census.shodan.io
137.184.190.205
US
jug.census.shodan.io
137.184.112.192
US
elk.census.shodan.io
137.184.190.188
US
tab.census.shodan.io
167.172.219.157
US
buffet.census.shodan.io
143.110.239.2
US
deer.census.shodan.io
143.198.68.20
US
The additional following entries have been added on 30th September, 2022:
rDNS name
IP address
Location
sparkle.census.shodan.io
137.184.190.194
US
fish.census.shodan.io
137.184.190.246
US
heimdal.scan6x.shodan.io (PTR only)
137.184.9.17
US
gravy.scanf.shodan.io (PTR only)
137.184.13.100
US
scanme.scanf.shodan.io (PTR only)
137.184.94.133
US
frame.census.shodan.io (PTR only)
137.184.112.103
US
collector.chrono.shodan.io (PTR only)
137.184.180.190
US
ships.data.shodan.io
143.198.50.234
US
The additional following entries have been added on 30th September, 2022. These were obtained by using the above IP addresses and then scanning any /16 subnet with more than one IP address in it. They have not necessarily been seen scanning. Note the the same rDNS record can be returned by multiple IPs:
rDNS name
IP address
Location
green.census.shodan.io
185.142.236.36
NL
blue.census.shodan.io
185.142.236.40
NL
guitar.census.shodan.io
185.142.236.41
NL
blue2.census.shodan.io
185.142.236.43
NL
red2.census.shodan.io
185.142.239.16
NL
census2.shodan.io
198.20.69.96/29
US
census3.shodan.io
198.20.70.112/29
US
border.census.shodan.io
198.20.87.96/29
US
census4.shodan.io
198.20.99.128/29
NL
malware-hunter.census.shodan.io
66.240.205.34
US
refrigerator.census.shodan.io
71.6.146.130
US
board.census.shodan.io
71.6.147.198
US
tesla.census.shodan.io
71.6.147.254
US
thor.data.shodan.io
71.6.150.153
US
grimace.data.shodan.io
71.6.167.125
US
house.census.shodan.io
89.248.172.7
NL
Sources: own research, log reviews.
Contributor Note!
if you DROP ranges that were in the notorious “AS29073 Quasi Networks LTD” already, you’re already banning the “SC” (Seychelles) sources detailed above; those ranges have been inherited by AS202425. “AS9009 M247 Ltd” contributes to most of the “RO” (Romania) sources; furtherly M247 (AS9009) seem to be the exit point of most NordVPN/pureVPN and many low cost script-kiddies VPN. Firewalling them is usefull for `quietness. Interactions between shodan and m247 seems to be very close.
You might add a comment to each host, such as “scanner” or “shodan” to make clear why you added those.
It is possible to block other common scanners here, too. However, please keep in mind that this isn’t a technique which is very scalable. Please consider running an IPS, if possible.
Second, set up a firewall group and add all those host entries to it. Add a title and a comment to this firewall group. In this guide, we assume you have named the group “shodanscanners”.
Set up firewall rule
Third, create a new firewall rule. Set the “shodanscanners” group as source. For destination, use “standard networks” and set this to “any”. Set “rule action” to “drop”.
The setting “reject” is not recommended here, since the firewall will send an ICMP status message to the host(s) which triggered the firewall rule. By this, however, the host knows that there is something which at least sends ICMP errors back. To avoid this, “drop” is suitable because the network packets will be dropped silently and there is no way of telling (without additional scans) wether the target IP address is just down or drops network packages.
Enter a comment, if you want to and hit “add” to set the new firewall rule.
Please make sure that this rule is placed before rules which accept something (i.e. port forwarding rules) so that shodan scan traffic will be blocked instantly.
Reload the firewall engine to apply the new rule.
Limitations of this rule
The OpenVPN service will not be protected – OVPNINPUT firewall chain is above the chain where this rule will land.
Limitations of this guide
Nobody (and nothing) is perfect. This guide isn’t either. 😉
For example, if the IP addresses of the Shodan scanners change, your firewall rule will be probably useless and does not provide any protection against the scanners any more. Consider setting up an IPS for additional protection since some rules there will also block other scanners which are not mentioned here.
Blocking Shodan scanner is fine, but I want to block all scanners This is basically possible. However, it is a nightmare to set up a firewall host group which covers all IPs which belong to scanners. (And it is also a nightmare to find out those IP addresses since most scanners do not just put them on their web sites…) In case you are thinking similar, setting up an IPS in combination with suitable rules (this is just one example, there are many out there) might be a solution for you.
In this blog entry, we provide technical details and analysis on the 3CX attacks as they happen. We also discuss available solutions which security teams can maximize for early detection and mitigate the impact of 3CX attacks.
By: Trend Micro Research March 30, 2023 Read time: 7 min (1870 words)
Updated on:
April 5, 2:39 a.m. EDT: We added Windows, Mac, and network commands to the Trend Micro Vision One™️ guide in the linked PDF.
April 4, 3:29 a.m. EDT: We added Trend Micro XDR filters to the solutions.
April 3, 2:33 a.m. EDT: We added details on d3dcompiler_47.dll‘s abuse of CVE-2013-3900 to make it appear legitimately signed.
April 1, 1:50 a.m. EDT: We added a guide on how Vision One can be used to search for potential threats associated with the 3CX desktop app.
March 31, 11:07 p.m. EDT: We added technical details, an analysis of the info-stealer payload, and information on Trend Micro XDR capabilities for investigating and mitigating risks associated with the 3CX desktop app.
March 31, 3:00 a.m. EDT: We added the execution flow diagram, a link to Trend Micro support page, and a list of Mac IOCs and detection names.
In late March 2023, security researchers revealed that threat actors abused a popular business communication software from 3CX — in particular, thereports mention that a version of the 3CX VoIP (Voice over Internet Protocol) desktop client was being employed to target 3CX’s customers as part of an attack.
On its forums, 3CX has posted an update that recommends uninstalling the desktop app and using the Progressive Web App (PWA) client instead. The company also mentioned that they are working on an update to the desktop app.
For a more comprehensive scope of protection against possible attacks associated with the 3CX Desktop App, the Trend Micro XDR platform can help organizations mitigate the impact by collecting and analyzing extensive activity data from various sources. By applying XDR analytics to the data gathered from its native products, Trend Micro XDR generates correlated and actionable alerts.
Trend Micro customers can also take advantage of Trend Micro Vision One™ to search for and monitor potential threats associated with the 3CX Desktop App, and to better understand observed attack vectors. For more information on how to utilize Trend Micro Vision One features, you may download the PDF guide here.
Additional guidance for Trend Micro customers including help with protection and detection can be found on our support page.
What is the compromised application?
The 3CX app is a private automatic branch exchange (PABX) software that provides several communication functions for its users, including video conferencing, live chat, and call management. The app is available on most major operating systems, including Windows, macOS, and Linux. Additionally, the client is available as a mobile application for both Android and iOS devices, while a Chrome extension and the PWA version of the client allow users to access the software through their browsers.
The issue was said to be limited to the Electron (non-web versions) of their Windows package (versions 18.12.407 and 18.12.416) and macOS clients (versions 18.11.1213, 18.12.402, 18.12.407 and 18.12.416).
According to the company’s website, more than 600,000 businesses and over 12 million daily users around the world use 3CX’s VoIP IPBX software.
How does the attack work?
The attack is reportedly a multi-stage chain in which the initial step involves a compromised version of the 3CX desktop app. Based on initial analysis, the MSI package (detected by Trend Micro as Trojan.Win64.DEEFFACE.A and Trojan.Win64.DEEFFACE.SMA) is the one that is compromised with possible trojanized DLLs, since the .exe file has the same name.
The infection chain begins with 3CXDesktopApp.exe loading ffmpeg.dll (detected as Trojan.Win64.DEEFFACE.A andTrojan.Win64.DEEFFACE.SMA). Next, ffmpeg.dll reads and decrypts the encrypted code from d3dcompiler_47.dll (detected as Trojan.Win64.DEEFFACE.A and Trojan.Wind64.DEEFACE.SMD3D).
The decrypted code seems to be the backdoor payload that tries to access the IconStorages GiHub page to access an ICO file (detected as Trojan.Win32.DEEFFACE.ICO) containing the encrypted C&C server that the backdoor connects to in order to retrieve the possible final payload. In addition, d3dcompiler_47.dll also abuses CVE-2013-3900 to make it appear that it is legitimately signed.
Figure 1. The detailed execution flow and Trend Micro detections of the malicious files. The MSI installer contains the .exe and two .dll files. The main source of the detection in the MSI installer is “ffmpeg.dll,” which is the trojanized DLL.
As part of its attack routine, it contacts the servers noted in the list of indicators of compromise (IOCs) at the end of this blog entry. These domains are blocked by the Trend Micro Web Reputation Services (WRS).
Execution flow
Upon execution, the MSI package installer will drop the following files that are related to malicious behavior. Trend Micro Smart Scan Pattern (cloud-based) TBL 21474.300.40 can detect these files as Trojan.Win64.DEEFFACE.A.
3CXDesktopApp.exe: A normal file that is abused to load the trojanized DLL
ffmpeg.dll: A trojanized DLL used to read, load, and execute a malicious shellcode from d3dcompiler_47.dll
d3dcompiler_47.dll: A DLL appended with an encrypted shellcode after the fe ed fa ce hex string
Some conditions are necessary for execution. For example, the sleep timestamp varies depending on the following conditions: First, it checks if the manifest file is present, as well as if it is using a specified date. If the file is not present or if it is using the specified date, the timestamp will generate a random number and use the formula rand() % 1800000 + current date + 604800 (604,800 is seven days). After the date is computed, the malware will continue its routine.
Upon execution of 3CXDesktopApp.exe, ffmpeg.dll, which seems to be a trojanized or patched DLL, will be loaded. It will still contain its normal functionalities, but it will have an added malicious function that reads d3dcompiler_47.dll to locate an encrypted shellcode after the fe ed fa ce hex strings.
Figure 2. Reading “d3dcompiler_47.dll” and locating the “fe ed fa ce” hex string
Upon decryption of the malicious shellcode using RC4 with the key, 3jB(2bsG#@c7, the shellcode will then try to access the GitHub repository that houses the ICO files containing the encrypted C&C strings that use Base64 encoding and AES + GCM encryption at the end of the image.
These B64 strings seem to be C&C domains that the shellcode tries to connect to for downloading other possible payloads. However, we were unable to confirm the exact nature of these payloads since the GitHub repository (raw.githubusercontent[.]com/IconStorages/images/main/) had already been taken down at the time of this writing. Note that the process exits when the page is inaccessible.
Figure 3. Code snippet showing the hard-coded GitHub repositoryFigure 4. An ICO file from the GitHub repository
The above description applies to the Windows version. The behaviour of the Mac version is broadly similar, although it only uses a subset of the Windows C&C domains.
Info-stealer payload analysis
Based on our ongoing analysis of attacks on 3CX and the behaviors observed, the following section details what we know so far about the payload’s attack vector.
Payloads in investigated 3CX attacks are detected as TrojanSpy.Win64.ICONICSTEALER.THCCABC. Upon analysis of the payload named ICONIC Stealer, we discovered that if it is executed using regsvr32.exe as the DLL loader, it will display the following system error:
Figure 5. Error displayed upon executing the sample using “regsvr32.exe”
Meanwhile, if rundll32.exe is used as the DLL loader, it encounters a WerFault error and displays the following pop-up message:
Figure 6. Error displayed if “rundll32.exe” is used as the DLL loader
This indicates that the sample must be loaded by a specific application to proceed to its malicious routine.
ICONIC Stealer then checks for a file named config.json under the folder “3CXDesktopApp.”
Figure 7. Checking for “config.json”
ICONIC Stealer was then observed to steal the following system information:
HostName
DomainName
OsVersion
The gathered data will then be converted into a text-string format.
Figure 8. Converting gathered data into a text-string format
ICONIC Stealer then proceeds to its last behavior, which steals browser data. It uses the function shown in Figure 9 to traverse the infected system using predefined directories related to the browser’s history and other browser-related information.
Figure 9. Function for traversing the infected system
The following figure shows a list of predefined strings:
Figure 10. List of predefined strings
The system directories on the following list compose the targets identified in the partial analysis of the ICONIC Stealer’s behavior. More information will be provided as this blog is updated.
AppData\Local\Google\Chrome\User Data
AppData\Local\Microsoft\Edge\User Data
AppData\Local\BraveSoftware\Brave-Browser\User Data
AppData\Roaming\Mozilla\Firefox\Profiles
Browser
Target information
Chrome
History
Edge
History
Brave
History
Firefox
places.sqlite
Table 1. The targeted section of each browser. Note that “places.sqlite” stores the annotations, bookmarks, favorite icons, input history, keywords, and the browsing history of visited pages for Mozilla Firefox.
ICONIC Stealer was also found with the capability to limit the retrieved data to the first five hundred entries to ensure that the most recent browser activity is the data that is retrieved:
Figure 11. Limiting data to the first 500 entries
“UTF-16LE”, ‘SELECT url, title FROM urls ORDER BY id DESC LIMIT
“UTF-16LE”, ‘500’,0
“UTF-16LE”, ‘SELECT url, title FROM moz_places ORDER BY id DESC
“UTF-16LE”, ‘LIMIT 500’,0
Figure 12. Retrieved results stored on an allocated buffer
The gathered data will be passed to the main loader module to POST then back to the C&C server embedded in the main module.
What is its potential impact?
Due to its widespread use and its importance in an organization’s communication system, threat actors can cause major damage (for example, by monitoring or rerouting both internal and external communication) to businesses that use this software.
What can organizations do about it?
Organizations that are potentially affected should stop using the vulnerable version if possible and apply the patches or mitigation workarounds if these are available. IT and security teams should also scan for confirmed compromised binaries and builds and monitor for anomalous behavior in 3CX processes, with a particular focus on C&C traffic.
Meanwhile, enabling behavioral monitoring in security products can help detect the presence of the attack within the system.
The following domains are blocked by Trend Micro Web Reputation Services (WRS)
akamaicontainer[.]com
akamaitechcloudservices[.]com
azuredeploystore[.]com
azureonlinecloud[.]com
azureonlinestorage[.]com
dunamistrd[.]com
glcloudservice[.]com
journalide[.]org
msedgepackageinfo[.]com
msstorageazure[.]com
msstorageboxes[.]com
officeaddons[.]com
officestoragebox[.]com
pbxcloudeservices[.]com
pbxphonenetwork[.]com
pbxsources[.]com
qwepoi123098[.]com
sbmsa[.]wiki
sourceslabs[.]com
visualstudiofactory[.]com
zacharryblogs[.]com
Trend Micro XDR uses the following filters to protect customers from 3CX-related attacks:
Filter
ID
OS
Compromised 3CX Application File Indicators
F6669
macOS, Windows
DLL Sideloading of 3CX Application
F6668
Windows
Web Reputation Services Detection for Compromised 3CX Application
F6670
macOS, Windows
Suspicious Web Access of Possible Compromised 3CX Application
F6673
Windows
Suspicious DNS Query of Possible Compromised 3CX Application
F6672
Windows
Trend Micro Malware Detection Patterns for Endpoint, Servers (Apex One, Worry-Free Business Security Services, Worry-Free Business Security Standard/Advanced, Deep Security with anti-malware, among others), Mail, and Gateway (Cloud App Security, ScanMail for Exchange, IMSVA):
Starting with Trend Micro Smart Scan Pattern (cloud-based) TBL 21474.200.40, known trojanized versions of this application are being detected as Trojan Win64.DEEFFACE.A.
The Mac version of this threat is detected as Trojan.MacOS.FAKE3L3CTRON.A.
The SMTP protocol is the main protocol used to transfer messages between mail servers and is, by default, not secure. The Transport Layer Security (TLS) protocol was introduced years ago to support encrypted transmission of messages over SMTP. It’s commonly used opportunistically rather than as a requirement, leaving much email traffic in clear text, vulnerable to interception by nefarious actors. Furthermore, SMTP determines the IP addresses of destination servers through the public DNS infrastructure, which is susceptible to spoofing and Man-in-the-Middle (MITM) attacks. This vulnerability has led to many new standards being created to increase security for sending and receiving email, one of those standards being DNS-based Authentication of Named Entities (DANE).
DANE for SMTP RFC 7672 uses the presence of a Transport Layer Security Authentication (TLSA) record in a domain’s DNS record set to signal a domain and its mail server(s) support DANE. If there’s no TLSA record present, DNS resolution for mail flow will work as usual without any DANE checks being attempted. The TLSA record securely signals TLS support and publishes the DANE policy for the domain. So, sending mail servers can successfully authenticate legitimate receiving mail servers using SMTP DANE. This authentication makes it resistant to downgrade and MITM attacks. DANE has direct dependencies on DNSSEC, which works by digitally signing records for DNS lookups using public key cryptography. DNSSEC checks occur on recursive DNS resolvers, the DNS servers that make DNS queries for clients. DNSSEC ensures that DNS records aren’t tampered with and are authentic.
Once the MX, A/AAAA and DNSSEC-related resource records for a domain are returned to the DNS recursive resolver as DNSSEC authentic, the sending mail server will ask for the TLSA record corresponding to the MX host entry or entries. If the TLSA record is present and proven authentic using another DNSSEC check, the DNS recursive resolver will return the TLSA record to the sending mail server.
After the authentic TLSA record is received, the sending mail server establishes an SMTP connection to the MX host associated with the authentic TLSA record. The sending mail server will try to set up TLS and compare the server’s TLS certificate with the data in the TLSA record to validate that the destination mail server connected to the sender is the legitimate receiving mail server. The message will be transmitted (using TLS) if authentication succeeds. When authentication fails or if TLS isn’t supported by the destination server, Exchange Online will retry the entire validation process beginning with a DNS query for the same destination domain again after 15 minutes, then 15 minutes after that, then every hour for the next 24 hours. If authentication continues to fail after 24 hours of retrying, the message will expire, and an NDR with error details will be generated and sent to the sender.
Tip
If you’re not an E5 customer, use the 90-day Microsoft Purview solutions trial to explore how additional Purview capabilities can help your organization manage data security and compliance needs. Start now at the Microsoft Purview compliance portal trials hub. Learn details about signing up and trial terms.
What are the components of DANE?
TLSA Resource Record
The TLS Authentication (TLSA) record is used to associate a server’s X.509 certificate or public key value with the domain name that contains the record. TLSA records can only be trusted if DNSSEC is enabled on your domain. If you’re using a DNS provider to host your domain, the DNSSEC may be a setting offered when configuring a domain with them. To learn more about DNSSEC zone signing, visit this link: Overview of DNSSEC | Microsoft Docs.
Example TLSA record:
There are four configurable fields unique to the TLSA record type:
Certificate Usage Field: Specifies how the sending email server should verify the destination email server’s certificate.
Value
Acronym
Description
01
PKIX-TA
Certificate used is the trust-anchor Public CA from the X.509 trust-chain.
11
PKIX-EE
Certificate checked is the destination server; DNSSEC checks must verify its authenticity.
2
DANE-TA
Use server’s private key from the X.509 tree that must be validated by a trust anchor in the chain of trust. The TLSA record specifies the trust anchor to be used for validating the TLS certificates for the domain.
3
DANE-EE
Only match against the destination server’s certificate.
1 Exchange Online follows RFC implementation guidance that Certificate Usage Field values of 0 or 1 shouldn’t be used when DANE is implemented with SMTP. When a TLSA record that has a Certificate Usage field value of 0 or 1 is returned to Exchange Online, Exchange Online will treat it as not usable. If all TLSA records are found unusable, Exchange Online won’t perform the DANE validation steps for 0 or 1 when sending the email. Instead, because of the presence of a TLSA record, Exchange Online will enforce the use of TLS for sending the email, sending the email if the destination email server supports TLS or dropping the email and generating an NDR if the destination email server doesn’t support TLS.
In the example TLSA record, the Certificate Usage Field is set to ‘3’, so the Certificate Association Data (‘abc123…xyz789’) would be matched against the destination server’s certificate only.
Selector field: Indicates which parts of the destination server’s certificate should be checked.
Value
Acronym
Description
0
Cert
Use full certificate.
1
SPKI (Subject Public Key Info)
Use certificate’s public key and the algorithm with which the public key is identified to use.
In the example TLSA record, the Selector Field is set to ‘1’ so the Certificate Association Data would be matched using the destination server certificate’s public key and the algorithm with which the public key is identified to use.
Matching Type Field: Indicates the format the certificate will be represented in the TLSA record.
Value
Acronym
Description
0
Full
The data in the TSLA record is the full certificate or SPKI.
1
SHA-256
The data in the TSLA record is an SHA-256 hash of either the certificate or the SPKI.
2
SHA-512
The data in the TSLA record is an SHA-512 hash of either the certificate or the SPKI.
In the example TLSA record, the Matching Type Field is set to ‘1’ so the Certificate Association Data is an SHA-256 hash of the Subject Public Key Info from the destination server certificate
Certificate Association Data: Specifies the certificate data that is used for matching against the destination server certificate. This data depends on the Selector Field value and the Matching Type Value.
In the example TLSA record, the Certificate Association data is set to ‘abc123..xyz789’. Since the Selector Field value in the example is set to ‘1’, it would reference the destination server certificate’s public key and the algorithm that’s identified to be used with it. And since the Matching Type field value in the example is set to ‘1’, it would reference the SHA-256 hash of the Subject Public Key Info from the destination server certificate.
How can Exchange Online customers use SMTP DANE Outbound?
As an Exchange Online customer, there isn’t anything you need to do to configure this enhanced email security for your outbound email. This enhanced email security is something we have built for you and it’s ON by default for all Exchange Online customers and is used when the destination domain advertises support for DANE. To reap the benefits of sending email with DNSSEC and DANE checks, communicate to your business partners with whom you exchange email that they need to implement DNSSEC and DANE so they can receive email using these standards.
How can Exchange Online customers use SMTP DANE inbound?
Currently, inbound SMTP DANE isn’t supported for Exchange Online. Support for inbound SMTP DANE will be available in the near future.
What is the recommended TLSA record configuration?
Per RFC implementation guidance for SMTP DANE, a TLSA record composed of the Certificate Usage field set to 3, the Selector field set to 1, and the Matching Type field set to 1 is recommended.
Exchange Online Mail Flow with SMTP DANE
The mail flow process for Exchange Online with SMTP DANE, shown in the flow chart below, validates domain and resource record security through DNSSEC, TLS support on the destination mail server, and that the destination mail server’s certificate matches what is expected based on its associated TLSA record.
There are only two scenarios where an SMTP DANE failure will result in the email being blocked:
The destination domain signaled DNSSEC support but one or more records were returned as inauthentic.
All MX records for the destination domain have TLSA records and none of the destination server’s certificates match what was expected per the TSLA record data, or a TLS connection isn’t supported by the destination server.
Related Technologies
Technology
Additional Information
Mail Transfer Agent – Strict Transport Security (MTA-STS) helps thwart downgrade and Man-in-the-Middle attacks by providing a mechanism for setting domain policies that specify whether the destination email server supports TLS and what to do when TLS can’t be negotiated, for example stop the transmission.
More information about Exchange Online’s upcoming support for inbound and outbound MTA-STS will be published later this year.
DomainKeys Identified Mail (DKIM) uses X.509 certificate information to ensure that destination email systems trust messages sent outbound from your custom domain.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) works with Sender Policy Framework and DomainKeys Identified Mail to authenticate mail senders and ensure that destination email systems trust messages sent from your domain.
Currently, there are four error codes for DANE when sending emails with Exchange Online. Microsoft is actively updating this error code list. The errors will be visible in:
The Exchange Admin Center portal through the Message Trace Details view.
NDRs generated when a message isn’t sent due to a DANE or DNSSEC failure.
starttls-not-supported: Destination mail server must support TLS to receive mail.
4/5.7.322
certificate-expired: Destination mail server’s certificate is expired.
4/5.7.323
tlsa-invalid: The domain failed DANE validation.
4/5.7.324
dnssec-invalid: Destination domain returned invalid DNSSEC records.
Note
Currently, when a domain signals that it supports DNSSEC but fails DNSSEC checks, Exchange Online does not generate the 4/5.7.324 dnssec-invalid error. It generates a generic DNS error:
4/5.4.312 DNS query failed
We are actively working to remedy this known limitation. If you receive this error statement, navigate to the Microsoft Remote Connectivity Analyzer and perform the DANE validation test against the domain that generated the 4/5.4.312 error. The results will show if it is a DNSSEC issue or a different DNS issue.
Troubleshooting 4/5.7.321 starttls-not-supported
This error usually indicates an issue with the destination mail server. After receiving the message:
Check that the destination email address was entered correctly.
Alert the destination email administrator that you received this error code so they can determine if the destination server is configured correctly to receive messages using TLS.
Retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.
Troubleshooting 4/5.7.322 certificate-expired
A valid X.509 certificate that hasn’t expired must be presented to the sending email server. X.509 certificates must be renewed after their expiration, commonly annually. After receiving the message:
Alert the destination email administrator that you received this error code and provide the error code string.
Allow time for the destination server certificate to be renewed and the TLSA record to be updated to reference the new certificate. Then, retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.
Troubleshooting 4/5.7.323 tlsa-invalid
This error code is related to a TLSA record misconfiguration and can only be generated after a DNSSEC-authentic TLSA record has been returned. There are many scenarios during the DANE validation that occur after the record has been returned that can result in the code being generated. Microsoft is actively working on the scenarios that are covered by this error code, so that each scenario has a specific code. Currently, one or more of these scenarios could cause the generation of the error code:
The destination mail server’s certificate doesn’t match with what is expected per the authentic TLSA record.
Authentic TLSA record is misconfigured.
The destination domain is being attacked.
Any other DANE failure.
After receiving the message:
Alert the destination email administrator that you received this error code and provide them the error code string.
Allow time for the destination email admin to review their DANE configuration and email server certificate validity. Then, retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.
Troubleshooting 4/5.7.324 dnssec-invalid
This error code is generated when the destination domain indicated it was DNSSEC-authentic but Exchange Online wasn’t able to verify it as DNSSEC-authentic.
After receiving the message:
Alert the destination email administrator that you received this error code and provide them the error code string.
Allow time for the destination email admin to review their domain’s DNSSEC configuration. Then, retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.
Troubleshooting Receiving Emails with SMTP DANE
Currently, there are two methods an admin of a receiving domain can use to validate and troubleshoot their DNSSEC and DANE configuration to receive email from Exchange Online using these standards.
Adopt SMTP TLS-RPT (Transport Layer Security Reporting) introduced in RFC8460
TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 is a reporting mechanism for senders to provide details to destination domain administrators about DANE and MTA-STS successes and failures with those respective destination domains. To receive TLS-RPT reports, you only need to add a TXT record in your domain’s DNS records that includes the email address or URI you would like the reports to be sent to. Exchange Online will send TLS-RPT reports in JSON format.
Example record:
The second method is to use the Remote Connectivity Analyzer Microsoft Remote Connectivity Analyzer, which can do the same DNSSEC and DANE checks against your DNS configuration that Exchange Online will do when sending email outside the service. This method is the most direct way of troubleshooting errors in your configuration to receive email from Exchange Online using these standards.
When errors are being troubleshooted, the below error codes may be generated:
NDR Code
Description
4/5.7.321
starttls-not-supported: Destination mail server must support TLS to receive mail.
4/5.7.322
certificate-expired: Destination mail server’s certificate has expired.
4/5.7.323
tlsa-invalid: The domain failed DANE validation.
4/5.7.324
dnssec-invalid: Destination domain returned invalid DNSSEC records.
Note
Currently, when a domain signals that it supports DNSSEC but fails DNSSEC checks, Exchange Online does not generate the 4/5.7.324 dnssec-invalid error. It generates a generic DNS error:
4/5.4.312 DNS query failed
We are actively working to remedy this known limitation. If you receive this error statement, navigate to the Microsoft Remote Connectivity Analyzer and perform the DANE validation test against the domain that generated the 4/5.4.312 error. The results will show if it is a DNSSEC issue or a different DNS issue.
Troubleshooting 4/5.7.321 starttls-not-supported
Note
These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.
This error usually indicates an issue with the destination mail server. The mail server that the Remote Connectivity Analyzer is testing connecting with. There are generally two scenarios that generate this code:
The destination mail server doesn’t support secure communication at all, and plain, non-encrypted communication must be used.
The destination server is configured improperly and ignores the STARTTLS command.
After receiving the message:
Check the email address.
Locate the IP address that is associated with the error statement so you can identify the mail server the statement is associated with.
Check your mail server’s setting to make sure it’s configured to listen for SMTP traffic (commonly ports 25 and 587).
Wait a few minutes, then retry the test with the Remote Connectivity Analyzer tool.
If it still fails, then try removing the TLSA record and run the test with the Remote Connectivity Analyzer tool again.
If there are no failures, this message may indicate the mail server you’re using to receive mail doesn’t support STARTTLS and you may need to upgrade to one that does in order to use DANE.
Troubleshooting 4/5.7.322 certificate-expired
Note
These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.
A valid X.509 certificate that hasn’t expired must be presented to the sending email server. X.509 certificates must be renewed after their expiration, commonly annually. After receiving the message:
Check the IP that is associated with the error statement, so you can identify the mail server it’s associated with. Locate the expired certificate on the email server you identified.
Sign in to your certificate provider’s website.
Select the expired certificate and follow the instructions to renew and to pay for the renewal.
After your provider has verified the purchase, you may download a new certificate.
Install the renewed certificate into its associated mail server.
Update the mail server’s associated TLSA record with the new certificate’s data.
After waiting an appropriate amount of time, retry the test with the Remote Connectivity Analyzer tool.
Troubleshooting 4/5.7.323 tlsa-invalid
Note
These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.
This error code is related to a TLSA record misconfiguration and can only be generated after a DNSSEC-authentic TSLA record has been returned. But, there are many scenarios during the DANE validation that occur after the record has been returned that can result in the code being generated. Microsoft is actively working on the scenarios that are covered by this error code, so that each scenario has a specific code. Currently, one or more of these scenarios could cause the generation of the error code:
Authentic TLSA record is misconfigured.
The certificate isn’t yet time valid/configured for a future time window.
Destination domain is being attacked.
Any other DANE failure.
After receiving the message:
Check the IP that is associated with the error statement to identify the mail server it’s associated with.
Identify the TLSA record that is associated with the identified mail server.
Verify the configuration of the TLSA record to ensure that it signals the sender to perform the preferred DANE checks and that the correct certificate data has been included in the TLSA record.
If you have to make any updates to the record for discrepancies, then wait a few minutes then rerun the test with the Remote Connectivity Analyzer tool.
Locate the certificate on the identified mail server.
Check the time window for which the certificate is valid. If it’s set to start validity at a future date, it needs to be renewed for the current date.
Sign in to your certificate provider’s website.
Select the expired certificate and follow the instructions to renew and to pay for the renewal.
After your provider has verified the purchase, you may download a new certificate.
Install the renewed certificate into its associated mail server.
Troubleshooting 4/5.7.324 dnssec-invalid
Note
These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.
This error code is generated when the destination domain indicated it’s DNSSEC-authentic but Exchange Online isn’t able to verify it as DNSSEC-authentic. This section won’t be comprehensive for troubleshooting DNSSEC issues and focuses on scenarios where domains previously passed DNSSEC authentication but not now.
After receiving the message:
If you’re using a DNS provider, for example GoDaddy, alert your DNS provider of the error so they can work on the troubleshooting and configuration change.
If you’re managing your own DNSSEC infrastructure, there are many DNSSEC misconfigurations that may generate this error message. Some common problems to check for if your zone was previously passing DNSSEC authentication:
Broken trust chain, when the parent zone holds a set of DS records that point to something that doesn’t exist in the child zone. Such pointers by DS records can result in the child zone being marked as bogus by validating resolvers.
Resolve by reviewing the child domains RRSIG key IDs and ensuring that they match with the key IDs in the DS records published in the parent zone.
RRSIG resource record for the domain isn’t time valid, it has either expired or its validity period hasn’t begun.
Resolve by generating new signatures for the domain using valid timespans.
Note
This error code is also generated if Exchange Online receives SERVFAIL response from DNS server on TLSA query for the destination domain.
When an outbound email is being sent, if the receiving domain has DNSSEC enabled, we query for TLSA records associated with MX entries in the domain. If no TLSA record is published, the response to the TLSA lookup must be NOERROR (no records of requested type for this domain) or NXDOMAIN (there’s no such domain). DNSSEC requires this response if no TLSA record is published; otherwise, Exchange Online interprets the lack of response as a SERVFAIL error. As per RFC 7672, a SERVFAIL response is untrustworthy; so, the destination domain fails DNSSEC validation. This email is then deferred with the following error:
450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records
If the email sender reports receipt of the message
If you’re using a DNS provider, for example, GoDaddy, alert your DNS provider of the error so that they can troubleshoot the DNS response. If you’re managing your own DNSSEC infrastructure, it could be an issue with the DNS server itself or with the network.
Frequently Asked Questions
As an Exchange Online customer, can I opt out of using DNSSEC and/or DANE?
We strongly believe DNSSEC and DANE will significantly increase the security position of our service and benefit all of our customers. We’ve worked diligently over the last year to reduce the risk and severity of the potential impact this deployment might have for Microsoft 365 customers. We’ll be actively monitoring and tracking the deployment to ensure negative impact is minimized as it rolls out. Because of this, tenant-level exceptions or opt-out won’t be available. If you experience any issues related to the enablement of DNSSEC and/or DANE, the different methods for investigating failures noted in this document will help you identify the source of the error. In most cases, the issue will be with the external destination party and you’ll need to communicate to these business partners that they need to correctly configure DNSSEC and DANE in order to receive email from Exchange Online using these standards.
How does DNSSEC relate to DANE?
DNSSEC adds a layer of trust into DNS resolution by applying the public key infrastructure to ensure the records returned in response to a DNS query are authentic. DANE ensures that the receiving mail server is the legitimate and expected mail server for the authentic MX record.
What is the difference between MTA-STS and DANE for SMTP?
DANE and MTA-STS serve the same purpose, but DANE requires DNSSEC for DNS authentication while MTA-STS relies on certificate authorities.
Why isn’t Opportunistic TLS sufficient?
Opportunistic TLS will encrypt communication between two endpoints if both agree to support it. However, even if TLS encrypts the transmission, a domain could be spoofed during DNS resolution such that it points to a malicious actor’s endpoint instead of the real endpoint for the domain. This spoof is a gap in email security that is addressed by implementing MTA-STS and/or SMTP DANE with DNSSEC.
Why isn’t DNSSEC sufficient?
DNSSEC isn’t fully resistant to Man-in-the-Middle attacks and downgrade (from TLS to clear text) attacks for mail flow scenarios. The addition of MTA-STS and DANE along with DNSSEC provides a comprehensive security method to thwart both MITM and downgrade attacks.
On April 5, 2023 the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability we discovered in WP Data Access, a WordPress plugin that is installed on over 10,000 sites. This flaw makes it possible for an authenticated attacker to grant themselves administrative privileges via a profile update, if the targeted site has the ‘Role Management’ setting enabled.
Wordfence Premium, Care, and Response users received a firewall rule to protect against any exploits targeting this vulnerability on April 5, 2023. Sites still using the free version of Wordfence will receive the same protection on May 5, 2023.
We performed our initial outreach to the developer on April 5, 2023, the same day we discovered the vulnerability. We received a response the same day and sent over the full details. The developer released a patch swiftly the next day on April 6, 2023.
We’d like to say a special thanks to the lead developer of WP Data Access, Peter Schulz, who provided an exemplary example of how security issues should be handled by responding immediately and releasing a patch the next day.
We strongly recommend ensuring that your site has been updated to the latest patched version of WP Data Access, which is version 5.3.8 at the time of this publication.
The WP Data Access plugin for WordPress is vulnerable to privilege escalation in versions up to, and including, 5.3.7. This is due to a lack of authorization checks on the multiple_roles_update function. This makes it possible for authenticated attackers, with minimal permissions such as a subscriber, to modify their user role by supplying the ‘wpda_role[]‘ parameter during a profile update. This requires the ‘Enable role management’ setting to be enabled for the site.
Vulnerability Analysis
WP Data Access is a WordPress plugin designed to make data table creation in WordPress more intuitive and easier to manage for site owners. One feature of the plugin is the ability to enable role management, which makes it possible for a site owner to create custom roles and assign multiple roles to different users. Unfortunately, this functionality was insecurely implemented making it possible for authenticated users to assign any role to themselves, including the administrative role.
Taking a closer look at the code, we see that the ‘multiple_roles_update‘ function used to assign a user’s new roles upon updating a profile is hooked via ‘’profile_update‘’. This hook is triggered immediately after any user profile is updated and it does not perform any sort of authorization checks on the user performing the action. As such, this means that any update to a user’s profile, including on the profile.php page, will invoke the hooked function ‘multiple_roles_update‘.
This makes it possible for any authenticated users with an account, such as subscribers, to invoke the ‘multiple_roles_update‘ function.
If the associated function had a capability check, then it may have prevented these users from fully executing the function, however, that was not the case. Reviewing the hooked function, we see a check verifying that the role management setting is enabled, but nothing more. The function then determines the user and looks for the ‘wpda_role‘ array parameter from a given request. If present, it will process the supplied roles and add the role and applicable permissions to the user retrieved in the first step.
This made it possible for authenticated users, such as a subscriber, making profile updates to supply the ‘wpda_role‘ array parameter with any desired roles, such as administrator, during a profile update that would be granted immediately upon save of the profile updates.
publicfunctionmultiple_roles_update( $user_id) {if( ! $this->is_role_management_enabled ) {return;}$wp_user= new\WP_User( $user_id);if( isset( $wp_user->data->user_login ) ) {$user_login= $wp_user->data->user_login;// Get access to editable rolesglobal$wp_roles;if( isset( $_REQUEST['wpda_role'] ) && is_array( $_REQUEST['wpda_role'] ) ) {// Process roles$sanitized_roles= array();foreach( $_REQUEST['wpda_role'] as$new_user_role) { // phpcs:ignore WordPress.Security.ValidatedSanitizedInput$sanitized_new_user_role= sanitize_text_field( wp_unslash( $new_user_role) ); // input var okay.$wp_user->add_role( $sanitized_new_user_role);$sanitized_roles[ $sanitized_new_user_role] = true;}// Remove unselected rolesforeach( $wp_roles->roles as$role=> $val) {if( ! isset( $sanitized_roles[ $role] ) ) {$wp_user->remove_role( $role);}}} else{// BUG!!! REMOVED!!!// When plugin role management is enabled, this removes all user roles when a user updates his profile.// foreach ( $wp_roles->roles as $role => $val ) {// $wp_user->remove_role( $role );// }}}}</pre><pre>
As with any Privilege Escalation vulnerability, this can be used for complete site compromise. Once an attacker has gained administrative user access to a WordPress site they can then manipulate anything on the targeted site as a normal administrator would. This includes the ability to upload plugin and theme files, which can be malicious zip files containing backdoors, and modifying posts and pages which can be leveraged to redirect site users to other malicious sites.
Disclosure Timeline
April 5, 2023 – Discovery of the Privilege Escalation vulnerability in WP Data Access. Wordfence Premium, Care, and Response users receive a firewall rule to provide protection against any exploits that may target this vulnerability. April 5, 2023 – We initiate contact with the plugin vendor asking that they confirm the inbox for handling the discussion. April 5, 2023 – The vendor confirms the inbox for handling the discussion. April 5, 2023 – We send over the full disclosure details. The vendor acknowledges the report and begins working on a fix. April 6, 2023 – A fully patched version of the plugin, 5.3.8, is released. May 5, 2023 – Wordfence free users receive the firewall rule.
Conclusion
In today’s post, we detailed a flaw in the WP Data Access plugin that enabled authenticated attackers, with at least subscriber-level access to a site, to elevate their privileges to that of a site administrator which could ultimately lead to complete site compromise. This flaw has been fully patched in version 5.3.8.
We recommend that WordPress users immediately verify that their site has been updated to the latest patched version available, which is version 5.3.8 at the time of this publication.
Wordfence Premium, Care, and Response users received a firewall rule to protect against any exploits targeting this vulnerability on April 5, 2023. Sites still using the free version of Wordfence will receive the same protection on May 5, 2023.
If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a serious vulnerability that can lead to a complete site takeover.
This is a Friday long-read, so grab a warm cup of something and kick back because we’re going to take our time on this. The world is about to profoundly change. I know you’re nervous – perhaps excited and optimistic, but if you’ve been paying attention and have been watching the trajectory of this thing, the rational reaction is to be nervous. In this post I’d like to unpack in practical and tangible terms what AI is, where it came from, and the state of play, and then I’ll show you a path that will give you a pretty good shot at surviving the coming revolution.
Who am I? I’m Mark Maunder and I founded Wordfence in 2011 and wrote the early versions of the product until 2015 when Matt Barry took over as lead developer and I morphed into a tech executive running Defiant Inc, which makes Wordfence. We have over 4 million customers using our free product and a large number of paying customers using our various paid WordPress security products. I’ve been a technologist since the early 90s and a kid hacker in my teens in the 80s and 90s. I started my career in mission-critical operations for companies like Coca-Cola, Credit Suisse (now UBS), and DeBeers and then went over to do dev for companies like the BBC and eToys which was one of the biggest dot-com busts. I created the first job meta-search called WorkZoo in the UK around 2001 which later competed with Indeed, launched after us, and which I sold in 2005 but which made Time Magazine and NYTimes. I subsequently launched a Geoblogging platform, inline comments via JS, an ad network, real-time analytics, a localized news website, and more. You could say I’ve been in the innovation game for a minute, and I’m in it for life. I’m based in the USA these days in case you’re curious – moved over here in 2003.
Examining Bubbles
My apologies for the long bio, but what I’d like to illustrate is that I’ve seen tech come and go. The hype cycles I’ve seen typically include:
Outlandish claims about how the tech will solve everything from slicing bread to world peace and everything in between.
Commercial vendors jumping on the emerging mega-trend to surf the wave with proprietary technologies of their own which they position as standards, or at the very least the default choice.
Nascent technologies implementing the tech, that are immature, unstable, rapidly changing, and may very well be abandoned in a few months or a few years.
The press contracting a bad case of rabies and foaming at the mouth about the tech, amplifying the most extreme aspects and use cases and creating a lot of noise, which makes it hard for implementors to sift for the truth and the fundamentals around the technology.
The investment community pouring cash into the space with little focus. This creates an extremely adversarial environment for tech practitioners who are building fundamental value, who now have to compete with powerful VC-backed marketing machines.
As Warren Buffet says, the Innovators, the Imitators, and the Swarming Incompetents enter the space in that order. I’d add that they have a pyramid structure with each successive wave being at least an order of magnitude bigger than the last. Things get crowded for a while.
Then you have the typical bust cycle which cleans house and makes the tech uncool again, but also makes it interesting to the true believers. The VC’s go away and stop making noise that innovators have to compete against. The imitators and swarming incompetents drift off to imitate and mess up something else. The businesses not creating fundamental value fail. Some creating fundamental value fail too but the talent and tech are sometimes reincarnated into something else useful.
So who prospers, and what tech survives after a bust? Sometimes none of it, but helpful derivative technologies are created, like Java Applets in the 90s that inspired Flash which inspired standards-based rich content web browsers.
Sometimes out of the ashes, an Amazon is born, as with the dot-com boom. And sometimes you have incredible innovation where the innovators never see large-scale commercial success, but others do, as with Igor Sysoyev who created Nginx which eliminated the need for a data center full of web servers to handle large-scale websites. Igor has a commercial thing, but the real winners were companies like Cloudflare who based their global infrastructure on Nginx, reverse proxying massive numbers of connections to origin servers with rules about what gets proxied. Hey, I benefited too. Nginx saved our behinds when Kerry and I were running Feedjit.com from 2007 to 2011 because it let us handle over 1 billion application requests per month on just 6 servers. Thanks Igor!
Blockchain technology is in a bust cycle and you can map the characteristics I defined above to blockchain. It looks eerily similar to the dot-com bust and you’ll see an Amazon emerge from the ashes about a decade from now. It might be Coinbase if they survive the over 80% dive in market cap that may continue, but who knows?
Derivative Versus Fundamental Technology Innovation
I’ve mentioned a few tech bubbles so far and it’s really the first step in pulling us out of the trees so that we can examine the various forests out there. Now let’s go a little more meta and talk about which forests matter. Some technology is derivative. Examples of derivative tech are new stuff that runs inside a browser, for example, Websockets.
Websockets are awesome because they let a browser keep a connection open and get push notifications without doing the old TCP three-way handshake to establish a new connection every time the browser wants to check if there’s data waiting on a chat server or whatever. We used to call this long-polling and I wrote a web server to do long polling which was a clumsy but necessary approach, so when Web Sockets came along we all breathed a sigh of relief and I happily retired my web server glad that no one would see my nasty source code which worked quite well mind you.
Another derivative technology – and you’re not going to like this – is blockchain. It’s a useful and novel implementation of hashing algorithms and a few other cryptographic tricks, but honestly, we should have disintermediated banking at least two decades ago and the fact that blockchain has still failed to do that is both disappointing and illustrative that it is just a set of derivative applications built on a tower of fundamentals that has a way to go before it matures. The hype cycle and speculative bubble around it was simply humans making human noise.
So that’s derivative tech. In addition to derivative tech, you have what I’d like to call fundamental tech. Electricity is fundamental. It’s cornerstone technology that transformed the world in our ability to use and transport energy which has enabled an industrial and technological revolution the likes of which the world has never seen. The microprocessor is also fundamental tech for similar reasons. You have algorithms that are fundamental tech like the RSA algorithm which allows us to establish a secure communication channel while a bad person is listening in the whole time – the kind of tech that could have changed the outcome of World War II.
The Internet is fundamental tech. It connected the world and gave us the ability to build applications on top like HTTP and the web which are derivative tech.
Oh I know you want to have a bar fight with me at this point and we’ll do that if you’re attending Wordcamp EU – a collegial and metaphorical barfight, that is – but hopefully, you’re picking up what I’m putting down here in a general sense: There is fundamental tech that profoundly enables and changes the world and which many other things are built on top of, and there is derivative tech that gets a lot of attention but isn’t quite as transformative in a historical sense if you’re thinking in terms of centuries. And there’s the big fat grey area in between.
AI is fundamental tech. For decades we have been programming by writing functions by hand. We’ve gotten quite good at structuring our code using metaphors like object-oriented programming to create logical structures that make sense in a human world, and help us organize large code bases. But fundamentally the way we define logic in a program hasn’t changed for a long time. Until now. For the first time in all of history, we can create functions in programming by training them, rather than writing them by hand. In other, slightly more technical words, we can infer a function from observations and then use it. Like babies and toddlers do. This is historic, it’s transformative and it is a fundamental breakthrough.
Funny thing is that until quite recently – around 2015 – AI had suffered many so-called “AI Winters” where there was significant interest in the field that catalyzed investment dollars, and then a setback usually caused by a reality check, that caused a winter in funding and interest. Does anyone remember the “expert systems” of the 80s? By the early 2000s AIs name had been dragged through the mud so many times that anyone doing serious research in the field used different words to describe their work, like “machine learning” or “informatics” or “knowledge systems”.
A few hardcore true believers like Yann Lecun, Yushua Bengio and Geoffrey Hinton powered through like Bilbo and Sam across The Dead Marshes and went on to win the Turing Award, which is basically the Nobel Prize of computer science and which I had the privilege of attending when Rivest, Adleman and Shamir won theirs for public key crypto. The Turing Award is a very big deal and well deserved considering how adversarial the AI environment was for a while.
So what changed? Well for one thing you’re reading this post because it’s about AI and you’re interested. And you’re interested because you recently used GPT-4, MidJourney, Dall-E or another model to create something. You’re seeing tangible results. And the reason you’re seeing results is that GPU hardware, algorithms, and an interest in the field have brought us to an inflection point where the technology is delivering results that are jaw-dropping enough to catalyze more funding, more research, and more jaw-dropping results. This cycle really picked up steam in 2015, and with the release of GPT-4 recently, has entered a phase of what I would describe as true and consistent exponential growth.
According to NVidia “LLM sizes have been increasing 10X every year for the last few years”. In two years that’s 100X. Three years from now that’s 1000X and so on. Extrapolate that out and be afraid. Or optimistic if your mind isn’t for rent and you are hopeful yet discontent. Rush lyrics aside, that pace should give you an idea of how quickly this thing is coming. And now that we’ve reached the point of inflection I mentioned, where the hardware and algorithms seem to have overcome the cycle of disappointment that AI has been stuck in for decades, I predict that you’ll see consistent and exponential growth in the field in capabilities for the foreseeable future, with a financial bubble and bust in there that won’t be of much consequence to the fundamental value of the technology.
“Thanks for the history lesson Maunder, but you brought us here with promises of telling us what to do about AI. So?”
What to do about AI
So far we’ve discussed what boom cycles look like and the kind of noise and bear traps you should be aware of. We’ve defined what AI is in fundamental terms – a function that you can train rather than hand code. And we’ve hopefully agreed that we’ve entered a period of consistent and exponential growth in the field. Now we’ll chat about how to survive and prosper in a world that looks a lot like when electricity was invented and commercialized, or the microprocessor, or the Internet.
Goldman estimates that AI will add 7% to global GDP at a rate of about 1.5% growth per year. They also estimate that roughly two-thirds of US occupations are exposed to some degree of automation by AI. You can extrapolate this globally. That kind of global disruption is matched only by the industrial revolution or the entire recent tech revolution as a whole starting from 1980. From the same publication, “A recent study by economist David Autor cited in the report found that 60% of today’s workers are employed in occupations that didn’t exist in 1940.”. So on an optimistic note, this kind of disruption isn’t a new thing and we’ve been disrupting and adapting for some time now.
Perhaps you’re reading this because you are running a WordPress website, perhaps secured by my product, Wordfence. Which means you’re a creator of some kind. Perhaps you’re a writer, an artist, or perhaps you’re an entrepreneur creating a business out of thin air. [Yes my fellow entreps, you get to hang with the other cool creator kids too!!]. If you don’t plan on adapting at all, that makes you far more vulnerable to this coming wave than say a chef who runs a restaurant, or someone who manages real estate and rentals. And that really is the key: adaptation. So how can we adapt?
If you’re a creator, you need to become a user of AI. You’re probably already using GPT to write copy for your product catalogs on your e-commerce website, or using MidJourney (MJ) or Dall-E to create art for ad campaigns. If you’re a designer or artist, you may feel the kind of resentment this Blender artist does in the Blender subreddit.
“My Job is different now since Midjourney v5 came out last week. I am not an artist anymore, nor a 3D artist. Rn all I do is prompting, photoshopping and implementing good looking pictures. The reason I went to be a 3D artist in the first place is gone. I wanted to create form In 3D space, sculpt, create. With my own creativity. With my own hands.”
“It came over night for me. I had no choice. And my boss also had no choice. I am now able to create, rig and animate a character thats spit out from MJ in 2-3 days. Before, it took us several weeks in 3D. The difference is: I care, he does not. For my boss its just a huge time/money saver.”
While I sympathize with how hard change and disruption can be, it’s been a constant for the past couple of centuries in many fields. MidJourney has a long way to go before it can match a real-world artist, unless you’re just churning out images and letting the AI guide the design choices and are happy to work around the bugs. For MidJourney and other generative AIs to produce exactly what we want, they’re going to have to get better at understanding what exactly we want to create. And that’s where the skill comes in. You’re already seeing this with a document that someone has created listing famous photographers and examples of their look. This can be used in MJ prompts to say “in the style of” to get a specific look, but it is an incredibly rudimentary approach.
Another way to guide the MJ AI in particular is to blend photos it has generated. Again, super rudimentary, but it’s the start of having the ability to tightly specify exactly what you want and get that out of MJ. And if you need a reminder of how basic it still is, try to get MJ to generate hands. It still sucks, even at version 5.
So if you’re a creator, start getting good at using the tools now, understand their limitations, and evolve as the products evolve until you’re an expert at guiding the AI to create exactly what you want. This will help you guide your customers in explaining the limits of the current state of AI to them and where you add value, let you take immediate advantage of the use that the current tools have, and ramp up your productivity as the tools get better at taking instructions from you.
This applies to writers, artists, designers, filmmakers, photographers, screenwriters, and anyone with creative output. Get good at the tools. Get good at them now. Do it with an open mind. Know that changes aren’t permanent and that change is. (Again with sneaking in the Rush lyrics)
Adapting as a Dev
Coders! My people! We have a problem. Most of you have become users of AI. You’re users of GPT-4 via their API. You’re plugging into other generative AIs via an API. You aren’t rolling your own. And rolling your own is where all the fun is!!
Ever heard of transfer learning? You can grab a pre-trained model from Hugging Face, chop off the head – aka the final layer in the layers of neural nets, substitute it with random weights, and train the pre-trained model with your own data to take advantage of the sometimes millions of dollars that someone else already spent training their model. In fact Facebook’s LLAMA model which is one of the largest LLM’s in the world was leaked via Torrent recently.
The most important thing you need to do right now as a developer is to stop being a user of AI and become a dev of AI. GPT-4 is a shiny ball that the world will have forgotten about in a year, but it’s a very shiny and attractive ball right now that is fueling many a late-night dev chat. Remember that stat I gave you above? That LLM’s have been increasing in size at 10X per year. The current state of the art will be accessible to you on a desktop in a few years and you need to get ready for that world today.
I’m going to just go ahead and tell you what you need to do to get your AI stuff together, fast.
Ignore the math. Trust me on this. Most people including devs are not good at math and it intimidates the hell out of them. AI is just matrix multiplication and addition using GPU cores to parallelize the ops. Expressing this as code is easy. Expressing it as math will make you hide under your bed and cry. Ignore the math. If you can code, you’ll get it.
Learn Python. Everything in AI is Python. It’s a beautiful little language that you’ll come to appreciate very quickly if you’re already a dev. It’s like coming over to Aikido if you’re already a black belt. OK the MMA scene kinda messed up my metaphor proving that Aikido is actually worthless, but whatever.
Then go do the Practical Deep Learning for Coders course at fast.ai. It’s how we get our guys up to speed fast in the field and it’s brilliant. Jeremy Howard does a spectacular job of getting you up to speed fast in the field by immediately getting you productive and then unpacking the details in a fun non-mathy way.
As you progress in the course, definitely get up to speed using Jupyter Notebooks and I’d recommend Kaggle for this. They were bought by Google a few years ago and kind of compete with Google’s own notebook system called Colab, but I prefer Kaggle. You get GPU access by simply verifying your email address and it’s free which is kind of amazing. So you can use a rich text environment on Kaggle to write your code, see the output and run it on some fairly decent GPUs. Kaggle GPU’s perform at about 20% of the speed of my laptop RTX 4090 in case you’re curious about benchmarks.
The course teaches fundamentals, how to use pre-trained models, how to create Jupyter Notebooks or fork others, how to create Hugging Face Spaces, and how to share your models and their output with the world. It is the fastest way right now to transform yourself from an AI user into an AI dev and get drinks bought for you at parties by folks that have not yet made the leap.
Alright, this went long but that was the plan. We’ll talk more about AI. Go forth, be brave, learn, and create!
Mark Maunder – Founder & CEO – Wordfence and Defiant Inc.
Footnotes: All images on the page were created with MidJourney and if you’d like to see the prompt I used, simply view the image in a new tab and the image name is the prompt, all except for the heavy metal hands image which a colleague created. I’ll be in the comments in case there’s discussion.
On January 26, 2023, the Wordfence team responsibly disclosed an unauthenticated stored Cross-Site Scripting vulnerability in Limit Login Attempts, a WordPress plugin installed on over 600,000 sites that provides site owners with the ability to block IP addresses that have made repeated failed login attempts.
The plugin is vulnerable in versions up to, and including, 1.7.1. A patch addressing this vulnerability was released on April 4, 2023 as version 1.7.2. We recommend all site owners update to version 1.7.2 as soon as possible.
All Wordfence Premium, Wordfence Care, and Wordfence Response customers, along with those still using the free version of the plugin, are protected by the Wordfence firewall against any exploits targeting this vulnerability.
The Limit Login Attempts plugin offers some simple configuration options. These include a maximum number of login retries, lockout duration, lockout expiration times as well as some logging and notification options. The vulnerability, assigned CVE-2023-1912, requires a specific configuration: the site connection option must be set to “From behind a reversy [sic] proxy” and logging of IP addresses on lockout must be enabled.
With the reverse proxy detection option enabled, the plugin uses the X-Forwarded-For header to determine the visitor’s IP address. While this HTTP header is spoofable, the plugin does offer its use as an alternative for those who are behind a load balancer or cache handler. It does not use this setting by default.
With the plugin’s logging feature enabled, login blocks are logged and displayed on the configuration page. The following code accomplishes this (slightly edited for legibility).
As can be seen, this function assembles a table of information but does not escape the values it uses. While sanitization is recommended as input is received, escaping output, even if it is already sanitized, is a far more effective tool in preventing Cross-Site Scripting. Unfortunately, this plugin was not utilizing either sanitization or escaping of the stored IP value that could be supplied via the X-Forwarded-For header.
To exploit this vulnerability, an attacker could send a login request with the following X-Forwarded-For header set:
This header can be set via many methods, such as through a browser plugin or by intercepting the login request and adding it manually. Once the plugin’s blocking threshold is met, it will record the above code as the blocked IP and execute the malicious JavaScript code when an administrator visits the configuration page where the list of blocked IP addresses is displayed. This malicious code is executed under the authentication of an administrator and can be utilized to help facilitate a site takeover.
Cross-Site Scripting Vulnerabilities are the result of missing sanitization and unescaped display of user input. Most commonly, we see user input that is exploitable to Cross-Site Scripting collected via a form. In this vulnerability, the processed information is still provided by a user, but collected via a different and more unusual route which is why proper sanitization and escaping may have been missed.
Timeline
January 26, 2023 – We reached out directly to the WordPress Plugin Security Team as no contact information was readily available for the developer of the plugin. March 24, 2023 – The WordPress Plugin Security Team team acknowledges receipt of our report. April 4, 2023 – Version 1.7.2 addresses this issue.
Conclusion
In today’s post, we covered an unauthenticated Cross-Site Scripting vulnerability via the X-Forwarded-For header in the Limit Login Attempts plugin. This can be leveraged by unauthenticated attackers to facilitate a site takeover by injecting malicious JavaScript into the database of an affected site that may execute when a site administrator accesses the logging page.
Again, all Wordfence Premium, Wordfence Care, and Wordfence Response customers, along with those still using the free version of the plugin, are protected by the Wordfence firewall for any exploits targeting this vulnerability.
Special Note: We independently discovered this vulnerability in January while reviewing a vulnerability in another plugin. We followed our responsible disclosure process and reported it to the WordPress Plugin Security Team, ensured it got patched, and published it to our vulnerability database once a patch was released. After adding the vulnerability to our database, we were made aware of another unnamed security researcher who also discovered this issue and publicly disclosed details about this vulnerability five years ago without ensuring the vulnerability got patched, which does not follow standard practice. Regardless, we would like to make mention of this so the other researcher who also found the vulnerability receives credit.
If you have any friends or colleagues who are using this plugin, please share this announcement with them and encourage them to update to the latest version of Limit Login Attempts as soon as possible.
