Madrock

The problem has been discovered in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.

In addition to the unpatched hole in Internet Explorer, a now published hole in Windows allows users with restricted access to escalate their privileges to system level – and this is believed to be possible on all 32-bit versions of Windows from Windows NT 3.1 up to, and including Windows 7. While the vulnerability is likely to affect home users in only a minor way, the administrators of corporate networks will probably have their hands full this week.

The problem is caused by flaws in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.

Ormandy has also published a suitable exploit which functions under Windows XP, Windows Server 2003 and 2008, Windows Vista and Windows 7. When tested by the The H’s associates at heise Security, the exploit opened a command prompt in the system context, which has the highest privilege level, under Windows XP and Windows 7. No patch has become available, although Ormandy reports that Microsoft was already informed of the hole in mid 2009. The developer decided to publish the information regardless because, in his opinion, there is a simple workaround: to disable the MS-DOS subsystem.

The workaround requires users to start the group policy editor and enable the “Prevent access to 16-bit applications” option in the Computer Configuration\Administrative Templates\Windows Components\Application Compatibility section. When tested with these settings by the heise Security team, the exploit no longer functioned. The settings reportedly don’t cause any major compatibility problems for most users while no 16-bit applications are being used.

Update – The above option is only available through the group policy editor on Windows 2003 systems. Some versions of Windows do not include a group policy editor. As an alternative, users can also create a registry key under \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat with a D-Word value of VDMDissallowed = 1. Under Windows XP, to prevent the system from being vulnerable to the exploit, users can place the following text:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat]

“VDMDisallowed”=dword:00000001

into a file called vdmdisallow.reg and double click the file. Windows will then automatically import the key (admin rights are required to perform this action).

Update 2 - Microsoft has now confirmed the privilege escalation hole in Windows. The company says that it wants to complete its investigation of the vulnerability and will then decide whether, how and when to close it.

See Also:

• Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack, security advisory from Travis Ormandy.

REDMOND — When it rains, it pours. Especially in the Seattle area. Tavis Ormandy has published full details on a privilege escalation hack of all versions of Windows including Windows 7.

The exploit takes advantage of a bug in the Windows implementation of the ‘virtual DOS machine’ used to run legacy 16-bit programs. The exploit can be avoided by turning the VDM ‘feature’ off but the danger of course is that enough Windows lusers won’t know about the bug and/or bother turning the ‘feature’ off.

16-bit applications need BIOS support; the Windows kernel supports virtual BIOS interrupts in its ‘Virtual-8086′ mode monitor code. The code is implemented in two stages. The #GP trap handler transitions to the second stage when CS:EIP faults with specific ‘magic’ values.

The transition requires (subsequent to authentication) restoring the context and the call stack from the faulting trap frame. But the authentication process is flawed, relying as it does on three incorrect assumptions.

• Setting up a VDM context requires SeTcbPrivilege.The barrier to getting a VDM context can be subverted by requesting the NT VDM subsystem and then using CreateRemoteThread() to run code in the context of the VDM subsystem. The VDM subsystem already has the necessary flag set.
• Ring 3 (unprivileged) code cannot install arbitrary code segment selectors.Using the two least significant bits of CS/SS to calculate the privilege of a task doesn’t work when it comes to Virtual-8086 mode. The 20-bit addressing (by adding CS << 4 to the 16-bit IP) is also used to map onto the protected linear Virtual-8086 address space. If CS can be set to an arbitrary value, then the privilege calculation can be circumvented.
• Ring 3 (unprivileged) code cannot forge a trap frame.Returns to user mode are through IRET. An invalid context can cause IRET to fail pre-commit, which in turn forges a trap frame. And even with address randomisation it’s trivial to use NtQuerySystemInformation() to obtain the address of the second stage BIOS handler.

Affected Systems

This bug dates back 17 years and affects all systems released since 27 July 1993 – Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7. See the links below for further details.

See Also
MITRE: CVE-2010-0232
Windows plagued by 17-year-old privilege escalation bug
NEOPHASIS: Trap Handler Allows Users to Switch Kernel Stack

Recently I have been looking into the vulnerabilities in the TLS negotiation process discovered late last year.

