DISCLAIMER : [Insert the biggest, most comprehensive lawyerspeak here]. Basically, the author(s) are NOT RESPONSIBLE for anything arising out of the information presented below. Enjoy.

Contents

• Covert Channel and Tunneling over the HTTP protocol detection
  (Simon Castro from Gray-World.net)
  
  
• Technology without policy
  (Rants from Charles Hornat)
  
  
• Generic attacks against a honeypot : Blind your enemy
  (An interesting possibility of DoSing sensor mechanisms)
  
  
• Innovative Mailbombs : A new approach
  (An unreleased paper from 2001 .. does it hold true today ?)
  
  
• New Beginnings
  (Rants from a faceless curious kid)
  
  
• How can you contribute ?
  { Procedure for sending submissions for the zine }

Learn

"any number is a limit, and perfection doesn't have limits.
Perfect speed, my son, is being there." .. Jonathan Livingston Seagull

Spotlight

Adrian Lamo .. not for tech, just for the philosophy, long after the news faded :).

Google .. for being the best teacher to many, better than many books out there.

Technology without Policy
By Charles Hornat

This is the first of a series I hope to grow into something that others can read, learn from, and share (or even laugh at).

After several years of working for several Wall St. firms and having the opportunity to work with some of the brightest
out there, I've come to realize one thing.. technicians love to throw technology at problems rather than develop a strategy and/or policy to resolve the issue.

For example, we will examine how a company offered a technical solution to a problem not yet identified. They had a DMZ that contained many high profile servers, and some technologists were gathered together to design the standards

All systems that would reside in the DMZ had to meet this rigid set of standards, or it would not be allowed. So they set off, defining routers and Access Control Lists, Firewalls, Network Based Intrusion Detection, and the likes. About a month into this process, a business unit of the company requested for a system to be placed in the DMZ that would be accessed and controlled by a third party. It was not an unusual request, but one that was discussed among those responsible for the standards in the DMZ. The first response emailed to everyone was: the system must have Host Based Intrusion Detection.

This comment was also defined in the standards and one that I would consider an industry best practice guideline. The problem was, there was no process or policy pertains to Host Based Intrusion Detection defined yet. Thus, we had a technologist throwing technology at a project to mitigate a risk not yet defined. Never mind the fact that there was no reporting structure for the IDS. Nor were there any guidelines for responding to alerts generated by the IDS. Additionally, there weren't even guidelines on what the IDS would monitor.

Technology is meant to support and help enforce policy. Before any security technology is ever deployed, and I mean ever,the responsible party should first stop and do the following:

• Identify the risks
  
  
• Achieve a balance between security and usability
  
  
• Offer mitigating steps to risks identified that balance in the organization

In this case, after risks are identified and understood, one could then create policies on setup, monitoring, maintenance, and etc.

On the other hand, it's not always just technicians throwing technology around. I remember a prime example that occurred several years ago,and to this day, I still reference it with my peers and staff. This time it was Human Resources offering technical solutions to a non-technical problem.

The Network Manager came by my office and requested directions on how to disable someones Internet access. It turned out that an employee was doing more browsing than work. Next, the management pinged HR who in turn called us. So some engineers and I sat down and created a solution using the internal hosts file and some other small changes. It then occurred to me that this was not clearly a technical issue.

Management, or more so, Human Resources needed to speak to this person who was abusing their privileges and warn them that it must stop. I raised my concerns but they were ignored. We implemented the solution. The next day, we got a call that the user went to another computer and surfed from that computer and that that system needed it's Internet access removed as well. Pretty soon, no one in the department had Internet access. To make a long story short, Human Resources recognized the problem and terminated the employee for abusing their Internet privileges and failure to comply with corporate policy.

These are just two out of a hundred examples I could give about the importance of determining when technology should be used to fix or address problems.

Thank you and good luck!

Generic attacks against a honeypot : Blind your enemy
By Arun Darlie Koshy

I proudly call myself a neophyte when it comes to the brave new world of "Honeypots/nets", the project has the best people working in it .. its got money, the backing of corporates and everybody who is anybody in the field wants to be associated with it (including this website :-)).

The concept itself is pretty old, its basically "know your enemy" Sun Tzu stuff (at least the old chinese philosopher is becoming more mainstream with movies and netsec intiatives being named after his main theory ;-)).

We now come to following lines from the book (Chapter 3, How a Honeynet works ?) :

