Monday, January 28, 2019

Chrome and xclip

Have been watching a number of crackme-type walk-throughs, where the speaker relies heavily on xclip to capture a command line output so that the mouse can be used to paste data into the browser. I could never get it to work with Chrome, until today. To use xclip with Chrome, add the following to ~/.bashrc (or .bash_aliases if you have it): alias xclip="xclip -selection clipboard" After that, it should work as expected.

Thursday, January 10, 2019

My VLAN beef

After all these years, why is it that pundits still associate use of VLANs with security? Any security afforded by use of a VLAN is a side effect and is considered (by those in security) as not assurable (e.g., it cannot be proven by testing), is easily broken, and is very easily mis-configured.

A VLAN is a traffic management tool, designed to increase overall (employable) bandwidth in an architecture. It does not employ authentication or encryption. Security is increased (often negligibly) by ensuring that traffic doesn't "go" somewhere. In some architectures (e.g., VoIP phones on the same network segments as the workstations), this separation doesn't exist.

Monday, December 31, 2018

Modify Recoll's Web-UI Template

I've been experimenting (again) with search engines (other than the Sphinx/MySQL-based document management system (DMS) currently used in-house), in attempt to come up with a less input-intensive approach to managing thousands (coming up on 11K) of documents. The tool that I'm currently testing is Recoll (something that I've worked with before).

In an attempt to make each document's metadata more portable, I'm working on embedding such within each document's EXIF data (via the exif tool). This approach dovetails nicely with my kluge of Gleebox, Chromix, and (recently added) SurfingKeys browser extensions.

Mod 1

I've added an "Edit" link to Recoll's "Open/Download/Preview" menu. Clicking on Edit takes the user to the metadata editor from the existing DMS system. Of course, the editor no longer saves to the database. Instead, it saves the metadata in the documents EXIF header.

Mod 2

I've enabled display of tags (Recoll calls them "keywords") in the Web-UI's output. This was a simple addition because Recoll already indexes keywords from document EXIF headers (if they exist). In a future version, I intend to modify the template so that each tag is actually a link to a listing of other documents with the same keyword. Implementation will likely require use of a SQLite3 database, which is periodically (nightly?) rebuilt.

So far, I have the following opinions about Recoll:


  • The approach is much more portable as there's no longer a separate database to replicate/back up/otherwise maintain.
  • I don't have to write additional document parsers (\o/ -yay!). Not that I have very many Word documents in the data store but...


  • A C++ engine that uses HTML templates for the front-end, which contain embedded Python commands, with Javascript and CSS making everything look pretty. Need I say more?
  • A cannot seem to get a consistent output from the same search phrase. When more than one page of results exists, relevence sorting returns slightly different ordering each time the query is run. Note: this may be a result of my ongoing updating of metadata info but it should affect results to the degree that it does.
  • There's no "sort by title" search option. Shouldn't this be a must-have?


Overall, it's a usable tool but the following may make it more attractive:

  • Thumbnails in the results.
  • Keywords which are individual links to external tag lists.
  • Triggering recollindex via inotify.
  • Sort by title


The new Web-UI result.tpl template is posted on: Github.

Sunday, December 16, 2018

To-do items

Notes to self/for the to-do list:
  • need a way to reference specific docs as external links (probably need a get function and an internal link)
  • feature for DMS - flag for possible project or useful for pending/existing project
  • after start of new year, clean out deprecated/non-functional feeds from rss reader

Wednesday, August 22, 2018

Journalism? Meh.

I don't usually write this sort of post anymore, mostly because it's no longer catharsis for me, but there's an article on CSO Online, entitled "32,000 smart homes can be easily hacked due to misconfigured MQTT servers" (by Ms. "Not Her Real Name" Smith), that annoys me to no end. It comes across as little more than click-bait and the magazine doesn't allow comments. My issues with the article follow.

The author's derision, aimed towards use of an "older" protocol, is irksome. Talking about a "bygone era when security wasn't a concern" is the trademark of an engineer who's promoting something else (solution, self, or corporate stance). That said, I do like how the author avoided use of the word "legacy" (I see it all too often) but, using her logic, Tim Berners Lee could be blamed for the Equifax leaks. The insecurity lies in the lack of proper configuration, not the protocol.

You keep hearing about how IoT is insecure? It's the "I" in IoT that's the problem. The article somehow avoids discussing how MQTT was not meant to run in any environment other than a local LAN or within a single security enclave. As with any other similar protocol, running it "on the Internet" adds insecurities.

Another problem is use of the phrase "Avast found...". Let's give credit where credit is due. Avast did not scan the Internet looking for insecure MQTT servers. Instead, someone at Avast used Shodan to get their numbers. Effectively, this is taking credit for someone else's work. Do they no longer teach "quote your sources" in college?

I have a Shodan account. As of this morning, the MQTT numbers break out to:

Total:  49,223
China: 12,185
US:  8,315
Germany: 3,048
HK:   2,177
RoK:  2,033

If you search specifically for port 1883, the numbers are:

China: 12,115
US:  8,275
Germany: 3,042
HK:  2,186
RoK:  2,031

This article butts up against another topic: being a journalist doesn't exclude you from laws. It doesn't matter that an insecure server exists on the Internet. If you connect to that server without permission, you've violated a number of laws. It's irresponsible not to mention this. The article should include such a warning, vice implying how easy the servers are to access.

The article ignores that there are some servers (okay, only a few) that are set up to be intentionally insecure. There are a number of use cases where a server might be set up insecure:

  • A few of the insecure servers might be the honeypots set up by varous organizations. A Google search for "honeypot mqtt" returns some interesting examples.
  • Some servers are intentionally set to be insecure. Ignoring the usual hackme/CTF stuff, brokers like HiveMQ are set up open, so that others can develop code and/or learn about use of MQTT. (Google search for "free mqtt broker"). Others are set up to provide public services (e.g., weather stations, ISS locator, stock data, Twitter feeds, BBC Radio 3 LiveTexts) (examples here and here).
  • Some people don't care that they're being tracked. More often than not, they're tracking themselves and don't care if anyone else knows their location. The free MQTT servers are "open" and the encrypted/authenticated servers are not. Some people make the conscious choice to use the open servers. Some of those already know that they can be tracked via other means (e.g., your Android or Apple phone). The author's "shot" at OwnTrack fails to recognize that OwnTrack requires the user to "find" an Internet-accessible MQTT server (OwnTrack doesn't provide such). The author should probably next write an article about how APRS is insecure.

