isecom-discuss — Discussion and work requests for all projects

[ISECOM-discuss] Abbreviations in the port list

[Fran C. <bl...@te...>]

It would be more helpful if the abbreviations in the port list could be 
expanded to words.  If I see only a collection of letters when I look up a 
port reference, I still do not know what the function of the port is. 

Re: [ISECOM-discuss] A Few Items

[<ro...@is...>]

Thomas Jones(ad...@bu...)@Sat, Oct 08, 2005 at 11:32:23AM
> First I have one question: Does the manual come in any other format? I
> would like to see it produced in OO format if all possible. If not, I
> may convert it as needed and forward it to isecom.

We have considered OO in the past, but my personal preference is LaTeX. 
LaTeX can be edited by notepad, vi, etc.  Currently there are plans to
implement a Wiki type interface so people can more easily contribute to
the OSSTMM project.

> On a sidenote, I did notice some errors in the manual while making a
> first pass attempt on review of non-printing characters. Who may I
> forward my diffs to?

Pe...@is... is the best address for now.  He's currently merging
changes.

> Second, has there been any consideration to directives and best
> practices of the storage of data derived from the osstmm testing?

There are suggestions that we give out during the OPST/OPSA classes.  If
you have specific questions or suggestions feel free to continue the
discussion here.

> There has been impressive consideration and development of the ethical
> and engagement boundary of the osstmm. However, I think that post-test
> processes should be exponentially more critical.

What did you have in mind?

Robert

-- 
Robert E. Lee
Director of Projects & Resources,
The Institute for Security and Open Methodologies
W - http://www.isecom.org
E - ro...@is...
M - (949) 394-2033

[ISECOM-discuss] A Few Items

[Thomas J. <ad...@bu...>]

Hello all,

I am new to the OSSTMM, but am very pleased to see the quality of this 
product.

First I have one question:
Does the manual come in any other format? I would like to see it 
produced in OO format if all possible. If not, I may convert it as 
needed and forward it to isecom.

On a sidenote, I did notice some errors in the manual while making a 
first pass attempt on review of non-printing characters. Who may I 
forward my diffs to?

Second, has there been any consideration to directives and best 
practices of the storage of data derived from the osstmm testing? I 
think it should be of the utmost importance to securely store and house 
the data/results of the client with regards to the processes and/or 
procedures utilized through implementation of the osstmm methodology.

There has been impressive consideration and development of the ethical 
and engagement boundary of the osstmm. However, I think that post-test 
processes should be exponentially more critical.

Thanks for your time.
Thomas Jones

[ISECOM-discuss] Reactive risk driven security using transactional context-sensitive full digraph authorization.

[<rm...@xs...>]

I've been working on a small whitepaper focusing on the fundamentals of the
TRACS authorization system design. As I had some trouble comunicating my
full design, I've take the time to try and focus on the fundamentals first
in this whitepaper, as the complete design apeared to be somewhat
confusing and intimidating. If anyone of you guys would be able to give me
some feedback
on this short whitepaper, that would be very welcome.

http://osdn.dl.sourceforge.net/sourceforge/tracs/trans.pdf

Pete, maybe you can put this document on the sipes page, as TRACS is a
SIPES spinn-off, and this paper describes the fundamentals that TRACS
will build on.

[ISECOM-discuss] Would you use the folowing in your pentests: H323 libACE ethereal

[<rm...@xs...>]

I am curently working on a CF image based linux distribution for
(inline) pentesting purposes. While working truegh my wishlist of
libraries and tools to add to this image, I ran into the fact that
some of the libraries end/or tools being either by themselves or by their
implied dependancies rather big.
I now end up with 3 of those things that I must considder if I should
add or drop them. They could fit on the image, but maybe the users
(that could be you guys) would find them a waste of space.
I would like to hear your ideas of wether to add or drop these
items:

OpenH323 etc: Library and tools for H323 based VoIP
              I have no high knowledge on VoIP, and am not sure if anyone
              is actualy including H323 stuff in their pentests.
              Its altogether kind of big, so if noone else also ever uses
              H323, this may be a waste of space.
Ethereal etc: Ethereal is a simple but modular network protocol monitoring
              tool, together with all the development possibilities it
              takes up a real big amounth of space. I personaly would use
              a range of perl modules included in the LIPAX distro also,
              but I know some people think the world of ethereal.
              I would personaly like to drop it unless any of you guys
              can convince me I shouldn't.
libACE:       LibACE is an extremely powerfull C++ library for writing
              networking software, it is kind of big, but when you like
              me like to use C++ to write your own non trivial network
              testing tools for specialized purposes, it would be worth
              this space. I am hoping I am not the only one who likes
              using C++/ACE in such context, If I am I could considder
              droping it if  both OpenH323 and Ethereal are considdered
              essential by you guys.


So my proposal would be:

* Keep libACE
* drop Ethereal
* No clue with respect to H323

Please let me know what you guys think of it.

Rob

Re: [ISECOM-discuss] channels

[Pete H. <pe...@is...>]

> VoIP falls where?

It is a combination of channels.  Channels are points to test but it's
not uncommon that technologies will continue to cross the boundaries.
If I have to test an office that has PDAs that use wireless LANs to
transmit calls via VOIP, I would need to test mostly all 5 channels at
least in part.

 > Just call it Human Interaction .. or People .. or something like that?

like HUMSEC?

> 
> I like mimicing the SIG INT type names.  If we want more open adoption, we should use terms that are used at places that take security seriously.
> 

True.  ut it gets complicated sticking with military specs.  For example:

