[HN Gopher] Alpaca Attack
___________________________________________________________________
Alpaca Attack
Author : todsacerdoti
Score : 116 points
Date : 2021-06-09 12:58 UTC (10 hours ago)
(HTM) web link (alpaca-attack.com)
(TXT) w3m dump (alpaca-attack.com)
| robin_reala wrote:
| I'd assumed from the title that this would be the latest Jeff
| Minter / Llamasoft game.
| sqrt17 wrote:
| 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...
| teh_klev wrote:
| That was my very first thought as well. We may be showing our
| ages :)
| annoyingnoob wrote:
| I hope there are not a lot of folks running the kinds of
| configurations that are vulnerable here.
| orliesaurus wrote:
| The title of this totally got me, I think it was gonna be some
| video game release by an HNer or something...
| eesmith wrote:
| 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 wrote:
| 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)?
| LightG wrote:
| Appreciate this might be useful to someone else ... but the name
| for this is begging to be a game. Sorely dissapointed!
| justin_oaks wrote:
| 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 wrote:
| 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.
| echelon wrote:
| 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.
| jsiepkes wrote:
| 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.
| tgsovlerkhgsel wrote:
| 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.
| remram wrote:
| Yeah, I do that. On my box services point to
| /etc/letsencrypt/live/...
| chasil wrote:
| 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 wrote:
| Ah, but IIS uses it so it probably is still floating around
| somewhere.
| Lex-2008 wrote:
| 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
| technion wrote:
| 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.
| handrous wrote:
| 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-h wrote:
| 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).
| handrous wrote:
| 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)
| samizdis wrote:
| 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...
| blfr wrote:
| 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 wrote:
| 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.
| shp0ngle wrote:
| 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 wrote:
| 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).
| jsight wrote:
| Practically speaking, how would this work without also
| hacking the FTP server, SMTP server, or somehow hacking the
| original page?
| Lex-2008 wrote:
| 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.
| steeleyespan wrote:
| I was pretty disappointed that this wasn't a website about
| alpaca's gone mad.
| alpaca128 wrote:
| I'm glad it's not a site about me
|
| (scnr)
| ejcx wrote:
| 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.
| geofft wrote:
| 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.
| ejcx wrote:
| 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.
| geofft wrote:
| 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.
| that_guy_iain wrote:
| 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.
| icecap12 wrote:
| Just a guess, but I think some of this is because they want to
| present the story at a big security conference.
| hannob wrote:
| 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.
| ChrisArchitect wrote:
| ha yeah, seems to a trend more this year to launch a full on
| dedicated domain about these vulnerabilities
| Aissen wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-09 23:01 UTC)