Alpaca Attack | Hacker News Reader

Alpaca Attack

alpaca-attack.com

142 pointstodsacerdoti46 comments

It's an interesting read but as they acknowledge themselves the attack surface is probably pretty low.

> Sharing certificates between a Webserver and an FTP server is almost always dangerous if an attacker has write access to the FTP server. It is sometimes dangerous if the attacker has no write access.

When dealing with "secure FTP" it is usually SFTP (so actually SSH so no TLS / certificate in the picture) instead of FTPS (ie. actual FTP + TLS). I don't think I've ever seen FTPS in the wild. But thats just my personal experience.

> Sharing certificates between a Webserver and an SMTP/POP3/IMAP server is sometimes dangerous, depending on the exact behavior of the server.

Are there people who do that? I don't think I've ever seen a SMTP or IMAP server with a wildcard certificate. Let alone the cert being shared with a HTTP server.

I use the same certificate for http and smtp on my small personal server since they have the same hostname and it's easier to generate with Let's Encrypt through http.

I suggest you have a hostname for each service. So you could change the hostname of the mx but have it point to the same IP address. You can then have a certificate for each hostname. Certbot can generate/renew the certificate using http even if that hostname normally doesn't do http.

Yeah, I do that. On my box services point to /etc/letsencrypt/live/...

I implemented an FTPS service once! AMA?

My needs were: 1) Client login [edit: should have been more clear—I mean randos who signed up on our website, basically], 2) username and password login, no key stuff, 3) obviously plain FTP was not an option.

Nice to have: 1) Same username and password as the website, not managed separately.

My personal hang-up: 1) I really didn't want to create actual system users for any of this.

I settled on ftps, which could satisfy all the needs plus my hang-up, and then chose PureFTPd which made implementing the nice-to-have very easy:

https://download.pureftpd.org/pub/pure-ftpd/doc/README.Authe...

I'd already factored out our auth into what you'd call a microservice (I think the term was just starting to enter wide use then?) because we needed to serve multiple barely-related services with the same auth, so writing a little script to handle that auth was downright trivial. The only reason it took more than an hour, once I settled on a solution, was that I had to make it play nice with haproxy, and I wanted to thoroughly test my auth script's failure modes.

This basically never broke. It was great.

A++++ would ftps again.

I've done approximately that and just used https://github.com/atmoz/sftp bound to port 2222 or whatever. SFTP supports password auth just fine if you like, and AFAIK is at least as accessible and probably moreso (clients like filezilla will support both, and sftp shhould be preinstalled on most unix-likes).

Right, of course you can use password auth with sftp, but 1) there was no docker at the time (as in the linked repo), 2) lxc itself was very new at the time, in fact, and 3) that project appears to create system users (in the container) which was one thing I was trying to avoid doing, without adding undue complexity (LDAP or whatever). My solution was mature at the time, relied entirely on our existing auth system so there was no need to keep accounts in sync or manage them separately, and didn't cause any complications with permissions for which directories an account could access (if our normal auth system said a user could access ftps for a given project, then they could, and that was it—no messing with Unix permissions and groups or, more likely, Linux ACL-based permissions, and keeping those in sync with the settings on the site)

Oh sure; certainly not dissing your solution, just pointing out that SFTP is also workable now.