1.Personnel Security (humsec)
2.Physical Security (physsec, opsec)
3.Telecommunications Security (comsec)
4.Wireless Communications Security (sigsec, elsec)
5.Data Networks Security (comsec)

So how does the military differentiate data network security from
telecommunications?

> I like the terms from the rainbow series and the common criteria.  Common Criteria is a world wide standard, not just a US thing.
> 

I searched through looking for channel names but came up light.
Suggestions on definitions misused in 2.1 that could be changed?

-pete.

Re: [ISECOM-discuss] channels

[Pete H. <pe...@is...>]

> 
> Isn't Wireless considered a subset of Telecommunications, or is their a
> wide area v. local area distinction that isn't fully explained here ?
> 

Actually, channels mix.  Wireless in the OSSTMM is not wireless networks
only.  It's much bigger.  In military terms, it is a combination of
SIGSEC and ELSEC.  Actually, we may adopt dual designations for channels
for military and civilian use.

-pete.

-- 
Pete Herzog - Managing Director - pe...@is...
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.isestorm.org
-------------------------------------------------------------------
ISECOM is the OSSTMM Professional Security Tester (OPST),
OSSTMM Professional Security Analyst (OPSA), and Hacker Highschool
Teacher certification authority.

Re: [ISECOM-discuss] channels

[<ro...@dy...>]

Pete Herzog(pe...@is...)@Sat, Jul 09, 2005 at 07:32:03PM +0200:
> Telecommunications
> Comprises of the telecommunication networks, digital or analog, where
> interaction takes place over established telecommunication network lines
> without human assistance.

VoIP falls where?

> For example, Personnel, is a channel and Social Engineering (aka
> psychological) is a type of test within that channel.  But what if the
> test is not on an organization (personnel) and instead on a nation
> (citizens).

Just call it Human Interaction .. or People .. or something like that?

I like mimicing the SIG INT type names.  If we want more open adoption, we should use terms that are used at places that take security seriously.

I like the terms from the rainbow series and the common criteria.  Common Criteria is a world wide standard, not just a US thing.

Robert

-- 
Robert E. Lee
CEO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - ro...@dy...
M - (949) 394-2033

Re: [ISECOM-discuss] channels

[Barrie D. <ba...@re...>]

On Sat, 2005-07-09 at 19:32 +0200, Pete Herzog wrote:
> Okay, so I'm working on geting 3.0 underways but I've been stumped by a
> nomenclature.
>=20
> 3.0 is divided now into 5 channels:
>=20
> Personnel

Human Resource (or People or "Human Element", personally prefer Human
Resource)


>=20
> Telecommunications
> Comprises of the telecommunication networks, digital or analog, where
> interaction takes place over established telecommunication network lines
> without human assistance.
>=20
> Wireless Communications

Isn't Wireless considered a subset of Telecommunications, or is their a
wide area v. local area distinction that isn't fully explained here ?


--=20
With Regards..
Barrie Dempster (zeedo) - Fortiter et Strenue

blog: http://reboot-robot.net
site: http://www.bsrf.org.uk
ca:   https://www.cacert.org/index.php?id=3D3

"He who hingeth aboot, geteth hee-haw" Victor - Still Game

[ISECOM-discuss] channels

[Pete H. <pe...@is...>]

Okay, so I'm working on geting 3.0 underways but I've been stumped by a
nomenclature.

3.0 is divided now into 5 channels:

Personnel
Comprises of the human element of interaction where people are the
gatekeepers of information and physical property.

Physical
Comprises of the non-human tangible element of security where
interaction requires physical effort to manipulate.

Telecommunications
Comprises of the telecommunication networks, digital or analog, where
interaction takes place over established telecommunication network lines
without human assistance.

Wireless Communications
Comprises of all non-human interaction which takes place over the known
communication spectrum, from the very lowest frequencies to the highest.

Data Networks
Comprises of all data networks where interaction takes place over
established data network lines without human assistance.

But the names of these channels may not be proper.

For example, Personnel, is a channel and Social Engineering (aka
psychological) is a type of test within that channel.  But what if the
test is not on an organization (personnel) and instead on a nation
(citizens).

The original name for this channel in OSSTMM 1.0 was Social Engineering.
 That was dropped because it's a test method and not a channel.  It was
called Process in 2.0.  But that's wrong since not all processes are
about people.  The channel is really
Psychological/Sociological/Economical/Cultural which you could consider
to be more like a band than a channel.  So what to call it?  Should we
keep Personnel although it may not be fitting but is in 99% of the
OSSTMM use cases?  Or should we call it People (blah!)?  Ideas?

And about the other channels, should we consider military designations
like Sig Int, etc.?  Is any of it organized properly even?  Comments?

Sincerely,
-pete.

-- 
Pete Herzog - Managing Director - pe...@is...
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.isestorm.org
-------------------------------------------------------------------
ISECOM is the OSSTMM Professional Security Tester (OPST),
OSSTMM Professional Security Analyst (OPSA), and Hacker Highschool
Teacher certification authority.

[ISECOM-discuss] LIPAX 'inline' pentest linux distro, input needed.

[Rob J M. <rm...@xs...>]

I've been looking a bit more at what would be needed for creating a
'in-line' pentest distro aimed at small network appliances.
I've put together a webpage on the subject, and a list of software
packages that will need to be included in the system.

The current setup is build around 4 concepts.

1) The yet to implement man in the midle framework, combining different
   MITM techniques behind a generic API. The basic design of LIPAX will
   be thus that at startup, all trafic from all interfaces will always
   traverse the MITM framework. The user can build software that uses
   the MITM framework API.
