As with Rob, this is my final say as well.

On Fri, Sep 11, 2015 at 1:38 PM, Petr L?z?ovsk? <lazna at volny.cz> wrote:

> > 1. Security through obscurity is your first mistake. There is no such
> thing.
>
> Interesting.... It does not exist, but it have article on wikipedia.
> Sounds like UFO or Yetti...
>

"Security through Obscurity" in layman terms is that you provide no
additional valid information to whomever is accessing your system.  If
you're URL provides CGI in its path, it points (Doesn't necessarily MEAN)
more at that it is a Linux box than a Windows box.  That doesn't mean it
isn't, just that it is more likely to.  Looking at HTTP headers, you can
find out what OS your script is running on, what version of PHP, ASP, .NET,
whatever.  Black Hats typically keep a very long list of found security
holes on every single version of whatever script processor you're using.
Obscurity means you're just muddying the waters, or hiding facts, *or
acting like an outright liar*.  It doesn't mean your system becomes locked
down and people aren't going to be interested ESPECIALLY if you're found to
be on a fat pipe to the net.  Because Security through Obscurity is
becoming more mainstream, I'm sure these Black Hats don't even look at that
and have techniques to just get what they need done.


>
> > 2. Assuming that nobody is writing CGI scripts on Windows Servers is
> your next mistake. A lot of systems still do this, a lot of old systems
> still use this technique and some new ones, The attack vector is not
> necessarily through your CGI script itself but through the Windows Web
> server. Unless you have patched and patched and patched your web server,
> you will be attacked.
>
> Of course I keep my web server software up-to-date, why do you think I do
> not did it? I am talking here about my scripts, not about the server SW.
> But the server SW is relatively rare too...
>

"Scripts" and the underlying script processors are what do the processing.
OS updates are one thing, but the script processing engine is another, and
so are the scripts you write.  If any one of those three links in the chain
are broken, then buh-bye security.  The script processor talks to the OS to
get things done, such as allocate memory, set aside a portion of drive
space, execute other code, etc.  If you don't sanitize your inputs 100% of
the time properly, you're subject to losing a LOT of information or having
your machine taken over, or as Rob mentions, resources sold (A thought I
hadn't even  thought about).  The 'execute other code' should scare the
bejezus out of you.  If your system is allowed to run other code (Say, for
example, [ ls -ltr /etc ] to get a directory list), if you don't sanitize
your code, someone can (Not might, CAN if you don't sanitize) change that
to [ ls -ltr /etc ; rm -rf /etc ] and if Apache has access to write
anything there, you have a new install of an OS to do.

The company I work for sells software for the web that runs off both IIS
and Apache under Linux.  Both are scrutinized for security even though the
main portion of the software is behind a paywall (Need credentials to get
into the heart and main functions of the system) and all communications are
via HTTPS.  All HTTPS does is ensure that no one else knows what you're
saying on the socket, essentially.  It doesn't mean that the system isn't
hackable.  If we didn't ensure that the login field on the login page
wasn't sanitized, then we're pretty much bending over.


>
> > 3. You assume that nobody is interested in your machine. Wrong. A lot of
> people are very interested as they can add your hacked server to their
> bonnet and sell your resources on. Your machine does not have to be
> publicised at all. As an example, I have a private server which I use. It
> has no DNS entry (a common way to search for machines), so is only
> accessible through an IP address which has never been published. It only
> has a single ssh port open and port 80 for a private web server running
> some software there rest of the machine is locked down as best I can. The
> lock down took me a day to do. It is not trivial. My last weekly report
> showed over 200,000 attempts to break into the machine via ssh, http, and
> various CGI exploits. Thats 200,000 robot attempts, the most prevalent was
> an ssh attempt from a single machine which accounted for 72,000 goes. A
> public web server I have has over 1M hacking attempts per week. This is for
> a low usage machine.
>
> Script kiddies starting codes writen to attack widely spreaded systems,
> otherwise it will be not much fun. Some of this codes could be specialized
> to intrude minor systems, but I have doubts there are number of working
> scripts to successfuly intrude systems with rare occurance.
>
> Real hackers, those who are experienced in writing WORKING code targeted
> to intrude one specific rare system, need a REAL reason to did such job. My
> system does not offer such reason....
>
>
"Real hackers" is funny.  I've never met a fake one.

People DO want your machine, and it isn't for fun, but for profit and
money, which is a hell of a lot more motivational than fun.  Your mentality
is still pointing at the script kiddy level, not at a high end serious
money making strategies which INVOLVES your computer(s).  They don't care
what your computer has on it, what it is running, what your software does,
or anything of the sort.  They just want onto your machine to make it do
their bidding, and if you don't ONLY secure the box with updates, and
validate that your code can't be tricked into doing something it shouldn't
be doing, then you might as well just hand the keys over to the black hats.


> > I give your machine less than 24 hours once it is live on the internet
> if you put it on without taking security seriously. You need to get the OS
> patched up, the ports closed down, the web server patched up and correctly
> configured. Out of the box the security on a Windows server (depending on
> the version) is poor. You need to learn what you need to do (and there are
> loads of guides on the internet) otherwise your server will be owned by
> somebody else very quickly.
>
> As I already wrote, not using IIS. OS is protected by manualy configured
> firewall. By concept Security through obscurity using this one
> http://wipfw.sourceforge.net/ Intruding script perform OS detection
> first, but do  not expect BSD firewall on Windows... Simple as it. Did you
> understand STO concept now?
>

A firewall isn't going to save your hide.  A firewall is a bunch of holes
to let information flow through to different machines.  It is a single
point in which one more more computers are exposed to the net.  Firewalls
have the ability to sniff out what inbound traffic is doing and validate if
what the inbound communication is doing is not an attempt to break the
TCP/UDP packaging system, or not allow Torrent traffic, or decide the
actions on whatever different type of communication protocols are out
there, but it ABSOLUTELY WILL NOT protect you against unsanitized code.

What people expect versus what people are going to do are two completely
different things.  They may not expect that you're running a BSD firewall
on windows, but then, why would they care?  They already know you're
running a web server, so they'll run their suite of tools against it to
find those exploits.

You need to get it through your head that money is the driving force Black
Hats work for.  If they have access to ONE of your computers, they may be
able to gain access to more.  If they have access to more, they'll turn
whatever they have access to into a cluster.  These guys DO-NOT-CARE what
you're running, just that the resources exist and that they want to exploit
it.

Reply via email to