Stefan Taubenberger
email: staubenberger@munichre.com

Jan Jürjens

Yijun Yu
email: y.yu@open.ac.uk

Bashar Nuseibeh
email: b.nuseibeh@open.ac.uk

Problem Analysis of Traditional IT-Security Risk Assessment Methods -An Experience Report from the Insurance and Auditing domain

Keywords: IT risk analysis, IT risk assessment, Security requirements

Traditional information technology (IT) security risk assessment approaches are based on an analysis of events, probabilities and impacts. In practice, security experts often find it difficult to determine IT risks reliably with precision. In this paper, we review the risk determination steps of traditional risk assessment approaches and report on our experience of using such approaches. Our experience is based on performing IT audits and IT business insurance cover assessments within a reinsurance company. The paper concludes with a summary of issues concerning traditional approaches that are related to the identification and evaluation of events, probabilities and impacts. We also conclude that there is a need to develop alternative approaches, and suggest a security requirements-based risk assessment approach without events and probabilities.

Introduction

Companies and governmental organizations are interested in detecting and mitigating the risks of possible profit and image losses. Many quantitative and qualitative methods and toolkits for Information Technology (IT) security risk analysis have been developed using, such as normal probability, Bayesian probability, Fuzzy theories, Annual Loss Expectancy (ALE), all of which are based on probabilities and events as the risk is "measured in terms of a combination of the likelihood of an event and its consequence" in the ISO 27005 standard [START_REF]ISO 27005 Information technology -Security techniques -Information security risk management[END_REF]. Estimating risks reliably with precision is difficult because of their unpredictability according to this definition: in each traditional risk assessment method or toolkit, probabilities about the events and the possible consequences have to be determined, and each of the steps to determine risk -identifying events, determining probabilities and impacts -has weaknesses, making risk assessments prone to errors, unreliable, and results questionable. The objective of this paper is to discuss the general issues of determining risk with events and probabilities within traditional approaches. We report on our experiences in IT risk assessments in the insurance and auditing domain. The main contribution of the paper is the thorough analysis of the problems of traditional risk assessment approaches based on the literature and our experiences. The paper is structured as follows: in section 2 we present problems of traditional approaches related to underlying methods and risk assessment steps. In section 3 we report on our problem experiences applying a traditional approach by hand on a real world example. We summarize the issues of traditional risk assessment approaches in section 4 and in section 5 we suggest developing alternative risk assessment approaches, such as based on security requirements and business process models.

Traditional approaches to IT-security risk assessment

In the literature many approaches for IT security risk assessment are available to researchers and practitioners. Discussions of available approaches can be found in Ralston et al. [START_REF] Ralston | Literature review of security and risk assessment of SCADA and DCS systems[END_REF], Alter and Sherer [START_REF] Alter | A general, but readily adaptable model of information system risk[END_REF], ENISA [START_REF] Enisa | Inventory of risk assessment and risk management methods, ENISA ad hoc working group on risk assessment and risk management[END_REF], and Putnam [START_REF] Putnam | Information security management references[END_REF]. We discuss these methods from the perspective of the used underlying assessment methods (qualitative or quantitative), risk assessment activities, and the selection of assessment methods. In the following, we present our critiques based on a literature review.

Qualitative and quantitative methods

Quantitative risk assessment methods use numeric probability where the probability expresses the knowledge that the event occurs. With quantitative approaches risk is determined by the probability of an event and the likelihood of a loss. Examples of use of quantitative methods are: normal probability, Bayesian probability, Fuzzy theories and Dempster Shafer theory, Monte Carlo Simulation [START_REF] Kaplan | The words of risk analysis[END_REF], Annual loss expectancy (ALE), and stochastic dominance [START_REF] Rainer | Risk analysis for information technology[END_REF]. The advantages of quantitative methods are that IT assets are identified most likely for damages [START_REF] Rainer | Risk analysis for information technology[END_REF], measures can be used for the impact magnitude and be directly compared [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF], [START_REF] Feather | Relating risk and reliability predictions to design and development choices[END_REF]. The disadvantages of quantitative methods are that there are no exact probability values of loss at the time when they are estimated and half of the estimates are statistically either too high or too low [START_REF] Rainer | Risk analysis for information technology[END_REF]. Furthermore, the probability function that usually follows a normal distribution may be deformed because it represents average values of a few extremes and many low ones [START_REF] Rainer | Risk analysis for information technology[END_REF]. Additionally, a scale has to be provided for what the value of "x" percent means [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF]. These values have to be translated to a literal meaning.

Qualitative risk assessment methods use non-numeric values or number ranges to express the risk as descriptive values [START_REF] Rainer | Risk analysis for information technology[END_REF]. Examples for qualitative methods are: scenario analysis, fuzzy metrics, questionnaires [START_REF] Rainer | Risk analysis for information technology[END_REF], preliminary risk analysis (PHA), hazard and operability study (HAZOPS), and failure mode and effects analysis (FMEA/FMECA) [START_REF] Rausand | System Reliability Theory[END_REF]. The advantages of qualitative methods are that these approaches are time and cost efficient because no exact value has to be determined and they are valuable in estimating risk approximately [START_REF] Rainer | Risk analysis for information technology[END_REF] as well as areas of improvement can be easily identified [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF]. However, the disadvantage of qualitative methods is that they are not precise as the value is expressed within a spectrum that has to be understood by all involved parties [START_REF] Rainer | Risk analysis for information technology[END_REF]. Additionally, methods provide no measurement for the impact and therefore it is difficult to conduct a cost benefit analysis [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF]. Although quantitative and qualitative methods can be combined and used together [START_REF] Zhang | A qualitative and quantitative risk assessment method in software security[END_REF], results combination and interpretation become more difficult because different rating scales, underlying assessment principles or the variances in risk weighting are difficult to mix up.

Risk determination

In internationally accepted standards or methods like Octave [START_REF] Alberts | Introduction to the OCTAVE Approach[END_REF], CORAS [START_REF] Stølen | Model-based risk assessment -the CORAS approach[END_REF], AS/NZS 4360 [START_REF]Australian/New Zealand Standards Comittee[END_REF] or ISO 27000 standards, the principal steps to determine risks are asset identification, event/threat identification, vulnerability/control identification, likelihood determination and impact analysis. Within the literature many issues of or critique on traditional approaches are provided. We can categorise all of these into three areas: identification, data and assessment.

(1) The identification category is about activities to determine, e.g. an event. A threat that uses vulnerabilities is defined as an event [START_REF]ISO 27005 Information technology -Security techniques -Information security risk management[END_REF]. The identification of threats and vulnerabilities is challenging as underlying conditions change constantly e.g. development of new technologies, new competitors, new laws, etc. [START_REF] Kinney | Research opportunities in internal auditing -chapter 5 auditing risk assessment and risk management process[END_REF], [START_REF] Jackson | NII-OU Security Workshop @ The Open University[END_REF] Therefore, threats and vulnerabilities are not static, with their behaviour and seriousness change within days. Threats and vulnerabilities are identified based on security expert knowledge, usage of security scanning tools and public available data. Security experts use implicit knowledge and experiences as well as explicit data such as vulnerability lists for the risk identification. But how do we know and how can we verify whether or not all threats and vulnerabilities have been identified correctly and completely? Furthermore, events in associated companies (e.g. outsourcing partners or inter-company process chain partners) could not be discovered as there are beyond company boundaries. However, these events could negatively affect a company as business processes and systems are heavily interconnected nowadays [START_REF] Kinney | Research opportunities in internal auditing -chapter 5 auditing risk assessment and risk management process[END_REF].

(2) The data category is about data needed for the evaluation of risks. For the impact and probability assessment of a risk, data regarding the impact and probability of event in a given situation for systems is needed. The major issues here are that exhaustive public available data of occurred events, impacts and their probabilities are not available [START_REF] Stewart | On risk: perception and direction[END_REF], and the internal historic data are not available for the estimation of possible change impacts on the company. For example, the event has not occurred in this type of industry yet, within the company or the scope in this situation. If no comparable data is available, best guesses must be used for determining the change impact and probability. But how to make such a best guess in an environment where we do know little about the basic population to determine the occurrence rates, effects or the change impacts of the events? In case that event data is available, internal data about events in companies can still be incomplete or may represent a "lucky" history [START_REF] Frachot | Mixing internal and external data for managing operational risk[END_REF] and get quickly obsolete. In addition, internal historic event data may not represent a true view and events recorded could be lower-than-average [START_REF] Frachot | Mixing internal and external data for managing operational risk[END_REF]. For example, the claims data recorded regarding the occurrence rate and extent of loss is often below the average of the reference industry or competitors. Another issue is that probability distributions get incorrect as they are based on historic data not representing event behaviour changes [START_REF] Stiglitz | Making globalization work: Global financial markets in an era of turbulence[END_REF]. For example, the 100-year events reoccur nowadays for every 10 years in fat-tailed distributions. How can we ensure or verify that the data used for the assessment based on such data is still correct?

