fabacab on master
Fix typo. (compare)
fabacab on master
Cleaner configuration. (compare)
fabacab on master
Fix ToC link. (compare)
fabacab on master
Additional reference. (compare)
fabacab on master
Add TCP Meltdown and TCP-over-T… (compare)
🔰 🏴 Historically, and in SSH's output today, this kind of active interception is termed a "man-in-the-middle attack." While the author concedes it is undisputably true at the time of this writing that most such malicious behavior is conducted by men, this term carries sexist implications and is also technically inaccurate. We therefore use the gender-neutral and more accurate term "machine-in-the-middle" instead.
@/all For those of you who remember last year's AnarchoTech NYC CTF games, several of us participated in a cybersecurity challenge known as PicoCTF. It is designed for middle and high school students, but that doesn't mean they are trivial problems.
It is happening again this year! If you want to be on our team, message me privately, and I'll loop you in. Last year was a lot of fun. You don't have to be in NYC to participate, but you do have to dedicate a chunk of time to play with us (since there are a limited number of spots per team). We typically "meet" in a private channel (so as not to wreck the fun for anyone else). You can play asynchronously, but it's more fun if we coordinate a time to play together so that we can pair on challenges and thus learn more along the way. If you've never done this sort of thing before, I suggest that you set aside an entire weekend, at a minimum.
If you can't commit to this, no worries! You can still register to play independently and still chat about your progress here and/or elsewhere. Registration is free and does not (technically) require your legal information. Use Tor and a disposable mail service if you need the added privacy.
Have fun, and I'm looking forward to playing this with some of you when the game starts on September 28th.
Not sure if folks are particularly interested in this, but I started writing up another practice lab that begins closer to, well, the beginning. It's an introduction to new kind of introduction to the command line, focused on security of course, called Securing a Shell Account on a Shared Server.
And here's (one reason) why you might want to read it: it's got a fictional narrative. :)
Imagine, for a moment, that you are an employee at a company with a mainframe system, or a student at a prestigious university that had a computer department. You come in to work or school and sit down at your desk. On your desk is a machine with a monitor and a keyboard. There is no mouse. There is no tower with a blinking light. There are no hard disk drives, no compact discs (CD's), and no thumbdrives anywhere in your office. There is only a keyboard with a long cable coming out the back, and a monitor with a similar but thicker cable.
On the monitor is a power button. When you press it, the screen flickers. Slowly, a green phosphorescent light shines from the video monitor in the shape of text. The text reads:
This moment is arguably one of the early geneses from which all modern computing was born. This simple experience of digital access is both the promise and the power that we will be exploring during this lab. If you can understand at a deep and philosophical level exactly what happened when your imaginary alter-ego from the 1970's turned on that monitor, then there is nothing that happens on a computer today that will be a mystery to you.
What you are seeing is the result of electrical charges sent from the mainframe, located somewhere else on campus, over the cabling and ultimately into a cathode ray tube that fired electrons onto the glass of the video monitor. The glass is coated with phosphorescent dust, which shines when charged. The result is your invitation into Wonderland:
Hey all, does anyone have any experience programming in Lua? There have been two independent situations in the same number of weeks in which it would have been extremely helpful for me to know more about the Lua programming langauge than I do. The first is when I took a look at an Nmap NSE script, which was Lua, and the second was when I found myself needing to write a Wireshark protocol dissector, but hoping not to dive too far into Wireshark's C API because all the documentation keeps telling me that using Lua is faster for prototyping.
A lot of the Lua stuff I'm finding seems to be revolving around game development. That's nice and all but not really what I'm interested in. I have, of course, found the Lua reference manual and its getting started sections, and they're…fine. The book they recommend is also…fine. It has a lot of maths examples, which I don't care for. I'll read them if there's nothing better but I just thought I'd ask for advice in case anyone knows of a diamond in the rough for these sorts of tasks.
(P.S. Please don't tell me "use Python." I know Python is the go-to language for a lot of stuff these days. When Wireshark and Nmap get Python bindings, I'll use Python. In the mean time, help me learn Lua. Thanks.)
@camfassett Welp! We discovered recently that they changed the PicoCTF mechanics this year. Last year, you were able to re-submit the same answer as someone else on the same team and the game would tell you whether or not the answer was correct. This made it possible to be on the same team but still solve problems (and thus try your hand at learning from them) individually. This year, the game doesn't permit this. Which I suppose makes sense if you're actually a physical classroom, but makes less sense for our situation. Sooo, weirdly, we…no longer really have a team.
You can still create an account as an individual (which you'd need to do anyways), though, so if you wanted to try your hand at the challenges, the best thing to do is simply register at https://2018.picoctf.com and then ping this channel when you're trying a puzzle. :)
Hey all lemme ask you something: what year is it?
Because I just spent the good part of a night and a bit of this morning trying to troubleshoot a problem with a USB boot disk thinking there was some bullshit about the filesystem I had to do some hardcore Matrix-fu on and you know what the actual solution was? The USB wasn't getting enough power. The solution, ultimately, was to unplug that shit and then literally wait 5 minutes and plug everything back in again. ???????????????????????????????????? Leaving me staring at the solution's success murmuring softly, "It's 2018" over and over again.
Anyway, for anyone who runs into this problem potentially, what happens is when you try to install an OS using a USB as your boot media, you might get this error that says
device descriptor read/64 error -110 -- that last number may vary. Essentially this is a sign that the USB isn't getting enough power to actually serve as a filesystem. After that, you get dropped into an emergency mode shell such as dracut.
To fix this:
I did not think this would work, but lo and behold, it fucking did.
Update for those who are enthralled with IRC: the above linked Digital Ocean guide turned out to be out of date enough that many things have changed. The newest release (alpha) of InspIRCd came out 5 days ago, also!
So, using the official InspIRCd wiki is proving to be much more fruitful thus far. Specifically, these installation instructions. I'm trying to get this set up now on a Debian stretch VM. Wish me luck, I'll reportback here. :)
I have been a little preoccupied as well, working on an Ansible role for Tor Onion services.
iptablesrole, which automates firewall configurations. Here's a somewhat complex example of auto-configuring the firewall based on a related role's configuration.
Unsure if anyone here can help but here's a problem I'm running into: I'm trying to have Prosody make s2s connections in a very small test network (two machines). I want userA@s1.invalid to be able to speak with userB@s2.invalid. Classic federation, nothing complex.
I can make this work when not using s2s TLS connections, but whenever I try to make s2s connections over TLS, I see a
policy-violation in Prosody's error log (when set to
debug), which says
Encrypted server-to-server communication is required but was not used. This message comes from this part of the code.
I can't quite figure out why this is happening, though, because I've already:
mcabber) in strict TLS mode (
set tls = 1) to verify that the mcabber client on s1.invalid can log in and authenticate as userB@s2.invalid from s1.invalid (ensuring that s1.invalid's root certificate store trusts s2.invalid's newly generated TLS certificate), and vice versa.
Sooo…I'm at a loss. It appears as though Prosody's s2s connections just aren't using TLS at all, even though I have explicitly required them and, AFAICT, set it up correctly so that it works flawlessly for at least c2s connections.
Here is a test branch of my current code in a Vagrant multi-machine environment that describes the above situation:
If you want to try it out, the Vagrantfile at that commit should be all you need:
vagrant up && vagrant provision --provision-with=tls
Thanks in advance.