Information Technology

 TCP and UDP Port Information 

ICMP Type and Code information

Over the past few years more and more security holes have been found in and around the Android platform.  Now we have a push for more frequent updates to fix the problems, but this comes with it's own problem, as much of the android core is hard coded into the OS itself, and not easily fixable without changes to the core. 

How can this be fixed?

For Google, it would be isolation, where the Kernel, Drivers, Android, Applications, are all operating seperately from each other, this would allow any single area to be replaced without the requirement of all of the services above it to be replaced.  A single app can be configured to be used to install the default applications without them needing to be installed, and will be updated to the latest upon the first usage.  This can also update the drivers and to the latest version of Android, as long as a kernel replacement is required, it would allow for more frequent updates to Android, and other security updates, without a massive overhaul of the underlaying operating systems.

Changes that would be nice to see

Backup capability

I would like to see the ability of backing up both the complete system that doesn't require root, such as Titanium Backup, there's been many times that this has been useful in restoring data to previous date.

Security

Firewall Security, would be nice, this can be accomplished with something as a simple as including creating the permissions.  By default Android should allow no inbound connectivity.

Upgradability by for all vendor products.

One problem for Android, is that any updates may be missing on phone that are even only a few months old, and may take months if not years to be released.  This is not a problem for iPhone, because they control the hardware and the software, where android doesn't.  In the case of Android, this can be improved by creating a usermode driver model that would allow the drivers to be upgradable without a massive overall of the kernel, and the software the Android infrastructure isn't modified by the change of the driver.  This could mean Android might be on Linux Kernel 4.0 but Android could be Android P.  This is because the drivers themselves are not part of the kernel, and could lead to rapid prototyping of the drivers, and Android.

The RPZ standard  provides many actions, in response to when a trigger is activated. The triggers that are activated can be both from client requests, or the responses from the remote DNS Servers.  The actions for these, determine what the requesting client receives back from the DNS Server they are querying. The DNS server can reply with No Domain, No Data for the Domain, Whitelist, and Rewrite record. For BIND 9, there are 2 more actions available Tar-pitting and Quench.

Over the past while I have noticed a few common things for the Spam, Phishing and Malware emails.  Most of these because they are sent from Zombied home computers while often have the IP addresses in the Domain Name for site.

With Exim, I have created a couple of rules that drastically reduces the number of emails that are received.  One rule set if for on the connection phase, this will reduce the amount of traffic right at the onset so that the mail server doesn't have to process any of the traffic related to these connections.  The second though not RFC Compliant, drops after the HELO stage, again to reduce the amount of processing as possible.  Again since my mail server isn't suppose to be recieving email from any DSL or Cable connections, I personally feel this is an advantage.

Triggers operate from least specific to most specific

QNAME Trigger

The most common method of triggering RPZ, will be the QNAME Trigger, which is a trigger based on the Domain Name of the requested site. The site can must match exactly except for wildcard matching, which will only replace one level of the domain address.  The domain addresses would have the appended to the full address the name of the zone, such as www.domain.com.rpz.zone.

Examples of the domains that would be valid are:

Examples of the domains that would be invalid are:

Request IP Trigger (rpz-ip)

RPZ can match the returned IP Address for a request from the DNS Server, this could allow for an exception, or to block a site that has many Domain names assigned such as a Virtualhosting company.  Part of this format will include the prefix length for the network size, for IPv4 this is a mask between 0 to 32 and 0 to 128 for IPv6 addresses.  For IPv6 addresses, you can remove many of the "00" grouping and replace them zz.

Client IP Trigger (rpz-client-ip)

RPZ may also match the clients IP Address and will process these, designed to block ddos amplifiers or zombied clients, this will complete an action for a specific client, without obeying triggers.  This will in effect can prevent a client from resolving any addresses.

Nameserver Domain Name (rpz-nsdname)

RPZ also can provide a method of operating against the hostname of a domain server, and taking an action for any query that comes from a specific DNS Server, and any domains that this server is authoritative for.

Nameserver IP Address (rpz-nsip)

RPZ also provide a method of operating against an IP Address of a domain server, and taking an action for any query that comes from a specific DNS Server, and any domains that this server is authoritative for. (Please note in the example 8.8.8.8 is not authortative, so this entry will not work)

