Re: Botnets

[Aarón Mizrachi <unmanarc () gmail com>]

On Jueves 09 Abril 2009 14:53:10 R. DuFresne escribió:
> On Wed, 1 Apr 2009, Aarón Mizrachi wrote:
> > On Miércoles 01 Abril 2009 11:26:48 usted escribió:
>
>       [SNIP]
>
> > > > 1th motivation: Useful way to bypass firewalls, when a bot/trojan make
> > > > a connection to an IRC server, it connects like a normal user do it, in
> > > > the past, firewalling only protected you against incomming connections,
> > > > but, outcomming connections is allowed by default.
> > >
> > > Not nessecarily, firewalls can and often do control outgoing
> > > connections. Allowing all outbound tends to be more a desktop thing
> > > often employed by less technical folks often on home PC's.
> >
> > Heh, you are right, but i think you miss the point of my comment.
> >
> > We are talking about IRC botnets... The owner of the botnet commonly use
> > the bots for DDoS attacks, distributed password cracking, or something
> > like.
> >
> > Since... i was talking about home desktop's pc's used for this pourporse,
> > using a common setup.
> >
> > The goal of bot-owner can be reached with home-pc's.
>
> No argument here about the difference tween home pc's and work networks.
> Yet, some of us do take a work laptop off the work network home to do our
> chores.  And alsom, the key here is not how the botnet escapes the
> infected Pc to abuse others on the internet, it's the vector used to
> infect the system in the first place.  some here might remember back about
> 2000 or so and the slammer worm, worked to infect via the M$ protocols on
> the 135-139 ports, the infection vector.  Interesthing thing to note was
> that the folks both homeside and workwide that avoided that "intrusion"
> did not allow those ports into or out of their networks.  They may well,
> like me have allowed internal machines to use those ports though.
>
> Once systems are infected the game is lost.  the infected system is likely
> to find a way to communicate outwards via some channel unless the ultimate
> firewall is in place <the ultimate firewall, I beleive is a Marcus Ranom
> invention>.
>
> So, the real issue in mitigatiung the affects of botnets is not worrying
> about how to control outgoing traffic after infection, it is about how to
> avoid being infected in the first place.
Well... at this point, its your point of view. not else.

The original post was: "Can someone please explain to me how botnets use IRC?"

I dont know if im missunderstating the original question about: how botnets 
use IRC (Or specifically: The communication channel.)

From this point of view, we are studying and sharing experiences about the 
communication channel (And its variations).

Other points of view are valid. ;-)
> > > Most companies tend to block at
> > > least some outgoing traffic.
> >
> > Indeed. Companies can block some outgoing traffic. It depends on the
> > policy, but, there are two _common_ important holes of the outgoing
> > traffic:
> >
> > - Port TCP 443 (IRC SSL server can safetly run on this port)
> > - DNS (TCP/UDP 53)
> >
> > There are also DNS botnets, that can use dns resolve information to
> > receive commands... or send a reply... (with methods like iodine and
> > others).
> >
> > I seen before a network with 443 blocked or Mitm'd, and DNS limited, but:
> >
> > - 443 mitm represent a securit risk.
> > - block 443 will help you with security, but it'll decrease the usability
> > of the internet.
> > - DNS limited also will decrease the usability of the internet.
> >
> > Also i seen before a botnet patern detector, but, i also seen before
> > botnet's using random patterns and... "the delegate model"..
> >
> > But is not the case of study... because the goal of an attacker is to
> > infect easy computers. not a bunker network.
>
> again read my reply above...
>
> > > I note alot of FUD about firewalls and their abilities in this list in
> > > recent times...
> >
> > What is the real risk that you have to measure if you are talking about
> > of the company point of view?
> >
> > I already assume that you are bot-net free...
> > but, at this point, we are not safe from botnets...
> >
> > DDoS against the company can be possible, application resource
> > starvation, bandwidth starvation, distributed computing against you ,
> > whatever.
>
> Point of fact though, I do not need a botnet to DDOS or cause any of the
> above issues. 
False. DDoS stands for Distributed Denial of Service.

Denial of Service attacks that are not distributed are refered to as DoS.

> For DDOS I just need a slightly bigger pipe then yours.
False. As i said before, today, the starvation could be on many serious 
vectors like:

- Memory: Flooding bad cleaning code
- CPU: Flooding fat proccess (Could be done with a little pipe).
- Network: (bigger pipe than yours, but not necessarily true, depending on the 
routing algorithms)

Memory and CPU starvation to cause an DDoS (Distributed Denial Of Service), 
does _not necessarily require a big pipe which alone may fail_. 

