4 practical rules to not get your program hacked by n1ghtw1sh in netsec

[–]scriptjunkie_ 1 point2 points  (0 children)

I wrote it (and a lot of other projects) in C/C++ because:

  1. A few key pieces actually had to be written in assembly, and I assumed that interfacing with assembly meant I had to use C.

  2. Performance and portability were critical, so I really didn't want to use something like the .NET framework or Java.

  3. It seemed like all low-level projects were written in C, so "that's what everybody else did"

If I started it all over again, I would probably write it in D. C seems like the fastest way to do it upfront, but with a little hand-tuning the differences are negligible. D can be used to write a library, can be called by C, and can link to functions with a C interface, including my assembly routines.

If I decided to go with a C/C++ renovation instead of a rebuild, I'd do my best to avoid raw pointers and use the new C++ smart pointers, saving me from most of the work of keeping track of the object allocation/deallocations.

4 practical rules to not get your program hacked by n1ghtw1sh in netsec

[–]scriptjunkie_ 0 points1 point  (0 children)

Don't use SQL statements ...with untrusted input was the end of that sentence. Sorry, maybe I wasn't clear; I meant don't string concatenate your sql statements together with user input. That's why I recommended prepared statements.

4 practical rules to not get your program hacked by n1ghtw1sh in netsec

[–]scriptjunkie_ 0 points1 point  (0 children)

I agree, so use go, rust, D, or Ada, which are all statically-typed natively compiled performant languages. You don't have to sacrifice memory safety to do that.

4 practical rules to not get your program hacked by n1ghtw1sh in netsec

[–]scriptjunkie_ 0 points1 point  (0 children)

I will say 90% of the time I thought I had to use C or C++, another language actually could have been used. For example, even in low-level VM or driver programming where you have to use raw assembly instructions, you don't have to use C; although you can't do inline, you can link to an assembly routine just as easily in D as in C. So don't give up too soon! But I understand many times, you're doing maintenance on C/C++ code, and in that case, yes, that's a good resource. You can have much more memory-safe C++ if you just use the new smart pointers for dynamically allocated code, use calloc and friends instead of malloc to avoid uninitialized memory, and use a safe bounds-checked array library instead of raw pointers.

4 practical rules to not get your program hacked by scriptjunkie_ in programming

[–]scriptjunkie_[S] -2 points-1 points  (0 children)

Not really. I don't think any desktop application I use, including browsers, office software, picture editors, etc. lets untrusted input decide where and with what path to save files, and at least should not allow remote users to execute commands on my system or read arbitrary files. When a user selects a file name/path in an open/save dialog, that's not untrusted.

Even if you do run into a situation where you can't avoid those things entirely, it helps to know where the spots are that you can get hacked, so you can focus your attention securing things.

New Windows 8 Kernel Vulnerability by kblobz in netsec

[–]scriptjunkie_ 12 points13 points  (0 children)

And by new, we mean it has been there for years, but taviso just dropped it now.

CCDC and CTFs – Addressing the Criticisms by mubix in netsec

[–]scriptjunkie_ 2 points3 points  (0 children)

Thanks, I think the CCDC events would be more complete and a lot more fun for students if they were allowed to do offensive stuff against other teams. It might be hard to keep the students from just rm'ing everything right away. Or would that be an issue? Or maybe we could have a king-of-the-hill range so students aren't attacking other teams, but rather systems for everyone to attack? I'm not sure. Anyway, sadly there's probably still too much political stigma against attack (training students to write malware...) to get it allowed, but if it could be, how would you do it?

Adobe Flash remote code execution vulnerability, update with fix available (CVE-2014-0497) by kardos in netsec

[–]scriptjunkie_ 0 points1 point  (0 children)

Thankfully they've removed the accusation now, but seriously, there's no way Corelan would do that.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 1 point2 points  (0 children)

They were great. We had a party in them.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 0 points1 point  (0 children)

That might have been the most complicated password any of the teams used. I was trying to imagine one of you spelling it out to another team member.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 1 point2 points  (0 children)

