Lesson 8:Two days ago we covered VoIP assessments, and yesterday
we covered Intranets and the use of proxies. Most of last week also
covered internal network infrastructure assessments, except for some
topics such as PDA phones and WiFi devices.
Today I wanted to talk about reconnaissance, which some people refer to
as footprinting. Besides the usual sources of trouble (i.e. Google),
there are plenty of old school avenues to take when finding information
about a company, organization, or person.
Of particular interest is to look at external network connectivity. How
does an organization connect to the Internet? I talked about war dialing
on Day 6, which has a similar goal and effort. However, war dialing is
pure enumeration -- start with a number and increment. Searching for
external network information is much different as we will see.
We'll also be covering DOM-based XSS tools in the software assurance
section today. I hope you enjoy it.
Part 1: Information assurance vulnerability assessment —
Footprinting the perimeter
Whether you know about it or not, your company or organization connects
to the Internet the same way that everyone else does. Using the Border
Gateway Protocol, version 4. If you don't run it, then your upstream
does -- or possibly their upstream.
BGP-4 requires an autonomous system number (ASN) for every organization
connecting. Usually these are ISP's and very large Enterprises. Every
owned IPv4 prefix is announced from one of these ASN's (some
organizations have more than one).
This information leaves a trail of data that anyone can query using a
whois client. First of all, a Regional Internet Registry (RIR) must be
contacted in order to acquire an ASN. If an upstream provider (an ISP)
provides the IP prefix(es), this is known as provider-aggregated IP
space (PA). Most RIR's (well, ARIN who is the RIR for North America)
loosely require that PA space have additional downstream information
placed into their database. There have been two typical ways of doing
this: Shared Whois IP (SWIP) and Referral Whois (RWhois). SWIP is in the
RIR database, while RWhois is kept in a local ISP database, which can be
queried by the RIR to keep information updated.
If an organization goes directly to an RIR to acquire an ASN or IP
prefix(es), their IP space is known as provider-independent (PI).
Getting PI space usually requires a minimum infrastructure size (a
certain number of IP's to be used). Detailed ASN and IP prefix
information, along with organization information (such as contacts for
billing, technical support, and abuse issues) is available in the RIR
database. This is what is queried via whois/RWhois.
Similarly, you may be familiar with network information center type
services (NIC) as provided by the original Network Solutions. Today, we
call these domain registrars, and their antiquated whois services, which
have access to their databases, may one day disappear. Network Solutions
whois even still supports querying antiquated role handles, although I
have no idea how to get one of these since around 1999.
Recommendation: Find and protect your Whois data. I suggest a
service, such as the one from Namecheap, called
WhoisGuard, when you setup your domains
(or change them to this). Make sure that your modification of this
information is protected by passwords (or better yet -- PKI) in the
safest manner possible.
Similarly, protect your RIR, RADB, and RWhois data. The RADB is a part
of the IRR, with free IRR services available from
ALTDB. If this information for your IP
prefixes is not secure, then your entire traffic or source could be
subverted. This could happen regardless of whether or not your
organization runs BGP-4 because it could be a lack of precision by one
of your upstream providers that could cause this to happen. Better --
use a new type of service to provide assurance to your routing such as
using a commercial service from Renesys or
the free
service from
Packet Clearing House, Prefix Sanity
Checker.
Querying live BGP information is best done with a Looking Glass
server, PWhois,
Network ThinkTank,
FixedOrbit, and the Team
Cymru Network Monitoring
pages. My two favorite projects around this space have been Route
Views and MERIT's BGP
Inspect, just because of how
much data they maintain. Searching through an old BGP table snapshot, or
an old copy of the RADB database (or Domain registrar, RIR, and other
IRR data) -- even in text format -- can be extremely revealing about an
organization's network infrastructure.
Other services such as CompleteWhois maintain information about ASN/IP
hijacking (and information on individual/group hijackers, which are
often -- but not always -- spammers). The Web Security
Authority combines some
CompleteWhois information lists to create mod-security rules, which may
be an interesting way to protect externally-facing web applications.
I also suggest getting away from the web and using your command line to
query this sort of information. You'll never know when an adversary will
insert an XSS as whois database
information
(although one could argue that a client-side attack could also happen
with command-line whois).
whois -h com.whois-servers.net tssci-security.com | grep Server:
This command tells us which domain registrar's whois server to query for
more information. (Note it is possible to change com.whois-servers.net
to net, org, us, edu, and many other possibilities if the default com
Whois server does not provide the detailed information you want).
Whois-servers.net is basically a referral service for domain
information. Let's query the real (i.e. referred) domain registrar now:
whois -h whois.godaddy.com tssci-security.com
Here you can see that TS/SCI uses DomainsByProxy (a similar service as
WhoisGuard, but provided by GoDaddy instead of Namecheap).
Try
whois -h whois.arin.net 64.135.2.110
You'll see both the ARIN information, as well as the RWhois information.
If we connect to that RWhois server, as seen below, there are other
techniques you can use to gain more information about both the ISP and
their customers.
nc rwhois.host.net 4321 %rwhois V-1.5:003eff:00 whois.host.net (by Network Solutions, Inc. V-1.5.9.5) -holdconnect on %ok -forward on %ok -limit 600 %ok -status %status limit:600 %status holdconnect:ON %status forward:ON %status objects:682 %status display:DUMP %status contact:hostmaster@host.net %ok host*
-quit
(You'll also want to check out other RWhois commands such as -security
and -register from the RWhois specification, RFC
1714)
whois -h whois.radb.net 64.135.0.0/17 route: 64.135.0.0/17 descr: HOST-64-135-0-0-17-BLOCK origin: AS13645 notify: db-admin@host.net mnt-by: MAINT-HOST changed: db-admin@host.net 20040621 source: HOST
whois -h whois.radb.net maint-host mntner: MAINT-HOST descr:
HOST/BroadbandONE maintainer object admin-c: HNA-ORG-ARIN tech-c:
HNA-ORG-ARIN upd-to: db-admin@host.net mnt-nfy: db-admin@host.net auth:
CRYPT-PW IZVSxc8/dvNpk mnt-by: MAINT-HOST changed: db-admin@host.net
20040811 source: HOST
whois -h whois.radb.net as13645 ...
As you can see, there is quite a bit of information available from
Whois/RWhois from Domain Registrars (which you can find using
Whois-servers.net), RIR's, IRR's, and individually hosted RWhois
servers. There is quite a lot to explore, so check out the
specifications and also use the server "help or ?" functionality (e.g.
`whois -h whois.networksolutions.com \?').
Part 2: Software assurance vulnerability assessment — XSS on the
DOM
Best DOM-based XSS attack tools
Web Developer's View Javascript, FireBug, w3af, Burp Intruder, scanajax,
ProxMon, OWASP Pantera, cruiser, CSpider.js
Any claims that an automated scanning tool can find all XSS is dead
wrong when it comes to DOM-based XSS (or Flash based XSS, et al). There
are already unique enough scenarios for finding some reflected or stored
XSS, but DOM-based XSS vulnerabilities make this even more troubling. Do
the right thing and check the source code in addition to dynamic
testing. Commercial tools such as Fortify SCA 5.0 support Javascript and
Ajax for just this purpose, but open-source tools Aptana, JSLint,
JSONLint, and many of the language-specific static analysis tools
mentioned in Day
7's,
"Best XSS attack helper tools" section may also be of use.
Posted by Dre on Wednesday, January 16, 2008 in
Defense,
Hacking,
Itsm and
Security.
Lesson 7: Today I wanted to bring the real meaning behind these
techniques into the spotlight. Learning about how IT groups do real
security is only part of this.
I'm also talking about what I've seen that IT security shops don't do.
What penetration-testers or auditors don't recommend. What everyone
misses. This is my way of shaping the industry in a way. I feel it's
extremely important.
You may laugh about some of the ideas or think they are trivial. That's
fine -- let me know what you do and don't like! You may also be lost in
a sea of acronyms and content. This is why I make sure to recommend
additional books you can read that explain the topics well.
I see all of this as a step-up for instructional capital around
vulnerability assessments. I want to give everyone a chance to improve
their skillsets, techniques, as well as toolchains.
Part 1: Information assurance vulnerability assessment — Network
Access Control
This post is not about NAC, the common technology you may all be
familiar with or studying/researching. The Cisco version of NAC is a
poor concept. The endpoint security work in the IETF by Juniper Networks
and the Microsoft work (or StillSecure and anybody else) is also a
complete waste of time. This industry and these products are dead and or
dying. So let's just skip Cisco NAC and concentrate on the real topic:
access controls in networks.
Is anyone here familiar with VLAN's? How about VACL's? What about
Cisco's new access control layer in the network? This is more along the
lines of what I'm talking about. However, I don't want to get into
protecting the network infrastructure (that's next week).
Recommendation: There is a concept, which is really more of a dream
that I have. In the spirit of Martin Luther King Jr. (who was born on
this day, 79 years ago) -- I am going to get my favorite industry to
believe in this dream. To believe in a network that has no traffic
except SSL, GPG, and SSH (or any of the other secure channel
technologies
talked about on Day 5). Every packet that flies over the WiFi, the
Ethernet, and between servers is all wrapped in happy encryption. All
ports are closed unless they speak SSL.
But wait -- what about DNS? Surely, DNS must be used for the local
Intranet -- to get to local servers and printers, and to get to an SSL
VPN or automatically-configured SSL proxy (so that packets can go
to/from the global Internet). But Internet-aware DNS can be restricted
internally, so that only the SSL proxy has access to the Internet. This
keeps people from tunneling SSH in DNS or other strange network affairs.
All other services besides some Intranet DNS, a little printer port
access, and SSL can be completely shut down and shut off. We don't need
it anymore. This is 2008, not 1998. Certainly, there will be exceptions
at some companies or organizations -- but these can be monitored with
compensating controls. Even Intranet servers and printers should
technically be behind an "Intranet proxy" which works in a similar way
as the Internet SSL proxy. All traffic can thus be wrapped in SSL, so
that printers can be accessed via HTTP (although it would be nice if
they supported SSL natively). The Intranet proxy could then whitelist
scripts coming from the Internet to prevent cross-site printing or other
unwanted script execution.
Better - the SSL proxies can be configured with concepts from
ClientVA and
Whitetrash. All client-side
applications that access the Internet not only are passively verified
for their version numbers (also don't see: NAC scanning which actively
verifies by scanning), but they are additionally only allowed to certain
URI's via a whitelist.
I'm not really big on Windows or Apple file sharing for distributed
clients. iSCSI might be ok on a server backend network, but these sorts
of protocols don't belong on a safe network regardless of how they are
encrypted. I'm mostly referring to SMB, which is safe to turn off in
2008. We have Intranet wiki software that allows flies to be uploaded
instead.
Intranet web servers that do allow file uploads/downloads should have
the presence of web shells or malicious Javascript detected. Some
network-IPS devices do block some web shells or malicious Javascript
content, but this is hit or miss. It's best to run a utility such as
SpyBye locally, or utilize a commercial tool
such as Nessus or PVS to detect malicious
Javascript.
While on the server, documents can also be scanned for versions by using
Metagoofil or
OfficeCat.
Also, ideally all user clients would be thin clients -- but this is
possibly a dream for a different day.
Part 2: Software assurance vulnerability assessment — Stored XSS
Best Stored-XSS attack tools
w3af, HTMangLe, Hackvertor (or anything Gareth Heyes writes),
PostInterceptor, Tamper Data, Burp Suite, Paros, OWASP WebScarab,
XSSscan.py, Acunetix XSS Scanner, Syhunt Sandcat Free, Wapiti, OWASP
CAL9000, Wfuzz, SPIKEproxy, Gamja, screamingCSS
Best XSS attack helper tools Web Developer, RSnake's Security
Bookmarklet methodToggle, .mario's Encoding
tools, Dean Edwards'
Packer, JSMin, RSnake's XSS Cheat
Sheet, OWASP SWFIntruder, HackVertor (and everything else Gareth Heyes
writes), HTMangLe, ExtendedScanner, Hunting Security Bugs' Reference for
ASP.NET Control Encoding and Web Text Converer, WhiteAcid's XSS
Assistant, Net-Force Tools' NF-Tools, Hunting Security Bugs' Overlong
UTF, RefControl, User Agent Switcher, ProxMon, OWASP Pantera, AppPrint,
AppCodeScan, FindBugs, FxCop, Pixy (for PHP), Milk (for Java), SWAAT
(for ASP, JSP, PHP), ASP-Auditor (for ASP.NET), XSSDetect (for .NET),
Mod-Security, PHP-IDS, CORE GRASP, Inspekt, RATS, PSA3, PFF, PHP-SAT,
PHPSecAudit, Orizon, LAPSE
Unlike black-box testing Reflected-XSS, it is highly recommended that
every time that you change a parameter or POST a form -- that each test
string be unique. Know which tool you used and where in the application
your vector was initially sent. Stored-XSS can pop up anywhere
throughout the web application much in the same way that a fuzzer can
crash a fat application by sending a sequence of strings. This is the
reason why humans are needed and manual testing must be
done
to expose all flaws.
However, I am highly impressed with the accuracy and methods used when
doing manual code review for finding XSS. There are plenty of SQL
injection and XSS that can only be found by looking through the source
code. Often, either finding the source code through information
disclosure or other means (identifying an open-source application or
component is the easiest/obvious way) will allow finding the most
obscure of stored-XSS vulnerabilities.
Posted by Dre on Tuesday, January 15, 2008 in
Defense,
Hacking,
Itsm and
Security.
Lesson 6: Last week was great as I started out talking about a
variety of topics including --
Over the weekend I spent some time playing with some of my favorite
tools. I learned a few things about them. For the browser tools, I
installed the SecurityQA
Toolbar, written
by Tim Newsham. It has a restricted evaluation, which is an IE BHO. The
evaluation is very restricted, but I'm sure that the full-copy from
iSecPartners works amazing just based on what I've seen from the
interface. Not only is it limited in the types of attacks one can do (no
blind SQL injection, XML injection, OS command injection, XSS/CSRF/HRS
testing, no directory traversal, and no ActiveX testing -- but all of
these look to be available in the full commercial product. There is only
one attack vector for even the attacks that do work (and you can see the
ones for the attack vectors that are grayed out). The reports and the
wizard are fantastic -- certainly a browser-based tool that has a
future.
Firebug Lite is one of my favorite external browser tools that works
with browsers. However, I found out a method to use Firebug with IE
using bookmarklets.
Besides just Internet Explorer, I also found some useful tools for
Opera, such as the Opera developer
tools, as
well as Firefox crawling using
spider.xpi. I also learned a few
other things that I'll save for later. Also, I'm leaving out a separate
"Part 2" section today because I've already given you some new software
assurance tools to check out. We'll cover Stored-XSS tomorrow!
Information assurance vulnerability assessment — "Technology X over
IP"
TCP/IP used to be a fascinating protocol because you could run it both
on and off the Internet. When I first got into TCP/IP, friends and I
would run local networks that did not connect to the Internet. By, this
I mean that there was no firewall. DEC hadn't even invented the TCP/IP
firewall until at least a year or two after I got online. We ran a local
LAN using TCP/IP and even had our own DNS... e.g. domain.lan or
domain.local. This worked really well.
Once Network Address Translation became popular, local LAN's based on
TCP/IP went away. So did DECnet, AppleTalk, Novell IPX/SPX, and OSI.
Everything became connected to the Internet, and Intranets became
something you had internally but thought were safe behind a firewall. I
knew right away that these networks were not safe, as the most powerful
attacks and backdoors I had seen at that time were all based on the
client-side (IRC grok, ssh client backdoors, etc).
Circa 1995-1996, I was already much aware of using ptrace(2) in a way
that a reverse engineer would use UHooker today. Yet, I was also playing
with the first IP telephony systems using Dialogic boards (similar to
the Digium PRI and FXO/FXS PCI cards) under Solaris x86 and connecting
them to ISDN (both PRI and BRI), POTS, and T1 CAS -- even as trunks to
other IPBX's (e.g. MiTel) at the time. With Asterisk, Trixbox, and
ShoreTel -- we now refer to these as IP-PBX's, but it's the same
acronym. Before I got bored of ISP access engineering (this was around
1997-1998 when Internet data centers started popping up all over the
country), I also got to play a little with SS7 and setting up IMT trunks
on Cisco AS5300's and Lucent Portmaster 4's.
On my mind the entire time was why on earth would any telecommunications
provider want to connect this stuff to the Internet? It's one thing to
keep your SS7-connected Portmasters out-of-band for management access
and allow dial-up users to be on the modems for said devices. But it's
another huge issue to allow integration of RIPv1 (and years later, RIPv2
to provide CIDR support), RADIUS, DNS, DHCP, and all the other features
(I think I even ran BGP-4 on a Portmaster) available at that time.
Nobody ever changed the paradigm... the devices worked and they didn't
suffer a lot of security problems (none that I knew about at least).
Today, telecommunications fraud is huge... growing by at least 10% per
year. In 2003, a survey conducted by the Communications Fraud Control
Association put the losses at $35 to $40 billion dollars per year. This
puts 2008 at over $60B in telecom fraud losses at the most generous
level.
We are facing a new scenario today. Some of the most complex modern
applications happens to be those based on voice and video
communications, as well as the popular web applications we already spoke
about. Network drivers, even Bluetooth, WiFi, and IRda are dangerous
because of their scope but not necessarily their complexity. Microsoft
models the design of these types of network drivers using SAL (their
Standard Annotation Language) and also provides a lot of software
verification with tools such as SLAM (a model-checker). Many IP
communications and web applications do not get the benefit of formal
methods testing.
I recently saw the season finale for the TV show, "Hero", where a
prominent Cisco IP Video Communications web interface was utilized in
the show instead of the classic Hollywood security surveillance room. I
think they even used it in one of those Vegas shows. The first thing I
thought of is what a bad idea it would be to use this sort of system.
Combining internal communications system and web applications on the
Internet is asking for the worst kind of trouble. See also: SCADA.
Asterisk alone had suffered two of the most popular types of web
application attacks last year. The first one I already mentioned in my
post Ajax security opens up a whole new can of
worms,
where I mention Wade Alcorn's work on XSS Interprotocol
Exploitation. This start with an
XSS that allows a buffer overflow to be passed through the client-side
browser to an Asterisk server. Even more recently, Asterisk-Addons
allowed a SQL
injection
to run remote commands.
Recommendation: Test your VoIP (and Video-over-IP systems if you
have them) and maintain strict vulnerability management over these sorts
of cross-technology converging worlds. In my opinion, MITRE OVAL isn't
enough -- although integrating these concepts into OVAL-Compatible
solutions would be a good start. Use reconnaissance, footprinting, and
enumeration tools such as iWar (a
VoIP-enabled war dialer to bring you back to the 1983 WarGames era).
Also utilize full-knowledge to gain access to known 800/WATS and DID
numbers. Check PBX or IP-PBX configurations for correct DID assignments.
I've mentioned before that while WiFi has WVE, it doesn't have a
software weakness enumeration program. Voice and video/surveillence
communications systems should also have their own CWE-like programs.
Peter Thermos and Ari Takanen created these sorts of CAPEC and CWE
models for VoIP in their book on, "Securing VoIP Networks". They call
these the VoIP threat and VoIP vulnerability categories, respectively --
and even compare the VoIP vulnerability categories to both CWE and OWASP
Top Ten. Using these along with binary analysis is a good place to start
to define where systems are weakest and require testing, as per my usual
recommendation.
The guys over at Learn Security Online have some great content. One of
my favorites was submitted by a user named Sandro Gauci last month,
where he demonstrates how to use SIPVicious to "get the job
done"
(login required -- get their free registration!). It's definitely a must
read when thinking about penetration-testing or VoIP systems.
I also recommend additional reading such as the "Securing VoIP Networks"
book mentioned above and the "Hacking Exposed VoIP" (of which the
author's blogs are great reads if you can find them). There's also a
recent SANS paper by David Persky available in their Reading Room -
VoIP Issues.
Sorry about the lack of a Part 2, Software assurance section today.
I promise waiting one more day for a better Stored-XSS post will be
worth it.
Posted by Dre on Monday, January 14, 2008 in
Defense,
Hacking,
Itsm and
Security.
Lesson 5:After the first week, many of these assessment techniques
don't all fit together or seem congruent. Mid next-week, I think a lot
of these pieces will start to come together to form a big picture. The
recommendations I've given so far are not things I've seen or heard from
the community of security professionals. Many people are asking for
examples, but my question is -- what exactly do you want to delve into?
If anything, I would rather spend my time introducing the concepts so
that you can explore the details for yourself.
Part 1: Information assurance vulnerability assessment — Secure
channels
There has been constant debate about how to create a secure channel over
a network, especially say, the global Internet. The two leading systems
are SSL and DNSSEC.
SSL has had various problems over the years, but it's the top dog.
DNSSEC will likely never become popular, and the complexity behind it
rivals IPSec. SSL VPN has all but replaced IPSec today as well. SSH is
in use but isn't seen as a consumer-level technology, not even with
SSHTerm / Ajaxterm. Other abominations such as SNMPv3, S-BGP, and
Kerberos-enabled protocols, encrypted IMAP/POP3, et al -- these are
bound to be around and unpopular for another ten to twenty years.
Off-topic and unrelated, yet on my mind as I write this: I can't believe
that people still use TFTP for router/firewall images and
configurations. I'm sorry did I say, "people still use"? I meant,
"vendors left implemented for over 13-14 years because that's how long
SSH and SSL have been around for".
Drive-by-pharming, which involves using CSRF (possibly aided by XSS or
other attack vector) to modify Intranet/home routers and firewalls,
often changes the router DNS servers. DNS hijacking in this way could
create a situation where browser rootkits are always installed on
Intranet users' browsers universally. RSnake's Using DNS to enable
XSS and
the subsequently linked LURHQ paper are must reads.
Similarly, DNS cache poisoning can cause the same effect. ARP cache
poisoning, ditto. We've seen BIND 9 exploits and ARP spoofing malware
throughout 2007. The only interesting defenses in the research community
have also ended up in failure, as seen by the PRIV8 SCM Firefox
Add-on. It appears that this
research has been duplicated by OpenDNS and DNSstuff, as I recently read
in this article from Dark Reading on Hacking a New DNS
Attack.
Sure, there are issues with Firefox
add-ons
(which I knew about the first time I installed an extension). I love how
every security professional thinks their research is new when they apply
an old concept (e.g. arp cache poisoning) with a bleeding-edge
technology (e.g. Firefox add-ons).
Recommendation: There were plenty of exploits available for both
Microsoft's DNS server and ISC BIND last year. Do you want to repeat the
same mistakes and headaches this year? Consider alternatives, or push
vendors to provide reliable DNS server software that has high assurance
properties.
CoDoNS is
an interesting research project that needs more attention and support.
Every book worth it's weight on network security and system
administration has a section on DNS server security. Go read that
section now. I also suggest reading Domain
Contamination
from Amit Klein.
Monitor your DNS servers. I also suggest monitoring external DNS and
co-operating with other organizations to form a strong passive DNS
infrastructure for replication. Recently, source code was released for
dnslogger-forward in
order to create sensors for this purpose.
As for SSL, I'm getting quite upset about what once was a great
technology. I mean, what good is it when browsers have serious problems
that remain unfixed for years? Please be sure to read heise Security's
article on Bugs in Mozilla browsers facilitate man-in-the-middle
attacks. Try out the test
page that they link to and see the problem for yourself.
Certificates are a nuisance and all of this is being wrapped up under
the umbrellas of liability and Certificate Authority god-complexes.
Sure, SSL works today and DNSSEC
doesn't,
but I'm pretty sure both are wrong and we'll see the demise of both over
time. If anyone besides myself thinks that
Enigform and mod_auth_openpgp are the
future of secure HTTP channels, please holler.
For more information, you would think I'd recommend DNS & BIND, but it
turns out that one of the authors is a spammer (yes, Cricket Liu is an
evil, bad spammer -- how's that for irony?) and BIND software just plain
sucks. Instead, I suggest you read "The dotCrime Manifesto", by Phillip
Hallam-Baker.
Part 2: Software assurance vulnerability assessment — Reflected
XSS
Best Reflected-XSS scanning tools
XSSscan.py, XSS-Me, HttpBee, Acunetix XSS Scanner, Syhunt Sandcat, w3af,
Wapiti, OWASP CAL9000, Wfuzz, Grabber, SPIKEproxy, WebFuzz, Gamja, Burp
Intruder, Burp Repeater, Paros, OWASP WebScarab, screamingCSS, gunzip
webfuzzer, N-Stealth Scanner Free Edition
I'll cover Stored-XSS, DOM-based XSS, and XSS attack helper tools next
week! I will go into more detail about finding XSS once more
techniques/tools are suggested. Here's a few suggested tools to play
with over the weekend.
I don't usually repeat tools if they aren't particularly interesting for
helping individual attacks. However, you'll want to go back and review
how Reflected-XSS can be found using HTTP request tampering tools or
browser-based tools. In the case of Reflected-XSS, these can be found in
both parameters and forms, as well as in binaries (UXSS), emails,
images, QuickTime/Flash and other media files, and pretty much just
about
everywhere.
Posted by Dre on Friday, January 11, 2008 in
Defense,
Hacking,
Itsm and
Security.
Last night Rich Mogull of Securosis, and
co-host of Network Security Podcast,
hosted SunSec (which was on hiatus for far too long) at the Furio in
Scottsdale. It was a great turnout last night -- about twenty people had
shown up and talked up all kinds of storms for several hours.
Dre and I talked with Dennis Groves, one of the founding members of
OWASP and contributor to the OWASP Guide. Dennis had mentioned the
DARPA Browser Project
and we then talked about trusted systems and how software assurance
through formal methods will fix all the security problems.
Obviously with Mogull we had to talk about data security -- his
specialty, and what's also obvious he is a rockstar at it. Where are all
the other security researchers that are into data security like he is??
All I can count and know of is Dan
Geer, Rob
Newby and Gunnar
Peterson (oh, and Christofer
Hoff too!). We also had
brought up the little SCADA hack/hoax that Hoff and him had tried to
pull a couple weeks ago. Trailing off, we then got into a discussion
about hacking train controllers, and what do I notice in my feed reader
this morning? Courtesy of Domber's
Basecamp: Schoolboy hacks into city's
tram
system.
All in all, SunSec rocked. If you live in the Phoenix area, you
definitely have to make it to the next one.
Posted by Marcin on Friday, January 11, 2008 in
Conferences,
People and
Security.
