« first day (3224 days earlier)      last day (33 days later) » 

7:47 AM
Q: PUTTY - Most insecure SSH client?

T.ToduaI have been astonished when I found that Putty stores cleartext credentials in Windows Registry: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\ How or why is Putty so popularized, while it has a child's play approach to security? Not only malware but even a simple bat file can steal th...

This is a prime example of "I have learned some information security principles, but not enough to actually see the bigger picture".
"If malware has admin access on my machine, it can steal my credentials." Yes, it can. It can also replace the executable of any SSH client I choose to use and steal the credentials that way.
@ConorMancone "Florida schools are now required to collect, store and crunch data on students in the name of predicting a school shooting."
It's not like teachers aren't very aware of which kids are being bullied every single day. We already have the data, we just choose not to do anything with it.
4 hours later…
11:30 AM
Q: How should major revisions of answers been dealt with?

MechMK1I recently had quite a funny case with this answer that I had written. I wrote an answer that was technically wrong. Overnight, the question hit the HNQ, and subsequently got lots of attention and upvotes. When I had returned, there were several comments, indicating that I was indeed wrong. I do...

I did an oopsie again
12:21 PM
@MechMK1 That reminds me of a random anecdote. In grad school one of the servers used by my research team was hacked and compromised, causing no small amount of trouble. I learned that the attacker got in because they gained the access credentials of someone in the department. Talking to my adviser about it I was like, "Who's stupid enough to give away their access credentials" to which he immediately responded, "Oh, that was me."
I felt like a complete ass
Turns out he was visiting another institution and their server had been compromised. The attacker had replaced their SSH client with a malicious one that sent credentials off to a C&C server they owned, so when my adviser attempted to connect to his "home" server from it his credentials were immediately stolen due to no fault of his own
Learned a few lessons that day...
Well, such is life. We all have been compromised at some point
I have been, it wasn't even such an elaborate setup
Just got a random link from someone in my steam friends list. He had been compromised, and the bot sent me a link
Since that friend happens to often just send me random links, it didn't seem like suspicious behavior to me
Incidents like that have worked on my personality over time to decrease the amount of "ass" I show on a day-to-day basis
@MechMK1 Any idea if it hit up a windows, steam, or browser-based vulnerability?
I always find those things fascinating
The malware was a windows executable that injects into the running steam process, sends itself to all people in your friends list and then attempts to trade all your items away to some throwaway accounts.
Luckily I had steam guard enabled, so the malware could not bypass that
I immediately reinstalled my OS, notified all my friends not to open that link and changed all my passwords
Nuke it from orbit!
I did
I didn't go as far as to get new HW, but it seems fine
12:32 PM
Yeah, I think that definitely would have been overkill. We get lots of those "I'm hacked, what do I do!" and often get answers suggesting new HW due to firmware exploits, but the reality (IMO) is that such things almost never happen. Unless your computer contains nuclear launch codes, firmware exploits are usually not worth worrying about. I'm always worried someone is actually going to buy a new computer because of an offhanded comment from someone like that
I think it's overkill as well. I get why companies with 1.000.000 USD IT budget might do that, but as someone with my income, that's just not worth it
On the other end our office server (used by about 20 people) got hit by ransomware and the IT guy in charge just locked down the account that got hacked, and then restarted the server to make sure there wasn't something hiding in cron to restart the ransomware.... I was like, "Are you crazy?" (not my actual words). Response: "Reinstalling will take too long"...
/double facepalm
It never occurred to me that the organization I work for has a terrible security posture (to be fair, true of almost all small/medium businesses)
I talked with the owner about a number of suggested steps we should take and in the end it just wasn't a priority
Turns out the hacker got in because we have an open RDP connection and most everyone uses password for their password. It was found and compromised by an automatic scanner.
When I figured that out the guy in charge of the windows server decided to put some password restrictions in place: minimum of 8 characters, requires at least one number in the password, and has to reset every 3 months. I about had a meltdown. "Dude, password1 is still an allowed password under those rules, and changing passwords every 3 months is just mean"
He set a 10 character minimum and now has the password reset every 5 months... /sigh
Changing passwords regularly is such BS anyways
It's security theatre
12:47 PM
Even the NIST doesn't recommend it anymore. It's a personal pet peeve.
I like to play Security Inquisition then:
"Why do you use a 3 month password expiry?"
"For increased security"
"Security against what?"
"So that if a hacker gains access, it's not permanent?"
"So you would be fine with a hacker having access for up to 3 months?"
lol! In this case it was clear that no one else cared. In my experience, it's a waste of time under those circumstances. In fact, this was actually the second time the office got ransomware (the first time was before I was hired). If it happens enough times the loss of productivity might eventually convince the owner to care, but in the meantime it's about baby steps in the right direction
The blackhat approach to security
Each breach either destroys the company or gets them to increase security
1:02 PM
Unfortunately, In my experience that's the approach that most companies take.
Hence my rule nr. 5: "Proactive security is cheaper than reactive security"
And since you mentioned backups: If restoring a server from a backup "takes too long", then you need a different backup policy.
2 hours later…
2:36 PM
This guy really lost the forest for the trees
Q: Double Submit Cookie: Can the attacker set the cookie as a separate header?

