LethargicStud
Joined 10 years ago
Karma
164
Submissions
44
Member since
Sep 17
Recent submissions
Comment · 5 years ago
Comment · 5 years ago
It is open source - https://github.com/jchorl/sendfiles
Comment · 6 years ago
GCP supports remotely loading public ssh keys onto a box. They do this using the metadata endpoint - this is (in theory) a trusted API endpoint available to instances @ 169.254.169.254. IAM actually uses this - when you call other services, client libs reach out to the metadata endpoint and get IAM creds to send with each request.
Anyway, they have a local process that polls the metadata endpoint and adds authorized keys on the host. So you can e.g. upload your public key in the web UI, their metadata endpoint will serve it up on your instance, the guest agent will poll the metadata endpoint and add your key to the authorized_keys file.
These folks spoofed a response from the metadata endpoint. They used https://github.com/kpcyrd/rshijack to inject their own hand-crafted public key, which the guest agent happily added to authorized_keys (and created the wouter user).
They then ssh'd using their key:
> ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
> Once we accomplished that, we had full access to the host VM (Being able to execute commands as root through sudo).
Looks like they had passwordless sudo as well.
Comment · 6 years ago
My main FUD with alpaca.markets is the ability to transfer assets in/out. It doesn't look like they offer ACATS transfers (although there's not much info on this!).
Using them for anything beyond entertainment budget is very scary - you may incur substantial tax liability if e.g. they ever go out of business or you choose to use a different brokerage.
Any insight here? Am I missing something? Is there any way to transfer holdings out without incurring the cap gains?
Comment · 6 years ago
Hey!
I built this because I had 10+ bank accounts, and they were annoying to monitor. I'd log in every month and have to chase down why they didn't look as I expected them too.
I've set up Lambda functions to e.g. post bills to Splitwise, email me when my balances go above/below thresholds, and pipe all transactions into Google sheets. I've been running my own personal finances off it for a while and it's greatly improved my quality of banking life.
Would love feedback :)
Comment · 6 years ago
Coming soon! I appreciate the feedback.
It uses plaid under the hood, so I get read-only access to bank data. You can validate by inspecting network reqs - it just grabs a public token from plaid and sends it to my backend - I never see the bank creds. Whether you trust plaid is up to you.
Comment · 6 years ago
I'm hacking on https://bankhooks.com
The premise is simple - define arbitrary conditions on transactions or balances, and get webhooks or emails when those conditions fire on any of your bank accounts.
I have >10 bank accounts and was having trouble monitoring them. I use this to alert me of any activity, on any of my accounts, that is unexpected. I no longer need to log into banks. I also use it to alert me if my balance gets too low or too high in any account.
I've also deployed Lambda functions to e.g. post my utilities bill to Splitwise to automatically split with my roommates, or pipe all transactions into a Google sheet so I can analyze my spending over time.
It started out as a simple hobby project but has grown into an immensely useful tool in my day-to-day life.
The webauthn spec has public/private keys incorporated: https://www.w3.org/TR/webauthn-2/#sctn-sample-registration
There should be no risk to storing all your public keys in e.g. 1password. When signing up for e.g. facebook.com, you should be able to hit a button and have all your keys registered at the same time. You can send $site all your public keys, and sign auth reqs as you log in. Of course, the UX would be handled by webauthn, so you'd really just be tapping your yubikey or scanning your fingerprint on login.
Ideally, password managers would offer key servers that websites could hit in real-time to pull your public keys. That's probably a stretch - maybe websites could sync your 2fa pub keys in the background.
With such a model:
1. Having multiple yubikeys
2. Having multiple team members with access (same as 1, effectively)
3. Revocation of individual 2fa devices
4. Adding 2fa devices after account creation
Would be pretty trivial.
I assume there's something basic in the webauthn protocol that I'm overlooking that prevents such a model. What is it, and why can't we have these properties?
I for one don't want all my accounts to hinge on access to a single physical device, and I certainly don't want to register 10 yubikeys with every service (some I may not even have physical access to on a day-by-day basis).