(3) The assessment category is about activities or models to evaluate the change impacts. Risk assessment is based on the impact and the probability of the event. The models used to determine risks and dependencies are poor because co-occurrence of risks, uncertainty between event relations and different assessment scales are not considered. Co-occurrence of events within different or the same risk leads to indeterminable impacts and damages because the events might occur in associated companies that may have an impact on other risks that are not considered when they are evaluated on their own. In current methods, the assessments are performed on decomposed model elements but do not consider the organization as a whole. Furthermore, there is uncertainty between the relation of an event and the impact by its nature. For example, the impact of the event is not known or dependent on other conditions/parameters. However, side effects (multiple impacts or dependencies) or parameters are not considered and uncertainty is assessed by gut feelings or subjective security expert knowledge [START_REF] Stewart | On risk: perception and direction[END_REF]. Although safeguards put in place are considered in the impact assessment, they are evaluated for a particular threat/vulnerability, and the side effects of other events are not considered. How do we determine that safeguards are operated as intended? A systematic assessment of the safeguards regarding secure operation, secure design and effectiveness is currently missing. Furthermore, probabilities are measured by different techniques; for example, by quantitative and qualitative methods. But the comparability of qualitative and quantitative assessments of risks or probabilities within an assessment method is not validated. Furthermore, assessments are influenced by perceptions. Behavioural biases outgoing of the educational background, organizational level or positive/negative attitude of the assessor may affect the assessment of events, probabilities of occurrence or the impact estimation [START_REF] Kinney | Research opportunities in internal auditing -chapter 5 auditing risk assessment and risk management process[END_REF], [START_REF] Stewart | On risk: perception and direction[END_REF], [START_REF] Redmill | Risk analysis -a subjective process[END_REF]. In addition, current risk assessment proceedings lead to simplification and are focused to strong on technical issues rather than on information or business issues [START_REF] Gerber | Formalizing information security requirements[END_REF]. For procedural reasons the assessor will usually simplify otherwise he will be lost in detail and forget the objectives [START_REF] Halliday | A business approach to effective information technology risk analysis and management[END_REF]. Additionally, methods follow the waterfall model and therefore are not capable of considering changes during the lifetime of the assessment [START_REF] Vidalis | A critical discussion of risk and threat analysis methods and methodologies[END_REF].

Selection and classification of IT-security risk assessment methods

In the literature many approaches for IT security risk assessment are available by researchers and practitioners and in general "published work related to risk assessment is very difficult to categorize." ( [START_REF] Ralston | Literature review of security and risk assessment of SCADA and DCS systems[END_REF], p.6) and "There are more than 200 risk management methods making it a challenge to select the most adequate one" ( [START_REF] Matulevius | Adapting Secure Tropos for Security Risk Management in the Early Phases of Information Systems Development[END_REF], p.1). These difficulties to categorize and select an appropriate risk assessment approach arise because the risk assessment process consists of different phases namely: risk identification, risk analysis, risk assessment (evaluation and ranking) and risk management (treatment and mitigation), and developed approaches cover different phases as well as concentrate on different aspects, problems or business areas. An issue in classifying approaches is to determine how much of the risk assessment process is covered by the proposed approach. Another issue is the great variety and profundity of the approaches and their description how they perform and to apply in a given situation. Researches tried to classify approaches like Campell and Stamp [START_REF] Campbell | A classification scheme for risk assessment methods[END_REF] who provided a classification scheme consisting of two dimensions "level" and "approach" divided further into subcategories, however lacks a classification regarding the elements of the risk assessment approach. The five basic classes used by Siponen [START_REF] Siponen | An analysis of the traditional is security approaches: implications for research and practice[END_REF] misses any further distinguishing characteristics and are therefore not expedient for a classification. In an ENISA working group paper [START_REF]ENISA 2007-2008 ad hoc Working Group on Risk Assessment/Risk Management. Determining your organization's information risk assessment and management requirements and selecting appropriate methodologies[END_REF] as well as in the thesis of Poettinger [START_REF] Pöttinger | Self assessed risk management[END_REF], risk exposure, risk impact and impact segment are used to determine the most appropriate risk assessment methodology. Although Spider diagrams are used to compare the methods with organizational requirements, currently there is no general accepted and proven classification scheme in existing approaches. Further on, developed or criticized approaches are typically not classified or categorized making it hard for researches to apply the approach in the correct setting or to select the most appropriate one.

Our experiences with traditional approaches

In Information System (IS) audits as well as for providing insurance cover for business interruptions auditors have to evaluate IT risks. They evaluate IT systems, processes and risk prevention capabilities. The purpose of these risk assessments is to determine significant risks that are associated with the design, implementation and operation of IT systems of a company. The audit committee or the insurer commissions these assessments. The audit team presents these significant risks to the management or underwriters and reports to the audit committee or insurer. The significance of risks is determined qualitative by the impact of the threat and the results are used to decide about risk acceptance/ mitigation or about insurance cover. However, auditors face the problem that data about events, probabilities are rarely available in public or in the company assessed. Furthermore, these audits have to be cost and time efficient and the results should be reliable regarding future events to acquire profitable business as well as for the annual financial statement.

IT-security risk assessment with a traditional approach

In this section we describe the context and the results of applying a traditional approach on a simplified real world example. Context: We have applied a proven traditional approach such as [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF] more than ten times to determine IT security risks in subsidiaries and branches of a reinsurance company within audits as well as at companies that applied for business interruption insurance. These assessments conducted by an IT auditor and an independent security expert, focus on IT management, systems, and normally last one week. The assessment team is independent of the IT operation or IT management of the assessed company or branch. IT departments of different sizes and organizational forms were assessed. In a centralized environment the assessments stopped at the service interface; however service quality and service agreements were considered. Approach selection: We selected the NIST 800-30 approach [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF] because it is well known and documented, learnt in less than three days [START_REF] Buyens | Empirical and statistical analysis of risk analysisdriven techniques for threat management[END_REF] and the tendency to rate threats as medium or low [START_REF] Buyens | Empirical and statistical analysis of risk analysisdriven techniques for threat management[END_REF]. Especially, the tendency to have a few high risks is important to direct management/companies efforts to the most critical issues. Limitations: With risk assessments not all risks may be identified neither can we guarantee that. However, we adjusted our assessments to identify significant risks regarding best practices within a confidence level of professional experience. The following is a simplified real world example: The main sales channel of an internet retailer for clothes is their online web store. The customer has to provide all shipping and payment data before an order via the online store is processed. Customers can make payments by credit card or on delivery. After providing and verification of all necessary data, the order is stored and processed. The web store is a web application with a connected database containing all order data and has an interface to a third party service to verify credit card data. As we have thorough knowledge about vulnerabilities, we know that the web application has an SQL injection problem and an encryption problem in the communication with the costumer and third party service. An IT security risk assessment with a traditional approach such as [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF] would proceed with asset-, threat-, vulnerability-and impact-analysis to determine risks.

(1) Asset identification and analysis: Hardware, software, data, people have to be identified as well as their criticality or value to the organization. In our example we identified the online web store, the external service provider, customer, credit card and order data. People involved include customers and order handling personnel.

(2) Threat identification and analysis: All potential threat sources have to be identified. We identified natural disaster threats such as tornados, floods and earthquakes, and human behaviour threats from hackers, computer criminals, terrorists or espionage and insiders/disgruntled employees. Technical threats include blackouts, fire, and chemical pollution.

(3) Vulnerability identification and analysis: All weaknesses that can result in security breaches in the system security procedures, design or operation have to be determined. A system design analysis revealed that the web server application has an SQL injection problem and that the communication with the database is unencrypted. The external service provider was not analysed as an external report showed no vulnerabilities. Employees were not considered as vulnerable as there is no customer contact and no indications of disgruntled employees. (4) Likelihood determination and impact analysis: The impact and the likelihood of a successful security breach have to be determined with regard to the criticality of the asset. The probability ratings were defined as low (0-30%); medium (30-70%) and high (70-100%). The impact scale was defined as low (<1 million Euro), medium (1 to 5 million Euro) and high (>5 million Euro). Natural disaster threats were not considered because the data centre is not exposed and estimated probabilities are < 1 percent. The power blackout from the technical threats was rated as probable (low) but with low impact. Fire is no risk as it is treated by a sprinkler system. Chemical pollution was rated as unlikely. The web server encryption issue was rated with low probability for criminals, medium for hackers and the impact was rated medium for both. The web server injection issue was rated with low probability and medium impact. Terrorists and espionage was not considered because the business is not critical. Table 1 shows some of the risk ratings.

Methodological and Estimation problems

In the following we describe general and probability estimation issues we experienced by applying the steps of the NIST 800-30 [START_REF] Stoneburner | NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems[END_REF] approach. In the asset identification phase, the business process is decomposed into single elements. But any dependencies between elements are neither considered nor modelled. In the threat and vulnerability identification phases the main problem is uncertainty. We do not know whether the threats listed or the identified vulnerabilities are complete and comprehensive and how to verify them. We are dependent on publicly available data and the assessor knowledge and experience. For the likelihood determination and the impact analysis of threats there is no detailed guidance available. For example, NIST 800-30 does not describe how to link threat sources with vulnerabilities and how to derive or evaluate any probabilities. Our probability estimates may not represent a true view as the behaviour of attackers and defenders changes. The aggregation of probability values causes further problems as the probability of occurrence might be misrepresented. In addition, the consequences and the existence of misestimating are not considered. Misestimating or unknowingly influenced assessors [START_REF] Stewart | On risk: perception and direction[END_REF] as well as the existence of ambiguity and the aggregation of risk creates an estimation risk that is not considered. As a result, events and impacts may be under-/over-represented.

In what follows we demonstrate the divergence of probability estimates. Therefore, we try to verify our probability ratings of section 3.1. We attempt to determine the probability that a malicious user exploits the encryption weakness of the web server and the probability not exploiting any weakness. For determining these probabilities the following parameters should be considered:

 Number of known exploits and not secured exploits for the web server version: Determinable by publicly reported bugs/vulnerabilities and a security analysis.  Criticality of exploits: Determinable as exploits are rated.  Detection rate of all vulnerabilities by malicious user: Not determinable as the ratio is dependent on the knowledge of vulnerabilities, the used/ available tools and number of exploits/ vulnerabilities available.  Number of users: Determinable by page views and IP-address matching.

 Ratio of successful exploiting: Not determinable as the ratio is dependent on malicious user's knowledge, the complexity of vulnerabilities as well as the motive, resources and time of the malicious user.  Relation of friendly and malicious users accessing the web server: Not determinable and dependent on e.g. popularity of the company, monetary gain.  Impact of controls: Is implicitly considered in the successful exploiting ratio.

