THE ORIONID meteor shower promises to dazzle stargazers with a spectacular display of shooting stars TONIGHT. But what is the best time too watch the meteor shower?
When its the Orionids meteor shower?
If you can’t view it, either it being cloudy or heavey lit area, Slooh will be Live streaming the event from tonight. Join Paul Cox, Dr. Paige Godfrey, and Bob Berman for a decidedly casual and far-ranging chat as as we train our telescopes on the Orionids. SLOOH Live Event of the Orionid Meteor Shower
The Orionids light up the night sky every year towards the end of October in “one of the most beautiful showers of the year”, according to Nasa.
The meteor shower will peak in the early of hours of Saturday (October 20) and once again in the early hours of Sunday (October 22). Sporadic meteors have already been dashing across the night sky from October 15 and should remain visible until November.
During the peak, stargazers can expect anywhere up to 50 meteors per hour, though this year Nasa believes that the numbers may not be as spectacular.
Nasa’s Jane Houston Jones said: “The Orionids peak on October 20, a dark, moonless night. Look near Orion’s club in the hours before dawn and you may see up to 10 to 15 meteors per hour. “Use binoculars to look for bright asteroid 7 Iris in the constellation Aries. Newbies to astronomy should be able to spot this magnitude 6.9 asteroids even from the city.”
What is the best time to view the Orionids meteor shower?
The peak of the Orionids will be visible anywhere on Earth in the early morning hours of tonight and tomorrow night, usually after midnight and just before dawn.
The best time for skywatchers to head outside is usually around 2am when the shower is at its most intense.
Star gazers will be aided this year by the lack of moonlight which should keep the skies clear of any hindering light pollution.
But Storm Brian will make the sky overcast tonight much of the UK as the weather bomb unleashes strong winds and rainstorms.
A Met Office spokesman said: “There’s quite a lot of cloud around this evening and overnight. The best chance of seeing them will be in the early hours before dawn.” He said that the clearest skies will be from 3am in the eastern part of England across East Anglia, the South East, Lincolnshire and the Midlands.”
To get the best views, stay away from any sources of light pollution and give your eyes some time to adjust to the dark of space.
Where will the Orionid meteor shower appear?
The Orionids derive their name from there point of origin next to the Orion constellation, which ascends in the east.
But the shower’s radiant point is mostly irrelevant because the meteors will shoot out in all sorts of directions, and usually remain unseen until about 30 degrees from the radiant.
However, if you spot a streaking meteor, you should be able to trace its path back to its origin next to Orion’s club.
What are the Orionids?
The spectacular shooting stars are remnants of the prolific Halley’s Comet, which visits Earth every 74 to 79 years.
When the comet passes through the solar system, chunks (Debris) of ice and rock break off from the comet thanks to the sun, and trail in the comet’s path. The first recorded reports of the shower date back to 1839, when it was spotted in America.
The Orionids are incredibly fast meteors and crash into Earth’s atmosphere at a speed of 66 km/s. Many of the falling stars leave ionised trails of glowing gas in their path.
Orionid Meteors Over Turkey Credit & Copyright: Tunc TezelExplanation: Meteors have been flowing out from the constellation Orion. This was expected, as mid-October is the time of year for the Orionids Meteor Shower. Pictured above, over a dozen meteors were caught in successively added exposures over three hours taken this past weekend from a town near Bursa, Turkey. The above image shows brilliant multiple meteor streaks that can all be connected to a single point in the sky just above the belt of Orion, called the radiant. The Orionids meteors started as sand sized bits expelled from Comet Halley during one of its trips to the inner Solar System. Comet Halley is actually responsible for two known meteor showers, the other known as the Eta Aquarids and visible every May. Next month, the Leonids Meteor Shower from Comet Tempel-Tuttle might show an even more impressive shower from some locations.
Eclipsosaurus Rex Image Credit & Copyright: Fred Espenak (MrEclipse.com)Explanation: We live in an era where total solar eclipses are possible because at times the apparent size of the Moon can just cover the disk of the Sun. But the Moon is slowly moving away from planet Earth. Its distance is measured to increase about 1.5 inches (3.8 centimeters) per year due to tidal friction. So there will come a time, about 600 million years from now, when the Moon is far enough away that the lunar disk will be too small to ever completely cover the Sun. Then, at best only annular eclipses, a ring of fire surrounding the silhouetted disk of the too small Moon, will be seen from the surface of our fair planet. Of course the Moon was slightly closer and loomed a little larger 100 million years ago. So during the age of the dinosaurs there were more frequent total eclipses of the Sun. In front of the Tate Geological Museum at Casper College in Wyoming, this dinosaur statue posed with a modern total eclipse, though. An automated camera was placed under him to shoot his portrait during the Great American Eclipse of August 21.
Global Aurora at Mars Image Credit: MAVEN, LASP, University of Colorado, NASAExplanation: A strong solar event last month triggered intense global aurora at Mars. Before (left) and during (right) the solar storm, these projections show the sudden increase in ultraviolet emission from martian aurora, more than 25 times brighter than auroral emission previously detected by the orbiting MAVEN spacecraft. With a sunlit crescent toward the right, data from MAVEN’s ultraviolet imaging spectrograph is projected in purple hues on the right side of Mars globes simulated to match the observation dates and times. On Mars, solar storms can result in planet-wide aurora because, unlike Earth, the Red Planet isn’t protected by a strong global magnetic field that can funnel energetic charged particles toward the poles. For all those on the planet’s surface during the solar storm, dangerous radiation levels were double any previously measured by the Curiosity rover. MAVEN is studying whether Mars lost its atmosphere due to its lack of a global magnetic field.
Computer systems are powerful tools that touch upon many aspects of life in modern society. They can be used to enhance the quality of life or degrade it. The impact of this effect may range from negligible to the dramatic.
In order to ensure that computer systems are used in an effective and productive way, it is important that the owners, operators and users of these systems have a clear understanding of acceptable standards of use. Such an understanding can be gained as part of a Site Computer Security Policy.
The security requirements of computer systems owned and operated by one organisation will almost certainly differ from the requirements of another organisation. It is, therefore, important that each organisation formulates its own Site Computer Security Policy.
This paper outlines some issues that the writer of a Site Computer Security Policy may need to consider when formulating such a document.
The information contained in this paper is given freely as an account of the author’s own experience, and may be used by the reader as the reader sees fit.
No responsibility or liability will be accepted by the author or the author’s employer for any damages caused by direct or indirect use of the information or functionality described in this paper.
1.0 What Is A Site Computer Security Policy?
In the same way that any society needs laws and guidelines to ensure safety, organisation and parity, so any organisation requires a Site Computer Security Policy (CSP) to ensure the safe, organised and fair use of computational resources.
The use of computer systems pervades many aspects of modern life. They include academic, engineering, financial and medical applications. When one considers these roles, such a policy assumes a large degree of importance.
A CSP is a document that sets out rules and principles which affect the way an organisation approaches problems.
Furthermore, a CSP is a document that leads to the specification of the agreed conditions of use of an organisation’s resources for users and other clients. It also sets out the rights that they can expect with that use.
Ultimately a CSP is a document that exists to prevent the loss of an asset or its value. A security breach can easily lead to such a loss, regardless of whether the security breach occurred as a result of an Act of God, hardware or software error, or malicious action internal or external to the organisation.
2.0 Why Does An Organisation Need A Site Computer Security Policy?
In addition to the benefits outlined above, a CSP offers an organisation the following benefits:
(a) It helps to make decisions with regard to other policies. It is not uncommon for a policy on a particular matter to refer to other policies. For instance, a CSP may refer to a policy on Copyright or a policy on dealing with the Press. Similarly, other policies may need to refer to specific sections of a CSP. This obviously is not possible if a CSP has not been formulated.
(b) It helps in making purchasing decisions. A CSP offers guidelines for standards of protection required on particular classes of computer systems. If a software or hardware component under consideration for purchase could be used to (or will actually) compromise these standards, then this may have an influence on whether the component is purchased.
(c) A CSP forms a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP may contain guidelines of what authority particular people have to take certain actions to minimise the impact of that breach. Furthermore, after the breach, the policy will provide guidelines regarding the course of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach. This removes the scope for independent reasoning at inappropriate times.
(d) A CSP should be considered as a living, long-term document that provides guidelines for the development of procedures applied to an organisation’s computer systems on a regular or day-to-day basis. These procedures would be described in a Site Procedures Manual, and would be concerned with the specifics of an organisation’s computer system and networking resources. Whereas the CSP describes principles (not implementation specifics) and should only ever be changed infrequently (when necessary), the Site Procedures Manual would be more volatile.
(e) Similarly to the above, a CSP will offer a framework for computer system configuration and network design and configuration.
(f) Because the development and enforcement of a CSP (and a Site Procedures Manual) is a non-trivial task, the existence and use of these documents is testament to the commitment of an organisation to professionalism.
(g) An important aspect of law is that ignorance is no excuse. Similarly, a well formulated and well advertised CSP leaves all people who have contact with an organisation’s computer systems with a clear understanding of what constitutes acceptable behaviour, effectively removing ignorance of acceptable standards as an excuse for antisocial behaviour. (The reader should note that acceptable behaviour standards form only one part of a CSP, as explained in Section 4, What Does a Site Computer Security Policy Contain?.)
(h) A CSP may be required by an auditor in the course of an organisational audit.
3.0 What Are The Characteristics Of A Site Computer Security Policy?
An effectively written CSP should have the following characteristics:
(a) It should be useful, and preferably written in a form that is easy to read (implying usable and understandable English).
(b) It will be structured in a form that lends itself to finding relevant sections of the policy easily.
(c) Initial forms, and subsequent updates should be versioned and dated.
(d) In order to have any authority, it must be accepted as the official reference document by the authoritative people in the organisation.
(e) It must set out principles only. It should be written with the intention that it will be a living reference document, used over a long period of time, with infrequent (and preferably none) changes during its lifetime.
(f) It must be carefully worded. The key to preparing a policy document is to ensure that all terms are accurately and precisely defined, and that these terms are used exactly as they are intended. A careful balance must be achieved in the wording of concepts. Each concept must be worded precisely enough to effectively communicate the meaning of the concept, but not so precisely so as to be dependent upon a particular technology, or to otherwise unintentionally allow a breach of the intention (if not the wording) of the concept.
(g) A CSP should be considered as a parent document to a Site Procedures Manual, and prepared as such.
(h) Not only must a CSP set out acceptable conditions of use, but it should also set out unacceptable conditions of use.
(i) The CSP should be widely advertised to those people who are affected by it. Furthermore, there should be a section in the CSP about the advertising of the CSP.
(j) Because the CSP is intended to be a living document, it should be reviewed at regular intervals, and at any other time required. Furthermore, there should be a section in the CSP about these reviews.
(k) The CSP must not simply be an Acceptable Usage Policy (that is a policy on acceptable behaviour of users of computer systems). The CSP must also outline what rights and expectations of the resource provider users have with regard to the use of computer systems, guidance on various issues for system managers and decision makers, definitions of terms and so on.
4.0 What Does A Site Computer Security Policy Contain?
A CSP can be viewed as a document of three distinct parts, all of which are necessary, but within themselves not sufficient.
The first part outlines the parameters within which the policy will operate, and may consist of many sections.
The second part of the policy is essentially a risk analysis, which discusses assets that need to be protected, the threats that may cause damage to the assets, and the mechanisms that may be used to realise these threats. The material in this part forms the logic behind the rules and guidelines that form the actual security policies that are formally defined in the third part.
The following material outlines issues that the author of a CSP may like to address in the document. This is not necessarily exhaustive, and the content of the CSP ultimately rests with its author.
The abstract should set out what the document is and the organisation for whom it has been written.
This section should outline the context within which the resources under the control of the policy operate. For instance, a private company may not be connected to any network outside of its own domain, or on the other hand, it may be connected to banks throughout the world. A CSP for a university may describe the significance of Internet and AARNet, and the relationship of these entities with the campus network.
This context is important as it effectively determines what the governing policies are of the CSP, and influences the philosophy and procedural guidelines set out in the CSP.
4.3 Philosophy and Functions
The writer of a CSP will inevitably be faced with several alternatives when deciding on a particular policy for a particular issue. The classic instance of such a dilemma occurs when one determines that a compromise of a computer system is actively in progress, and that the compromise possibly includes a breach of Commonwealth Law. Does the system manager take steps to reduce the impact of the compromise (by, for example, disconnecting the compromised network from the source of the compromise), or does the system manager allow the compromise to continue in an attempt to identify the attacker at the risk of damaging or losing resources permanently?
The basic philosophy that should be used when constructing policies that may be used for making non-deterministic decisions should be outlined in this section.
The writer should also outline the functions that the CSP is expected to serve within the organisation. Similarly to the philosophy behind the CSP, the functions that the CSP will serve will affect the content of the CSP.
As mentioned earlier in this paper, the key to writing an effective CSP is accurate and precise definitions of terms. Any term that may have any ambiguity attached to it must be defined in a precise manner. Any loopholes left in this section or in the sections regarding the rights and responsibilities of users and resource providers may be exploited by people in order to circumvent the CSP.
For instance, consider a policy which states, in part, that “all accounts must be protected by a password”. This obviously precludes the use of guest accounts with no passwords. However, what effect does this have on anonymous ftp? Is it conceivable that one could make a case that the anonymous account is not password protected since any password could be used to access the account?
What constitutes an account? The login identifier only, or the resources associated with the account? Does the account holder own the account and those resources, or does the resource provider? Should the term “account” be omitted, and replaced by the concepts “user account”, “privileged account” and “public access account”?
When a policy refers to a Chief Executive Officer (CEO) of an organisation, should the term “Chief Executive Officer” be redefined to include the CEO and agents of the CEO, where an agent is any person authorised by the CEO to be such? If not, then the policy may award the CEO many rights and tasks, leaving nobody else with any rights or tasks at all, let alone the authority to act in the absence of the CEO!
Two of the most critical concepts that must be clarified are the concepts of authorisation and permission. At a technical level, is permission simply granted by access permission bits on a file, or is permission a combination of technical feasibility and authority to carry out an activity? Is authority implicit with technical feasibility, is it a property that must be explicitly granted, or is it a property associated with position?
These are but a sample of the terms that need to be defined for a CSP. This (crucial) section should be carefully and painstakingly constructed, and whenever there is any doubt as to whether a term should be defined, or what the definition should be, then one should err on the side of caution.
4.5 Governing Policies
It is important to make mention of the policies which govern the CSP.
The CSP may only make mention of policies that directly affect it, rather than get bogged down in all policies that may indirectly affect the document in varying degrees for pragmatic reasons. Examples of such direct policies include Commonwealth Law, State Law, (perhaps) the AARNet Acceptable Usage Policy and the “Terms and Conditions of AARNet Network Affiliate Membership” document (if appropriate). Other policies internal to the organisation may also be referred to in this section.
It is recognised that the content of this section is affected by external influences. However, it is these same external influences that affect the content of the CSP as a whole, and the interpretation of it. By including references to the governing policies, content of the CSP is simplified, and guidelines for action in the event of a security breach are automatically provided should such a breach influence an organisation’s environment.
However, because of the external nature of these governing policies, interpretation of them in this section should be kept to a minimum (again for pragmatic reasons).
In order to be effective, the CSP must be the product of a directive from an influential and authoritative person within the organisation.
It is important to define the driving force behind the development and implementation of the policy. Furthermore, this section must outline the person who has ultimate authority in the interpretation and application of it to a particular situation, particularly in lieu of any issue that may be addressed in subsequent sections.
Another consideration when writing this section is that of allowing for flexibility. That is, decision makers may need a clause in the policy that allows for a policy statement to be temporarily waived from time to time by a person of authority under certain conditions or guidelines. Such a clause allows those in authority to act with initiative (and still within policy boundaries) should unusual situations arise.
The organisation should formally define the standards it will adhere to ensure that the people affected by the policy are appropriately informed of its contents (as is its moral responsibility).
A CSP that is prepared in a final form and never reviewed for the appropriateness of its contents during its lifetime may quickly become a document that is either cumbersome or useless. This section should formally set out the periodicy and necessity for reviews of the CSP.
4.9 Risk Analysis
The previous sections set out the parameters within which the policy will be effective. This section outlines the assets that must be protected, and from what threats. This is necessary to provide the underlying logic for the following sections which formally define the rules that apply to the use of those assets.
The preparation of this section can be laborious and can require a great deal of insight. The depth of this analysis is up to the organisation and the uses to which the CSP will be put. For instance, if the CSP is expected to be heavily used in making purchasing decisions, particularly with regard to asset defence, then a full financial and likelihood analysis of the impact of any and all realised threats may be required. However, if this is not one of the main purposes of the CSP, then this section may only need to outline the assets, threats and vulnerabilities which ultimately justify the logic behind the following sections.
It is essential that in its most minimal form, this section has at least three subsections.
In the first subsection, a list of various asset categories must be provided, since the loss of an asset represents a significant loss to the organisation. In some cases, a lost asset cannot be replaced, particularly in the case of goodwill, trust, or confidential research. Examples of asset categories include:
- goodwill and reputation;
- people and skills; and
A discussion of these assets should include some indication of the size and type of investment that the asset represents, the impact on the organisation of the loss of the asset and how easily replaceable (if at all) the asset is. When considering assets in the information category, it is important to emphasise that a loss may be suffered simply by unauthorised access to that information, even if that information is still available to the organisation.
The loss of an asset is caused by the realisation of a threat. The threat is realised via the medium of a vulnerability. Threats cannot be controlled within an organisation as a threat is essentially a product of the organisation’s environment. This is not so for vulnerabilities, which usually exist within the organisation. Hence the purpose of the security policy and its associated procedures is to minimise the number and size of any vulnerabilities and thus negate any potential threat and its impact on an organisation’s assets should a threat be realised.
The second subsection might therefore be devoted to threats. Examples of threats that may be examined are:
- denial of service;
- destruction (of assets);
- disclosure of information;
- theft (of information or physical assets); and
- unauthorised access.
The examination of these threats might include a discussion on both the probable and maximum possible impact of the realisation of the threat upon the organisation, as well as the consequences for the organisation should these scenarios occur. It may also be useful to explore what further threats could be realised as a consequence of the realisation of an initial threat.
The third essential subsection must tie together the assets and threats to give some indication of the likelihood of and likely extent of damage of the threat being realised on the assets. This subsection therefore discusses vulnerabilities.
Vulnerabilities may differ from organisation to organisation. However, a possible categorisation of a vulnerability set may be:
This can be a difficult subsection to write. For each vulnerability identified, the following aspects might be discussed.
(a) Form, in which it is explained in understandable terms what the vulnerability is, possibly through the use of (or including) realistic examples.
(b) Type (whether the vulnerability allows a threat to be realised in a deliberate or accidental manner), as this may have a bearing on policies, procedures and penalties.
(c) Extent, in which it is discussed what type of threat(s) might be realised by the vulnerability, both in the first instance and subsequently (giving some justification for the statements regarding impact).
(d) Impact on the organisation, possibly in both financial and non-financial terms. The impact may be expressed as a range, rather than a discrete value. Examples of non- financial impact are “negligible”, “little” (where alternative workarounds are available with comparatively little effort and expense), and “complete” (the organisation will fold). The expression of non-financial impact is purely up to the ability, imagination and experience of the CSP author.
(e) Cause, in which a brief discussion is given of the primary reasons behind how and why the vulnerability may lead to the realisation of the threat.
(f) Solutions (possibly) to either effectively negate the cause or minimise the impact.
4.10 Rights and Responsibilities of Users
This section (and the next two) are the heart and soul of a CSP. It can be difficult to draw distinct lines between the rights and responsibilities of users and the resource provider, since many issues may be considered to be in the domain of either (privacy being one such issue). The key to writing this section and the next is to make a firm decision on which issues belong in which section (e.g. by preparing a detailed table of contents) and thus avoid duplication and complexity.
Issues that could be addressed in this section are listed below.
(a) Account use, by both the account holder and the resource provider. Special conditions may apply to the use of normal user accounts, and public access accounts (like anonymous ftp), and these conditions could be expressed here.
(b) Software and data access and use, including sources of data and software.
(c) Disclosure of information which is potentially harmful, such as password information or system configuration information.
(d) Etiquette, including acceptable forms of expression (e.g. non-offensive expression expected for unsolicited electronic mail), and unacceptable practices (such as the forging of electronic mail and news articles).
(e) Password use and format.
(f) Rights to privacy, and the circumstances under which the resource provider may intrude on the files held under or activities practiced by an account.
(g) Other miscellaneous guidelines regarding reasonable practices, such as the use of CPU cycles and temporary general access storage areas. Copyright issues may also be discussed here.
4.11 Rights and Responsibilities of the Resource Provider
There is a myriad of information that could be placed in this section. The content of this section assumes a large degree of importance (indeed, probably more than the previous section) when one considers recent statistics regarding the proportion of crimes involving computers that are committed by people internal (or recently internal) to the organisation.
Some (but by no means all) issues that could be addressed here include:
- contact information;
- dial-up access;
- host configuration guidelines, including:
- allocation of responsibility;
- network connection guidelines;
- authentication guidelines;
- authority to hold and grant account guidelines;
- auditing and monitoring guidelines;
- password format, enforcement and lifetime
- login banners;
- network construction, configuration and use guidelines,
- allocation of responsibility;
- supported protocols;
- network design principles;
- address allocation and authority guidelines; and
- use of network management and other equipment;
- physical security guidelines; and
- privacy guidelines.
There are no doubt many other issues and principles that could be discussed in this section. The content of this section is really a product of the basic philosophy of the organisation providing the resource.
A stated function of a CSP is to form a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP needs to offer to those who must take action, necessary guidelines as to what authority they have in order to minimise the impact of that breach. Furthermore, after the breach, the policy must provide guidelines for courses of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach.
It is therefore obvious that this section is also a non-trivial section concerned only with identification and discipline.
There could be a subsection devoted entirely to security incident handling principles. This subsection would be used directly in the construction of a set of procedures to be followed in the event of an actual security breach in progress. It could broach such issues such as:
parties who should be notified, and the method and urgency of such notification;
policy on the necessity, timing and requirements of any backups taken and logging that must be carried out;
computer system and network isolation authority and guidelines;
statement of entrapment policy (if this is not already expressed in the CSP philosophy); and
statement of policies and requirements should an alleged offender be traceable and possibly confronted (particularly where actions may be affected by external requirements such as a Statute dictating that Security Officers must identify themselves).
It may be desirable to also offer guidelines for liability of personnel with regard to security breaches. Such policies may tend to encourage people who are the victims of ignorance but honest intent to offer information that can be used constructively to prevent future incidents, rather than attempt to hide details of a breach that they may have (somewhat innocently) been involved in.
This section also needs to discuss, in some detail, guidelines regarding investigation of incidents and courses of action that could be taken by decision-makers based upon details of the security breach. Such guidelines may include guidelines about referral of various matters to law enforcement agencies, as well as internal investigation and disciplinary principles.
There should be some emphasis placed upon not only minimising the impact of and recovering from a security breach, should one occur, but also in learning any constructive lessons possible from an incident. The way in which this can be done is to carry out a post-mortem of incidents. Requirements for post-mortem procedures and reports could be outlined in this section. Such a post-mortem could include preparation of reports containing details like cause and effect of the incident, side-effects of the incident, costs involved in terms of losses and recovery, and possible repulsion and impact minimisation strategies should a similar incident occur in future.
The absence of a Site Computer Security Policy leaves a large void in any organisation’s ability to operate effectively and maintain business continuity, and allows for ad-hoc decisions to be made by unauthorised personnel. Conversely, a well written and easily understandable Site Computer Security Policy provides an effective basis for decision making and planning. It gives the providers and users of a resource a clear understanding of what is expected, and what may be expected in return. Adherence to such a policy lends some evidence to an organisation’s integrity and trustworthiness.
Caelli, W., Longley, D. and Shain, M., Information Security Handbook, Macmillan Publishers Ltd, 1991. ISBN 0-333-51172-7.
Site Security Policy Handbook Working Group, “Site Security Handbook”, RFC 1244, Internet Engineering Task Force, July 1991.
Boldly going where no man has gone before, the Kirk Ransomware brings so much nerdy goodness to the table that it could make anyone in IT interested. We have Star Trek, Low Orbital Ion Cannons, a cryptocurrency payment other than Bitcoin, and a decryptor named Spock! Need I say more?
Discovered today by Avast malware researcher Jakub Kroustek, the Kirk Ransomware is written in Python and may be the first ransomware to utilize Monero as the ransom payment of choice.
At this time there are no known victims of this ransomware and it does not appear to be decryptable. For those who want to discuss this ransomware or receive updates about it, they can subscribe to our Kirk Ransomware Support & Help topic.
Kirk Ransomware uses Monero for Ransom Payments
Ever since Monero was released, it has been highly touted as a more secure and anonymous payment system than Bitcoin. This has caused underground criminal sites, like AlphaBay, to accept it as payment and for criminals to mine it using mining Trojans. It was only a matter of time until ransomware developers started requesting it.
For possibly the first time, with the release of Kirk Ransomware, Monero has been introduced as a ransom payment. The problem is that this is only going to confuse victims even more. Even with Bitcoin becoming more accepted, it is still not easy to acquire them. By introducing a new cryptocurrency into the mix, victims are just going to become more confused and make paying ransoms even more difficult.
How the Kirk Ransomware Encrypts a Computer
While it is not currently known how the Kirk Ransomware is being distributed, we do know that it is masquerading as the network stress tool called Low Orbital Ion Cannon. Currently named loic_win32.exe, when executed Kirk Ransomware will now generate a AES password that will be used to encrypt a victim’s files. This AES key will then be encrypted by an embedded RSA-4096 public encryption key and saved in the file called pwd in the same directory as the ransomware executable.
If you plan on paying the ransom for the Kirk Ransomware, you must not delete the pwd file as it contains an encrypted version of your decryption key. Only the ransomware developer can decrypt this file and if a victim wishes to pay the ransom they will be required to send them this file.
Below is the current embedded RSA key used to encrypt the victim’s encryption key.
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
Kirk Ransomware will now display a message box that displays the same slogan as the LOIC network stress tool. This slogan is: “Low Orbital Ion Cannon | When harpoons, air strikes and nukes fail | v126.96.36.199”.
At this point, the ransomware infection will begin to scan the C: drive for files that have certain file extensions. At the time of this writing, Kirk Ransomware targets 625 file types, which are listed at the end of the article.
If a matching file is detected, it will encrypt it using the previously created AES encryption key and then append the .kirked extension to the encrypted file’s name. For example, a file called test.jpg would be encrypted and renamed to test.jpg.kirked.
When the ransomware finishes encrypting the files it will drop a ransom note called RANSOM_NOTE.txt in the same folder as the executable. It will also display the ransom note in a Window on your desktop. A full version of the ransom note can be see at the end of the article.
This ransom note tells the victim that they must purchase ~1,100 worth of the Monero currency and send it to the enclosed Monero address. Once a payment is made, the victim must email the pwd file and the payment transaction ID to the email@example.com or firstname.lastname@example.org email addresses to receive the decryptor.
The Spock Decryptor
This wouldn’t be a Star Trek themed ransomware without Spock. The developer agrees as they have named the decryptor “Spock” and it will be supplied to the victim once a a payment is made.
At this time we have not seen a sample of the decryptor, so cannot provide more info regarding it.
As previously said, unfortunately at this time the ransomware does not look like it can be decrypted. For those who want to discuss this ransomware or receive updates about it, they can subscribe to our Kirk Ransomware Support & Help topic.
oWMKxd, .,lxNKKOo;. :xWXklcc;. ...'.
k lMMNl . ON. :c. ''. ':....
.WXc ;WMMMXNNXKKxdXMM. . .
.NdoK: XMMMMMMMMMMMMMMM;oo; ...;,cxxxll. .
KK:xKKWMMMXNMMMMW; .. :WNKd, .. .'cdOXKXNNNNNWWMMMMMMMW0,
lNMXXMMMMMMMMWWMMWKk, ;0k' .,cxxk0K0O0XXWWMMMMMMMMMMMMMMX:.. ..
..,;XMMMMMMMWXWWK0KK: .;. .:lddddxOOO0XWMMMMMMMMMMMMMMMMMMO. .,
.kKXMMMMMWkoxolcc;.. .':loodxO00OO0NNXNWMMMMMMMMMMMMMMMN; '.
.MK;kWMMMWWKOc. . ..';cdxkKNX0kOOOKNMMMMMMMMMMMMMMMMMW: .
,MW:,:x0NMMMMWW0x' ..,:dXNWW0xkkKWMMMMMMMMMMMMMMMMMMWk. ..
oMMN; ;odoccc;c:. ...lXWWMOok0NMMMMMWNXKXKXWMMMMMMMOc.
XMMMX, ....';lldkWkodK0loc'. .'lxx0kOKNMMMXo.
'XMMMMMNc .dldXWx. ..,,coOXOkXMMMK,
,. .:dk0KNWMk. ... .kWMK,. ..:c .:.. .0MWMMMMO.
.':x0K0:. .. . . .OWMNNXO:cccdxKXWMW0o0WWMMMM;.
00000000000kdl:,'. ..'o00l 'KMMNKNWWNKXWWMMMMMMMMMMMMMM0.
0000000000000000000Oxl:' .;xKWWx .xNMMMWNMMMMMMMMMMMMMMMMMMMMMMl
0000000000000000000000000x;. ..,::,. .ck0KKk' '0WMMMMMMMWWMMMMMMMMMMMMMMMMMM0. .'
0000000000000000000000000000Oxdllc:;,....,'... .cdkOko: ,cOKKXWMMMKd0WMMMMMMMMMMMMMWW0. 'Kc:,
000000000000000000000000000000000OkkkxdoodxOkoooool .;okOx, .,'...cKMXl'oKWMMMMMMMWWNXN0 'MMc0.
0000OO000000000000000000000000000000000000000kc. .:dk0c ,KNKxdKMMM0;;kMMMMMMMMWNKXO ,kW0xl
OdloxO000000000000000000000000000000000000000000x, .,ll; .lokKWMMMMMMMMM0xNMMMMMMMNXXNo.xK;cXKx
lx000000000000000000000000000000000000000000000000l .'.. .'cKWXOXMMMMMMMMMMMMMMMMMWWNXXNKX0MNkNK0..
00000000000000000000000000000000000000000000000000O .. ..,;ok0X000KKXWMNNMMMMMMMMNNXKKXX00MMMWWc',
00000000000000000000000000000000000000000000000000d .. ..........;;.cKMMMMMWNXKKXNKxkNMMX,
:;ok00000000000000000000000000000000000O.;.d00000dc ... .........cONMMMMMMMMMNXXXN0dlddxN.
.dk000000000000000000000000000000000000;ld,.O00kocc .. ...,;::lokKNMMMMMMMMWKOO0OxloocxM:
OO0000000000000000000000000000000000000ol0Koc0xc:ll . ..;lxO0XNNMMMMMMMMMMMN0xoxOdl::,;0Md
:;,'..;loxk000000000000000000000000000000000lx..loo ,0 .'';lkKKNMMMMMMMMMNOd:;lc:;'..,kWMK
cccldxkkkO00Okdooddxk00000000000000000000000Oc'lddl dK, .':ollokOOOOOOOc'.........lXMMMM,
000000kdoc,....;cldkO0000000000000000000000Okdodddo'K0'. ....... .oKMMMMMM0
_ _____ ____ _ __ ____ _ _ _ ____ ___ __ ____ ___ ____ _____
| |/ /_ _| _ \| |/ / | _ \ / \ | \ | / ___| / _ \| \/ \ \ / / \ | _ \| ____|
| ' / | || |_) | ' / | |_) | / _ \ | \| \___ \| | | | |\/| |\ \ /\ / / _ \ | |_) | _|
| . \ | || _ <| . \ | _ < / ___ \| |\ |___) | |_| | | | | \ V V / ___ \| _ <| |___
|_|\_\___|_| \_\_|\_\ |_| \_\/_/ \_\_| \_|____/ \___/|_| |_| \_/\_/_/ \_\_| \_\_____|
Oh no! The Kirk ransomware has encrypted your files!
> ! IMPORTANT ! READ CAREFULLY:
Your computer has fallen victim to the Kirk malware and important files have been encrypted - locked
up so they don't work. This may have broken some software, including games, office suites etc.
Here's a list of some the file extensions that were targetted:
.3g2 .rar .jar .cgi .class .jtd .potx .xex .dds
.3gp .jpg .csv .pl .cd .jtt .potm .tiger .ff
.asf .jpeg .psd .com .java .hwp .sda .lbf .yrp
.asx .png .wav .wsf .swift .602 .sdd .cab .pck
.avi .tiff .ogg .bmp .vb .pdb .sdp .rx3 .t3
.flv .zip .wma .bmp .ods .psw .cgm .epk .ltx
.ai .7z .aif .gif .xlr .xlw .wotreplay.vol .uasset
.m2ts .dif.z .mpa .tif .xls .xlt .rofl .asset .bikey
.mkv .exe .wpl .tiff .xlsx .xlsm .pak .forge .patch
.mov .tar.gz .arj .htm .dot .xltx .big .lng .upk
.mp4 .tar .deb .js .docm .xltm .bik .sii .uax
.mpg .mp3 .pkg .jsp .dotx .xlsb .xtbl .litemod .mdl
.mpeg .sh .db .php .dotm .wk1 .unity3d .vef .lvl
mpeg4 .c .dbf .xhtml .wpd .wks .capx .dat .qst
.rm .cpp .sav .cfm .wps .123 .ttarch .papa .ddv
.swf .h .xml .rss .rtf .sdc .iwi .psark .pta
.vob .mov .html .key .sdw .slk .rgss3a .ydk
.wmv .gif .aiml .odp .sgl .pxl .gblorb .mpq
.doc .txt .apk .pps .vor .wb2 .xwm .wtf
.docx .py .bat .ppt .uot .pot .j2e .bsa
.pdf .pyc .bin .pptx .uof .pptm .mpk .re4
There are an additional 441 file extensions that are targetted. They are mostly to do with games.
To get your files back, you need to pay. Now. Payments recieved more than 48 hours after the time of
infection will be charged double. Further time penalties are listed below. The time of infection has
Any files with the extensions listed above will now have the extra extension '.kirked', these files
are encrypted using military grade encryption.
In the place you ran this program from, you should find a note (named RANSOM_NOTE.txt) similar to this one.
You will also find a file named 'pwd' - this is your encrypted password file. Although it was
generated by your computer, you have no way of ever decrypting it. This is due to the security
of both the way it was generated and the way it was encrypted. Your files were encrypted using
____ ____ ___ ____ _ __ _____ ___ _____ _ _ _____ ____ _____ ____ ____ _ _ _____ _
/ ___|| _ \ / _ \ / ___| |/ / |_ _/ _ \ |_ _| | | | ____| | _ \| ____/ ___| / ___| | | | ____| |
\___ \| |_) | | | | | | ' / | || | | | | | | |_| | _| | |_) | _| \___ \| | | | | | _| | |
___) | __/| |_| | |___| . \ | || |_| | | | | _ | |___ | _ <| |___ ___) | |___| |_| | |___|_|
|____/|_| \___/ \____|_|\_\ |_| \___/ |_| |_| |_|_____| |_| \_\_____|____/ \____|\___/|_____(_)
"Logic, motherfucker." ~ Spock.
Decrypting your files is easy. Take a deep breath and follow the steps below.
1 ) Make the proper payment.
Payments are made in Monero. This is a crypto-currency, like bitcoin.
You can buy Monero, and send it, from the same places you can any other
crypto-currency. If you're still unsure, google 'bitcoin exchange'.
Sign up at one of these exchange sites and send the payment to the address below.
Make note of the payment / transaction ID, or make one up if you have the option.
Payment Address (Monero Wallet):
Days : Monero : Offer Expires
0-2 : 50 : 03/18/17 15:32:14
3-7 : 100 : 03/23/17 15:32:14
8-14 : 200 : 03/30/17 15:32:14
15-30 : 500 : 04/15/17 15:32:14
Note: In 31 days your password decryption key gets permanently deleted.
You then have no way to ever retrieve your files. So pay now.
2 ) Email us.
Send your pwd file as an email attachment to one of the email addresses below.
Include the payment ID from step 1.
Active email addresses:
3 ) Decrypt your files.
You will recieve your decrypted password file and a program called 'Spock'.
Download these both to the same place and run Spock.
Spock reads in your decrypted password file and uses it to decrypt all of the
affected files on your computer.
> IMPORTANT !
The password is unique to this infection.
Using an old password or one from another machine will result in corrupted files.
Corrupted files cannot be retrieved.
Don't fuck around.
4 ) Breathe.
_ _____ _______ _ ___ _ _ ____
| | |_ _\ \ / / ____| | | / _ \| \ | |/ ___|
| | | | \ \ / /| _| | | | | | | \| | | _
| |___ | | \ V / | |___ | |__| |_| | |\ | |_| |
|_____|___| \_/ |_____| |_____\___/|_| \_|\____|
_ _ _ ____ ____ ____ ___ ____ ____ _____ ____
/ \ | \ | | _ \ | _ \| _ \ / _ \/ ___|| _ \| ____| _ \
/ _ \ | \| | | | | | |_) | |_) | | | \___ \| |_) | _| | |_) |
/ ___ \| |\ | |_| | | __/| _ <| |_| |___) | __/| |___| _ <
/_/ \_\_| \_|____/ |_| |_| \_\\___/|____/|_| |_____|_| \_\
In my previous post “Pentestit Lab v10 – The Mail Token”, we attained usernames through Intelligence Gathering, brute forced the SMTP Service, attained login credentials, and scored our first token. Today we will take our first steps at compromising the Global Data Security website – which will include the following:
A web application is the target of a SQL injection attack, so you must understand how these apps work. A web app can be described simply as an application that is accessed through a web browser or application (such as the apps on a smartphone). However, we need to be a little more detailed with our description in order to better understand SQL injection. In essence, a web application works by performing these steps:
The user makes a request through the web browser from the Internet to the web server.
The web server accepts the request and forwards it to the applicable web application server.
The web application server performs the requested task.
The web application accesses the entire database available and responds to the web server.
The web server responds back to the user once the transaction is complete.
The requested information appears on the user’s monitor. The details involved in these steps can change depending on the application involved.
Server-side vs. Client-side
First let’s look at the type of technologies involved in browsing and working with the Web. They mainly fall into two areas: client-side and server-side. Server-side technologies are those that run and are executed on the server itself before delivering information to the requester. Client-side technologies are those that run within the browser or somewhere on the client side. For the purposes of our discussion, we will not be covering client-side here.
Server-side technologies come in many varieties and types, each of which offers something specific to the user. Generally, each of the technologies allows for the creation of dynamic and data-driven web applications. There are a wide range of server-side technologies that you can use to create these types of web applications, among them:
All of these technologies are powerful and offer the ability to generate web applications that are extremely versatile. Each also has vulnerabilities that can lead to them being compromised, but this chapter is not about those. This chapter, like SQL injection, is designed to target the code that is used to make the technologies access a database as part of its functioning. This code, when incorrectly crafted, can be scrutinized and result in vulnerabilities uncovered and exploited.
SQL injection has been around for at least 20 years, but it is no less powerful or dangerous than any other attack we have covered so far. It is designed to exploit flaws in a website or web application. The attack works by inserting code into an existing line of code prior to its being executed by a database. If SQL injection is successful, attackers can cause their own code to run. In the real world this attack has proven dangerous because many developers are either not aware of the threat or don’t understand its seriousness. Developers should be aware that:
SQL injection is typically a result of flaws in the web application or website and is not an issue with the database.
SQL injection is at the source of many of the high-level or well-known attacks on the Internet.
The goal of attacks of this type is to submit commands through a web application to a database in order to retrieve or manipulate data. • The usual cause of this type of flaw is improper or absent input validation, thus allowing code to pass unimpeded to the database without being verified.
SQL Attacks in Action
In 2011, Sony Corporation was the victim of a SQL injection that compromised a multitude of accounts (estimated to be over one million e-mails, usernames, and passwords). The FBI revealed that a minimum of 100,000 records, including Social Security numbers of current and former federal employees, were compromised. Additionally, 2,800 of the records obtained included bank account numbers. When investigating this attack, the FBI revealed that not only the DoE and the Army were impacted; NASA, the U.S. Missile Defense Agency, and the Environmental Protection Agency were also affected. Details of these attacks have not been fully released as of this writing. SQL injection is achieved through the insertion of characters into existing SQL commands with the intention of altering the intended behavior. The following example illustrates SQL injection in action and how it is carried out. The example also reveals the impact of altering the existing values and structure of a SQL query.
In the following example, an attacker with the username link inputs for the original code after the = sign in WHERE owner which used to include the string ‘name’; DELETE FROM items; — for itemName into an existing SQL command, and the query becomes the following two queries:
SELECT * FROM items
WHERE owner = 'link'
AND itemname = 'name';
DELETE FROM items;--
Many of the common database products such as Microsoft’s SQL Server and Oracle’s Siebel allow several SQL statements separated by semicolons to be executed at once. This technique, known as batch execution, allows an attacker to execute multiple arbitrary commands against a database. In other databases, this technique will generate an error and fail, so knowing the database you are attacking is essential.
If an attacker enters the string ‘name’; DELETE FROM items; SELECT * FROM items WHERE ‘a’ = ‘a’, the following three valid statements will be created:
SELECT * FROM items
WHERE owner = 'link'
AND itemname = 'name';
DELETE FROM items;
SELECT * FROM items WHERE 'a' = 'a';
A good way to prevent SQL injection attacks is to use input validation, which ensures that only approved characters are accepted. Use whitelists, which dictate safe characters, and blacklists, which dictate unsafe characters.
Results of SQL Injection
What can be accomplished as a result of a SQL injection attack? Well, there are a huge number of possibilities, which are limited only by the configuration of the system and the skill of the attacker.
If an attack is successful, a host of problems could result. Consider the following a sample of the potential outcomes:
Identity spoofing through manipulating databases to insert bogus or misleading information such as e-mails and contact information.
Alteration of prices in e-commerce applications. In this attack, the intruder once again alters data, but does so with the intention of changing price information in order to purchase products or services at a reduced rate.
Alteration of data or outright replacement of data in existing databases with information created by the attacker.
Escalation of privileges to increase the level of access an attacker has to the system, up to and including full administrative access to the operating system.
Denial of service, performed by flooding the server with requests designed to overwhelm the system.
Data extraction and disclosure of all data on the system through the manipulation of the database.
Destruction or corruption of data through rewriting, altering, or other means.
Eliminating or altering transactions that have been or will be committed
Next up will be all about the anatomy of a SQL Injection and Database vulnerabilities.