2) The MITM framework will communicate with basic servers, on localhost
   allowing specific services to be diverted to these servers, while all
   other trafic is bridged transparently, or is made subject to configured
   MITM services.
3) A user can choose to take the system out of MITM mode, and configure
   the system using information gathered during MITM mode.
   After doing this, the user could run basic network analysis tools.
   The tools available ar chosen thus, that as litle as possible
   functionality is doubled, no 'hurt them BAD' kind of tools are
   included, and the distribution does not become just a bunch of
   freshmeat search results packed together into a 'big set of tools'.
4) The system should provide a complete development enviroment, as
   standard tools will scarsely be sufficient to complete a security
   audit, the system comes with a full development kit and networking
   libraries for C,C++,perl. The basic philosophy behind lipax is
   that we provide a limited set of tools for the basic stuff, and
   an extended set of libraries, frameworks and perl modules that
   could combine to tailor the distribution to provide exactly that
   functionality that you require.

I've put a page on LIPAX at:

   http://www.xs4all.nl/~rmeijer/inline.html

The list of software I would like to put on it is at:

   http://www.xs4all.nl/~rmeijer/pkg.txt

Just to make things clear, the MITM framework DOES NOT YET EXCIST,
and I will not get started on it before I have the tracs project TRACS up
and running.

I am just looking for input with respect to the required software.
The target for this linux distribution will be the pcengines wrap systems
at first, followed by soekris and mycable appliances, and the
target media will be (the fast version of) the 1024MB CF cards, keeping
aprox 300 or 400 MB free for user data and tools. I'll be using XFS
filesystems to compensate both for both the limited speed of CF storage,
and the fact that the running system will get unplugged all the time.

Please let me know what you think of where I am heading with this,
I know that for myself, this concept would make for the ultimate
inline pentesting tool that meets all 'my' needs, but a wider audience
than just me, myself and I would be the main goal of making it into
a distribution. I am esspecialy interested in what you all think about the
4 concept that I would like to build this distribution on, and the
current content of pkg.txt describing what software should be included in
the distribution,

[ISECOM-discuss] ISM3 awareness day

[<vi...@is...>]

Dear All,

I am preparing a long session on ISM3 in Madrid for the beginning of June.
As the model is very rich conceptually it seems necessary to carry out a
detailed exposition of the model for those interested.

I need latest news on ISM3 awareness, real life implementations, people
who found it useful for solving real problems, etc.

Please contact my at vi...@is... so I can give an accurate picture
of current ISM3 use.

My best

Vicente Aceituno

[ISECOM-discuss] Cost OSSTMM data security manual tasks

[Ron I. <rik...@hf...>]

All,

We just completed HIPAA compliance using CMS & OSSTMM standards, but
yet we have not factored in any cost of running all these tests.  Does
anyone know of any standard we can use to come up with a cost standard
equation (outside from just calculating FTEs hourly salary, of course)?

I would appreciate any feedback at this point.

Thanks,


Ron Ikonomou 
Siemens Security Analyst
Work 248-853-4961
Cell 248-977-0037

==============================================================================
HFHS CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed.  If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by replying in an email to the sender, delete the email from your computer system and shred any paper copies of the email you printed.

Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. These risks are described in our Privacy Policy at http://henryford.com.  Review that policy carefully before continuing to communicate with us by e-mail. For greater Internet security, our policy describes the Henry Ford MyHealth electronic communication process - you may register at http://henryford.com.  If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.


==============================================================================

Re: [ISECOM-discuss] 'in-line' pentest and pentest linux distro?

[Pete H. <pe...@is...>]

Rob,

> are there any specs on its content available, and do you think it matches
> the filosophy behind what I tried to summarize at the web page I pointed
> to?
>>>  http://www.xs4all.nl/~rmeijer/inline.html

Our goal is to have it as a handy tool to complete HHS and OPST
training.  It may be too big for your needs (350Mb I think). It also
does not have the scripts/languages you're looking for-- although it's a
great idea.  Maybe on the DVD version?

> 
> Who is/are currently responsible for the project, I would very much
> like to see if and how much of this I could use, and if the LIPAX
> CF images could maybe if suitable become a sub project of these effords.

Talk to Nick of Dreamlab, the ISECOM Affiliate for France, Switzerland,
and Germany. ni...@is...

-pete.

Re: [ISECOM-discuss] 'in-line' pentest and pentest linux distro?

[Rob J M. <rm...@xs...>]

On Mon, 18 Apr 2005, Pete Herzog wrote:

> ISECOM is maintaining a security test distro based on gentoo for the
> Hacker Highschool project as well as the OPST.  I have the demo already.
>   It's in final stages before release now.
>
> -pete.

Great,

are there any specs on its content available, and do you think it matches
the filosophy behind what I tried to summarize at the web page I pointed
to?

> >
> >   http://www.xs4all.nl/~rmeijer/inline.html
> >

Who is/are currently responsible for the project, I would very much
like to see if and how much of this I could use, and if the LIPAX
CF images could maybe if suitable become a sub project of these effords.

T.I.A.

Rob

Re: [ISECOM-discuss] 'in-line' pentest and pentest linux distro?

[Pete H. <pe...@is...>]

ISECOM is maintaining a security test distro based on gentoo for the 
Hacker Highschool project as well as the OPST.  I have the demo already. 
  It's in final stages before release now.

-pete.