There are a range of experts debating the exploit methods, tools and how it may be fixed (server or client site or both). From what I have seen so far this may prompt a change to the TLS standard to introduce an extension to the protocol to validate sessions (session hand off and certificate validity).

www.ietf.org

isc.sans.org

• The original description (site is suffering from a slashdot effect as I write this)
• The summary by the IETF TLS workgroup, and promises for an amended protocol
• Marsh Ray’s paper
• March Ray’s protocol diagrams

www.win.tue.nl/hashclash/rogue-ca/

www.sslshopper.com/article-ssl-and-tls-renegotiation-vulnerability-discovered.html

I’m also trying to find some tools which may assist in testing for this. It looks like the exploit relies on an ARP poison or similar and then inserting plain text into the negotiation process.

Could be something that can be fixed over time as servers and clients are patched.

Some Nmap examples I thought I would post.

Scanning past Watchguard Firewalls: nmap -sS -iL targetlist.txt -P0 -sV -T4

Verbose Scan: nmap -v <target IP>

This option scans all reserved TCP ports on the target machine. The -v option enables verbose mode.

nmap -sS -O <target IP>/24

Launches a stealth SYN scan against each machine that is up out of the 256 IPs on “class C” sized network where Scanme resides. It also tries to determine what operating system is running on each host that is up and running. This requires root privileges because of the SYN scan and OS detection.

nmap -sV -p 22,53,110,143,4564 198.116.0-255.1-127

Launches host enumeration and a TCP scan at the first half of each of the 255 possible eight-bit subnets in the 198.116 class B address space. This tests whether the systems run SSH, DNS, POP3, or IMAP on their standard ports, or anything on port 4564. For any of these ports found open, version detection is used to determine what application is running.

nmap -v -iR 100000 -PN -p 80

Asks Nmap to choose 100,000 hosts at random and scan them for web servers (port 80). Host enumeration is disabled with -PN since first sending a couple probes to determine whether a host is up is wasteful when you are only probing one port on each target host anyway.

nmap -PN -p80 -oX logs/pb-port80scan.xml -oG logs/pb-port80scan.gnmap 216.163.128.20/20

This scans 4096 IPs for any web servers (without pinging them) and saves the output in grepable and XML formats.

Instead of limiting ourselves to scanning just one target., let’s broaden our horizon’s to bigger and better things. In example 2 we used our IP address to base a scan against. Using that address again we can get a look at numerous targets in our “community”. At the command line type the following (substituting a valid address of your choice of course):

nmap -sT -O 206.212.15.0-50

What this does is instruct nmap to scan every host between the IP addresses of 206.212.15.0 and 206.212.15.50. If you happen to find many interesting feedback results from this or a larger scale scan then you can always pipe the output into your choice of a human readable file or a machine parsable file for future reference by issuing the following option:

To create a human readable output file issue the -oN<textfile name> command into your nmap string so that it would look similar to this:

nmap -sT -O -oN sample.txt 206.212.15.0-50

Rather have a machine parsable file? Enter the -oM <textfile name> to pipe the output into a machine parsable file:

nmap -sT -O -oM sample.txt 206.212.15.0-50

*Back when I was becoming aquatinted with all the nmap options, I ran my first large scale scan against 250 consecutive machines using an arbitrary number (nmap -sX -O -oN sample.txt XXX.XXX.XXX.0-250).To my great surprise I was confronted with 250 up and running virgin Linux machines. Another reason why Linux enthusiasts should NEVER become bored.

-I This is a handy little call that activates nmap’s TCP reverse ident scanning option. This divulges information that gives the username that owns available processes. Let’s take a look (Note that the host has to be running ident). At the command line issue this command against your target, in this case our default Eve running Linux:

-iR Use this command to instruct nmap to scan random hosts for you.

-p Port range option allows you to pick what port or ports you wish nmap to scan against.

-v Use verbosity to display more output data. Use twice (-v -v) for maximum verbosity.

-h Displays a quick reference of nmap’s calls

Now that we have looked at nmap’s three basic usage types and some of it’s other options, let’s mix and match them.

nmap -v -v -sS -O 209.212.53.50-100