Fig. 1. Dependency tree with probability ratings

A parameter tree showing dependencies and assigned probabilities values for our example in section 3.1 looks like figure 1. The percentages in the probability tree were assigned by us based on available data and estimates. The probabilities for events as asked in the beginning are as follows, if one computes the probabilities down the probability tree for a hacker or a criminal.

 A criminal exploits the encryption weakness in the web server in 0.144%.  A hacker exploits the encryption weakness in the web server in 0.384%.  A malicious user exploits the encryption weakness in the web server in 0.528%.  The likelihood that a malicious user does not exploit any weakness is 97.36%. The values express the probability of occurrence of exploiting the vulnerability by a malicious user. Notice, that there a major discrepancy between the results of section 3.1 and this calculation. These result variations maybe caused by us because of bad estimates or mistakes. Therefore, we also tried changing ratios besides the variations while we recognized the following: Dependencies: There is a direct dependency of the result to single parameters e.g. a reduction/increase of one parameter from 5 to 10 (100 percent change) leads to a reduction/increase of the result in the same percentage. We recognized that the percentage of misestimating is relevant not the absolute amount. Baseline: The total population has to be specified because a, for example, 12% or medium probability has no significance. This is especially important when populations are linked like the malicious users to normal user's ratio. Probability: In a chain of parameters the total probability inclines against 0 or 100 percent as it is below or above the minimum or maximum values. These high or low values blur the total probability exceptionally. Tree diagram: Generally, it is difficult to determine the dependencies of parameters, the correct tree diagram and to verify the diagram as there is no data available. Perception: The perception of the results is dependent on the probability question and the result value. A higher percentage and positive statement (e.g. an event is 80 percent likely instead of 20 percent unlikely) is assumed to provide more confidence.

Result presentation and perception

Traditional approaches present risks as threats or threat diagrams. Categories such as high, medium and low indicate the severity and probability of the threat like shown in table 1. However, without further information, like basic population, countermeasures costs, required security, and effects on operations and the security of the application, data or transaction, a reasonable decision on risk mitigation or acceptance is hardly possible. Furthermore, the decision on risk mitigation or acceptance is a second assessment influenced by subjective factors and on individual's perception of risk [START_REF] Stewart | On risk: perception and direction[END_REF] representing constraints to countermeasure implementation. Risk attitude and perception: The perception of risk is influenced by e.g. personal experiences, media, social groups [START_REF] Stewart | On risk: perception and direction[END_REF] as well as a person's risk attitude -risk taker vs. risk aware person. Frequency: Countermeasure implementation is dependent on costs, impact, probability and frequency. But the frequency in a period of time is not specified in the risk analysis results. Cost objectives: The implementation of measures depends on company internal cost objectives as personal or departmental objectives may not be accomplished. Furthermore, measures that are not planned in the current year budget may not be implemented immediately. Prioritization: Business critical projects or security issues in daily operations have a higher priority than proposed countermeasures as an event has materialized.

All these factors are influencing the overall assessment results and arise due to the representation of risk and the possibility to interpret results. As a result the optimal security level is not achieved and the company's security standard was defined, changed (without notification) or violated by the acceptance of risk.

Problem analysis -summary

In the literature review as well as through our experiences we have identified a number of issues related to used methods and activities in traditional risk assessments. Methods: Quantitative methods base on data that is not reliable available in practice with a certain precision and qualitative methods provide results within a range with deviations that have to be interpreted. Interpretation is subject to misjudgment and the selection of an approach in a given situation is not supported by any of the developed methods making it difficult to choose the appropriate approach. Guidance and identification: Current standards are missing guidance on likelihood determination, event correlation and linking of threats, probabilities and impact. However, such guidance would be highly beneficial for risk analysts. The concept used for identification of, threats, vulnerabilities or correlations "you know one when you see one" applied in most methods does not work on new risks as this concept is based on implicit experience, thresholds and occurred damages. Dependencies: In current approaches, the assessor conducts the risk assessment on decomposed single model elements. However, that proceeding neglects design or interrelated risks as well as organizational coherences. Probabilities: The assessor mostly estimates probability values in assessments, as there is no reliable and true data. But estimates are mostly biased, statistically incorrect or the data base of the distribution might be incorrect because of behavioural changes or a "lucky" history. In addition, we experienced that already small derivations or unconsidered parameters such as the timeframe or total population have a material impact on the result. There is no feasible way to verify the correctness and completeness of probability dependencies (tree) and positive and high probability statements are perceived as more trustworthy by people. Assessment: Assessments are conducted on uncertainty regarding events, probabilities and impact. However, uncertainty, co-occurrence as well as dependencies are not modelled and properly considered. Furthermore, assessments are specific to a point of time not considering environment changes or prevention capabilities of the company. Risks results: We experienced that low and a few medium risks were not mitigated because of personal and company specific constraints such as perception, cost objectives and prioritization of activities. Furthermore, the impact on the companies security level or polices is not appropriately considered when risk is accepted. Environment: To identify and to determine events, probabilities and impacts correctly we must have comprehensive knowledge about the environment of the risk, the company and outside world. This would require that all parameters, corresponding probabilities, the basic population as well as correlations are known, are immediately updated, base on enough statistic data and could be modelled. But comprehensive knowledge about the environment is not available, may be compromised, cannot be verified and cannot be modelled as the real world is too complex and unpredictable. This applies to all risk assessments and is not specific to our problem domain. Furthermore, risk is about people. Their behaviour is not objective or rational, may follow personal interests or herd-instincts and be biased.

Conclusion

Due to the nature of risk -its unpredictability and complexity -risk assessment is difficult. Our problem analysis of traditional approaches based on the literature and our experiences in the insurance and auditing domain showed that such issues like uncertainty, wrong estimation and perception are mainly associated with determining events, probabilities and change impacts, affecting adversely the risk results. We therefore suggest that future approaches should attempt to determine risk by alternative concepts. One possible and promising direction is to use security requirements (SR) [START_REF] Gerber | From risk analysis to security requirements[END_REF], [START_REF] Houmb | Developing secure networked web-based systems using model-based risk assessment and UMLsec[END_REF] not only for determining the impact of a threat or the seriousness of vulnerabilities but considering organizational needs in the risk assessment. An alternative risk assessment approach with SR could manage to determine risk without using events and probabilities and considering the organizations capability to handle and prevent events. This could be achieved, for example, by specifying the business process data security needs and by evaluating these requirements by hand of process model activities concerning the actors related to the system. Security requirements and corresponding security controls are evaluated at individual process activities for validating whether or not the system implementation, the actor's process activities (operation) and the process design adheres to the requirements. In addition to business process evaluation, IT process maturity and performance are evaluated to detect weaknesses, to determine operating effectiveness and prevention capabilities. The IT process evaluation results can be used to evaluate the adherence of business process data security requirements from an infrastructure perspective as well as to indicate the time invariance of the risk results. However, to determine risks only using security requirements without having to determine events and probabilities would lead to a redefinition of risk as "the non-adherence of security requirements thereby causing harms to the organization regardless of a point in time". An advantage of such an approach would be that assessment results are more time independent and results probably more accurate and linked to organizational security needs. Before developing such an approach we believe we need a better understanding of the interaction of security requirements, risk treatments, risks, assets and assurance as a foundation. We are confident that a security requirement based approach has the potential to overcome the limitations of traditional approaches and we hypothesise that an entity would face no substantial risks from any events/threats if the evaluated security requirements have been adhered to.

Table 1 .

 1 Risks and risk ratings in our scenario.

	Traditional approach
	Risk	Probability	Impact
	Power Blackout	Low	Low
	Web server encryption criminal	Low	Medium
	Web server encryption hacker	Medium	Medium
	Web server SQL injection	Low	Medium

Acknowledgement. Supported, in part, by the EU as part of the SecureChange project and SFI grant 03/CE2/I303_1.


Raz Abramov

Amir Herzberg

TCP Ack Storm DoS Attacks

Keywords: Denial of service, TCP, secure network protocols

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Most works in cryptography today adopt the all-powerful Man In The Middle (MitM) attacker model. The MitM attacker controls all of the traffic in the channels under him, with the ability to see, block and modify any package in the channel. In contrast, most works on Denial of Service (DoS) attacks, investigate the damage which much weaker attackers can cause, in order to focus on the most feasible and realistic attacks. Such weak attackers may only have the ability to send spoofed packets, or even weaker abilities -sending raw packets, sending only well-formed packets, or even merely issuing HTTP requests (e.g., puppets, see [START_REF] Lam | Puppetnets: Misusing web browsers as a distributed attack infrastructure[END_REF]).

In this work, we present and investigate the Weakling In The Middle (WitM) attacker model. The WitM attacker can eavesdrop on communication, but with significant limitations, mainly: eavesdropping only to one side of the connection, and receiving only a small percentage of the packets sent. These limitations are inspired by real-world wireless eavesdropping abilities, especially to open wireless networks; the 'one-sided' limitation is due to the fact that often the attacker is only able to eavesdrop to communication from the access point, and the low percentage is due to the weak reception by a remote eavesdropper. Open wireless networks are becoming more and more common, whether its in restaurants, malls or even as a city-wide infrastructure [START_REF] Wong | Sharing wireless internet in urban neighbourhoods[END_REF]. Attackers today can eavesdrop on public networks from a distance without the need for special equipment, and with poor reception quality (capturing low percentage of packets). It is widely known how to make a directional('Yagi') antenna, that can reach up to 12 miles of range and cost no more than a few dollars (see [START_REF] Chandra | How To Make A WiFi Antenna Out of A Pringles Can[END_REF] or numerous web pages).