This doesn't mean that there aren't insecure MQTT servers on the Internet. They do exist and they make up the majority of the numbers discussed in the article. However, not accounting for legitimate use cases, warning about accessing systems without permission, etc. (when writing a "doom & gloom" article) is just shoddy journalism. My 7th grade English teacher would have given this article a C (also, he'd probably make a comment about the quality of the magazine editor).

Wednesday, August 1, 2018

What was I reading in July 2018?

This was another of those months where I've been so busy that I did very little reading. Once again, I'm studying for multiple certification tests (re-tests?). Related to reading, the current Humble Bundle is looking quite interesting.

For those with access to the house network, the ESXi upgrade (to 6.5) appears to have worked without issue. Also in the network are: 2 Kali instances with the first target and a full reverse proxy, a Gogs instance, a Markdown editor, a Vim trainer, and a web-based man page reader. Some heavy tweaking of the reverse proxy was required but it appears to be working (including access to VMRC from the Hamachi network).

For awhile, I was having issue with the "s" (star) key in TT-RSS. It turns out that my customized instance of Gleebox had updated and the navigation settings had shifted from the right-side of the keyboard to the left. Finding it required that all extensions be turned off and behavior studied while each was re-enabled. It appears to be "playing nice" again.

I received a DLP-to-RPi adapter board from Mick Makes. Although it's intended to work with the RPI Zero, I'm hoping that it'll work with the new B+. It should, because the Zero and the B+ have the same header pin-out. Fingers crossed!

I've also turned on HTTPS for the blog (just now). Whether or not it works well remains to be seen. In any case, this past month's reading...


- How we discovered three poisonous books in our university library
- Pointers Are More Abstract Than You Might Expect in C
- There was a time when search engines were a thing. And it seems they still are
- SMS over IRC
- Reverse Engineering for Beginners


- Anti-Flow
- The advantages of an email-driven git workflow
- Water compresses under a high gradient electric field


- This new dual-platform malware targets both Windows and Linux systems


- Your IoT security concerns are stupid


- A Short Guide to Hard Problems
- did.txt file
- How to Implement Open Source Container Security: Part 1 - Runtime Security


- C's Biggest Mistake
- Autopsy of a deep learning paper


- Leonardo Da Vinci's To Do List (Circa 1490)

Above was generated by a homegrown bolt-on script for Wallabag, which is a free utility for capturing web content so that it can be read later.

Monday, July 2, 2018

What was I reading in June 2018?

Didn't get much reading done this past month. Between the day job and moving/updating the lab, there was very, very little leisure time was left. I did manage to write a script to clean up buddy requests in a Bitlbee/ZNC architecture (separate post in this blog).

For those with connectivity to the lab, it's now running on ESXi v6.5. This means that ESXi labs are possible, without having to install the vSphere Client. Because most modern hypervisor platforms are "nestable", this means that you can install/learn about other hypervisors (or install ESXi on top of ESXi).

In any case, last month's articles:


- De Bruijn sequence
- Microsoft Is Said to Have Agreed to Acquire Coding Site GitHub
- The Long View: Nobody Expects an Accountable Inquisition
- Patents - how and why to get them
- Price's Law: Why Only A Few People Generate Half Of The Results
- Today we mitigated
- Microsoft's Interest In Buying GitHub Draws Backlash From Developers


- Marcus Hutchins WannaCry-killer hit with four new charges by the FBI


- Reverse Engineering One Line of JavaScript


- SPARK Core - Nextron Systems - Yara scanner. Looks interesting.


- Face recognition with OpenCV, Python, and deep learning
- x86 assembly doesn't have to be scary interactive


- Calm Down: It's Only Assembly Language
- Trachtenberg system