This instructs nmap to use a maximum amount of verbosity to run a stealth scan and OS detection against all machines between IP addresses 209.212.53.50 and 209.212.53.100. This command will also require root privileges due to both the -sS and -O calls. Of course this will display a very overwhelming amount of data so let’s log our results into a human readable file for future reference:

nmap -v -v -sS -O -oN sample.txt 209.212.53.50-100

Now let’s make nmap run a stealth scan and instruct it to look only for machines offering http and ftp services between the addresses of 209.212.53.50 and 209.212.53.100. Once again we will log the output (I’m a log junkie) for future reference into a human readable file called ftphttpscan.txt:

nmap -sS -p 23,80 -oN ftphttpscan.txt 209.212.53.50-100

Remember the -iR option mentioned previously? Let’s use it to take a random sampling of Internet web servers using the verbatim example from nmap’s man page:

nmap -sS -iR -p 80

Last but certainly not least, while gleaning information, don’t forget to nmap yourself. Just type at the command line: nmap 127.0.0.1 This is especially useful and recommended if you’re a newcomer to Linux and connected to the Internet via DSL or cable modem.

I was reading some posts on the Full-disclosure mailing list and came across the some posts relating to WPA hacking (WPA attack improved to 1min). After spending hundreds of hours using the AIR tools to crack WEP encryption and looking into networks as part of my previous job, I was very interested to see how things are progressing.

The thread mentioned the paper “A Practical Message Falsification Attack on WPA” posted on http://bit.ly/8qwQt.

It was a coincidence as I was only taking to one of the executives at work about how easy WEP is to crack and what you can do/discover once you are in.

I hope you enjoy the paper.

—– Update —–

Once this was posted I received many message s and a few more links for the post.

So here thet are:

http://www.youtube.com/watch?v=ZeCVkWMUSzE

http://www.crn.com.au/News/154177,researchers-crack-wpa-encryption-in-60-seconds.aspx

http://www.renderlab.net/projects/WPA-tables/
http://205.127.87.136:6969/torrents /wpa_psk-h1kari_renderman.torrent?95896A255A82D1FE8B6A2BFFC098B735058B30D7
http://www.churchofwifi.org/Project_Display.asp?PID=90
http://jwis2009.nsysu.edu.tw/location/paper/A%20Practical%20Message%20Falsification%20Attack%20on%20WPA.pdf – Though will only help with TKIP

Thanks to

Oliver from ethicalhack.org

Michael from SA Government

Tim from CQR Consulting

—– End Update ——

This is an article I found on the Phone Losers site I thought I would copy here so I can give it a go at some stage.

How To Hijack Fast Food Drive-Thru Frequencies

A few years back, some friends and I were messing around with a Taco Bell’s drive-thru frequencies. RijilV and isotek showed me how easy it was to hijack the frequencies of just about any fast food restaurant with a very simple mod to a ham radio. The radios they used were Yaesu VX-5 and VX-7 models. We had a few weeks of occasional fun, sitting a few parking lots away and saying all kinds of horrible things to potential fast food customers. For the most part, I didn’t record any of it. But you can find a few clips of our fast food hijinks if you scroll down on the PLA Sound Clips Archive page.

Finally we decided to capture a bit of our FCC violations on video. But instead of capturing actual customers being harassed by us as they placed an order, I drove through the Taco Bell drive-thru myself with a video camera sitting on the dashboard. As I attempted to place my order, RijilV informed me of some crazy new Taco Bell policies and a manager immediately rushed out to explain to me that I wasn’t actually talking to an employee. Here is that video:

After spending several years on Google Video and YouTube, it’s been watched approximately 20,000 times. And of those 20,000 people who have viewed it, approximately all of them have emailed me and asked me what kind of radio we used and how can they use a radio to do the same thing. So in the spirit of April 1st and in order to quell the number of emails sent to me and posts on the PLA Forums asking the same thing, I’ve decided to write this tutorial to help those people out.

