Alpaca Attack

https://alpaca-attack.com/

by todsacerdoti • 5 years ago

142 46 5 years ago

alpaca-attack.com

robin_reala• 5 years ago

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

teh_klev• 5 years ago

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

sqrt17• 5 years ago

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...

LightG• 5 years ago

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

echelon• 5 years ago

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.

justin_oaks• 5 years ago

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.

duskwuff• 5 years ago

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.

shp0ngle2• 5 years ago

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.

gregmac• 5 years ago

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).

_ea1k• 5 years ago

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

shp0ngle2• 5 years ago

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.

orliesaurus• 5 years ago

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

eesmith• 5 years ago

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.

rob74• 5 years ago

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)?

jsiepkes• 5 years ago

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.

blfr• 5 years ago

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.

kroeckx• 5 years ago

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.

remram• 5 years ago

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

handrous2• 5 years ago

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.

yjftsjthsd-h2• 5 years ago

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).

cookiengineer• 5 years ago

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.

samizdis• 5 years ago

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...

chasil• 5 years ago

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...

hobs• 5 years ago

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

Lex-20082• 5 years ago

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

tgsovlerkhgsel• 5 years ago

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.

technion• 5 years ago

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.

ejcx2• 5 years ago

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.

geofft2• 5 years ago

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.

ejcx2• 5 years ago

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.

that_guy_iain• 5 years ago

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.

Aissen• 5 years ago

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.

hannob• 5 years ago

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.

tptacek• 5 years ago

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.

icecap12• 5 years ago

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

ChrisArchitect• 5 years ago

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

steeleyespan• 5 years ago

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

alpaca128• 5 years ago

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

(scnr)

annoyingnoob• 5 years ago

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

867-5309• 5 years ago

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

afrcnc• 5 years ago

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.

ndndnsnsnsb• 5 years ago

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.

Alpaca Attack

Related Stories