In addition to their limited eavesdropping capabilities, WitM attackers can also send spoofed packets to the network. This ability is very common, since many ISPs fail to properly deploy Ingress filtering [START_REF] Borella | Realm Specific IP: Protocol Specification[END_REF]. However, we restrict the number of packets that the attacker can send into the network per attack; real attackers will try to restrict the number of packets they send, in order to stay hidden and avoid capture. Note also that sending few packets per attack increases the number of attacks that the attacker can perform simultaneously. These aspects are similar to the stealth attacker model of [START_REF] Herzberg | Stealth DoS attacks on secure channels[END_REF].

We present several 'Ack-Storm DoS Attacks' that, by injecting (two or more) packets into an existing TCP connection, cause a long exchange of TCP packets between a client and a server, terminated only by connection reset or packet losses. This way enables a WitM attacker to disrupt services to local and regional junctions in the Internet infrastructure, as well as well as to individual web sites and services.

The Ack-storm behavior of TCP has been mentioned before in [START_REF] Joncheray | A simple active attack against TCP[END_REF] and [START_REF] Wu | A survey of attacks and countermeasures in mobile ad hoc networks[END_REF] as a side effect of TCP hijacking attacks, and thus as something to be minimized and prevented.

We present a typical scenario in Fig. 1, with a client Alice connected to an open wifi network AliceNet. Alice is connected to a remote web server Bob, over a standard TCP based connection, such as HTTP, SSL etc. The attacker (Eve) has two abilities: eavesdropping and spoofing. Eve has a receiver antenna, with which she able to eavesdrop on (a small percentage of) packets sent by the access point over AliceNet. Eve in not able to inject packets into AliceNet, because of the long distance between them. Eve is also able to send raw packets into the Internet via its ISP. We assume that Eve's latency to both Alice and Bob is higher than the latency between them. Also, Eve cannot delay, drop, or otherwise affect any traffic sent in the network.

The Ack-storm attacks are based on the fact that, upon receiving a packet with the acknowledge number field (the receiver's sequence number) larger than the one sent by the receiving client, the client must, according to the TCP standard [START_REF] Postel | Transmission Control Protocol[END_REF], resend the last sent acknowledgment packet to the other side, and discard the received packet. A design flaw in TCP causes the client and the server to be trapped in an infinite loop of sending and receiving empty acknowledgment packets.

The basic attack -Two Packets Ack Storm, as performed by the attacker, consists of three main stages:

1. Pick up (at least) one packet from a TCP connection between a client and a server. [START_REF] Sherwood | Misbehaving TCP receivers can cause internetwide congestion collapse[END_REF] 251.6 Client Smurf [START_REF] Vaughn | DNS amplification attacks[END_REF] ≤ 1000 Spoofer DNS Amp. [START_REF] Vaughn | DNS amplification attacks[END_REF] 73 Spoofer Fig. 2. Comparing DoS Amplification Attacks 2. Generate two packets, each addressed to one party and with sender address of the other party (i.e. spoofed). The packets must be inside the TCP windows of both sides. The packets should have content -at least one byte of data. 3. Send the packets to the client and the server at the same time. The connection will then enter an infinite loop of sending ack packets back and forth between both parties.

The N -packets Ack Storm attack and the Everlasting Ack Storm attack offer further amplification to the Two-packets Ack Storm attack, consuming more bandwidth and increasing the duration of the session. In our experiments, we measured an amplification factor of over 400,000, when performing the Everlasting Ack Storm attack -the highest amplification rate measured until today (see Fig. 2 for comparison with existing amplification attacks).

Contributions. This paper presents the following contributions:

1. We present the WitM attack model and demonstrate how a WitM attacker can preform DoS attacks. 2. We present the Ack-storm DoS attacks. These are powerful attacks, requiring low resources (low probability to intercept packets from the network, low bandwidth requirements) from the attacker and providing the highest amplification factor measured until today.

The Ack-storm DoS attacks demonstrate an advantage of the use of IPSec

over the use of TLS/SSL. SSL connections are vulnerable to the Storm attacks, and even help the attacker target the servers and not the web proxy. IPSec, on the other hand, is immune to the attack, as it does not reveal TCP connection details to an eavesdropper attacker.

Two-Packets Ack-storm Attack

In this section we present the flaw in the TCP standard that enables the Ackstorm DoS attacks, describe the Two-Packets Ack-storm attack and explain the strengths and weaknesses of this attack.

The TCP RFC Flaw

The TCP RFC [START_REF] Postel | Transmission Control Protocol[END_REF] defines all states and actions in a TCP connection. According to the RFC, the way to handle false data is, usually, to drop the packet. This behavior is recommended as it does not allow an attacker to trigger a response from either party by injecting false packets into the stream. However, there is one exception: When a TCP connection in ESTABLISHED state, and a packet is received with an ACK field that acknowledges data not yet sent, the client must act as follows (described in page 71 of the RFC):

1. Send an ACK (the last sent).

2. Stop processing ('drop') the segment. In particular, ignore the payload in the segment.

Sending an acknowledge packet in response to a malformed packet is not recommended -as such packet is clearly not a result of normal traffic. This behavior is what makes the Storm attacks possible.

Attack Description

To initiate the Two-Packets Ack-storm the attacker sends two packets containing data: one to either side of a TCP connection. The attack uses the RFC flaw described above in order to cause the client and server to send false acknowledgment packets back and forth. No additional data could be sent once the attack takes place: every packet sent from now on will contain ack number higher then the one the receiving party has, and hence will only cause generation of another (malformed) ACK. If either side trys to send additional data over the channel (assuming the TCP send window is not full), the packets will increase the strength of the attack by creating additional 'sub sessions' of acknowledge packets (additional explanation can be found in the next section). Since according to the standard such packet must be dropped, and its data discarded, neither side can increase its sequence number, making it impossible for the sequence numbers to re-synchronize.

Figure 3 demonstrates the message passing between the client, server and attacker. By sending packets to both sides simultaneously, the attacker raises both the client and server's reserved ack numbers. This will make it impossible for them to overcome the false data sent, as all packets sent from that point will be considered false due to the ACK field being too high.

By sending a minimum of two packets, the Two-Packets Ack-storm attack can cause hundreds of thousands of acknowledgment packets to be sent over a Fig. 3. The Two-Packets Ack-storm attack. Numbers are for illustration only. The attacker sends both the client (impersonating as the server) and server (as the client) a message with length 10. Both sides send an ACK, while advancing their ACK number by 10. When the packets arrive at the other side, they contain an ACK field higher than the actual data sent. The client and server then send (according to the standard) the last ack sent by them, which triggers the loop all over again. single TCP session. The figures, presented in the experiments section (Tab. 2) show that by sending only two packets, each with the minimal length of an Ethernet packet size (64 bytes), we can cause an amplification factor of over 261,000 times the original sending size.

The attack scenario is illustrated below (and in Fig. 3 The behavior in step 3 is performed again. 5. The loop continues when both parties keep receiving packets with an ACK larger than their sequence numbers, stopping only when both packets are dropped, or when one side reaches a timeout and ends the connection by RST.

Analysis

The attacker sends one packet to the client and one to the server, both with length of the minimum Ethernet packet size -64 bytes. Each of the two packets sent by the attacker causes ACK packets (each of length 64 bytes) to be sent back and forth until the connection is terminated by the server, after T ime R seconds. We are using the fact that the minimal length of an Ethernet packet is 64 bytes, while the size of an empty TCP packet is only 60 bytes. This allows the attacker to send up to 4 bytes of data without adding to the length of the packet.

The two packets sent at the beginning of the attack are sent back and forth between the client and server, creating two 'sub sessions' of traveling packets. The attack continues until a RST packet terminates the attack after the maximal number R of retransmissions is sent; let T ime r denote the time of the r th retransmission (and T ime R the time of the last retransmission before reset). During the total time of the attack, i.e., (T ime R ), these two 'sub sessions' of packets would have caused a total of 128 × R ρ bytes sent, where ρ denotes the round trip time (RTT). Notice that the shorter ρ (the RTT between the client and server), the more effective the attack.

Since the attack interrupts an active session, altering the sequence numbers as it does so, acknowledgments of already sent packets are dropped. Therefore, the unacknowledged packets will be retransmitted by the sender. Since no retransmission will succeed, the sender will eventually give up and abort the connection.

Table 1 shows the retransmission scheme of Apache web server -the most common web server in the Internet today. Transmission times are all based on our experiments. From the table we can see that after T ime R =225 seconds the server resets the connection. The server would have retransmitted ten times, in each the time waited between retransmissions is roughly doubled 1 . Each retransmission packet that the server sends contains an acknowledgment number higher then the client's actual sequence number. Therefore, each retransmission attempt that the server sends starts a new 'sub session' of acknowledge packets sent between the client and server. Since the server makes 10 retransmission attempts, by the end of the last timeout there are 13 'sub sessions' of packets traveling back and forth. We mark T r = T ime r -T ime r-1 1 The retransmission policy of Microsoft IIS server is different: an IIS server will attempt a retransmission once every ten seconds, and initiate a connection abortion after sixteen unsuccessful retransmission attempts. In the analysis, we use the Apache retransmission properties, since it is more common, but the calculation could easily be modified to fit IIS (and other servers).

as the current retransmission duration, ρ being the RTT, R the maximum retransmissions before connection abortion (for Apache R=11). The amplification factor that the attacker achieves, with the first retransmission sent roughly at the beginning of the attack, is therefore:

Amp T wo (R, T, ρ) = 1 2 × R r=1 T r ρ × (r + 2) (1)

Experiments

In this section we present the results achieved both when we tested the Two-Packets Ack-storm attack in the lab, and when we tested the attack on popular sites in the Internet. We tested the attacks on both HTTP and HTTPS sites, using both Apache and IIS web servers. The results from the experiments can be seen in Table 2. In the tests we measures the RTT to the site, the number of packets the attack generated and the time passed until the server reset the connection2 . In Tab. 2 we can see that while attacking sites running Apache, the time until termination of the attack remains constant -225 seconds. This value is the connection abortion after maximum failed retransmissions. Once the attack takes place, no data is acknowledged in the session. That causes the server (usually the one sending the data over HTTP sessions) to retransmit the data 10 times, when each time the retransmission timeout doubles. Table 1 shows us the times of the retransmissions in relation to the beginning of the attack, and the termination of the connection occurred after the 10th timeout expired. The Two Packet Storm attack presents a substantial amplification factor to the data sent by the attacker. The attack, however, has two main limitations:

1. The attack causes a constant number of 'sub sessions' , consuming a limited amount of network resources. If an attacker wishes to attack a high bandwidth target, he would have to use a large number of connections. 2. This attack is time limited, since a server will terminate the connection after reaching the maximum failed retransmissions attempts. After T ime R seconds, the server will abort the connection, terminating the attack in the process. In order to attack a target for a time larger than T ime R , he would have to start new attacks to replace the old ones.

In the following sections we present two variations of the Two-packets Ack-storm DoS attack, which address the limitations described above.

The N -packet Ack-storm DoS Attack

The N -packet Ack-storm DoS attack enables the attacker to increase the number of packets sent over an attacked session. When using the N -packets Ack-storm DoS attack, the attacker can consume all of the bandwidth available for the session.

By Injecting additional ack packets to an attack already in progress, the attacker increases the bandwidth consumed by the attack. For every additional acknowledgment packet the attacker injects into the stream, another 'sub session' is created, and the client and server start passing the packet between them. This method bypasses the latency limitations of the client and server, since more 'sub sessions' simulate a shorter distance between the client and server: for the affective RTT to decrease by 0.5, the attacker doubles the number of 'sub sessions' in the connection.

Analysis

In order to maximize the effectiveness of the additional 'sub session' he creates, the attacker sends the additional Storm packets at the beginning of the attack. The number of 'sub sessions' at the end of the attack, for 2 packets sent in order to trigger the attack, N additional Storm packets and retransmission generated packets is 2 + N + R. The amplification achieved would be, for R maximum retransmissions and 64 bytes acknowledgment packet length:

Amp N (N, R, ρ) = 1 2 + N × R r=1 T r ρ × (r + 2 + N )
The attack minimizes the sessions needed to reach a high bandwidth consumption. Using storm packets, we were able to trigger 485,000 packets sent over a single session (with Yahoo.com), when the Two Packet Storm generated only 50,000.

When reaching the bandwidth limitations of a connection, packet losses will start to occur. Each packet loss will end the 'sub session' of that packet in the stream, while the rest of the 'sub sessions' will continue executing.

Table 3 presents the amplification results when attacking Yahoo.com. Number of packets increases as a function of packets sent, until reaches a point where packets losses start occurring (at about 42 Storm packets sent). Notice that packet losses do not stop the attack, but only limit the maximum bandwidth it can consume. We did not send over 42 packets in order to avoid causing real harm to users in the network, as would result from causing congestion on a live network). While bandwidth consumption increases as a function of the Storm packets sent, the amplification factor decreases. The attacker has to send an additional packet for every 'sub session' he wants to create, but the number of retransmissions (and the number of 'sub sessions' they create) remains the same. The disadvantage of lower amplification factor is balanced by the lack of need to manage multiple attacks in order to achieve the same amount of bandwidth usage.

Everlasting Ack Storm Attack

The main limitation of the two attacks presented so far is the the maximal connection duration T ime R . The attacker can avoid a connection abortion by artificially sending data over the channel, preventing the client or server from reaching a timeout. The Everlasting Ack Storm data packets should contain at least one byte of data, which will not add to their size because it is below the Ethernet packet size minimum. The packets should be sent at least every T ime R seconds, in order to avoid the timeout. When data is being sent over the connection (however considered retransmission by both the client and server), the connection timeout is not triggered, allowing us to continue the attack until reset by application layer or any other network entity.

Analysis

The number of initial packets sent by the attacker is the same as the Two Ack Storm attack. The additional packets are sent every T ime R seconds in order to maintain the connection. The amount of total data sent over the channel is composed of the initial T ime R seconds, in which the amount of packets is identical to those of the Two Packet Storm attack, and the following minutes, in which the attack continues with the number of 'sub sessions' increases for every storm packet sent. The amplification achieved when sending Eve R storm packets (for R maximum retransmissions of server):

Amp ∞ (R, T, ρ) = 1 Eve R × R r=1 T r ρ × r + 2 + Eve R r=R T ime R ρ × (r + 2)
In Tab. 4 we show the different abilities the attacker can achieve by using the attacks described above. Notice that the amplification factor when sending storm packets without data decreases, but the total bandwidth increases as a function of the packets sent. Also notice that when sending storm packets with data, the attacker increases both the duration of the attack (by avoiding timeout), and the bandwidth consumed by it (as it opens another 'sub session' )). Using Storm packets with data, sent every 1 minute, we maintained an attack on Google.com for over 26 minutes, causing over 10,000,000 packets (over 640,000,000 bytes of data) to be sent before terminating the connection -an amplification factor of 400,000. We terminated the attack as part of our policy to avoid causing damage to the attacked sites.