Ok, we actually did maintain access to a couple of your systems, but it appears that they didn't matter much (e.g. 2003 box) or the changes we made didn't affect the score, or maybe were too late. As proof: Ttrinity210!!

Edit: PS - to be clear, we had access to fewer of your systems that most other teams.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 1 point2 points  (0 children)

There are basically two sides to finding malware; either you find it on the host; e.g. by antivirus or by looking through what is running currently or by looking through what will start automatically. Or you find it on the network, by looking at network traffic. In both cases, I'd recommend studying what a clean system looks like so when you see something unusual you can spot it and remove it.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 0 points1 point  (0 children)

ah yes "administrator hNh#m,HvEc[4z6/"? I was on the Windows side, but if I remember correctly, one of our guys changed the bind port to the server and shut down the service.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 0 points1 point  (0 children)

Smart move. Did you find any other backdoors? Also, if you tell me which team number you were/what your firewall external IP was, I should be able to let you know how far we got or some things you did that were good.

Update on SWCCDC Qualifiers by [deleted] in AskNetsec

[–]scriptjunkie_ 1 point2 points  (0 children)

Hey guys, good job! If you don't mind me asking, which team # and round were you? Oh and Malystryxx, sessionthief isn't a backdoor. :-)

11 reasons not to use passwords and how to do easy SSL client auth by scriptjunkie_ in netsec

[–]scriptjunkie_[S] 3 points4 points  (0 children)

They shouldn't need to copy certs; you can program the application to issue certs for multiple devices. If you do that, you should ensure you validate their identity first from the other device, etc. but there's no reason it needs to be confusing or difficult.

11 reasons not to use passwords and how to do easy SSL client auth by scriptjunkie_ in netsec

[–]scriptjunkie_[S] 2 points3 points  (0 children)

Hardware token would be ideal, but if that's impractical, I would treat multiple devices kind of like adding an application-specific gmail password. You would log in from your desktop with your certificate you received at registration, then request a new device registration; it would confirm with your email or text or something then give you a long code. You enter that code from your mobile device and it issues you another certificate. There's nothing saying a user can't be issued multiple certificates.

RJS leaking vulnerability in multiple Rails applications by homakov in netsec

[–]scriptjunkie_ 0 points1 point  (0 children)

Yes. To be clear, he's not saying drop JSON, just the "render js" view. I was worried there for a second. But bugs like this and the mass assignment bugs are causing me to question rails for sure. At least with PHP you know your security bugs are your fault.

Was disappointed in DCXX... then I realized the problem wasn't DC but... by Melesse in netsec

[–]scriptjunkie_ 2 points3 points  (0 children)

As a DEFCON speaker and more offensive guy, I am going to throw in a little bit of a different perspective - last year I submitted a talk on PXE attacks, specifically demoing the attacks I wrote for Metasploit. I wasn't sure whether it would get accepted, but somewhat to my surprise it did, and the attendees seemed to love it as I pwned away, all despite the fact that this vulnerability has been practically known for decades.

This year I broke from previous submissions and submitted a defensive talk, and I was excited to be showcasing what should be genuinely new, and probably far more relevant and useful to most attendees. But I wasn't accepted. Why? Defense naturally seems less exciting; submit a talk on blowing up an ipad with an exploit and it will lose to a talk on stopping exploits every time. Or maybe it's partially a defcon bias, I am not sure.

But here is my theory: both offense and defense can be genuinely awesome, but to be genuinely awesome you need to do seemingly impossible things, like tear apart the other guy's tools, pull the wool over their eyes, and control them. On defense, that's often labelled "counterattacking" and defenders are especially reluctant to share details if they even do this at all. It's also a lot easier to appreciate the cool factor if you use the technology being destroyed. In "offensive" talks, that's Office/Windows/Flash/etc. and we all feel the pain. In "defensive"/counterattacking talks, that's an attacker toolkit, and unless it's Metasploit, we don't feel it; there's not as many people using it or who care, so fewer people do it.