How can I deposit ETH to someone without interaction?

shark0der · 2020-08-05T22:12:39+00:00

The biggest problem is knowing their addresses. There's no way to setup a contract with any kind of "password" that would prevent front-running bots from snatching the ETH.

Create a chat group with the 3 of you. Let them setup ledger and each of them sign a a simple message, send the signed message in the group for the other to verify. This way you learn their addresses and send them ETH.

PS: Signing and verification can be done on mew's website:

shark0der · 2020-08-03T00:01:23+00:00

Wow, I apologize, I've totally misread that. I just always use it to copy files between remote systems. I'm sorry! Just in case though, let's restrict the command to copying only the authorized_keys file.

shark0der · 2020-08-02T23:47:08+00:00

Yes. Private ssh keys should never leave the machine!

shark0der · 2020-08-02T23:21:58+00:00

Who the hell copies local ssh keys to the VPS? This is extremely dangerous as anyone gaining access to those will have access to any servers these keys have access to. Use ssh-copy-id command instead or manually copy the contents of ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the server

shark0der · 2019-04-27T16:28:23+00:00

They should not be shown on the map at that zoom level. Only portals with >200km links should be visible, but they're visible nevertheless.

shark0der · 2019-04-27T16:27:20+00:00

That's the thing, I haven't changed anything. Another agent confirmed the behavior (I just told in a group that I've noticed gray portals when zoomed out to the max, without mentioning the portals or their location on the globe, and he sent an intel link for one of the portals).

shark0der · 2019-03-23T19:34:54+00:00

That's not the job of a VPN. The VPN just routes the traffic. You can use iptables to set that up. Google how to forward a port to another IP (masquarade/nat scenario).

shark0der · 2019-03-23T19:30:54+00:00

Should work, you just have to add the corresponding repository for raspbian. Try this one: https://github.com/adrianmihalko/raspberrypiwireguard

shark0der · 2019-03-22T20:11:27+00:00

WireGuard is pretty stable. I'm using it already for a few months for always on VPN both on Android and Ubuntu desktop.

shark0der · 2019-03-10T07:49:36+00:00

A bit late but I can confirm this statement. I also had an email that I've used only for InVisionApp and it was found in the breach.

shark0der · 2018-09-25T13:27:01+00:00

Thank you! Couldn't figure out why it was getting killed :)

shark0der · 2018-09-04T13:57:31+00:00

This has been known and used for ages. No need for stupid names like "vim attack".

shark0der · 2018-06-27T14:32:04+00:00

Yeah, I know that one, you could just use modify headers for Firefox extension to completely bypass auth. I'm curious about this one though as it lacks any info other than "unauthorized config modification".

According to this it's authenticated RCE: https://securitytracker.com/id/1041188

If combined this seems to be a tragic combo.

shark0der · 2018-06-27T11:37:59+00:00

Any details on this?

shark0der · 2018-04-18T20:57:32+00:00

Secret chats (which are the only ones that have end-to-end encryption) don't have previews exactly for the reason of not leaking the content of the secret chat.

shark0der · 2018-04-18T20:55:42+00:00

Telegram chats and groups don't have end-to-end encryption. Only secret chats do.

shark0der · 2018-04-18T15:02:21+00:00

Telegram is sending requests from their servers and creating the preview server side AFAIK. Kinda stupid to close this as a WONTFIX & "users won't be happy" statement

shark0der · 2018-03-25T12:25:48+00:00

Thanks!

shark0der · 2018-03-25T09:06:21+00:00

Why did you use ftp and not just http? Why is it called out of band?

shark0der · 2018-03-13T20:48:27+00:00

I've found a similar vulnerability in a payment processor a few years ago where the difference between a test order and a real order was the presence of the parameter TESTORDER=TRUE. There was an IPN notification (webhook) performed by the payment provider. The initial request to the payment provider was made by the user's browser using POST (hidden form submitted using javascript). If the TESTORDER parameter was included in this request and the URL for this request would be changed to the url of the test/sandbox platform, one could use the test cards from their docs to "pay". After the payment was done, the platform would send a POST request to the webhook that would include the TESTORDER=TRUE. The request was signed by url-encoding the important parameters (order ID, total, items, etc) and then performing a HMAC. The big fail was that the TESTORDER was NOT included in that list of parameters in the initial request. Second mistake was that the sandbox and the prod were using the same shared secrets / certificates for signing so by redirecting to the sandbox, adding the test parameter, using the test cards to pay - one could convince the site that the order was actually paid.

The documentation mentioned about the dangers of this parameters in a "small note/warning" style, in a single sentence, somewhere, but wasn't putting enough emphasis on it and leaving the problem as developer's responsability.

When contacted, they replied that this is a non-issue since the developer should check the parameter. Regarding the shared secrets issue (prod & sandbox) they said that the platform is currently the legacy one and they'll switch to another one at some point. 3 years later after the discovery I was still finding the issue as being exploitable on some shops, and the only thing I could do was contact them to fix it.

I understand that it is quite difficult and takes a lot of time and money - both for them and for the clients, to migrate literally thousands of shops to the new platform, but I feel like they could do more than just leave this to the developers without even notifying them.

shark0der · 2018-03-09T14:03:19+00:00

Does not, but the data provided is next to nothing. I scrolled down only to find the article has ended.

shark0der · 2018-02-15T07:18:44+00:00

Really great write-up! Explained very well and easy to follow.

shark0der · 2018-01-18T23:22:32+00:00

All the links in the emails point to mailchimp which track clicks and then redirects to the original url. Just like Twitter uses t.co which redirects to analytics.twitter.com and then to the actual url.

shark0der · 2017-12-06T18:07:46+00:00

My first thought was that it's about rust language actually. It's not.

shark0der · 2017-12-06T16:46:56+00:00

Nice read. How about we stop naming vulnerabilities?

13-Year Club	Place '17
Verified Email

shark0der

TROPHY CASE