This is a very useful feature, not only can it provide a method of blackholing, but also to provide a method of remapping addresses for services hidden behind NAT devices.  RPZ has one major limitation, is that there are at least 4 queries for each query that is made.  The configuration isn't really that hard, but it's hard to get really good and clear information.

Each Zone file entry for RPZ can be treated as an ordinary zone, but it is recommended that you do not allow the zone to be queried from remote sites, as this would allow for a remote agent to gather information on what is blocked, this is especially useful for directed attacks.  For the RPZ zones allowing the file to be transferred to secondary servers this would allow capacity, due to the extra queries that will be made.   Doing updates, is useful for fast dynamic changes to the RPZ Zones, including from various public sites, such as http://www.malwaredomains.com/. 

Over the years, there has been many attacks and compromises of various networks, some of these are from internal attacks, others are from external agents.  Many of these attacks are in the form of attempting to gain access to an account with high enough access to give them privileges to gain access to services they require for their purposes.  In the case of Sony they were after their internal data.  In these cases the enemy agents, their main goal is to gain an account with Administrative priviledges, because these accounts give unfettered access to not just a single system but multiple system, and all the data on those systems.  These may include, but not limited to the workstations, servers, file servers.  And in the case of Windows based systems, this could give access to even Workstations and Servers that are encrypted with Microsoft's Encrypted File System.  This single all powerful account permission, gives a single attack target, and with this ability being remotely accessible it makes this an ideal target.  This account alone can not only gain access to the important information, but in some cases even hide the existance of the attack. 

So how could this be fixed?  People may believe that this cannot be fixed, but this risk can be greatly reduced, since many attacks that are not from "inside threats", occur through phishing attacks, the simplest method is to simply seperate the users account from their administration accounts, with this change it makes it more difficult from providing unfettered access.  An added level of security would to provide seperate machines for administration and day to day usage, this limits the attack plane.  But either method, requires that these administrative accounts should have the least level permissions to do their job.

A better solution though it would require a great deal more configuration, and possibly functional changes with the various operating systems, is to build a system based on Privilege seperation, each administrative account will have limited access, and cannot view or access functions outside of it's mandate.  So a user administration account, could manipulate the users account information, and provide privilege access to below this accounts privilege levels of this account, but would not have access to the file system.  The filesystem administration account would be totally unaware of detailed user information, and could not modify or user information, and would not have access to the account passwords.  Services administrator account, would give access to required file, network, and other services required to start and run the service.  The main Administrator account can only modify, create, delete the privilege administrator accounts.

Priviledge seperation would provide, a greater level of security by limiting what an administrator account can do, especially if the true administrator account is only accessible from a trusted interface, this would completely limit what can be done by any of the administrator accounts, and almost completely limit unauthorized accounts or accounts receiving unauthorized permissions.

Problem

SSL and TLS standards all have a major weakness, trust is linear.  The certificate your server is signed by one organization, that certificate is either signed by one of their own keys, or by the the key for the same certificate.  This can lead to one of the security risks if someone can compromise or falsify one of the signing keys of the trust relationships. Once this trust relationship is compromised, the attacker may use this for countless actions.

Why this proposal?

Well over the past year, there has been an increasing number of attacks against POS systems?  And this has lead me to think up what I feel is a more secure system.  The idea I have come up with, is to remove the direct storage or usage of the credit card number by the POS terminal or the vendor, while maintaining a method of credit card authentication.

Currently on SSLabs this site has an A+ Rating, but with this rating the level of support for older web browsers has been reduced.

As of this change, IE on XP is not supported, but you should be updating XP anyways.

SSL2 and SSL3 has been fully disabled.  TLS1.0 is on my list to disable

So OpenSSL has released their Project Roadmap, to many this seems to be a push in the right direction after many notable vulnerabilities in the past, which has caused at least to forks to be created. 

I have noted in the past, many issues with the OpenSSL code base, which has finally been brought to light, these consist of a constantly changing API, poor or non-existant documentation, complexity of the code, readability of the code, and the shear number of versions.

Changing API

The API in a release should never change, for any version of 0.9.8*, they API should be unchanging.  Once the version has been released no new features should be added, only security fixes.  This reduced the headache of refactoring code when some major change has occurred.  API Changes should occur in phases as well, with deprecation of previous functions occuring over a long period, this would allow for updating to newer major versions with little impact to the third party code.