But I’m not going to explain how to modify a Yaesu VX5 or a Yaesu VX7. A simple Google search will show you how to modify these ham radios. The problem with these mods is that, even though they’re fairly simple, you have to buy the radios which could cost you anywhere from $200 – $400. Then, after removing a couple solder points, you have to learn how to use it, you have to look up fast food frequency lists, you have to understand the difference between the transmit frequencies and the receive frequencies and you have to scroll through PL tones using trial and error to find the correct one.

Or how about we do this a different way. A way that uses a couple items that you might already have in your home. You can easily modify most old CB radios in a way that will allow them to transmit directly to drive-thru frequencies. You won’t have to scroll through hundreds of possible drive-thru frequencies, because a CB radio’s channels line up in exactly the same way as most drive-thru’s channels, only at a higher frequency. How do you get your CB radio to run at a higher frequency? A simple replacement of the crystal inside, with a 6.5536 MHz crystal. This triples the megahertz that are broadcast on and there is no learning required. You just take the modified CB radio to a fast food restaurant and start broadcasting to the customers.

“But RBCP, I don’t have a 6.5536 MHz crystal lying around my house,” you might be whining at this point. But this isn’t true. Just about any house has several 6.5536 MHz crystals in them if you know where to look. This just happens to be the exact same crystal that you can find in electric heaters, hair dryers, electric stoves, curling irons, electric hot water heaters, irons, and toasters. These crystals are in just about any item that has heated coils and are used to control the frequency of the heating elements so that they don’t burn your house down.

So for this modification you need…

• 1 CB radio. It has to be a 40 channel CB radio with a digital display, which includes just about any CB radio manufactured after the mid 1980’s. The old 23 channel CBs from the 1970’s will not work. It can even be a walkie talkie CB radio. If you don’t have one, you can find one at Goodwill or a yard sale for probably less than $10.
• 1 toaster. (Or other item with heating elements inside.) A toaster is the most ideal to use, because it’s almost guaranteed to have the crystal inside of it. It’s more common to find curling irons and hair dryers that don’t. Again, it should be a toaster manufactured within the past 20 years or so. Before that they didn’t have crystal requirements for toaster manufacturers. (And incidentally, there were a lot more electrical house fires back then.) Goodwill will probably have a toaster for less than $10.
• 1 soldering iron and solder. Don’t worry if you don’t have soldering experience. It’s actually pretty easy. Click here for a soldering tutorial. You can purchase a soldering iron at Radio Shack or Sears for about $10.
• A few screwdrivers

Even if you have to buy all these materials, you’re only out $30. That’s a lot better than the $300 you might end up spending on a Yaesu radio. And some of you might already have all these items so you don’t have to pay anything. Ask a friend or a relative if they’ve got an old toaster or CB radio lying around that they don’t need.

First you’ll want to take apart your toaster. This isn’t too hard. Just flip it upside down and start removing the screws. You’ll probably need to pull off the plastic lever and knobs before you remove the top of the toaster. Once you have the top off, you’ll see a green or brown circuit board inside.

Flip the circuit board down and you’ll see all the components on the other side, including the 6.5536 MHz crystal. The crystal is silver and will have 6.5 stamped on the side of it. In the picture below, I’ve used an arrow to show you where it’s located.

The crystal is likely in a different spot in other toasters, but it’s hard to mistake for any other electronic component. The crystal will have some form of 6.5 stamped on the side of it. In my toaster, it showed 6.55-12. While the official frequency needed is 6.5536 MHz, anything within 1.6 megahertz will work. So don’t worry if your crystal just says 6.5 or 6.50 – it’s all the same for our purposes.

It’s kind of hard to see what I’m doing in the picture above, but I’m heating up the leads on the crystal from underneath with my soldering iron to melt the solder, and I’m pulling on the crystal from above with a pair of needle nose pliers. It only takes a few seconds to get the crystal out of the toaster.

Now that the crystal is out of your toaster, throw your toaster away! Do not attempt to use it once the crystal is removed. Remember, the crystal is in there for safety and using your toaster without the crystal could burn your toast and/or start a kitchen fire. It’s likely your toaster won’t even turn on with the missing crystal, but please don’t even try. Just throw it away.