Rob J Meijer wrote:
> 
> On Tue, 12 Apr 2005 ro...@dy... wrote:
> 
> 
>>>3) Is anyone seriously working on a pentest linux distro?
>>
>>There are lots of "pen-test" linux distros that come to mind.  They seem
>>to all be collections of tools that are good for demo's and handouts,
>>but not really specific enough for any of our real life scenarios.  We
>>started to make our own based on the bootable slackware image (SLAX), but we
>>rarely find ourselves requiring a boot CD of this kind.  We opt to have
>>specialized hardware/software for the task at hand.
> 
> 
> I've been looking at some of the distro's people sugested, they all are
> mostly a 'just throw any tool on you can find' kind of distro's, no
> synergy what so ever, and not realy meant for adding anything custom
> functionality. I think I use them just for giving me some pointers to
> usefull tools,and than expand on that, but also trying to focus greatly on
> making it more a 'just add your own scripts and code' type of device,
> trying to focus more on libraries, scripting modules and frameworks than on
> the actual ready to use tools.
> 
> 
>>>4) Do you think building and combining this functionality ino a
>>>   specialized small linux distribution for something like the
>>>   sigarete-box sized XXS1500, or something like it would be desirable
>>>   for such functionality.
>>
>>Sure, especially for onsite tests.  We function more often as a blue
>>team (lot's of customer involvement) than as a red team (attacker
>>simulation).  For us the traditional "maximum damage" or as I like to
>>call it "Just kick em in the nuts" style of causing damage where ever
>>possible doesn't apply very often.
> 
> 
> My idea exactly, I have no use for 'nasty' stuff on the appliance,
> 
> 
>>It is assumed that the MAC filtering
>>is of minimal security benefit for keeping undesireable people off the
>>network.  That might keep a student studying ballet in college out, but
>>that's about it.
>>
>>
>>>As you might know I am currently spending most of my spare time on the
>>>TRACS project, so litle time remains this year for any other projects,
>>>so I am hoping someone else has or will do some work on both the
>>>testing of MAC locked or MAC ID enabled enviroments and the creation
>>>of a pentest linux distro.
>>
>>What is the TRACS project?
> 
> 
> Tracs is a sub project of the isecom SIPES project, it will be an
> authorization system designed to work in the context of a security
> incident policy enforcement system. It is at this moment my main
> sparetimesink, leaving me with litle time to work on other projects at
> this moment.
> 
> 
>>I have thought about making some special hardware in the past.  That's
>>more fun/impressive than the OS customizations needed, which may be
>>minimal.  We have done phone bugs in the past.  Combining the phone bug
>>mentality with an inline device that only sometimes sends malicious payloads
>>but always has the ability to monitor and MITM traffic sounds very fun,
>>especially if you can get the form factor down to a small size.
>>
>>I can just imagine the look on the poor network engineers face as he opens
>>his network closet 3 years later.
> 
> 
> I am now puting together some specs on what the distribution should look
> like, I'll be building it in the first place for my own use, but will put
> the images online, ones TRACS is done I will put some more time in making
> sure it is also usable for users who dont do as much custom scripting
> as I do, and will put some time in adding more support for hardware.
> I'm starting off with a cheap pcengines board based device, later on I
> will see if I can get myself a soekris and a mycable device, the later has
> the most appealing form factor and specs.
> 
> I've put what I now think I am going to put on the image at:
> 
>   http://www.xs4all.nl/~rmeijer/inline.html
> 
> As stated, unfortunately I wont be able to put the time resources in this
> project to turn it quickly into something finished, I'll be gathering more
> specs on what tools and lings and modules should be on it, so if you have
> any idea's on that, these would be very welcome, both open source and
> (cheap) commercial tools.
> 
> 
> Tnx,
> 
> Rob
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> ISECOM-discuss mailing list
> ISE...@li...
> https://lists.sourceforge.net/lists/listinfo/isecom-discuss
> 
> 

Re: [ISECOM-discuss] 'in-line' pentest and pentest linux distro?

[Rob J M. <rm...@xs...>]

On Tue, 12 Apr 2005 ro...@dy... wrote:

> > 3) Is anyone seriously working on a pentest linux distro?
>
> There are lots of "pen-test" linux distros that come to mind.  They seem
> to all be collections of tools that are good for demo's and handouts,
> but not really specific enough for any of our real life scenarios.  We
> started to make our own based on the bootable slackware image (SLAX), but we
> rarely find ourselves requiring a boot CD of this kind.  We opt to have
> specialized hardware/software for the task at hand.

I've been looking at some of the distro's people sugested, they all are
mostly a 'just throw any tool on you can find' kind of distro's, no
synergy what so ever, and not realy meant for adding anything custom
functionality. I think I use them just for giving me some pointers to
usefull tools,and than expand on that, but also trying to focus greatly on
making it more a 'just add your own scripts and code' type of device,
trying to focus more on libraries, scripting modules and frameworks than on
the actual ready to use tools.

> > 4) Do you think building and combining this functionality ino a
> >    specialized small linux distribution for something like the
> >    sigarete-box sized XXS1500, or something like it would be desirable
> >    for such functionality.
>
> Sure, especially for onsite tests.  We function more often as a blue
> team (lot's of customer involvement) than as a red team (attacker
> simulation).  For us the traditional "maximum damage" or as I like to
> call it "Just kick em in the nuts" style of causing damage where ever
> possible doesn't apply very often.

My idea exactly, I have no use for 'nasty' stuff on the appliance,

> It is assumed that the MAC filtering
> is of minimal security benefit for keeping undesireable people off the
> network.  That might keep a student studying ballet in college out, but
> that's about it.
>
> > As you might know I am currently spending most of my spare time on the
> > TRACS project, so litle time remains this year for any other projects,
> > so I am hoping someone else has or will do some work on both the
> > testing of MAC locked or MAC ID enabled enviroments and the creation
> > of a pentest linux distro.
>
> What is the TRACS project?