Poor or Non-Existant Documentation

This is a pretty annoying issue.  There is little in the way of useful documentation, this is more of a problem for new users to using OpenSSL,  many of these questions aren't answered on the OpenSSL site at all, but are elsewhere, on potentially less reliable or trusted sites.  Now some of the questions have been answered, but still not in such a way that a lay-person could easily understand what they are doing, why they are doing it, or the potential risks?  These are such questions

• How to create a self-signed certificate?
• How to generate an SSL Key?
• How to generate an SSL Certificate Request?
• How to revoke an SSL Certificate, or Key?
• How to remove the passphrase from a Key?
• Descriptions of each encryption, random number generation, and hashing methods, and the pro's and con's of each.
• As a developer, How to use each function?  (This can also have a wrapper to simplify development, by having 1 or 2 functions that do the required steps for the developer, this means that common security mistakes can be avoided, for the less advanced)

These are all very important questions, and not always covered by the developer, but often through third party sources.  Mind you, I have noticed more information cropping up in recent months and years.  For functional documentation, the POD files generated should be on the website, and documented inline, if it isn't already.

Complexity of the Code 

The OpenSSL code is notoriously, complex to browse through with the multitude of files.  Many things should be done to simplify the code tree.

• Group together similar items in the source.
  • Encryption routines
  • Hashing routines
  • Formatting routines
  • Configuration routines
  • Platform Specific code (for adding missing functions from a platform, or Assembler code)
  • Applications
• Abstract functions to allow for a single code base to support multiple platforms, don't ifdef the crap out of the code
• Standardize on coding practices
• Code reviews
• Internal and External Audits
• Modular coding style, this would then allow for functions/features to be stripped away, with very little change to the base code, such as delete a directory, and a single line change in the base code.
• Remove the external engines, as useful as it can be, this should be part of the OS, and if you are keeping them use them as a data source for RNG not as the RNG.

A major thing is that is missing that should be implemented would be

Number of Versions

This has always been a sticking point for me, there shouldn't be the number of versions on the go as OpenSSL currently has, this creates code complexity, as a change for one might have to be back ported and forward ported to the various releases, right now there's at least 5 in development if not more. 

• 0.9.8* series that dates back to 2005
• 1.0.0* series that dates back to 2010
• 1.0.1* series that dates back to 2012
• 1.0.2* series is in Beta
• 1.1.0* is in development
• Two FIPS modules for OpenSSL

Of these 0.9.8* should have been retired awhile ago. 1.0.0* should be in a stage of critical bug fixes.  1.0.1* should be fixes and usability improvements. 1.0.2* should be still changing, with creating wrappers for the new API to port the old code to using it. and 1.1.0* should be in API flux.

Description:

The HTTP Protocol, is a Response-Request protocol, that was created for distributed, collabrative information system.  Information is formatted using HTML

Links

• Wikipedia - Description of the HTTP Protocol.
• W3C - The Standards Body for the Web Protocols

Description:

UDP port 22, was commonly used for PCAnywhere status checks upto version 7.51, but this has been changed since that version.  It is also assigned to be used by SSH, but I do not know of any server or client that uses this. 

Causes:

Currently the only known cause to see traffic to this port would be if you are running a version of PCAnywhere version 7.51 or older.  But this does not mean that Trojans may not use it.

Suggestions:

 - Upgrade PCAnywhere, if running on the network.

• ICMP Echo Reply

• If you can do it, block this protocol inbound and outbound. If this is not a possibility limit who can do it. Some stateful firewalls, will monitor outbound traffic and allow for corresponding inbound traffic, including ICMP echo request to ICMP echo reply.
• If your firewall has the capability limit the size and the ICMP codes that are considered valid, and drop the rest of the echo reply requests.
• In general, your router and firewall should disallow traffic outbound that is not from your internal network to be sent.
• Run an IDS on the network to allow you to detect these strange traffic, many can now detect this type of malware.

TCP/UDP port 0, is a reserved port, it should not be seen in the real world.  This port sometimes is used in networking programming, where the system is used to dynamically assign the next available port, though this does not work in windows programming.

• OSVDB - Information on vulnerability that caused a Checkpoint Firewall-1 to crash. 
• About -  Information regarding Port 0 from About.com.