Preserving the Attack During Losses

When the attack reaches the bandwidth limitations of the channel, packet losses start to occur. For every dropped ack packet, one 'sub session' is stopped and the attacks consumed bandwidth drops by 64 ρ Bps. In order to maintain the bandwidth of the attack, the attacker must generate an storm packet for every dropped ack packet.

When a TCP connection encounters losses, the TCP window size decreases rapidly. In the full version of the article, we present an experiment demonstrating the depredation in TCP bandwidth when performing an attack.

Conclusion and Future Work

In the article we presented the the WitM attacker model. We showed the Storm attacks, which can cause DoS to network infrastructure, as well as individual web sites and services. We showed both in analysis and in experiment results the high amplification factors the Storm attacks achieve.

The Storm attacks are just the beginning of a wide rage of attacks possible for the WitM attacker. Zombie-based DoS attacks can be accomplished by a WitM without the need to control the node itself, but only by using its connection details. Injection attacks are also possible to the WitM attacker, however the ability to inject the data in the correct timing requires further work, due to the high latency the attacker has. Finding additional DoS attacks and uses for a WitM attacker will add additional impact for the WitM attacker model.

Fig.

  Fig. 1. Example attacker model -Alice is connected through the wireless access point AliceNet, to a remote web server Bob. Eve is able to receive occasional traffic from Alice's network. In addition, Eve's ISP does not filter traffic, so Eve is able to send spoofed packets to the Internet.

  ); to illustrate, we assume initial values of A.SEQ = 1000(= B.ACK), and B.SEQ = 2000(= A.ACK). 1. Eve sends A and B packets of length 10, each on behalf of the opposite side. 2. Upon receiving the packet, A advances A.ACK to be 2010, and sends an ack to B. B advances B.ACK to be 1010 and sends an ack to A. 3. When B receives a packet with A.ACK = 2010, when B.SEQ = 2000, he acts according to the standard: discards the packet and re-sends A the ack (in which B.ACK = 1010 > A.SEQ). A does the same, as it received a packet from B with B.ACK = 1010. 4. Both A and B receive packets with the ACK number bigger than their SEQ.

Fig. 4 .

 4 Fig.4. Attack results when attacking various Apache-based sites (T imeR = 225), in comparison to analysis. We measured the number of packets sent and compared to the analysis. The graph shows the correlation between the analysis results, and the ones achieved in real attacks. Differences can occur due to packet loss/duplication, retransmission time deviations etc.

Fig. 5 .

 5 Fig. 5. The N -packets Ack-storm DoS attack. The storm packets sent by the attacker are in bold. Every new packet triggers another 'sub session' of acknowledge packets sent back and forth.

  1. Example attacker model -Alice is connected through the wireless access point AliceNet, to a remote web server Bob. Eve is able to receive occasional traffic from Alice's network. In addition, Eve's ISP does not filter traffic, so Eve is able to send spoofed packets to the Internet.

	Attack	Highest Ampl.
		Measured Attacker
		Ampl.
	Two-Pkt	261, 000 WitM
	Ack
	Storm
	N	261, 000 WitM
	Ack
	Storm
	Everlasting 400, 000 WitM
	Ack
	Storm
	Opt Ack

Table 1 .

 1 Apache Server Retransmissions During the Attack

	Retr. Attempt (r)	1	2	3	4	5	6	7	8	9	10 R=11
	'sub sessions'	3	4	5	6	7	8	9	10	11	12	13
	T imer(sec.)	0 0.24 0.68 1.56 3.32 6.84 13.88 27.96 56.12 112.44 224.88
	T imer -T imer-1 (sec) 0 0.24 0.44 0.88 1.76 3.52 7.04 14.08 28.16 56.32 112.44

Table 2 .

 2 Comparison of 2-Packet Storm Attacks on Different Sites

	Site	Total Dur.	RTT Server Total	Ampl. Ampl.
		Packets (sec)	(sec) Type Bytes	By
		(T imeR) (ρ)		Analysis
	live (SSL) 13,000 229	0.270 IIS	832,000	7,500 5,002
	oranim	20,000 120	0.180 IIS	1,280,000 10,000 16,000
	yahoo	50,000 225	0.170 Ap. 3,200,000 25,000 25,415.5
	facebook 60,000 225	0.160 Ap. 3,840,000 30,000 27,004
	google	140,000 225	0.110 Ap. 8,960,000 70,000 39,299
	bbc (uk) 190,000 225	0.060 Ap. 12,160,000 95,000 72,000
	il.msn (p) 234,000 225	0.030 Ap. 14,976,000 117,000 144,098
	bing (p) 320,000 225	0.018 Ap. 20,480,000 160,000 240,163.5
	Lab	522,000 225	0.001 Ap. 33,408,000 261,000 4,322,944