Tracs is a sub project of the isecom SIPES project, it will be an
authorization system designed to work in the context of a security
incident policy enforcement system. It is at this moment my main
sparetimesink, leaving me with litle time to work on other projects at
this moment.

> I have thought about making some special hardware in the past.  That's
> more fun/impressive than the OS customizations needed, which may be
> minimal.  We have done phone bugs in the past.  Combining the phone bug
> mentality with an inline device that only sometimes sends malicious payloads
> but always has the ability to monitor and MITM traffic sounds very fun,
> especially if you can get the form factor down to a small size.
>
> I can just imagine the look on the poor network engineers face as he opens
> his network closet 3 years later.

I am now puting together some specs on what the distribution should look
like, I'll be building it in the first place for my own use, but will put
the images online, ones TRACS is done I will put some more time in making
sure it is also usable for users who dont do as much custom scripting
as I do, and will put some time in adding more support for hardware.
I'm starting off with a cheap pcengines board based device, later on I
will see if I can get myself a soekris and a mycable device, the later has
the most appealing form factor and specs.

I've put what I now think I am going to put on the image at:

  http://www.xs4all.nl/~rmeijer/inline.html

As stated, unfortunately I wont be able to put the time resources in this
project to turn it quickly into something finished, I'll be gathering more
specs on what tools and lings and modules should be on it, so if you have
any idea's on that, these would be very welcome, both open source and
(cheap) commercial tools.


Tnx,

Rob

Re: [ISECOM-discuss] 'in-line' pentest and pentest linux distro?

[<ro...@dy...>]

Rob Meijer(rm...@xs...)@Tue, Apr 12, 2005 at 11:13:40AM +0200:
> 1) Is nobody running into MAC lock and MAC ID enviroments where the
>    workstation network connections are relevant?

Sure, we see those.

> 2) If anyone is, what are you using to do these tests, and would this
>    be suitable for 'in-line' usage?

Depends on the objective.  I see where you are going with this... unplug
a working device, plug it into your inline device, observe traffic.

Once you've onserved sufficient traffic to see what acceptable network
traffic looks like, including valid MAC addresses to use, start
communicating from your own device.

> 3) Is anyone seriously working on a pentest linux distro?

There are lots of "pen-test" linux distros that come to mind.  They seem
to all be collections of tools that are good for demo's and handouts,
but not really specific enough for any of our real life scenarios.  We
started to make our own based on the bootable slackware image (SLAX), but we
rarely find ourselves requiring a boot CD of this kind.  We opt to have
specialized hardware/software for the task at hand.

> 4) Do you think building and combining this functionality ino a
>    specialized small linux distribution for something like the
>    sigarete-box sized XXS1500, or something like it would be desirable
>    for such functionality.

Sure, especially for onsite tests.  We function more often as a blue
team (lot's of customer involvement) than as a red team (attacker
simulation).  For us the traditional "maximum damage" or as I like to
call it "Just kick em in the nuts" style of causing damage where ever
possible doesn't apply very often.  It is assumed that the MAC filtering
is of minimal security benefit for keeping undesireable people off the
network.  That might keep a student studying ballet in college out, but
that's about it.

> As you might know I am currently spending most of my spare time on the
> TRACS project, so litle time remains this year for any other projects,
> so I am hoping someone else has or will do some work on both the
> testing of MAC locked or MAC ID enabled enviroments and the creation
> of a pentest linux distro.

What is the TRACS project?

You can grab a MAC by plugging an existing machine into your laptop over
a cross over cable and observing the MAC used.  Alternatively, some
servers have the MAC printed on them.  Also I keep a cross-over adapter
in my bag... just a little plastic device that has a RJ45female on one
side and RJ45male on the other side with the proper cross over change in
the middle.

After you have the MAC address you can simply:
ifconfig eth0 hw ether <MAC address you want to use>
<config the IP and Networking info as observed>

Then plug yourself into the switch jack the other server was pluged into
and you're in.

I have done this with a stock laptop + slackware in the past.

> I think I could fit in some porting to small devices from a basic PC
> Linux based distribution to such a device, if however I completely
> would have to role a new distribution from scratch, building lots of
> the tools myself, I would not be able to fit this in this year (unless
> someone needs it enough to actualy pay me for working on it, while
> keeping it open source).

For the form factor you mentioned, you'll want to invest in some sort of
RF/Cell/internet communication.  This will allow you to receive transmissions
external to where ever you place this inline bug.... which can be important if
disk space is a premium.  It will also allow for active control of the
device that is placed in a sensitive area (like a server room or network
closet).

> I think building a pentest inline device linux distro would be practical
> and usefull, but maybe its just my gadget madnes playing tricks on me ;-)
> Let me know what you think.

I have thought about making some special hardware in the past.  That's
more fun/impressive than the OS customizations needed, which may be
minimal.  We have done phone bugs in the past.  Combining the phone bug
mentality with an inline device that only sometimes sends malicious payloads
but always has the ability to monitor and MITM traffic sounds very fun,
especially if you can get the form factor down to a small size.

I can just imagine the look on the poor network engineers face as he opens
his network closet 3 years later.

Robert

-- 
Robert E. Lee
CEO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - ro...@dy...
M - (949) 394-2033

[ISECOM-discuss] 'in-line' pentest and pentest linux distro?

[Rob M. <rm...@xs...>]

It apears that I'm either the only one ever to have had the need for
inline pentests, in order to test at workstation network connections that
have MAC locking and ID in place, or that I just am using the wrong name
for the concept. I'm interesting to know:

1) Is nobody running into MAC lock and MAC ID enviroments where the
   workstation network connections are relevant?