I remember that BSDs original ftpd had a login password limitation with a wrong bytes allocation and a resulting RCE attack surface, which ultimately is still a threat to outdated ProFTPd instances running on Windows. (see exploitdb, it's full of PoCs)

I always asked myself: Why not simply use sshd and no login shell for the created user? Gives you legit transport encryption, blocking of keys/certs you wanna ban, and is the definition of battleproven software.

I never understood plaintext auth via encrypted transportation layers. They simply don't make sense to me from a security standpoint, and the risks of a broken transport layer is just too damn high as you must have control of every OSI level to really be able to verify it and that's never the case.

From an Ars Technica report about this [1], citing the researchers:

"Overall, the attack is very situational and targets individual users," Brinkmann said. "So, the individual risk for users is probably not very high. But over time, more and more services and protocols are protected with TLS, and more opportunities for new attacks that follow the same pattern arise. We think it's timely and important to mitigate these issues at the standardization level before it becomes a larger problem."

[1] https://arstechnica.com/gadgets/2021/06/hackers-can-mess-wit...

This is why you have never seen FTPS in the wild, from the vsftpd.conf manual page:

    ssl_enable
    If enabled, and vsftpd was compiled against OpenSSL, vsftpd will
    support  secure connections via SSL. This applies to the control
    connection (including login) and also data  connections.  You'll
    need a client with SSL support too. NOTE!!  Beware enabling this
    option. Only enable it if you need it. vsftpd can make no  guar‐
    antees  about the security of the OpenSSL libraries. By enabling
    this option, you are declaring that you trust  the  security  of
    your installed OpenSSL library.
    Default: NO

https://scarybeastsecurity.blogspot.com/2015/07/vsftpd-303-r...

Ah, but IIS uses it so it probably is still floating around somewhere.

Postfix has a similar note:

> NOTE: By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix.

http://www.postfix.org/TLS_README.html

I'm actually sharing a cert between a web server and another service. Refreshing the certificate with certbot is trivial if the cert is being used on a web server, and reusing the same cert for another service is easier than figuring out a separate way to refresh that cert.

I have no clue if the second service is vulnerable to this attack though - I kind of doubt it.

Microsoft exchange runs SMTP and web. It needs a minimum of two names to function, and can require several others depending on features. Microsoft just released a vulnerability fix that actually requires you add a new unique name to your certificate. That sort of annoyance often leads people to use wildcards. And prior to let's encrypt, a wildcard is often cheaper than a cert with six names like I've been dealing with. So in that situation, there are a lot of SMTP wildcards on a web server in the wild.

The title of this totally got me, I think it was gonna be some video game release by an HNer or something...

I almost got trampled over by a running alpaca when walking around the ruins at Machu Picchu. I kid you not.

So that's what first came to my mind.

Me too... maybe a browser-based remake of the Jeff Minter classic "Attack of the Mutant Camels" (https://en.wikipedia.org/wiki/Attack_of_the_Mutant_Camels)?

I’d assumed from the title that this would be the latest Jeff Minter / Llamasoft game.

That was my very first thought as well. We may be showing our ages :)

I was assuming someone had an attack on the Alpaca altcoin.

So if you throw in a random word, it could be either or all of a garage rock band, an indie game, an altcoin, or a software vulnerability. And probably there are three or four academic software systems with that name...

I don't really understand what is gained by the protocol switching :(

Does attacker need to be in possession of the ftp.bank.com in the example? If he is not, then what does he gain by the protocol switching? As he is not in possession so whatever is uploaded he cannot read?

I should reat the paper more carefully I guess.

No, they just need read and/or write access to ftp.bank.com, and the ability to redirect traffic from the victim's browser.

As I understood, by initiating an FTP upload and redirecting the TLS-secured request to the FTP's data port, the entire HTTP request (including cookies in the header) are "uploaded" to the FTP site. This can then be downloaded by the attacker, and now they've exfiltrated the data like the session id (and can do a session hijack attack).

A related attack can be done by placing an HTTP response on the FTP site, and getting the victim's browser to "request" that. This allows the attacker to inject javascript.

These work with certain other protocols, too, but varies by the server and browser tolerance for unrecognized stuff in a request (eg: SMTP will ignore HTTP headers, allowing an SMTP session to be embedded in a POST request as a <textarea>; IE will ignore POP3 "junk" before the beginning of an HTTP response embedded in an email body).

Practically speaking, how would this work without also hacking the FTP server, SMTP server, or somehow hacking the original page?

how I understand it after reading the original article:

in plaintext http world, man-in-the-middle (MitM) can redirect your browser request for www.bank.com to their own evil server which will pretend being www.bank.com.

in https world this wouldn't work since evil server doesn't have a valid TLS certificate for www.bank.com and thus your browser will refuse to talk to it.

However, MitM might redirect your request for www.bank.com to this bank's ftp server ftp.bank.com. If this mail server uses wildcard certificate *.bank.com - then your browser will accept it and start talking HTTP to it.

this article analyzes how various (email and ftp) software reacts when sees a browser talking http to them. If an ftp server saves such request (in plaintext form) to a world-readable file - hacker can read it and we're in trouble.

Yeah but then you need a read/write access to the FTP server on the bank domain.

Which, OK, is not as strong access as "full access to HTTP traffic". Got it.

Appreciate this might be useful to someone else ... but the name for this is begging to be a game. Sorely dissapointed!

I had the exact same reaction.

This trend of giving silly names to security disclosures is kind of neat, though. It certainly increases awareness of the security field and its importance.

If only they had come up with a simple web game that teaches you about the vulnerability while you play. Then you get the best of both.

It sounds like the sort of thing Jeff Minter (https://twitter.com/llamasoft_ox) -- author of games such as "Revenge of the Mutant Camels", "Llamatron: 2112", and "Moose Life" -- would make.

In the example image, why is ftp.bank.com:990 responding with CORS HTTP headers allowing attacker.com to establish a cross origin connection?

The whole thing seems a bit impractical to me.

It's not - you're allowed to send requests to arbitrary sites. CORS just controls whether you can see the response.

The reason for this is that you've been allowed to do things like <img src="https://unrelated-website"> and even <form action="https://unrelated-website" method="POST"> from basically the earliest days of the web. So you can send arbitrary GETs (automatically, no JS required) and POSTs (via getting the user to hit Submit, or using JS) to other websites, you just can't really see the response. For forms it navigates you to the new site (but you can do this in an iframe or something); for images, CSS, etc. the end user can potentially see the response but your website can't programmatically access it via JS.

In fact you can also do things like <script src="https://unrelated-website">, <link rel="stylesheet" href="https://unrelated-website">, etc. and evaluate the result of the page hoping it's JavaScript/CSS/etc., but you can't see it. Back before CORS, a common way to do opt-in cross-website data sharing was "JSONP", where you'd pass the name of a callback function in an argument, a website would return a script consisting of your_function({...JSON response...}), and just trust the other website to not be malicious.

(Web browsers now do a little bit of content sniffing and heuristics to try to prevent evaluating non-JS as JS, but that happens once the response has come back. You can still send the request.)

CORS applies to using XMLHttpRequest/fetch/etc. to actually access the data. And even with CORS, browsers send (most) GET/POST requests straight through, and they check the CORS header on the response, because for the reasons above you could send GET/POST requests anyway. Only for other methods, custom headers, etc. does CORS preflight the request with OPTIONS.

So, for some of the forms of this attack (e.g. tricking an FTP server into accepting an upload), you don't need to see the response. For some forms of this attack (e.g., tricking an FTP server into sending user-provided JS), the web model allows you to evaluate cross-origin content. No CORS is involved in either case.

Yes, you do in fact need CORS to set the arbitrary header in the example if it's even possible to send from a browser. I suppose it might be possible to send as `HELP xss:` which is close

Like you said, you can send requests, but not the one listed in the example and you're severely limited in cross protocol interactions to valid http where you don't need to receive a response... (which some of the example attacks require btw)

I think this is an interesting issue to consider, but the examples are based on wildly different threat models that include TLS being hijacked, maybe DNS if it was performed with rebinding, the FTP server being hijacked for one of the attacks. It is not at all concrete. Interesting, but not really worth worrying about.

The interesting cross protocol attacks that I've seen involved SSRF talking to memcached, as a classic example. Something private. In practice I think they would struggle to find a single real world instance where they can pull off an attack enabled by this behavior. Which is fine, it's academic. Just not what I expected given the coverage.

In the example given, there's no arbitrary header. "HELP" is part of the POST data, which is controlled by the application.

And example attacks 2 and 3 do not require seeing the response, only executing it, which you're permitted to do via a <script> tag.

I hope there are not a lot of folks running the kinds of configurations that are vulnerable here.

a selection of application layer protocols other than the checked HTTP, SMTP, IMAP, POP3, FTP:

Bitcoin, BitTorrent, DNS, IRC, NFS, RDP, SMB, SSH, Telnet, Tor, WebDAV, WebRTC

Attack is a 0.25/100 on the threat scale. If someone has MitM on a server they can do actually bad stuff, not this.

Wouldn’t TLS normally prevent the bad stuff? It seems with this someone can setup a naughty open hotspot at an airport and read otherwise encrypted traffic.

I was pretty disappointed that this wasn't a website about alpaca's gone mad.

I'm glad it's not a site about me

(scnr)

I get naming security vulnerability make them easier to talk about and spread awareness. But I think if the answer to "should I drop everything and fix this" is not yes, it doesn't need to be marketed so well.

On the contrary, if the FAQ entry is honest (and this is the first question), then I'd say let them market it however they like. But I fully understand how one could get quite a marketed-bugs-fatigue.

If you look at past attacks that had a name and logo it's often not that these attacks were particularly dangerous. Think about Spectre.

What these attacks often do however is breaking existing expectations. I think this attack ticks quite a few boxes there. It questions the idea that TLS can be "layered" on top of existing protocols and just be secure without consideration for the underlying protocols. It breaks security independently of all the fancy crypto we have in TLS 1.3 that we enforced due to previous attacks on weak crypto. It shows a generic problem with TLS that hasn't been tackled properly yet.

It's interesting because there's at least two audiences for vulnerability research. The preceding comment is the obvious audience: people wondering if they need to patch. But for some vulnerabilities, the more important audience is computer science. Alpaca might be almost irrelevant to people who operate systems, but it's profoundly relevant to people studying secure transports and their vulnerabilities.

It very much deserves whatever name the team chose to gave it.

Just a guess, but I think some of this is because they want to present the story at a big security conference.

ha yeah, seems to a trend more this year to launch a full on dedicated domain about these vulnerabilities

Reply on news.ycombinator.com