"Adminstrators are challenged with reviewing hundreds of megabytes of system and firewall logs on a daily basis. Production traffic is continually changing and evolving, making it difficult to determine what is "normal" traffic. The Honeynet solves these and many other problems through simplicity"

"Any traffic is suspicious by nature" (i.e if directed towards our sweet network)

As an attacker who has to operate in these tough times, I would be most interested in the above lines .. this is the critical point that I would wish to develop my skills against. I feel we're seeing an analogue from the "lame" vx scene here .. the scanner is nascent.
Lets make the patterns confusing and tough.

Rules of engagement for "blackhats" :

1) Use your own networks for communication (i.e do not be stupid enough to IRC from an "unidentified" rooted box), use public systems with proper encryption thrown in.

2) plan and formulate your objectives down to the last detail and use your bag of exploits with caution and restraint.

Now we come to the most amazing statement in the book and our target becomes more defined :

"On an average, the Honeynet Project collects only about 1 MB - 10 MB of network information a day"

So when operating in an environment which you have not ascertained to be a production environment (even if its a hunt for zombies), you have to take steps to overload the sensors .. in short, DoS the studying mechanisms .. e.g.

(Hypothetical overrun of a logging sensor)

Let's assume that you wish to do :

rm -rf /var/log/
cp troj.tgz /home/x

instad of that :

ls *.*
junk command 1
junk command 2
..
(insert n number of useless entries .. feel free to go wild here)
rm -rf /var/log
(mutate)
cp troj.tgz ..

Next, we build our list of signatures against known tools that are used in the architecture, a few examples would be those of analyzing and studying Snort, VMware etc .. interesting, to detect if ur in a VMWare box, its pretty easy (just check for some registry entries .. it takes just some lines of code to detect if the process is running in a simulated VM box).

So efforts may be already underway to build a "Honeypot detector", of course a carefully laid pot may be no different from a production system, but we're are going to get all the Honeypot kiddies .. And as usual, we will see people in both camps having a lot of fun.

If there is something that is sickening. its over-enthusiasm and the buildup of a concept to far larger proportions than it actually is (past examples : The Windows Vs Linux thing, Linux being the most "secure" OS) .. I see the same attitude in people armed with Spitzner's book .. Honeypots are just another row of squares in the game folks.

Don't hype it up. We're dealing with code still .. Remember the scene from the movie Rocky, you have to have the hunger to keep winning .. the eye of the tiger .. who ever has that for the specific instance, wins.

Innovative mailbombs : A new approach
By Arun Darlie Koshy

It's widely recognized that e-mail based attacks are "lame" and usually a "script kiddie" approach. But what's also
acknowledged is the fact that an effective list-linking attack cannot be put off easily. It usually means that you either have to :

• manually unsubscribe
• forgo the mail account

It also can be used to DoS a server.

Today some techniques are used to prevent such attacks are in place. Newsgroups, Message boards, newsletters
features are usually equipped to add users only after confirmation etc.

Strangely a potentially huge hole exists. There are a multitude of free "forwarder" services on the web.

No, before u jump the gun and think we are going to talk abt the echo bomb approach (where you use to addresses which are set to each other to bomb the target).. we're not.

Here's the variation :

1) Open up the forwarder account at a server that you control

2) Subscribe to sufficient number of high volume newsgroups in the message digest mode.

3) Confirm using the forwarder address as reply-to

(NOTE : step 2 and 3 are time consuming if manual, u can devise techniques to automate)

4) Immediately detach the forwarder account from the receptor account which u used. You don't want to get bombed when all the groups start sending u info.

Your bandwidth cheap e-mail bomber is ready. All you have to do to drown someone is to set the new target as his/her
mail address. This attack can be as many levels deep as possible.

Defenses ?

All I can think of at the moment is to find out the forwarder account (usually mentioned somewhere in the SMTP log of the
forwarded message) and to filter it out. To clean out the bombed account, you can use a standard pop cleaner.

Awaiting the community's comments. More importantly, we should now concentrate in making e-mail systems more and more resistant to variations of these kind of attacks.

More dangerous forms of attacks of the SMTP genre exist .. including readymade servers/relays or writing your own engines to send mail (most organizations today do not know how to differentiate from spoofed e-mail and they still think PGP is for the "strange" people).

A parting scenario :

put your brains to work on the "Received: from" header .. think of the possibilities.