2) If anyone is, what are you using to do these tests, and would this
   be suitable for 'in-line' usage?
3) Is anyone seriously working on a pentest linux distro?
4) Do you think building and combining this functionality ino a
   specialized small linux distribution for something like the sigarete-box
   sized XXS1500, or something like it would be desirable for such functionality.

As you might know I am currently spending most of my spare time on the
TRACS project, so litle time remains this year for any other projects,
so I am hoping someone else has or will do some work on both the testing
of MAC locked or MAC ID enabled enviroments and the creation of a pentest
linux distro.
I think I could fit in some porting to small devices from a basic PC Linux
based distribution to such a device, if however I completely would have to
role a new distribution from scratch, building lots of the tools myself,
I would not be able to fit this in this year (unless someone needs it
enough to actualy pay me for working on it, while keeping it open source).

I think building a pentest inline device linux distro would be practical
and usefull, but maybe its just my gadget madnes playing tricks on me ;-)
Let me know what you think.


Rob


On Thu, 7 Apr 2005, Rob J Meijer wrote:

>
>
> On Wed, 6 Apr 2005 ro...@dy... wrote:
>
> > Rob J Meijer(rm...@xs...)@Wed, Apr 06, 2005 at 08:33:37AM +0200:
> > > I need to set up a dual network card system as inline pentest system
> > > (between a workstation and the network). I havn't bothered before with
> > > the boot effects of pre-mac-spoofing stage, and havn't before used
> > > 'standard' tools inline, only custom spoofing tools.
> >
> > I'm not really sure what you're asking.  I read the post twice, and it
> > seems like you want the Linux inline box to behave like a bridge device,
> > have access to all data sent/received, and the opportunity to rewrite
> > packets on the fly as needed?
>
> No, not rewrite packets, it needs to 'boot' and act first like a bridge,
> learning gathering some basic information, and learning what is essential
> about MAC and IP adresses to use, and than at some point reconfigure into:
>
> 1) Masquerading as the workstation (MAC/IP) on the network side:
>
> If the in-between device is a laptop, than from that point the laptop
> could be used to do penetration tests with the identity of the
> workstation. If, what I would like to do, the device would be a
> litle XXS1500 box, than on the workstation side, the device could also:
>
> 2) Masquerading as either:
>    a) Router (MAC+IP) AND webserver, or
>    b) A local webserver.
>
> If the device has a webinterface that can provide some pentest
> functionality truegh a web interface, and/or a java applet based shell to
> the device, than the sigaret box sized device could provide the same
> functionality as the two network card laptop.
>
> > > Can anyone point me to some more information on hardware to use, and
> > > actions to take in order to make a linux system :
> > > * be able to boot inline, and to network-wise keep silent.
> > > * during boot completely assume the MAC adress (on the network side)
> > >   of the workstation.
> >
> > Those 1st two items conflict?  You can't assume the MAC address and be
> > silent at the same time.  Please explain what you mean.
>
> The point is that the whole point of using an in-between device and not
> just a simple laptop, is that on a lot of seriously setup networks, a
> single ethernet packet on a switch port that is not the known MAC adress
> will lead to at least the triggering of an alert, and in many cases to
> the switch port being disabled. If during system boot, the device outputs
> packets with its hardware MAC adress, this will lead to an unwanted
> situation. The device needs to do nothing with its own MAC adress, and
> after having determined a suitable MAC adress to masquerade as, start
> to use this adress.
>
> > > * On the workstation side run a shell application using browser applets.
> >
> > Again, I need more input.  Not sure what you mean by this.
>
> The workstations often have a very limited amounth of available
> applications, but a web browser with java functionality seems to
> always be pressent. This means that the user might not be always
> able to start a telnet or ssh connection to the device. For this reason,
> looking at using a java aplet to log in to the device with some form
> of shell, and thus being able to use the pentest tools on the device
> would seem a good way to overcome the limitations of standard
> workstations. This won't always work I guesse, but you could
> always have some tools using a simple web interface, be it more
> limmited than with shell access to the device.
>
> > > The point of this last one is that if all works well with standard
> > > PC hardware, and the standard set of tools works ok, I would like
> > > to look at those nifty litle XXS1500 boxes from mycable.de to look
> > > if we can create simple pocket-size inline device for the inline type
> > > of pentests.
> >
> > When you say inline pentest, are you just talking about all of the
> > different MITM possibilities, or do you mean something else?
>
> No, I don't mean 'inline' as in MITM atacks, I purely mean it as inline
> between unpriviledge user workstation and the network that this
> workstation has access to. Auditing the trafic specs of the workstation,
> and using this as input for (using spoofing of MAC+IP) all kinds of
> pentests that either require the workstations authorization combined
> with tools on the device, and thus need a MITM way of working, or can
> be directed from the device at either the worksation, the network,
> or auditing servers outside of the network in order to audit
> conectabillity.
>
> As stated before, I have very limited experience with such in-line
> pentests, as pentests are not my main line of business, and in the past
> I did not run into many enviroments where the switches were configured
> to use MAC/port based intrusion detection and port lockout. (It is
> actualy on my advice from previous audits that these filters are now
> in place, and I now need to re-audit).
>
> Rob
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>
> ISECOM-discuss mailing list
> ISE...@li...
> https://lists.sourceforge.net/lists/listinfo/isecom-discuss
>

[ISECOM-discuss] Re: [ISECOM-subscribers] Hacker's High School on the BBC Site

[<ro...@dy...>]