Table 3 .

 3 The N Packet Storm on Yahoo.com

	Storm Packets Packets In Attack	Bandwidth	Amplification
	Sent	Session	Duration (T) Consumption Factor
				(Max.) Bytes Sec
	2 (Two	50,000	225	4,517	25,000
	Packet Storm)
	6	103,000	225	6,023	17,166
	10	153,000	225	7,579	15,300
	22	283,000	225	12,047	12,863
	42	485,000	225	19,576	11,547

Table 4 .

 4 Amplification Types -Assuming No Bandwidth Limitation AmpT wo Everl. 128 × L Every Trst T imeR × L (T imeR) × BW 64 -(2 + R) Amp∞ >> AmpT wo

	Attack Data	Attack	Attack	Time Until	Ampl.
	type	Sent	Intervals Duration	Full Bandwidth	Factor
					Consumption
	Two	128 B	Once	T imeR	Never	AmpT wo
	N	128 × Q	Once	T imeR	Immediate	AmpN ≤

We focused on Apache servers, because they are the most common. IIS and SSL(live.com) were tested for the attack but comparative research was not done on them.

Acknowledgments Many thanks to Charlie Kaufman, Amit Klien and Ben Laurie for their important feedback and encouragement. Amit also introduced us to the earlier work discussing Ack storms (as an undesirable side-effect of TCP hijacking attacks), e.g. [4]


Dimitrios Damopoulos

Georgios Kambourakis

Stefanos Gritzalis

iSAM: An iPhone

Keywords: Stealth Airborne Malware Malware, iPhone, iOS, Jailbreak, Stealth, Airborne, Rootkit

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Mobile devices have evolved and experienced an immense popularity over the last few years. These devices have penetrated the market due to the variety of data services they offer, such as texting, emailing, browsing the Internet, documents editing, listening to music, watching videos and playing games in addition to the traditional voice services. As a result, analysts are expecting a mobile device population of 5 billion by 2015 [START_REF] Liu | VirusMeter: preventing your cellphone from spies[END_REF]. Moreover, these devices are capable of performing sophisticated tasks and communicating through various wireless interfaces. As mobile devices hardware functionality and performance get improved, Operating Systems (OS) have similarly evolved. Modern mobile devices run sophisticated OS like Google Android, Apple iOS, Symbian, Palm OS, Blackberry RIM, Windows Mobile 7, that need to confront almost the same risks as desktop computers. It is thus apparent that this growth has exposed mobile devices to an increasing number of security threats. According to Chow and Jones [START_REF] Chow | A framework for anomaly detection in OKL4-Linux based smartphones[END_REF], the only difference between desktop computers and mobile devices in terms of security risk is the challenge to understand the inner workings of the OS on different hardware processor architectures.

Very recently, Kaspersky Lab identified 39 new mobile malware families (SMS trojans, iPhone malware, Android spyware) with 143 variants [START_REF]Kaspersky lab at mobile world congress 2009[END_REF] which try to compromise mobile device security. Also, according to a ScanSafe report, malware volume grew 300% in 2008, and it is noted that several of the legitimate web pages crawling on the Internet maybe infected by different kind of viruses [START_REF] Landesman | The world's largest security analysis of real-world web traffic: annual global threat report[END_REF]. In the same report it is stated that malicious image files comprised 10% of all Web malware encountered in 2009.

In this paper, we focus on iPhone device security. We create a smart malware namely iSAM to expose possible vulnerabilities of modern mobile devices and OS, and demonstrate that is relative easy to bypass any security control. Towards achieving its goals, iSAM employs a variety of programming techniques (pubic and private frameworks, override OS functions), backgrounding methods (daemons, dynamic libraries), as well as open source iPhone malware resources (e.g. Star exploit, iKee scanner logic). The aim of iSAM is to stealthily execute, six malware mechanisms, self-propagate wirelessly to other iPhone targets and finally connect back to the iSAM bot master server to update its programming logic or to obey commands and unleash a synchronized attack. Although specifically designed for iPhone 2G and iPhone 3G with the 3.1 and 4.0.1 iOS version respectively, iSAM can be easily adapted to attack other Apple iOS devices (iPhone 3GS/4 and all generations of iPod Touch). To the best of our knowledge this is the first rootkit-similar, airborne and stealth multifarious malware that is capable of infecting iPhone devices.

The rest of the paper is structured as follows. The next section presents previous work on the topic. Section 3 provides basic mobile malware design requirements and attributes. Section 4 describes the iSAM overall architecture and presents an analysis of the six proof-of-concept malicious iSAM's subroutines. The last session concludes the paper and gives pointers to future work.

Preliminaries and Related Work

Soon after the first iPhone was released, hardware and software modules were developed to bypass root privileges and overcome any restrictions. That is, only software signed by Apple's Certificate Authority is allowed to run on iPhone. This process is generally referred to as "Jailbreak". Upon jailbreaking, the entire iPhone file system becomes open for use. Jailbreaking allows to create and execute third-party software without an official SDK from Apple. The first aim after jailbreaking was to bypass SIM-Lock. Specifically, every iPhone is locked to a particular network provider. Unlocking allows the user to place calls with any GSM/3G carrier by inserting a different SIM into the device.

The installer created by the development team RipDev, and Cydia created by J. Freeman were the first two package managers that allowed a user to browse and download third-party applications for jailbroken iPhones. The open-source Cydia became very popular after iPhone firmware version 2.0. Since then, every time a hacking team discovers a new iPhone exploit, they publish the corresponding software that jailbreaks the device. Also, the same software installs a version of Cydia, a SSH server, and enables the default root login password "alpine".

In July 2007, T. Ormandy discovered "libtiff ", a buffer overflow method that has already been used to attack Sony's PSP device. Hackers inspected Apple's Mobile Safari web browser in order to test and take advantage of the same vulnerability that lay in the Tag Image File Format (TIFF) library, which is used for viewing TIFFs. Finally, they managed to successfully attack iPhone. Capitalizing on this vulnerability they created the web site jailbreakme.com. There, by selecting the "Slide-to-Unlock" button, a malicious TIFF file was simply opened from Mobile Safari leading to injection and execution of an arbitrary code and a straightforward Jailbreak. Once the iPhone has been jailbroken, the exploit patched the libtiff vulnerability in order to avoid future attacks. Apple patched this vulnerability with iOS 1.1.2 firmware. Vaibhav in his Project Report [START_REF] Pandya | iPhone security analysis[END_REF], discuses and analyzes the libtiff security breach in detail. Moreover, Chavez in [START_REF] Chavez | A jailbroken iPhone can be a very powerfull weapon in the hands of an attacker[END_REF] discusses how an intruder can successfully attack a network using a jailbroken iPhone. To perform the attack, she installs and uses a collection of powerful tools (e.g. Metasploit, Nmap, Whois, tcpdump, a terminal, WifiStumbler).

A year later, Apple introduce the new iPhone 3G that incorporates firmware version 2.0. Also, it offered a powerful Software Development Kit (SDK) that gave the opportunity to developers to create and deploy software under certain public frameworks so as to create the AppStore. In the end of July 2008, one of the iPhone third-party games namely Aurora Feint was removed from AppStore due to privacy concerns. Actually, the game was uploading to the developers server all contacts stored in the host iPhone. In 2009, serious privacy concerns appeared within the AppStore applications. MogoRoad and Storm8 are only two of the AppStore applications that have been removed after users' complaints about privacy concerns. In July 2009, users have raised serious concerns about their privacy in regard of the behavior of four tracking providers namely Pinch Media, Flurry, Medialets and Mobclix. J. Freeman tried to protect iPhone users by creating PrivaCy, an application for jailbroken iPhones, which blocks AppStore applications from tracking usage information.

The authors in [START_REF] Miller | Fuzzing the Phone in your Phone[END_REF] presented a vulnerability in SMS messages, which enables an attacker to inject fuzzed SMS messages into iPhones, Android and Windows Mobile devices. This vulnerability leads to a Denial-of-Service (DoS) attack remaining at the same time invisible to the service provider. This weakness was patched with the new 3.0.1 iOS firmware.

In 2009, researchers were trying to gain access to private information (i.e. contacts, photos, mails, SMS messages, passwords) stored in iPhone devices using various forensics methodologies. J. Zdziarski was the first one who using proper tools was able to retrieve unencrypted the full iPhone disk image. The same year he published a white paper with forensics techniques and tools that could be used to retrieve information from an iPhone device. During the same period, the first iPhone worm namely Ikee was released and a wave of worm attacks started. Ikee was simply changing the iPhone's wallpaper. Note that, Ikee was a self-propagating worm attacking only jailbroken iphones using the installed SSH server and the default root password. The same vulnerability was also used by Dutch 5e ransom, a worm that locked the iPhone screen asking 5e on a PayPal account in order to remove the worm. Privacy.A, was another worm running in stealth mode and be able to steal personal data from the iPhone. In November 2009, a new highly disastrous version of Ikee, namely iKee.B appeared in several Europe countries. SRI International analysed iKee.B in [START_REF]An analysis of the Ikee.B (Duh) iPhone botnet[END_REF] and provided technical details about the logic and the internal mechanics of the first iPhone Botnet. Although iKee.B acts similar to Ikee, it includes a Command & Control (C&C) logic to control all infected iPhones via a Lithuanian botnet server. Moreover, it is able to periodically update its malware behaviour. Finally, iKee.B, changes the default SSH password into "ohshit", and collects and sends all SMS messages stored in the device to the bot server. The iKee.B source code is published in [10].