But in the fact, starvation, to be success require:

* _A big amount of pipes with different randomly IP address not related by a 
net-block_.

Thats doesnt happen on a company because:

- The tendence is use NAT/PAT
- When the company have a netblock, the victim could success block the attack 
blocking the source.

And big amount of pipes happens frecuently in home-pc's because:

- The tendence is have a public valid ip address by home (On many ISPs around 
the world)

Conclusion: an attacker could prefer big amounts of home pipes than your 
bunkered company pipe or a big pipe alone.

> DDOS was a problem long before botnets came into the picture.  As well as
> the other problems you mention.  My point is that if you wish to make
> statements that garner support and gain real attention you do not do so
> distributing FUD within the message. This was learned quicky by many in
> the 60's and 70's when trying to lecture thier kids  about drugs and sex,
> and various other social issues.  An ouce of FUD/misinformation can far
> outweigh a ton of real information...

:-) yes, im a Fedora User and active C++ developer, but, concerning to Fear or 
something, we are disscusing about how botnets use IRC.  

Taking my points i was talking about: 

- PHP bots using IRC
- IRC over SSL 
- Other communication mechanisms.  

It's true and it's a real scenario happening every day. You should know it 
yourself, it's not like it's some kind of a secret.

> Thanks,
>
> Ron DuFresne

Handling your point of view... about how to avoid being infected, its a big 
deal... Like you, i also remember a week ago, how conficker was spreading on 
banks and sites that we suppose were secured and armored... 

Is not something new, and its a shame that a worm using old "already-used" 
techniques comprommised a big amount of "secured" computers...

- Weak password detection (already used in the past)
- Exploits that wasn't a zero day... (already used in the past)
- Shared folders (already used in the past)
- Pendrives (already used in the past)

>  Interesthing thing to note was that the folks both homeside and workwide 
that avoided that "intrusion"
> did not allow those ports into or out of their networks.  They may well,
> like me have allowed internal machines to use those ports though.

Like you mentioned, the people tendence on security is to trace a border and 
build a wall (firewall)... inside the wall, we dont care about security 
issues...  ("let me work" phrase), outside the wall, we are concerned about 
how this wall doesn't have any open port. 

But the security are the compendium of many visions... There is not a unique 
solution...

Ex.

- How many times we talked about blocking autorun.inf? (A simple registry key)
- How many times we talked about study the business process and adapt the 
network infraestructure and user policy to it? (creating network segments 
according to the business, blocking traffic between vlans or segments, etc...)
- How many times we talked about software patch managment? (from AV updates, 
to Windows Updates..)
- How many times we talked about the importance of antivirus...
- How many times we talked about the importance of not to run non-essencial 
services...
- How many times we talked about the importance of a security plan...
- And... its fud or like you need to name it: How many times we talked about 
we need to be aware of the risks...  
- etc.

And do you know, why, if we as security consultants said all these statements, 
there is happening disasters like conficker?

Its a simple answer...: Cost.

- adapt your network and user policies to your business have a big cost... 
poor scalation without a costly mantain of this plan...
- patch managment have also have a cost... that starts on license managment 
and update, and something very nasty: product lifetime and legacy systems.
- Antivirus have an implicit cost...
- run non-essencial services have also an implicit cost of usability (you 
prefer to right click and share a folder when you want, without call for 
support...)
- Security plan? do you have one? complains with ISO 27001 or something? and 
its well implemented?

Hehe, There is when the equation has to be completed with a firewall or AV 
vendor saying that his product will solve the 99.999999999999% of your 
security problems, from this statement, the sysadmin lost the fear of have a 
weak passwords and mantain C$||ADMIN$ && IPC$ shared... 

Well, Finally

its not about fear, its about understand EVERY risk, to make the best strategy 
and decisions. There is a lot of things to do and to develop... to protect 
ourselves, we will need strategy and new developments...

But, also we have to be aware that we NEVER should think that we have seen 
everything...

if you study about malwares, conficker was using a tiny spectrum of harmful 
techniques to propagate itself...


Regards.
Aaron.

------------------------------------------------------------------------
This list is sponsored by: InfoSec Institute

Learn all of the latest penetration testing techniques in InfoSec Institute's Ethical Hacking class.
Totally hands-on course with evening Capture The Flag (CTF) exercises, Certified Ethical Hacker and Certified 
Penetration Tester exams, taught by an expert with years of real pen testing experience.

http://www.infosecinstitute.com/courses/ethical_hacking_training.html
------------------------------------------------------------------------