Phil Robinson(ph...@ir...)@Mon, Apr 11, 2005 at 01:39:53PM +0100:
> I'm interested in the experiences of other ISECOM partners doing this? What 
> has been the reaction? Clearly the name would appear controversial to 
> anybody who isn't aware of the original meaning of the word "hacker" - at 
> least it gets people talking.

That's the point of the name :).  It's there to help motivate the kids to come.

If you read through the content, most of it is in the mode to help wake up the
student to the predators on the internet.  It reads mostly as a self defense
class that helps wake them up to what's happening online.

I think the name is great in this case from a marketing perspective.

Robert

-- 
Robert E. Lee
CEO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - ro...@dy...
M - (949) 394-2033

[ISECOM-discuss] Hacker's High School on the BBC Site

[Phil R. <ph...@ir...>]

Hi,

Interesting article on Hacker's High School on the BBC here: -

http://news.bbc.co.uk/2/hi/programmes/click_online/4423351.stm

I'm interested in the experiences of other ISECOM partners doing this? What 
has been the reaction? Clearly the name would appear controversial to 
anybody who isn't aware of the original meaning of the word "hacker" - at 
least it gets people talking.

Regards,

Phil

-- 
Phil Robinson

Chief Technology Officer

IRM PLC

Tel:     +44 (0)20 7808 6420
Fax:     +44 (0)20 7808 6421

Information Risk Management Plc
8th floor, Kings Building
Smith Square
London
SW1P 3JJ

www.irmplc.com


The information contained in this email is privileged and confidential and
is intended only for the use of the addressee.  Unauthorised disclosure,
copying or distribution of the contents is strictly prohibited. Please reply
immediately if you receive this email in error and then immediately delete
it from your system.

Where relevant, any quotation contained within this email is exclusive of
VAT at the current rate and valid for 30 days from the date of this email.
Information Risk Management Plc (IRM) does not authorise the creation of
contracts on its behalf by email.  All information contained within this
email and its attachments are subject to IRM's standard terms and
conditions, a copy of which is available upon request.

All attachments have been scanned for viruses using regularly updated
programs. IRM cannot accept liability for any damage you incur as a result
of virus infection and we advise that you should carry out such virus and
other checks as you consider appropriate.

Re: [ISECOM-discuss] 'in-line' pentest, and booting Linux 'in-line' ?

[Rob J M. <rm...@xs...>]

On Wed, 6 Apr 2005 ro...@dy... wrote:

> Rob J Meijer(rm...@xs...)@Wed, Apr 06, 2005 at 08:33:37AM +0200:
> > I need to set up a dual network card system as inline pentest system
> > (between a workstation and the network). I havn't bothered before with
> > the boot effects of pre-mac-spoofing stage, and havn't before used
> > 'standard' tools inline, only custom spoofing tools.
>
> I'm not really sure what you're asking.  I read the post twice, and it
> seems like you want the Linux inline box to behave like a bridge device,
> have access to all data sent/received, and the opportunity to rewrite
> packets on the fly as needed?

No, not rewrite packets, it needs to 'boot' and act first like a bridge,
learning gathering some basic information, and learning what is essential
about MAC and IP adresses to use, and than at some point reconfigure into:

1) Masquerading as the workstation (MAC/IP) on the network side:

If the in-between device is a laptop, than from that point the laptop
could be used to do penetration tests with the identity of the
workstation. If, what I would like to do, the device would be a
litle XXS1500 box, than on the workstation side, the device could also:

2) Masquerading as either:
   a) Router (MAC+IP) AND webserver, or
   b) A local webserver.

If the device has a webinterface that can provide some pentest
functionality truegh a web interface, and/or a java applet based shell to
the device, than the sigaret box sized device could provide the same
functionality as the two network card laptop.

> > Can anyone point me to some more information on hardware to use, and
> > actions to take in order to make a linux system :
> > * be able to boot inline, and to network-wise keep silent.
> > * during boot completely assume the MAC adress (on the network side)
> >   of the workstation.
>
> Those 1st two items conflict?  You can't assume the MAC address and be
> silent at the same time.  Please explain what you mean.

The point is that the whole point of using an in-between device and not
just a simple laptop, is that on a lot of seriously setup networks, a
single ethernet packet on a switch port that is not the known MAC adress
will lead to at least the triggering of an alert, and in many cases to
the switch port being disabled. If during system boot, the device outputs
packets with its hardware MAC adress, this will lead to an unwanted
situation. The device needs to do nothing with its own MAC adress, and
after having determined a suitable MAC adress to masquerade as, start
to use this adress.

> > * On the workstation side run a shell application using browser applets.
>
> Again, I need more input.  Not sure what you mean by this.

The workstations often have a very limited amounth of available
applications, but a web browser with java functionality seems to
always be pressent. This means that the user might not be always
able to start a telnet or ssh connection to the device. For this reason,
looking at using a java aplet to log in to the device with some form
of shell, and thus being able to use the pentest tools on the device
would seem a good way to overcome the limitations of standard
workstations. This won't always work I guesse, but you could
always have some tools using a simple web interface, be it more
limmited than with shell access to the device.

> > The point of this last one is that if all works well with standard
> > PC hardware, and the standard set of tools works ok, I would like
> > to look at those nifty litle XXS1500 boxes from mycable.de to look
> > if we can create simple pocket-size inline device for the inline type
> > of pentests.
>
> When you say inline pentest, are you just talking about all of the
> different MITM possibilities, or do you mean something else?

No, I don't mean 'inline' as in MITM atacks, I purely mean it as inline
between unpriviledge user workstation and the network that this
workstation has access to. Auditing the trafic specs of the workstation,
and using this as input for (using spoofing of MAC+IP) all kinds of
pentests that either require the workstations authorization combined
with tools on the device, and thus need a MITM way of working, or can
be directed from the device at either the worksation, the network,
or auditing servers outside of the network in order to audit
conectabillity.