Recently in [START_REF] Seriot | iPhone Privacy[END_REF] Seriot, presented some interesting attack scenarios on how a malicious application can use official and public frameworks, provided by Apple, to collect users private information (e.g., phone number, email account setting, keyboard cache entries, Mobile Safari searches and the most recent GPS location) programmatically. This happens without the user's knowledge and without being rejected by the AppStore review.

On July 2010, the United States government and the new Digital Millenium Copyright Act (DMCA) legislation announced that modifications of smartphones, like jailbreak or Unlock are legal as long as they obey the copyright law [12]. Based on the new law, in August 2010, Comex, an iPhone exploit developer, with the help of several other hackers introduced the exploit namely Star or JailbreakMe 2.0. This new exploit can jailbreak all Apple's products which incorporate iOS firmware versions from 3.1.2 to the current 4.0.1. Until then, all previous iOS firmwares have been jailbroken using offline exploits. Star, like JailbreakMe, is a remote browser-based jailbreak that uses two security flaws [START_REF]Technical analysis on iPhone jailbreaking[END_REF]. The first one, uses a corrupted font embedded in PDF files that crash the Compact Font Format (CFF) to allow arbitrary code execution, while the second one uses a vulnerability in kernel to escalate the code execution to unsandboxed root privileges. Any iOS mobile device that opens a jailbroken PDF file from a website, email, SMS, or Apple's iBook can be automatically jailbroken. A few days after Star was released, Comex published the source code [14].

Designing principles and requirements for iPhone

The primary aims of a smart malware is to infect the target, self-propagate to other targets and finally connect back to a bot master server. The latter action is highly desirable to update the malwares programming logic by improving already existed features and adding new ones, or to obey commands and unleash a synchronized attack. To achieve the affomentioned goals, the malware needs to fulfill some basic design requirements. First off, it needs to infect the device and gain root permissions. Also, it needs to run continuously in the background of the OS and has smart malware behaviour remaining stealthy to the legitimate user.

The only way to infect an iPhone and gain root permissions is by exploiting a vulnerability on an iOS jailbroken device. In case the target iPhone is already jailbroken, the malware may attempt to use the SSH vulnerability1 to wirelessly connect and infect the device. According to Cydia developer, J. Freeman, over 10% of the 50 million iPhones worldwide are jailbroken [START_REF]The point of jailbreaking[END_REF]. Although these devices constitute a large proportion for possible targets, it is necessary to find new ways to infect non-jailbroken iPhones.

To do so, we propose to create a malicious version of Star exploit [14] that is able to work wirelessly. As already mentioned, Star exploit consists of a PDF, which uses two security flaws allowing arbitrary code execution and gaining root privileges, and of a website "JailbreakMe" which stores the PDFs caring the exploits (one PDF for each iPhone version and one for each iOS version) [START_REF]Technical analysis on iPhone jailbreaking[END_REF]. Once the PDF is opened, a dynamic library (dylib) named "installui.dylib" provides graphic interface and downloads from the corresponding website a file named "wad.bin". After that it proceeds to jailbreak the iOS and install Cydia using a second dylib named "install.dylib". The file "wad.bin" is a binary file that contains any type of data; in this case it contains the "install.dylib" and the Cydia package. According to F-secure, any iOS mobile device that opens an exploited PDF file from a website, an email, an Apple's iBook application or accesses a website directly from an SMS message, can be jailbroken [START_REF]How many ways can you remotely exploit an iPhone?[END_REF]. Note that iOS is capable of recognizing automatically hyperlinks sent via SMS.

Once a malicious Star PDF file is opened by an iPhone using our malicious Star version, it is being automatically jailbroaken and installed stealthily malicious software. Also, once an iPhone visits our website or opens the malicious PDF, the exploit procedure begins, stealthily, without providing any graphical interface or any information popups. Furthermore, we inject our malware into the "wad.bin". This means that once the jailbreaking procedure ends, Cydia and our malware will be both installed in the iPhone.

In order to create our malicious version of Star, it was necessary to modify the open source version of Star exploit [14]. Firstly, we decided to pack our malware as a Debian package. Once Cydia is installed in the iPhone, any file with the ".deb" extension stored in the folder "/var/root/Media/Cydia/AutoInstall", will be also automatically installed in the device. To inject our malicious package in the "wad.bin" file, it was necessary to modify the Star source class, named "install" and the python script "wad.py". Also, it was necessary to modify the source file "installui.m" which is used to build the dylib named "installui.dylib". In the source file "installui.m" we deactivated all displayed graphics interfaces making the exploit behave stealthily. Moreover, we edited the domain name from where our malicious "wad.bin" can be downloaded and we recalculated the size of our malicious "wad.bin" file editing the source where it was necessary. Last, after the installation of Cydia we shift our malware package into Cydia's autoinstall directory. It is stressed that all these operations are possible because the Safari browsing process has acquired root access using the kernel bug.

The second requirement when designing our malware was the ability to run continuously in the background of the underlying OS. Until iOS version 4, multitasking was not officially supported. Unofficially, jailbroken iOS could support applications that run in the background as deamons or use Objective-C dylib. iOS being a Unix-based OS, can provide multitasking using launchd, a launch system that supports daemons and per-user agents as background-services. Once an iOS has been jailbroken, any installed application or shell script is able to behave as daemon by creating a launch plist and placing it into the "/Library/LaunchDaemons" iOS directory. Another way to support multitasking is with dylib. When an application is launched, the iOS kernel loads the application's code and data into the address space of a new process. At the same time, the kernel loads the dynamic loader i.e., "/System/MobileSubstrate /DynamicLibraries" into the process and passes control to it. In addition, it is possible to load a dylib at any time through Objective-C functions. Finally, from iOS version 4 and later, Apple provided seven APIs that allow applications to run in the background. Although these APIs are the native way for providing multitasking, it is not the best way to create and launch a malware. A program that uses the native way for backgrounding can be easily spoted by the user from the corresponding menu.

The last requirement is to design a smart malware that will remain stealthy and invisible to the user at all time. These smart malwares need to achieve their purpose stealthily by modifying OS code, functions and/or data. Officially, Apple does not provide any frameworks that override iOS functions. To fill the gap, J. Freeman has created and incorporated into Cydia MobileSubstrate extension, a framework that allows developers to deliver run-time patches to system functions using Objective-C dynamic libraries [START_REF]Mobilesubstrate[END_REF]. By creating a dylib, developers are able to build applications that run in the background and be able to replace internal system functions at the same time.

The iSAM malware

Given the aforementioned requirements and possible solutions, we created iSAM. The iSAM malware has been implemented, using Objective-C source code compiled for iPhone ARM CPU. Also, iSAM was build using the unofficial ways (see Section 3) for backgrounding (daemons and dylibs), the public and private2 frameworks and the MobileSubstrate framework with the "substrate.h" header that overrides iOS functions. This means that certain modules of iSAM can be classified as rookit.

iSAM consists of a main daemon written in Objective-C and combined with a proper launch plist (activated at device boot time) and six subroutines written as Objective-C functions, dylibs or shell scripts. The iSAM main daemon is responsible to manage all subroutines which are in charge of the propagation logic (iSAMScanner), the botnet control logic (iSAMUpdate) and the smart malware behaviour (iCollector, iSMSBomber, iDoSApp, iDosNet). iSAMScanner is activated during the device boot time and runs as a deamon in the background. iSAMUpdate is activated once per day and only if an Internet connection is available, while the rest four subroutines are activated once per week but at random times. Figure 1 depicts the overall iSAM architecture. Important pseudocode segments of all the iSAM subroutines discussed in this section can be found in [22]. In addition to iSAM, we setup a bot master server namely iSAM Server (iSAMS) having multiple functionality. iSAMS incorporates two basic modules: (a) a repository server where the newer or special customized version of iSAM is stored, and (b) a multithread socket server used to communicate with the infected devices to update iSAM program logic, to collect sensitive information and to control and execute commands directly on the iPhones. Also, iSAMS stores our malicious version of Star exploit namely mStar.

iSAM Infection Methods

As already mentioned iSAM uses two different methods to wirelessly attack and infect iPhone devices. The first method is by using iSAMScanner (see next section) which tries to detect jailbroken iPhones having the SSH vulnerability and infects them directly. Alternatively, we employ mStar, a modified version of the exploit Star, which is able to jailbreak the device and simultaneously infect it with iSAM. A recent report by F-Secure showed that nearly 79.8% of mobile phones infections were as a result of content downloaded from malicious websites or delivered by Bluetooth and SMS messages [START_REF]The state of cell phone malware[END_REF]. Capitalising on these results we use iSMSBomber (see section 4.5) as part of the second infection method to contaminate iPhone devices. iSMSBomber is able to read any telephone numbers stored in the device and send to them stealthly a SMS message with the domain of iSAMS. This is to trick the user into visiting iSAMS. In addition, mStar can be delivered to an iPhone when visiting our iSAMS via a web link, email attachment or a legal popular AppStore application that uses a website link to redirect to iSAMS. Once 195.251.166.50 (iSAM.samos.icsd.gr) hyperlink is opened via a SMS message, mStar PDF is downloaded from iSAMS and loaded via Mobile Safari. After that, installui.dylib downloads wad.bin and install.dylib jailbreaks the iPhone and installs iSAM.

iSAMScanner: Scan, Connect, Infect