As I mentioned before, just about any brand and model of CB radio will work, as long as it has the digital display on it. Which means, just about any CB radio manufactured after the mid 1980’s. These are the kinds of CB radios whose frequencies are controlled by a single crystal inside of them. For my mod, I used a Radio Shack TRC-207 walkie talkie CB radio, which is pictured above. I prefer using a walkie talkie CB radio because it doesn’t requiring sticking a huge CB antenna on the roof of my car which might be noticed if a fast food employee starts looking around the parking lot for the culprits.

Taking apart your CB radio is just as easy as taking apart the toaster. Remove the screws and pop it open. You may or may not have to lift up the circuit board inside to find the crystal inside. In my particular model, the crystal actually plugged into a socket so I didn’t need to even desolder the old crystal. I just pulled it out with my fingers and then plugged in the new 6.55 MHz crystal. I don’t know how common this is, because in other CB radios that I’ve modified the crystal was soldered to the circuit board, just like in the toaster.

Put your CB back together and test it to make sure it’s working. You’re finished! Obviously, you won’t be able to talk on normal CB channels anymore since your CB is transmitting and receiving at a much higher frequency now. But who cares, CB channels are lame anyway. Let’s hop in the car and drive to our nearest fast food establishment to test it out.

Sit near the drive-thru and wait for a customer to pull up. While the customer is talking to the drive-thru speaker, start flipping through your channels until you hear them talking. I’ve found that most drive thrus end up being somewhere in the 16 – 25 channel range. I’ve never found one above channel 30 and only a few on channels 1 through 15. It all depends on how their drive-thru is set up and what frequencies they’re using. Anyway, push down your talk button and start talking to the customer.

The cool thing about using a CB radio to transmit on drive-thru frequencies is that a CB is designed to work for several miles. The headsets that those fast food people wear are only designed to work for about 100 feet. So you can easily overpower the employees, even if you’re several parking lots away. In fact, you may be inadvertently screwing with several other drive-thrus in town without even knowing it. This is more likely when you’re using the kind of CB radio that’s supposed to be installed in a car. Those usually run on 5 watts and can cover an entire city. This is another reason I like to use my walkie talkie. It’s lucky if it will work for even a mile, so I’m only harassing one restaurant at a time.

If you found this tutorial useful, you might also enjoy the video I’ve made on the same subject. It includes much of the same information in this tutorial, but also includes actual footage of us messing with a drive-thru with this CB mod. Enjoy!

You might also enjoy our original Taco Bell Takeover video, our Happy Birthday drive-thru video and our Drive-Thru Shenanigans video.

PLA TV: Hijacking Fast Food Frequencies [9:12m]: Download (4913)

Local Copy

The below lines can be placed into Google to find hidden cams on the net.

inurl:”ViewerFrame?Mode=
intitle:Axis 2400 video server
inurl:/view.shtml
intitle:”Live View / – AXIS” | inurl:view/view.shtml^
inurl:ViewerFrame?Mode=
inurl:ViewerFrame?Mode=Refresh
inurl:axis-cgi/jpg
inurl:axis-cgi/mjpg (motion-JPEG)
inurl:view/indexFrame.shtml
inurl:view/index.shtml
inurl:view/view.shtml
liveapplet
intitle:”live view” intitle:axis
intitle:liveapplet
allintitle:”Network Camera NetworkCamera”
intitle:axis intitle:”video server”
intitle:liveapplet inurl:LvAppl
intitle:”EvoCam” inurl:”webcam.html”
intitle:”Live NetSnap Cam-Server feed”
intitle:”Live View / – AXIS”
intitle:”Live View / – AXIS 206M”
intitle:”Live View / – AXIS 206W”
intitle:”Live View / – AXIS 210″
inurl:indexFrame.shtml Axis
inurl:”MultiCameraFrame?Mode=Motion”
intitle:start inurl:cgistart
intitle:”WJ-NT104 Main Page”
intext:”MOBOTIX M1″ intext:”Open Menu”
intext:”MOBOTIX M10″ intext:”Open Menu”
intext:”MOBOTIX D10″ intext:”Open Menu”
intitle:snc-z20 inurl:home/
intitle:snc-cs3 inurl:home/
intitle:snc-rz30 inurl:home/
intitle:”sony network camera snc-p1″
intitle:”sony network camera snc-m1″
site:.viewnetcam.com -www.viewnetcam.com
intitle:”Toshiba Network Camera” user login
intitle:”netcam live image”
intitle:”i-Catcher Console – Web Monitor”
inurl:viewerframe?mode= changing room
inurl:view index/shtml/home
nurl-’your frame?mode=motion’
inurl.”viewframe?mode=refresh”
sex inurl:/view/shtml
inural:view
inurl:viewerframe?mode=home
axis hacks
“inurl:”view from?mode=refresh”
/view/index.shtml.msn
”nurl:viewerframe?mode=refresh”
inurl:”viewerframe?mode=” naked
inurl:/view.index.shtml adult
nurl:”viewerframe? mode= refresh”
site:www.scribd.com inurl”viewframe?mode=refresh”
inurl:”viewerframe?mode=” live webcams
nurl:”view/index.shtml
reset mobotix camera
nurl: view
url:viewerframe?=mode
inurl:/view/shtml school
inurl::viewerframe?mode”refresh
inurl:view:/shtml porn
“inurl: /shtml”
inurl:”viewerframe?mode motion” motion