New beginnings

Have you had a playground on which you played during childhood, with some close friends .. a quiet spot, or places that you knew too well .. as you read this, are you expecting to read something that you've read before ?

Then it suddenly changed, buildings came up .. they put up labels and names on the place you knew .. that playground disappeared. Somethings similar has happened .. slowly all of this has become meaningless, organisation stifles freedom. Was it meant to happen ?

Some comments :

"The interesting thing about Palladium is that it just moves the location of the exploit. Let's assume, for the sake of this discussion, that Palladium is 100% secure - it really does provide a completely trusted path between the keyboard and the screen. All that happens is that the hacker moves the exploit to the special hardware. ... all you're doing is moving the point of exploitation about. Does it make it harder? Absolutely. Will it make it hard enough is not clear to me at this point" .. Dr.Richard Ford (from personal e-mail communcations)

" Unfortunately, there are still some aspects of the hacker community that disgust me. One is the rampant arrogance and elitism. Most hackers I have met are very friendly, but some have the attitude that they are somehow better than everyone else.. In the same vein, I am sick of the information leeches. They freely take from the hacker community, but then they hoard the information and refuse to share it with others. What rankles me the most are the miscreants who deface systems, engage in petty theft, or commit serious crimes and have the audacity to call themselves hackers.... Fyodor, Insecure

"Security is now sold in a red box with a support contract. And this is where things went downhill.. Don't lose sight of security. Security is a state of being, not a state of budget. He with the most firewalls still does not win. Put down that honeypot and keep up to date on your patches. Demand better security from vendors and hold them responsible. Use what you have, and make sure you know how to use it properly and effectively..And above all else, don't abuse or take for granted sources of help and information. Without them, you might find yourself lost or inconvenienced" .. RFP, Wiretrip

The future..

I say, lets put the "sub-culture" to rest.. we've fractured it .. now we look for playgrounds, the bars have been raised .. so you know "Hacking Exposed", nmap, firewalking .. and all the rest, welcome to the next level then.

Nothing has changed .. it is all about intent. Sloth and resting on past laurels are the perfect recipe for disaster. As the levels of complexity rises, the people involved will slowly become passive .. they will become subject to shock and the defenses they build will reflect that ..

You do not eliminate someone who wishes to break into a system by putting a thousand blocks in front of him .. given enough motivation and spirit, he will break it .. we have to eliminate the distress and inequalities in society to do that.

Till then, the plastic knives to get planes into buildings, exploit No.nth, service packs will continue. It is a fractal, repeating, without stop and no limits.. till we honestly try to eliminate dishonesty and exploiting the human spirit (be it in the form of divisions of border, corporations and sickening imbalance of wealth) .. nothing will stop. All harm is done when you do not allow someone to stand WITH you, and you make barriers.

For every one who used abused their privileges, there is a payback .. the countries who think they have solutions due to wealth will have to face the voids in their hearts as they count the number of anonymous souls they destroyed, the people living in large beautiful houses with everything going on for them would have to face the silent screams of those who do not .. you won the war with missiles and you belittled your brother.

With honeypots, you gave the group of people who had an upper hand a kick, now ur growing in arrogance .. forget the people who lay the building blocks .. how are u better than them ? You think that drawing up CERT, SANS and countless security procedures will put a stop ? Have you been arrogant to those who wish to learn ? How about pricing books explaining this .. how about restricting information .. how about talking rudely to someone on a newsgroup asking how to start learning ?

Also I take this opportunity to bash the PLAGIARISTS in this game, those people who are in it for the media glare..writing hacked up books, vomiting recycled information .. STOP, it makes me SICK.

I am just a kids' curiosity .. till date, when a sitiuation challenged me enough, i've circumvented it ... You cannot STUDY me with honeypots or psychoanalyzing me, the firewalls, IDSes .. billions of bits on wires and ether.

We can laugh, ignore or react in pity. Cain and Abel .. everything starts again.

(Taken from http://www.knowyourenemy.com )

Topics (but definitely not restricted to):
algorithms, stuff related to systems programming and applied network security.

Style:
The zine advocates a "hands-on" approach when it comes to tech.. Get to the code or point. Provide references and links if necessary (especially if you're presenting a fresh perspective on something already known).

All images, content & text (unless other ownership applies) are © copyrighted 2003, Infosecwriters.com. All rights reserved. Comments are property of the respective posters.