As stated before, I have very limited experience with such in-line
pentests, as pentests are not my main line of business, and in the past
I did not run into many enviroments where the switches were configured
to use MAC/port based intrusion detection and port lockout. (It is
actualy on my advice from previous audits that these filters are now
in place, and I now need to re-audit).

Rob

Re: [ISECOM-discuss] 'in-line' pentest, and booting Linux 'in-line' ?

[<ro...@dy...>]

Rob J Meijer(rm...@xs...)@Wed, Apr 06, 2005 at 08:33:37AM +0200:
> I need to set up a dual network card system as inline pentest system
> (between a workstation and the network). I havn't bothered before with
> the boot effects of pre-mac-spoofing stage, and havn't before used
> 'standard' tools inline, only custom spoofing tools.

I'm not really sure what you're asking.  I read the post twice, and it
seems like you want the Linux inline box to behave like a bridge device,
have access to all data sent/received, and the opportunity to rewrite
packets on the fly as needed?

> Can anyone point me to some more information on hardware to use, and
> actions to take in order to make a linux system :
> * be able to boot inline, and to network-wise keep silent.
> * during boot completely assume the MAC adress (on the network side)
>   of the workstation.

Those 1st two items conflict?  You can't assume the MAC address and be
silent at the same time.  Please explain what you mean.

> * On the workstation side run a shell application using browser applets.

Again, I need more input.  Not sure what you mean by this.

> The point of this last one is that if all works well with standard
> PC hardware, and the standard set of tools works ok, I would like
> to look at those nifty litle XXS1500 boxes from mycable.de to look
> if we can create simple pocket-size inline device for the inline type
> of pentests.

When you say inline pentest, are you just talking about all of the
different MITM possibilities, or do you mean something else?

Robert

-- 
Robert E. Lee
CEO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - ro...@dy...
M - (949) 394-2033

[ISECOM-discuss] 'in-line' pentest, and booting Linux 'in-line' ?

[Rob J M. <rm...@xs...>]

I need to set up a dual network card system as inline pentest system
(between a workstation and the network). I havn't bothered before with
the boot effects of pre-mac-spoofing stage, and havn't before used
'standard' tools inline, only custom spoofing tools.
Can anyone point me to some more information on hardware to use, and
actions to take in order to make a linux system :

* be able to boot inline, and to network-wise keep silent.
* during boot completely assume the MAC adress (on the network side)
  of the workstation.
* On the workstation side run a shell application using browser applets.

The point of this last one is that if all works well with standard
PC hardware, and the standard set of tools works ok, I would like
to look at those nifty litle XXS1500 boxes from mycable.de to look
if we can create simple pocket-size inline device for the inline type
of pentests.

I am kind of new to inline pentesting, so any pointers would be greatly
apreciated.

Rob

Re: [ISECOM-discuss] safety concerns

[Richard F. <rf...@ny...>]

http://www.scotland.gov.uk/library3/planning/nppg/nppg19-02.asp

I believe the Radio Telecommunications agency or Ofcom in uk covers this

Some interesting info:

http://www.nrpb.org/press/information_sheets/mobile_telephony/index.htm
http://www.sitefinder.radio.gov.uk/
http://www.iegmp.org.uk/report/clarification.htm


Jose Luis Martin Mas wrote:
> I'm not an expert on the subject :), but maybe this site could point to
> useful sources:
> 
> http://www.icnirp.de/
> 
> It's the International Commision for Non-Ionizing Radiation Protection.
> 
> In the specific question of mobile phones, as far as I know, there's been
> lots of talk in Spain about towers and neighbours having a tower near
> asking for regulations. The Spanish government made a law about it, but
> without clear restrictions... So some governments of the autonomous
> regions of Spain have made other regulations. For example, the Catalan
> government issued decree 148/2001 about mobile phone towers and eveything
> used for communications emitting between 10 MHz and 300 GHz. Link (in
> Spanish):
> 
> http://www.gencat.net/mediamb/lleis/atmosfer/eatmos020.htm
> 
> 
>>Hi,
>>
>>Does anyone know of a nation/state who has imposed safety/health
>>regulations for frequencies within the non-ionizing radiation range?  I
>>know for instance, there has been ELF/ULF/VLF concerns for animals,
>>specifically whales from the USA but anything on people?  I also know
>>there's talk and concerns about mobile phone radio towers and even
>>mobile phones but I suspect no regulation yet since it's such an
>>economically boosting industry.  Is there a regulative reason for
>>shieldings on our computers from the hi-frequency microchips?  And there
>>must be regulations about microwave frequencies used in transmissions.
>>Anyone able to point out sources or better yet, provide soecific
>>regulations?
>>
>>Sincerely,
>>-pete.
>>
>>--
>>Pete Herzog - Managing Director - pe...@is...
>>ISECOM - Institute for Security and Open Methodologies
>>www.isecom.org - www.osstmm.org
>>www.hackerhighschool.org - www.isestorm.org
>>-------------------------------------------------------------------
>>ISECOM is the OSSTMM Professional Security Tester (OPST),
>>OSSTMM Professional Security Analyst (OPSA), and Hacker Highschool
>>Teacher certification authority.
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>
>>ISECOM-discuss mailing list
>>ISE...@li...
>>https://lists.sourceforge.net/lists/listinfo/isecom-discuss
>>
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> ISECOM-discuss mailing list
> ISE...@li...
> https://lists.sourceforge.net/lists/listinfo/isecom-discuss
> 
>