A link to others http://peep.ontheweb.nl/

From Pentestmonkey.net, this is a great list of SQL Injection cheat sheets.

• Oracle
• MSSQL
• MySQL
• PostgreSQL
• Ingres
• DB2
• Informix

Some more Links:

SQL Injection Attacks by Example

Pangolin – Automatic SQL Injection Tool

SQL Injection Attacks Exploiting Unverified User Data Input

SQL Injection Cheat Sheet

Hi,

I have been putting some secure application development documents together recently and have found some good general tutorials and guidelines which I thought I would post here.

Best Practices

• The Ten Most Critical Web Application Security Vulnerabilities, 2004 Update, The Open Web Application Security Project. URL: http://www.owasp.org/documentation/topten
• A Guide to Building Secure Web Applications, The Open Web Application Security Project. URL: http://www.owasp.org/documentation/guide
• Improving Web Application Security: Threats and Countermeasures, Microsoft MSDN. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/ThreatCounter.asp
• Authentication in ASP.NET: .NET Security Guidance, Microsoft MSDN. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/authaspdotnet.asp
• Session Fixation Vulnerability in Web-Based Applications, ACROS Security. http://www.acros.si/papers/session_fixation.pdf
• Writing Secure Code, Michael Howard and David LeBlanc, Microsoft Press.
• Threat Modelling, Window Snyder, Microsoft Press.
• 10 Things You Shouldn’t Do with SQL Server (Data Access Developer “Don’ts”) http://www.dotnetjunkies.ddj.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
• Ten dos and don’ts for secure coding http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1172049,00.html
• Cross Site Scripting http://www.cert.org/archive/pdf/cross_site_scripting.pdf http://www.acunetix.com/websitesecurity/cross-site-scripting.htm
• The Cross Site Scripting (XSS) FAQ http://www.cgisecurity.com/articles/xss-faq.shtml
• XSS (Cross Site Scripting) Cheat Sheet http://ha.ckers.org/xss.html
• SQL Injection Cheat Sheet http://ha.ckers.org/blog/20070315/sql-injection-cheat-sheet/

Other Resources

• AusCERT is the national Computer Emergency Response Team for Australia http://www.auscert.org.au/
• SANS Institute http://www.sans.org/free_resources.php

EFT devices and systems differ depending on hardware vendor, country and bank / payment aggregator.
Below is a list of things you may like to consider. This list is off the top of my head so it is probably not complete.

Looking at the products and relationships us usually a good start.

Things to consider:

• Card skimming methods
• Some EFT POS devices restrict the connection of a skimmer
• Review levels of associated fraud
• Review devices and EFT methods
• Review terminal identification (merchant and customer)
• Manual processing. (internal and external)
• eCommerce products
• PC based software
• Dedicated server services (Nobil, etc.)
• Web based engine (Custom objects, Web pop-ups, etc)
• Authorisation / identification methods (Merchant and customer)
• TCPIP session hijacking / session spoofing
• Direct Debit as well as Credit Cards.
• Swift (methods and controls)
• Telegraphic transfer (methods and controls)
• Payment aggregator relationships (eg. Payment Tech, manual processing, cheque scanning, etc.)
• Internet banking facilities (attack / penetration,  Certificate registration / management, ISP SLA’s, etc.)
• Implementation of Smart Card and / or alternative customer recognition devices.
• Outsourcing and associated risks / service level agreements
• Payment processing
• Payment clearance
• Payment switching
• Reporting (segregation of merchant / customers / aggregators / partners / local / international)
• Fraud detection and reporting
• 3rd party acquiring risks
• Single merchant ID many businesses
• Allows moneys to be laundered if the payment aggregator does not place appropriate controls on the merchant.
• Encryption used
• Internet / trusted partner / inter-bank / extranet
• Private and / or public certificates
• Single use certificates
• Client side certificates
• Remittance advice processes and controls.
• EFT disaster recovery and manual fall back procedures (associated security and reconciliation risks)
• Trusted partner relationships, SLA’s, liabilities and risks.
• EFT regulatory / legal requirements (inter-bank and government)
• Refund processing / authorisation. (policies, procedures, controls, etc.)
• CVV, CVV-2 / CVC-2 processing and management. (http://www.atlanticpayment.com/CVV.htm)
• Fraud detection mechanism (neural networks, inter-bank / department customer checks, etc)
• Supported card schemes (AMEX/Visa/Mastercard/Discover/etc )
• Review EFT floor limits (corporate and SME merchants)
• Review the ability to withhold merchant settlement until the presence of fraud has been determined.
• Review customer identification details. Such as (This varies around the world depending on local regulations / privacy laws)
• Review real-time and batched processing methods and controls (sequence numbers, access to raw data, etc.)
• Review processing with and without expiry dates. (exception controls and policies)
• Review exception / fraud reports.
• Review payment store and forward policies and procedures.
• Review Pre-Auth and Completion controls.
• Token based payment (eCash, etc)
• Merchant reconciliation, reporting methods and controls (paper, Internet, email, PDF, Fax, etc.) and associated security.
• Real time gross settlement policies, procedures and controls. (IT and amounts)
• Card issuing policies and procedures. (customer ID checks, etc)
• Banking infrastructure (ingress / egress) controls and security. (Web, partner, payment switches, outsourced infrastructure, monitoring / reporting.)
• Use of Internet technologies for inter-bank transfers and remote equipment.
• Physical security and controls of devices, ATM,s, line encryptors, etc.

I was asked some time ago what sort of things may be considered when looking at Internet Banking.

Below is a list of things which could be considered. It was just a brain dump and as such may not be complete.

Don’t underestimate the value of standard for your infrastructure, website configuration,  database engine configuration/architecture,staging environment and development/QA environments.

Some thoughts:

• Many don’t lock accounts after X failed logins, this is normally done for good customer service, but leaves the system vulnerable.

- And all the other things expected for a remote login session (forced password changes, aging, etc))
- Tools such as Brutus may be use to brute force hack authenticated sessions.

• Many allow session sequence numbers to be incremented, allowing an authenticated user to view other customer session.

- These may be server side, client side, cookie based, etc.
- Get someone to check the development methodologies and the code being used.
- Database query strings can be placed into test entry fields, allowing table dumps to browser.
- Check all pages served are secure and contain user authentication flags.

• Customer data may not be segregated, this needs to be checked.
• Customer data should not reside on the Web Server.

• Authentication databases / system data should not reside on the webserver.
• The databases should reside on a private/semi-private network.

- A different segment to the main banking system.

• Webserver should be dual homed or equivalent (some VLAN techniques are good)

- Separate private and public network cards, monitoring/backup/administration
- Infrastructure set-up to explicitly deny inbound/outbound ports, private IP & monitoring escaping from the network.

• At all data segregation points ensure rules are in place which appreciates the traffic though that point.

• All customer data where possible should be sourced from a secure back-end database.

- This may be a staging environment. i.e. no the main banking system.
- This usually allows for transactions to appear real time to the customer.
- Many transactions may be batched in reality. (internal or external to the bank)

• Ensure suitable rules have been set-up on firewalls.