iSAMScanner is responsible for the propagation logic of iSAM. iSAMScanner driven by iSAM daemon, is activated at iPhone boot time. The iSAMScanner subroutine has three methods: iScan, iConnect and Infector. iScan is conducting three independent network scans just like iKee.B. Firstly, it scans iPhone's local WiFi network address space, then scans in a random way computer subnetworks on the Internet and finally scans a list of IP address range that belongs to a set of mobile phone companies in Greece (e.g. 195.167.65.0-195.167.65.255, GR, Cosmote) or in other European countries (e.g. 139.7.0.0-139.7.255.255, DE, Vodafone). When a vulnerable iPhone is detected, iConnect connects directly to the SSH Server using the default root password and by using Infector downloads the iSAM.deb package to the directory "/private/var/root/" of the targetdevice. Finally, Infector installs the package using the command dpkg -i -refusedowngrade -skip-same-version iSAM.deb. From this step forward, the victim's device is under the control of iSAM.

iSAMUpdate: Update, Command, Control

iSAMUpdate, is responsible for the botnet control logic of iSAM. It is also used for connecting iSAM back to iSAMS to check whether a newer iSAM version is available. This allows iSAM to be updated e.g., with a new programming logic or follow commands directly from the server in order to unleash an attack. iSAMUpdate is connected back to iSAMS once every day as soon as an Internet connection is detected. Every time iSAMUpdate is activated, it retrieves some useful information from the device and sends them as a textmessage to iSAMS to be stored in the local database. The message is consisted of the iSAM version, the Unique Device Identifier (UDID), which is a unique serial number for each iPhone, the IP address from the e0 interface (WiFi connection on the iPhone) and the GPS coordinates, as long as a GPS is enabled. The following quintuplet gives an example of such a message {version016 ||3bdf7jc607h1j7te441sc02f5h5j6229db66hh63||62.217.70.167||26.700039|| 37.794186}. In case a newer iSAM version is detected, the server answers back with the name of this version, else it sends back a null message. It is not necessary for the server to respond with the latest version; instead it can answer with a customized response based on the UDID or the georgraphical coordinates if it wants to manipulate the phone in a special way or to attack devices selectively (e.g. attack all devices that roam to a certain area). Once the iSAM client receives the name of the version, it executes a Unix shell script named "iUpdate.sh" which is called with the name of the version as a parameter. The shell script executes two script commands: the "curl -O iSam.samos.icsd.gr/debs/$1.deb", which downloads the newer iSam version directly from iSAMS and the "dpkg -i -refuse -downgrade -skip -same -version $1.deb", that uses the Debian package manager to install the new version. We should note that the name of the iSAM version, which the server has sent, is stored in the variable $1. It is also stressed that once the server has the client's IP address, is able to connect directly to the client's SSH service using the default root password.

An infected iPhone with iSAM is able to search for jailbroken iPhones into three different subnetworks (local subnet, random Internet subnet, mobile provider IP subnet) in order to infected them as well. Moreover, an infected iPhone can be updated or controlled by iSAMS. Lastly, if a non-jaibroken iPhone opens iSAM.samos.icsd.gr hyperlink through a SMS message, will get infected by mStar PDF.

iCollector: Gathers private information from the device

The purpose of this attack module is to collect stealthily confidential information directly from the device. iPhone stores all user's data in SQLite databases and plist files without providing any encryption mechanism to secure their contents. Once an iPhone has been jailbroken, the iOS sandbox collapses and all databases and plists stored in the path "/var/mobile/Library/" are exposed to the attacker.

iCollector is an iSAM subroutine that collects stealthily sensitive information from iPhone's databases (call, sms, calendar, note) and from Safari's plist files (bookmarks and Web browsing history), storing them into a new database named iCollection.db. After the data collection takes place (see line #1-3 in [22]) and when an Internet connection is detected (line #3-6), iCollector is connected back to the iSAMS using the Client/Server model and TCP sockets in order to send the collected information (line #7-8). iCollector is a dylib written in Objective-C and uses an SQLite library to read, create and write to databases.

iSMSBomber: Sends malicious SMS messages in stealth mode

Like all GSM mobile devices, iPhone uses a set of commands, called AT (attention), to dial a number or exchange SMS messages. In addition to AT commands, iPhone employs a high level private framework, named "CoreTelephone" (incorporated to iOS), in order to communicate with the Baseband using Objective-C functions. However, this framework is neither available by the iOS SDK nor documented. The only way to overcome this issue is to retrieve the CoreTelephone framework directly from the files of a jailbroken iPhone and then use class-dump utility. Class-dump examines Objective-C runtime information stored in Mach-O files in order to generate the header files [19]. This procedure is necessary to execute every time a private framework is used. Once the CoreTelephone framework and the header files are available, a direct communication with the Baseband can be placed.

To take advantage of such a powerful framework, we create iSMSBomber. This is an iSAM dylib subroutine that sends silently say 1000 malicious SMS messages using the private CoreTelephone framework and more specifically the CTMessageCenter header (line #1-3). Firstly, iSMSBomber makes an SQL query to the iPhone's address book database to retrieve telephone numbers from user contacts (line #4-5). In case no contact exists or the contacts are less than 1000, then random numbers are created to reach 1000. Every random number begins with the standard "003069" digit sequence, which represent a mobile phone number in Greece. Then iSMSBomber creates the following message: "Hello, how are you? I have found an interesting website: 195.251.166.50 -Please send it to all' !' and by using the sharedMessageCenter function, it sends the message to all the existing (plus random numbers if any) (line #6). Once an iPhone user receives this message and visits the website link, Mobile Safari web browser opens automatically and accesses the site. Recall that this domain is redirected to iSAMS that stores the mSTAR exploit, which in turn contains iSAM. Also note that this message is malicious only for iPhones iOS. Normally, once a SMS message is sent or received, automatically it is stored to the SMS database and a tone rings. iSMSBomber sends stealthily all the 1000 messages without storing them in the SMS database and without playing any tone. The only way to expose its presence is by the end of the month, when the mobile user receives his telephone bill assuming that the user does not usually send a high amount of messages.

iDoSApp: Denial of Application Services

Modern mobile devices are designed to increase the efficiency and the productivity of mobile users on the go. Therefore, by default, all mobile devices come bundled with some basic pre-installed applications or utilities. iPhone is offered with seventeen pre-installed applications. Additionally, AppStore contains more than 3 * 10 5 iOS applications [START_REF]U downloads top 300 million[END_REF] offering the user the necessary on the go productivity. One of the main iOS applications is SpringBoard that manages the iOS home screen by displaying all icons of the available applications, starts the WindowServer and launches and bootstraps other applications [START_REF]SpringBoard[END_REF]. For example, once a user touches the icon of an application, SpringBoard launches it. The goal of iDoSApp subroutine is to cause DoS in application launching by overriding some system functions required by SpringBoard.

In this context, iDoSApp is a dylib, which is activated at random time frames, is short-term (say 1-minute) and causes real DoS by non-loading an application. To achieve this, it is necessary to replace SpringBoard system functions, by class-dump SpringBoard in order to get the private headers and create a dylib. The headers used by iDoSApp are the substrate.h (used for overriding systems functions using the MobileSubstrate framework), the SpringBoard.h and the SBApplicationIcon.h headers (derived from the class-dump of SpringBoard (line #1-3)). SBApplicationIcon is a system function responsible for the behavior of all icons displayed by the SpringBoard. iDoSApp hooks, modifies and replaces SBApplicationIcon only when the selector is a launch message. A selector in Objective-C language is a message that can be sent to an object or class (4). Normally, every time the user touches on an application icon, a launch message is sent to SBApplicationIcon to load the application. In our case, once the iDoSApp is activated, it blocks all launch messages that are sent to SBApplicationIcon causing DoS (line #5-7). iDoSApp will not compromise iSAM existence, as some applications can automatically close when an application is written for older or newer iOS versions or when they fail to manage the memory correctly.

iDoSNet: Denial of Network Services

The aim of iDoSNet subroutine is to cause DoS by deactivating for -say 30 seconds -all communication services (line #3-6). iSAM will activate iDoSNet at random times during a random day of the week. iDoSNet is using a private framework, namely Preferences.framework which can enable/disable the Airplane mode that controls 3G/GSM functions. Furthermore, iDoSNet uses the Apple80211.framework, a private framework that configures all 802.11 network interfaces, to cause DoS (line #1-2). We make the hypothesis that the duration of 30 seconds will not expose the existence of iSAM and the vast majority of users will suppose that it happend due to a temporary interruption to the wireless signal.

Conclusion

The evolution of malwares is a continuous race between intruders and defenders. Both use the same programming methods, tools and resources either to create a smart malware or to develop an intelligent malware detection mechanism. Overall, with the increasing risk of mobile malware, designing a highly secure mobile device is still a very challenging task. This paper concentrates on the very popular iPhone device. We design and implement iSAM a new multifunctional malware that is able to wirelessly infect and self-propagate to iPhone devices. iSAM is able to override OS functions and uses a variety of advanced programming methods (public and private frameworks), backgrounding methods (daemons, dynamic libraries), and open source iPhone malware resources (e.g. Star exploit, iKee scanner logic) towards achieving its goals. It is also able to hide its presence, and update its logic via the iSAM bot master server. iSAM incorporates six different malware mechanisms and utilises two different methods to wirelessly infect other devices. The purpose of our study is to highlight iOS weaknesses and offer in-depth information towards combating such threats.

Our future work will concentrate on obtaining detailed experimental results e.g. infection and untraceability rates, collector effectiveness etc as well as into modifying iSAM core so as to be able to automatically infect any iOS-based device.

Fig. 1 .

 1 Fig. 1. iSAM architecture

The SSH vulnerability, allows intruders to remotely access a jailbroken device's file system using the SSH server and the default password "alpine".

Unsupported frameworks, which were retrieved directly from a jailbroken iPhone and have been dumped to get the headers.