zerohedgeI’m using an HttpOnly cookie to store authentication token client-side. To mitigate some of the risks of CSRF attacks, I’m employing the Double Submit Cookie pattern. The same token is saved client-side as a separate header with the same value, and both get sent for subsequent requests when the u...

I have to admit I don't have that much experience with CSRF mitigation techniques
It's one of the easiest to mitigate. In this case though the weird part (to me) was that he has an HTTPOnly cookie and he also stores its contents elsewhere in the app. Completely defeats the purpose of an HTTPOnly cookie.
That is true, yes. Though I would say a missing HttpOnly flag can be excused, if it is necessary to use the cookie in JS
3:11 PM
@MechMK1 Yup, absolutely. An HttpOnly flag isn't a requirement. However, if you're going to have an HttpOnly flag, then there's no point in also storing the cookie contents in the application. Those two actions are mutually contradictory
3:22 PM
@ConorMancone Yep. Typical case of adding security features without really groking it
Hey, so where's a good place to submit a public disclosure report for a company that has completely refused to acknowledge all attempts at responsible disclosure?
@ConorMancone medium?
Not a bad idea. I've read plenty of public disclosures there (although usually with the companies permission)
Just yeet it on twitter :D
@ConorMancone if the company won't acknowledge the responsible disclosure your only recourse is to go for full public disclosure
whether that's disclosing the vulnerability exists, or disclosing the vulnerability and exploit code, that's your call
3:37 PM
@ThomasWard Yup, that's my plan.
the other option is "Do nothing" but it sounds like you're not wanting to do that
@ThomasWard exploit code is not required in this case. It's a website with literally zero security and probably a few thousand customer (individuals, not businesses)
ah, then that's a little harder to do responsible disclosure ;)
i'd ask the specific site but i'm not really that interested xD
your only recourse is public disclosure
see if the public using that site actually care or not.
THIS SAID... if the 'static' site is not secure but the actual login/etc. stuff is secure that's not necessarily a vulnerability (Unless you have proof there's literally 0 security across the board)
It's for an app. The API endpoints are easy to guess, and it turns out that prepared queries are not used anywhere, among other very basic security mistakes (directory listing is on, application files and config are hosted in the public directory, etc...). It's a complete security disaster. Contacted the company a number of times over the past month and no one ever responded
I guessed an API endpoint and immediately found all sorts of vulnerabilities because I didn't include a necessary field and their lack of prepared queries meant that it triggered an SQL syntax error. Which I knew about because they had error reporting turned on and it printed out a full traceback with dozens of warnings. It would have been funny if (I'm pretty sure) there weren't login credentials for a few thousand users hiding in the database...

« first day (3224 days earlier)      last day (33 days later) »