- There should be inbound and outbound rules on firewalls and filtering routers.

• Don’t allow any infrastructure on the front end to allow remote administrative connections. (telnet, etc.)

- Use the serial console port to connect to a server or back-end terminal server.

• Look for the segregation / staging of online customer content from main banking systems

• Ensure that a separate development / QA / production environment system and suitable process is in place.

• Services not used by the system are active

- These should be disabled.

• Port scan of the supporting infrastructure (routers /switches) and server(s).

- Investigate the reasons for all open ports.

• Don’t use the main gateway for trusted partner access (clearing / RAS / etc.)
• Do all that standard IIS checks and NT checks (Sample scripts, change management, patching methodologies, etc.)
• Ensure denial of service precaution have been taken into account for all infrastructure and server equipment.
• Check the adequacy of the escalation procedures used.

- Look for real-time monitoring and alerting.
- Look for responsibility matrix.
- Look for ownership of issues.

• Consider upstream carrier(s) vulnerability (denial of service, IP spoofing, DNS hacking, etc)
• Consider social engineering of customer, administrative, partner accounts / systems / infrastructure.

- Helpdesk procedures and policies and/or alternate technologies (Caller ID, Gateway IP, etc.).

• Use dynamic passwords where possible (SecureID, TACACS, etc.).
• Use encrypted tunnelling where needed (IPSec, Firewall 1, etc)
• Consider looking at other customer authentication methods to enhance existing methods.

- Digital cert, IP address locked to account, etc.
- Consider use of CVV or CVN for bank issued cards.

• Consider how passwords are distributed /changed for customers.

- Plain text email, telephone, etc.
- Can passwords be changed online?

• Is additional authentication used between sections of the services once authenticated?
• Consider what the customer has access to once authenticated.

- Look at SWIFT, RTGS, inter-bank transfers, access to credit cards, etc.
- If an attacker does get in, what can the do?

• Use techniques to ensure pages, customer details are not cached at ISP, or client system.

- These are flags that can be set within pages.
- Normally SSL is cached, but some proxy vendors have been playing with techniques to do so.
- Caching of SSL pages on the client system can be turned on on some browsers.
- May banks use a Java (or similar) applet for all customer interaction, restricting all caching issues.

• Ensure paper based and on-line liability clauses are available are address all effected areas.
• Ensure within the customer sign-up process banking liability is reduced.

- I’ve seen statements like “use this system at your own risk, responsibility for any liability or claim will NOT……”
- Not very customer focused, but that’s what their legal department recommended.

All of the above can effect the security and/or operation of an on-line banking system.

Other things to consider:

• External development and support of the application.
• Ownership and management of the hardware/applications
• Publishing points for new content (internal/private/trusted network or Internet)
• Topology of front end.  i.e. Security Architecture document should be in place and managed appropriately.
• Are limited AP tests performed whenever changes are made to the environment? i.e. integrated AP into Change management process.
• Database access. Is it buffered or is it live to the core banking systems.
• What facilities are provided? Direct debit + Credit Card + SWIFT + ……. Consider different scenarios for your attack depending on the feature.
• What other services are shared within the network segment that the Internet Banking service is running. Can this be used to compromise the Internet Banking site. eg. different support/business/development organisations with differing security strategies/profiles.
• Consider all external supporting services within you AP. Look at internal/external DNS poisoning opportunities, mail relay, etc. What IPS’s do they use has the ISP any opportunity to access systems or supporting services which may affect Internet Banking.
• Depending on the size of the Bank, many organisation do not use the same support groups for infrastructure and the application. As a result external connections to the infrastructure may be provided for an external support organisation to administer the infrastructure.
• Look at the business and user authentication methods and paths (client side certs, secure ID, SMART Card, etc). Consider two factor authentication and modern user identification methods. eg. what is your favourite food in addition to normal usernames and passwords. Do system administration staff use dynamic passwords (secureID, etc)?
• See if the Internet Banking application sends email to users which may contain interesting information.
• Better access to the application can generally be gained after access to the system. i.e. get an legitimate account on the system. I have found that some sample/administration screens have been restricted to authenticated users only.
• Consider social engineering the Help desk to have an account password reset.