Live data from Hacker News

Show HN: URL Canary – Get an alert when someone finds your secrets

urlcanary.com

71–80 of 122 posts

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#71

Earlier quoted context omitted.

Indeed, at £1k (€1136, $1403) one might as well run an internal application. At a very basic level, it can be achieved with three lines of bash: while echo -en "HTTP/1.1 200 OK\r\n..." | nc -l $IP $PORT; do cat $MESSAGE | sendmail -i -t done More complex configurations could still be worked out in <50 lines of Python.

Why would anybody buy this (dropbox), I can recreate this with a simple ftp server and 30 minutes of coding!

Dropbox is not a devs-only product, given that eg. the CEO might want a personal Dropbox folder, or one might need a shared folder between the marketing team and the developer team (and even then, at the enterprise level it is not unheard of to use simpler alternatives like SFTP/NTFS shares).

Canaries on the other hand are exclusively used by technical people, who won't mind developing and spinning up a tiny honeypot.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#73
post #63

Semi related asking the wizard of HN. I recall reading a similar trick whereby one can embed a github key/token/api key/??? In a source file in one's repository and then if your code ever is stolen and pushed to github then you will receive a notification because github will revoke the token. Does this or similar ring a bell for anyone?

https://blog.github.com/2015-02-05-keeping-github-oauth-toke...

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#74
post #43

Earlier quoted context omitted.

If you can use any domain you like, that is great. MyURL.com/101/passwords /private /logins Is the idea that you'd embed this in a way that it is automatically triggered? Or that you would leave it in plaintext somewhere and assume someone would eventually visit it if they were snooping around your stuff?

You can use any domain you like, although I don't think I've documented that. Just point any domain at 46.101.33.42 and it'll work. (But obviously it needs to be a hostname you're not already using for something else).

Thanks!

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#75

Earlier quoted context omitted.

Given this kind of disaster potential, wouldn't it be a rather attractive option to use /dev/urandom?

Bytes::Random::Secure::Tiny seeds itself from /dev/urandom, I just need to make sure to initialise it on first use, instead of when my program first starts (which I've now done). In general I suspect if anything you'd be more likely to mess it up by reading bytes from /dev/urandom manually than by using a library.

I though the main issue of reading bytes from /dev/urandom was performance (ignoring the issue of ensuring /dev/urandom has been initialized since boot.)

So instead, we use them to seed CPRNGs, and use them for speed.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#76
post #43

Earlier quoted context omitted.

If you can use any domain you like, that is great. MyURL.com/101/passwords /private /logins Is the idea that you'd embed this in a way that it is automatically triggered? Or that you would leave it in plaintext somewhere and assume someone would eventually visit it if they were snooping around your stuff?

You can use any domain you like, although I don't think I've documented that. Just point any domain at 46.101.33.42 and it'll work. (But obviously it needs to be a hostname you're not already using for something else).

Sorry to offer unsolicited advice, but are you sure you wanna use a fixed IP for that? Seems more reasonable to ask people to CNAME to a domain you guarantee will always point to the correct servers.

This means you don't break the system when you move IP address. Moreover, should you ever need to, you can round-robin the domain for either reliability or load-balancing (though I doubt that would be necessary).

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#77
post #53
post #45

Earlier quoted context omitted.

As skeptical as I am about crypto currencies, this is a really interesting application. Basically exploiting human greed. Thank you for sharing it.

That's some awfully pessimistic and dehumanizing language. I just consider it to be paying someone for the trouble rather than jumping straight to "exploiting greed."

Since the person profiting is someone who obtained the secret through shady means - either breaking into an insecure system, or taking advantage of their access to a system which doesn't encrypt passwords - I don't consider it pessimistic or dehumanizing to describe the behavior as greed.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#79
post #40

Earlier quoted context omitted.

Put a URL in a firmware image that is never called by your device/app. Monitor the URL for access. You then receive an alert that someone accessed the URL. This gives you a real-time notification that a reverse engineer has looked at your firmware. It also gives you an IP address. So you now “know” that someone might try to hack your device. And you also have an IP address. This is a billion dollar security play! Jok…

Huh. That’s...a good idea. The idea has to be developed further though. This has to be deployed on different domain names and with full content control on the web pages. I guess that’s all doable with the “private server with root access” under enterprise pricing. What a great way to precisely measure cover time. You could inject arbitrary URLs into an application to see if your API has been reverse engineered.

Hackers worth their salt work in air-gapped environments.

This is a signal, but not a game changer for security pros.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#80
post #40

Earlier quoted context omitted.

Huh. That’s...a good idea. The idea has to be developed further though. This has to be deployed on different domain names and with full content control on the web pages. I guess that’s all doable with the “private server with root access” under enterprise pricing. What a great way to precisely measure cover time. You could inject arbitrary URLs into an application to see if your API has been reverse engineered.

Hackers worth their salt work in air-gapped environments. This is a signal, but not a game changer for security pros.

I’m speaking specifically about the case where someone is trying to reverse engineer a private API from an application. Then interacting with an API endpoint will necessarily trigger the canary.

Having retrieved API secrets offensively, and overseen secret rotation defensively, I’d say it would be a game changer. It’s an excellent idea to automate this discovery with an alarm. The current discovery system is either an internally developed, half-baked version of this that comes from sophisticated logging, or manual oversight.

Post reply on HN