'CEOinIRVINE'에 해당되는 글 2282건

  1. 2020.02.01 How to utilize Kali (Virtual Box) by CEOinIRVINE
  2. 2019.12.13 What is SQL injection (SQLi)? by CEOinIRVINE
  3. 2019.12.13 What is SQL injection (SQLi)? by CEOinIRVINE
  4. 2019.04.03 Accuracy, Precision, Recall or F1, Artificial Intelligence, Statistics by CEOinIRVINE
  5. 2019.04.03 AI Test DATA from UCI by CEOinIRVINE
  6. 2016.12.27 Major Cyberattacks On Healthcare Grew 63% In 2016 by CEOinIRVINE
  7. 2016.12.27 A Cybersecurity Christmas Story by CEOinIRVINE
  8. 2016.12.27 Brute-Force Botnet Attacks Now Elude Volumetric Detection by CEOinIRVINE
  9. 2016.12.27 Russian Hackers Run Record-Breaking Online Ad-Fraud Operation by CEOinIRVINE
  10. 2016.09.23 itune back up D drive by CEOinIRVINE

 

1. https://www.virtualbox.org/wiki/Downloads

 

Downloads – Oracle VM VirtualBox

Download VirtualBox Here you will find links to VirtualBox binaries and its source code. VirtualBox binaries By downloading, you agree to the terms and conditions of the respective license. If you're looking for the latest VirtualBox 6.0 packages, see Virt

www.virtualbox.org

 

Please install Virtual Box. 

Window user, Click Window Host

MAC user, Click OS X Host

 

 

2. Install Extension:

supported platforms

불러오는 중입니다...

 

3. Install 

Kali Linux VirtualBox 32-Bit

불러오는 중입니다...

There are two version of VirtualBox images, 32 bit vs 64 bit. 

Bottom line is 64bit is a little bit faster. However, for the safe, I recommend you to use 32 bit.

 

 

Pros for 64:

  • Programs may run a bit faster.
  • Can use all 4 GB RAM without any special kernel.
  • Allows running virtual machines with 64-bit guest OS. Newer VM versions may allow this on 32-bit hosts as well, though.

Pros for 32:

  • Less hassle using 32-bit applications and packages, allthough running 32-bit applications should work in 64-bit environment too.
  • Allows development linking to 32-bit (usually proprietary) libraries.

4. Double Click OVA file

5. default ID/PASSWD is kali/kali.

 

Thank you.

Justin Choi

 

Posted by CEOinIRVINE
l

What is SQL injection (SQLi)?

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.

In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack.

 

What is the impact of a successful SQL injection attack?

A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information. Many high-profile data breaches in recent years have been the result of SQL injection attacks, leading to reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise that can go unnoticed for an extended period.

 

Retrieving hidden data

Consider a shopping application that displays products in different categories. When the user clicks on the Gifts category, their browser requests the URL:

https://insecure-website.com/products?category=Gifts

This causes the application to make an SQL query to retrieve details of the relevant products from the database:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

This SQL query asks the database to return:

  • all details (*)
  • from the products table
  • where the category is Gifts
  • and released is 1.

The restriction released = 1 is being used to hide products that are not released. For unreleased products, presumably released = 0.

The application doesn't implement any defenses against SQL injection attacks, so an attacker can construct an attack like:

https://insecure-website.com/products?category=Gifts'--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

The key thing here is that the double-dash sequence -- is a comment indicator in SQL, and means that the rest of the query is interpreted as a comment. This effectively removes the remainder of the query, so it no longer includes AND released = 1. This means that all products are displayed, including unreleased products.

Going further, an attacker can cause the application to display all the products in any category, including categories that they don't know about:

https://insecure-website.com/products?category=Gifts'+OR+1=1--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

The modified query will return all items where either the category is Gifts, or 1 is equal to 1. Since 1=1 is always true, the query will return all items.

LABSQL injection vulnerability in WHERE clause allowing retrieval of hidden data

Subverting application logic

Consider an application that lets users log in with a username and password. If a user submits the username wiener and the password bluecheese, the application checks the credentials by performing the following SQL query:

SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

If the query returns the details of a user, then the login is successful. Otherwise, it is rejected.

Here, an attacker can log in as any user without a password simply by using the SQL comment sequence -- to remove the password check from the WHERE clause of the query. For example, submitting the username administrator'-- and a blank password results in the following query:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

This query returns the user whose username is administrator and successfully logs the attacker in as that user.

LABSQL injection vulnerability allowing login bypass

Retrieving data from other database tables

In cases where the results of an SQL query are returned within the application's responses, an attacker can leverage an SQL injection vulnerability to retrieve data from other tables within the database. This is done using the UNION keyword, which lets you execute an additional SELECT query and append the results to the original query.

For example, if an application executes the following query containing the user input "Gifts":

SELECT name, description FROM products WHERE category = 'Gifts'

then an attacker can submit the input:

' UNION SELECT username, password FROM users--

This will cause the application to return all usernames and passwords along with the names and descriptions of products.

Read moreSQL injection UNION attacks

Examining the database

Following initial identification of an SQL injection vulnerability, it is generally useful to obtain some information about the database itself. This information can often pave the way for further exploitation.

You can query the version details for the database. The way that this is done depends on the database type, so you can infer the database type from whichever technique works. For example, on Oracle you can execute:

SELECT * FROM v$version

You can also determine what database tables exist, and which columns they contain. For example, on most databases you can execute the following query to list the tables:

SELECT * FROM information_schema.tables

Read moreExamining the database in SQL injection attacksSQL injection cheat sheet

Blind SQL injection vulnerabilities

Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.

Depending on the nature of the vulnerability and the database involved, the following techniques can be used to exploit blind SQL injection vulnerabilities:

  • You can change the logic of the query to trigger a detectable difference in the application's response depending on the truth of a single condition. This might involve injecting a new condition into some Boolean logic, or conditionally triggering an error such as a divide-by-zero.
  • You can conditionally trigger a time delay in the processing of the query, allowing you to infer the truth of the condition based on the time that the application takes to respond.
  • You can trigger an out-of-band network interaction, using OAST techniques. This technique is extremely powerful and works in situations where the other techniques do not. Often, you can directly exfiltrate data via the out-of-band channel, for example by placing the data into a DNS lookup for a domain that you control.

Read moreBlind SQL injection

How to detect SQL injection vulnerabilities

The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

SQL injection can be detected manually by using a systematic set of tests against every entry point in the application. This typically involves:

  • Submitting the single quote character ' and looking for errors or other anomalies.
  • Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and looking for systematic differences in the resulting application responses.
  • Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the application's responses.
  • Submitting payloads designed to trigger time delays when executed within an SQL query, and looking for differences in the time taken to respond.
  • Submitting OAST payloads designed to trigger an out-of-band network interaction when executed within an SQL query, and monitoring for any resulting interactions.

SQL injection in different parts of the query

Most SQL injection vulnerabilities arise within the WHERE clause of a SELECT query. This type of SQL injection is generally well-understood by experienced testers.

But SQL injection vulnerabilities can in principle occur at any location within the query, and within different query types. The most common other locations where SQL injection arises are:

  • In UPDATE statements, within the updated values or the WHERE clause.
  • In INSERT statements, within the inserted values.
  • In SELECT statements, within the table or column name.
  • In SELECT statements, within the ORDER BY clause.

Second-order SQL injection

First-order SQL injection arises where the application takes user input from an HTTP request and, in the course of processing that request, incorporates the input into an SQL query in an unsafe way.

In second-order SQL injection (also known as stored SQL injection), the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability arises at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into an SQL query in an unsafe way.

 

 

Second-order SQL injection often arises in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.

Database-specific factors

Some core features of the SQL language are implemented in the same way across popular database platforms, and so many ways of detecting and exploiting SQL injection vulnerabilities work identically on different types of database.

However, there are also many differences between common databases. These mean that some techniques for detecting and exploiting SQL injection work differently on different platforms. For example:

  • Syntax for string concatenation.
  • Comments.
  • Batched (or stacked) queries.
  • Platform-specific APIs.
  • Error messages.

Read moreSQL injection cheat sheet

How to prevent SQL injection

Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.

The following code is vulnerable to SQL injection because the user input is concatenated directly into the query:

String query = "SELECT * FROM products WHERE category = '"+ input + "'";

Statement statement = connection.createStatement();

ResultSet resultSet = statement.executeQuery(query);

This code can be easily rewritten in a way that prevents the user input from interfering with the query structure:

PreparedStatement statement = connection.prepareStatement("SELECT * FROM products WHERE category = ?");

statement.setString(1, input);

ResultSet resultSet = statement.executeQuery();

Parameterized queries can be used for any situation where untrusted input appears as data within the query, including the WHERE clause and values in an INSERT or UPDATE statement. They can't be used to handle untrusted input in other parts of the query, such as table or column names, or the ORDER BY clause. Application functionality that places untrusted data into those parts of the query will need to take a different approach, such as white-listing permitted input values, or using different logic to deliver the required behavior.

For a parameterized query to be effective in preventing SQL injection, the string that is used in the query must always be a hard-coded constant, and must never contain any variable data from any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and continue using string concatenation within the query for cases that are considered safe. It is all too easy to make mistakes about the possible origin of data, or for changes in other code to violate assumptions about what data is tainted.

 

Posted by CEOinIRVINE
l

What is SQL injection (SQLi)?

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.

In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack.

 

What is the impact of a successful SQL injection attack?

A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information. Many high-profile data breaches in recent years have been the result of SQL injection attacks, leading to reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise that can go unnoticed for an extended period.

 

Retrieving hidden data

Consider a shopping application that displays products in different categories. When the user clicks on the Gifts category, their browser requests the URL:

https://insecure-website.com/products?category=Gifts

This causes the application to make an SQL query to retrieve details of the relevant products from the database:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

This SQL query asks the database to return:

  • all details (*)
  • from the products table
  • where the category is Gifts
  • and released is 1.

The restriction released = 1 is being used to hide products that are not released. For unreleased products, presumably released = 0.

The application doesn't implement any defenses against SQL injection attacks, so an attacker can construct an attack like:

https://insecure-website.com/products?category=Gifts'--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

The key thing here is that the double-dash sequence -- is a comment indicator in SQL, and means that the rest of the query is interpreted as a comment. This effectively removes the remainder of the query, so it no longer includes AND released = 1. This means that all products are displayed, including unreleased products.

Going further, an attacker can cause the application to display all the products in any category, including categories that they don't know about:

https://insecure-website.com/products?category=Gifts'+OR+1=1--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

The modified query will return all items where either the category is Gifts, or 1 is equal to 1. Since 1=1 is always true, the query will return all items.

LABSQL injection vulnerability in WHERE clause allowing retrieval of hidden data

Subverting application logic

Consider an application that lets users log in with a username and password. If a user submits the username wiener and the password bluecheese, the application checks the credentials by performing the following SQL query:

SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

If the query returns the details of a user, then the login is successful. Otherwise, it is rejected.

Here, an attacker can log in as any user without a password simply by using the SQL comment sequence -- to remove the password check from the WHERE clause of the query. For example, submitting the username administrator'-- and a blank password results in the following query:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

This query returns the user whose username is administrator and successfully logs the attacker in as that user.

LABSQL injection vulnerability allowing login bypass

Retrieving data from other database tables

In cases where the results of an SQL query are returned within the application's responses, an attacker can leverage an SQL injection vulnerability to retrieve data from other tables within the database. This is done using the UNION keyword, which lets you execute an additional SELECT query and append the results to the original query.

For example, if an application executes the following query containing the user input "Gifts":

SELECT name, description FROM products WHERE category = 'Gifts'

then an attacker can submit the input:

' UNION SELECT username, password FROM users--

This will cause the application to return all usernames and passwords along with the names and descriptions of products.

Read moreSQL injection UNION attacks

Examining the database

Following initial identification of an SQL injection vulnerability, it is generally useful to obtain some information about the database itself. This information can often pave the way for further exploitation.

You can query the version details for the database. The way that this is done depends on the database type, so you can infer the database type from whichever technique works. For example, on Oracle you can execute:

SELECT * FROM v$version

You can also determine what database tables exist, and which columns they contain. For example, on most databases you can execute the following query to list the tables:

SELECT * FROM information_schema.tables

Read moreExamining the database in SQL injection attacksSQL injection cheat sheet

Blind SQL injection vulnerabilities

Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.

Depending on the nature of the vulnerability and the database involved, the following techniques can be used to exploit blind SQL injection vulnerabilities:

  • You can change the logic of the query to trigger a detectable difference in the application's response depending on the truth of a single condition. This might involve injecting a new condition into some Boolean logic, or conditionally triggering an error such as a divide-by-zero.
  • You can conditionally trigger a time delay in the processing of the query, allowing you to infer the truth of the condition based on the time that the application takes to respond.
  • You can trigger an out-of-band network interaction, using OAST techniques. This technique is extremely powerful and works in situations where the other techniques do not. Often, you can directly exfiltrate data via the out-of-band channel, for example by placing the data into a DNS lookup for a domain that you control.

Read moreBlind SQL injection

How to detect SQL injection vulnerabilities

The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

SQL injection can be detected manually by using a systematic set of tests against every entry point in the application. This typically involves:

  • Submitting the single quote character ' and looking for errors or other anomalies.
  • Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and looking for systematic differences in the resulting application responses.
  • Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the application's responses.
  • Submitting payloads designed to trigger time delays when executed within an SQL query, and looking for differences in the time taken to respond.
  • Submitting OAST payloads designed to trigger an out-of-band network interaction when executed within an SQL query, and monitoring for any resulting interactions.

SQL injection in different parts of the query

Most SQL injection vulnerabilities arise within the WHERE clause of a SELECT query. This type of SQL injection is generally well-understood by experienced testers.

But SQL injection vulnerabilities can in principle occur at any location within the query, and within different query types. The most common other locations where SQL injection arises are:

  • In UPDATE statements, within the updated values or the WHERE clause.
  • In INSERT statements, within the inserted values.
  • In SELECT statements, within the table or column name.
  • In SELECT statements, within the ORDER BY clause.

Second-order SQL injection

First-order SQL injection arises where the application takes user input from an HTTP request and, in the course of processing that request, incorporates the input into an SQL query in an unsafe way.

In second-order SQL injection (also known as stored SQL injection), the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability arises at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into an SQL query in an unsafe way.

 

Second-order SQL injection often arises in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.

Database-specific factors

Some core features of the SQL language are implemented in the same way across popular database platforms, and so many ways of detecting and exploiting SQL injection vulnerabilities work identically on different types of database.

However, there are also many differences between common databases. These mean that some techniques for detecting and exploiting SQL injection work differently on different platforms. For example:

  • Syntax for string concatenation.
  • Comments.
  • Batched (or stacked) queries.
  • Platform-specific APIs.
  • Error messages.

Read moreSQL injection cheat sheet

How to prevent SQL injection

Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.

The following code is vulnerable to SQL injection because the user input is concatenated directly into the query:

String query = "SELECT * FROM products WHERE category = '"+ input + "'";

Statement statement = connection.createStatement();

ResultSet resultSet = statement.executeQuery(query);

This code can be easily rewritten in a way that prevents the user input from interfering with the query structure:

PreparedStatement statement = connection.prepareStatement("SELECT * FROM products WHERE category = ?");

statement.setString(1, input);

ResultSet resultSet = statement.executeQuery();

Parameterized queries can be used for any situation where untrusted input appears as data within the query, including the WHERE clause and values in an INSERT or UPDATE statement. They can't be used to handle untrusted input in other parts of the query, such as table or column names, or the ORDER BY clause. Application functionality that places untrusted data into those parts of the query will need to take a different approach, such as white-listing permitted input values, or using different logic to deliver the required behavior.

For a parameterized query to be effective in preventing SQL injection, the string that is used in the query must always be a hard-coded constant, and must never contain any variable data from any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and continue using string concatenation within the query for cases that are considered safe. It is all too easy to make mistakes about the possible origin of data, or for changes in other code to violate assumptions about what data is tainted.

 

Posted by CEOinIRVINE
l

Accuracy, Precision, Recall or F1?

 

Often when I talk to organizations that are looking to implement data science into their processes, they often ask the question, “How do I get the most accurate model?”. And I asked further, “What business challenge are you trying to solve using the model?” and I will get the puzzling look because the question that I posed does not really answer their question. I will then need to explain why I asked the question before we start exploring if Accuracy is the be-all and end-all model metric that we shall choose our “best” model from.

So I thought I will explain in this blog post that Accuracy need not necessary be the one-and-only model metrics data scientists chase and include simple explanation of other metrics as well.

Firstly, let us look at the following confusion matrix. What is the accuracy for the model?

Very easily, you will notice that the accuracy for this model is very very high, at 99.9%!! Wow! You have hit the jackpot and holy grail (*scream and run around the room, pumping the fist in the air several times*)!

But….(well you know this is coming right?) what if I mentioned that the positive over here is actually someone who is sick and carrying a virus that can spread very quickly? Or the positive here represent a fraud case? Or the positive here represents terrorist that the model says its a non-terrorist? Well you get the idea. The costs of having a mis-classified actual positive (or false negative) is very high here in these three circumstances that I posed.

OK, so now you realized that accuracy is not the be-all and end-all model metric to use when selecting the best model…now what?

Precision and Recall

Let me introduce two new metrics (if you have not heard about it and if you do, perhaps just humor me a bit and continue reading? :D )

So if you look at Wikipedia, you will see that the the formula for calculating Precision and Recall is as follows:

Let me put it here for further explanation.

Let me put in the confusion matrix and its parts here.

Precision

Great! Now let us look at Precision first.

What do you notice for the denominator? The denominator is actually the Total Predicted Positive! So the formula becomes

True Positive + False Positive = Total Predicted Positive

Immediately, you can see that Precision talks about how precise/accurate your model is out of those predicted positive, how many of them are actual positive.

Precision is a good measure to determine, when the costs of False Positive is high. For instance, email spam detection. In email spam detection, a false positive means that an email that is non-spam (actual negative) has been identified as spam (predicted spam). The email user might lose important emails if the precision is not high for the spam detection model.

Recall

So let us apply the same logic for Recall. Recall how Recall is calculated.

True Positive + False Negative = Actual Positive

There you go! So Recall actually calculates how many of the Actual Positives our model capture through labeling it as Positive (True Positive). Applying the same understanding, we know that Recall shall be the model metric we use to select our best model when there is a high cost associated with False Negative.

For instance, in fraud detection or sick patient detection. If a fraudulent transaction (Actual Positive) is predicted as non-fraudulent (Predicted Negative), the consequence can be very bad for the bank.

Similarly, in sick patient detection. If a sick patient (Actual Positive) goes through the test and predicted as not sick (Predicted Negative). The cost associated with False Negative will be extremely high if the sickness is contagious.

F1 Score

Now if you read a lot of other literature on Precision and Recall, you cannot avoid the other measure, F1 which is a function of Precision and Recall. Looking at Wikipedia, the formula is as follows:

F1 Score is needed when you want to seek a balance between Precision and Recall. Right…so what is the difference between F1 Score and Accuracy then? We have previously seen that accuracy can be largely contributed by a large number of True Negatives which in most business circumstances, we do not focus on much whereas False Negative and False Positive usually has business costs (tangible & intangible) thus F1 Score might be a better measure to use if we need to seek a balance between Precision and Recall AND there is an uneven class distribution (large number of Actual Negatives).

I hope the explanation will help those starting out on Data Science and working on Classification problems, that Accuracy will not always be the metric to select the best model from.

 

Posted by CEOinIRVINE
l

test.csv
0.00MB

Posted by CEOinIRVINE
l

US hospitals lack new technologies and best practices to defend against threats, new report says.

Some 93 major cyberattacks hit healthcare organizations this year, up from 57 in 2015, new research shows.

TrapX Labs, a division of TrapX Security, found this 63% increase in attacks on the healthcare industry for the period between January 1, 2016 and December 12. Some may have been ongoing prior to Jan. 1, but for consistency, researchers only used official reporting dates to the Department of Health and Human Services, Office of Civil Rights (HHS OCR).

Among the largest attacks were those on Banner Health (3.6M records), Newkirk Products (3.4M records), 21st Century Oncology (2.2M records), and Valley Anesthesiology Consultants (0.88M records).


Sophisticated attackers are now responsible for 31% of all major HIPAA data breaches reported this year, a 300% increase over the past three years, according to the report. Cybercriminals were responsible for 10% of all major data breaches in 2014 and 21% in 2015.

Despite the rise in attacks, the number of records breached dropped to about 12,057,759. That said, so many millions of health records have been stolen that the value of individual records decreased this year, TrapX reported.

Researchers pinpointed two major trends from 2016: the continued discovery and evolution of medical device hijacking, which TrapX calls MEDJACK and MEDJACK.2, and the increase of ransomware across a variety of targets.

MEDJACK involves the use of backdoors in medical devices like diagnostic or life-support equipment. Hackers use emailed links, malware-equipped memory sticks, and corrupt websites to load tools into these devices, most of which run standard/older operating systems and proprietary software.

"Once inside the network, these attackers move laterally in search of high-profile targets from which they can ultimately exfiltrate intellectual property and patient data," says Moshe Ben-Simon, co-founder and VP of services at TrapX Labs.

One successful penetration is often enough to give hackers access to the network, where they can find unprotected devices to host attacks, chat with humans, and access information. It's difficult to mitigate the effects of MEDJACK; many hospitals don't even know it happens.

"Unfortunately, hospitals do not seem to be able to detect MEDJACK or remediate it," Simon explains. "The great majority of existing cyber-defense suites do not seem able to detect attackers moving laterally from these compromised devices."

Ransomware attacks on large and mid-sized healthcare organizations have also become more diverse. The financial depth and criticality of operations make them easy targets. It's one thing to close a business for one day; it's entirely different to force a hospital shutdown.

A July 2016 survey conducted by Solutionary discovered healthcare is the industry most frequently targeted by malware, accounting for 88% of all detections in Q2. Hackers target healthcare because organizations will usually pay ransom for valuable patient data.

TrapX researchers predict ransomware will reach "unprecedented levels" next year as quick ROI, and easy access to untraceable money such as Bitcoin, make it easier for hackers to launch more attacks at once


Posted by CEOinIRVINE
l

In the spirit of the holiday season and after a weekend marathon of watching the greatest Christmas movies ever made, I offer the following observations for my fellow cybersecurity friends and those chartered with defending critical assets.

CISO Ralphie Parker wants only one thing for Christmas: a Red Ryder Carbine Action 200-shot Range Model malware BB gun. Ralphie's desire is rejected by his CIO, his CFO, and even a department store Santa Claus security consultant, all of whom give him the same warning: "You'll shoot your eye out."

Christmas morning arrives, and Ralphie dives into his presents, opening a bunch of new cybersecurity tools. Although he receives some tools he enjoys, Ralphie is ultimately disappointed that he did not receive the one thing he wanted more than anything. After Ralphie thinks that all the presents have been opened, his father and CEO directs him to look at one last gift that he had hidden. Ralphie opens it to reveal the coveted Red Ryder malware BB gun.

Ralphie takes his new malware gun outside and fires it at the latest malware of the day. However, the BB ricochets back at Ralphie and knocks his SIEM glasses off his face. While searching for them, thinking he has indeed shot his eye out, Ralphie accidentally steps on his glasses and breaks them. To cover up the incident, Ralphie tells his CIO that a falling icicle was responsible for the cybersecurity breach.

We have all seen leadership become fascinated with the latest cybertool of the day and decide to throw it into the mix of existing tools, only to have things quickly go awry. Visibility, manageability, and interoperability are not often the primary goals when adding a new capability, making a difficult situation more complex.

While it is paramount that businesses and governments remain agile and competitive in our new reality, they also need to stay within acceptable levels of operational risk. Three overarching challenges continue to drive security strategies:

  1. There is more to defend, and the information footprint has expanded beyond the control of IT. We have gone from 25 to over 500,000 new threats per day in the last decade. Users are bypassing IT with cloud services and personal devices; many “users” are IoT and other specialized endpoints; more traffic is encrypted and invisible to IT; and massive amounts of data are moving to the cloud.
  2. We cannot move fast enough, despite seemingly significant efforts and investment. It is not unusual to take months or even years to detect a security breach. Containing and remediating a breach can take a long time, giving adversaries too much leeway to achieve their objective and inflict financial and reputational damage.
  3. Workforce resources are not keeping pace with the increased volume of attacks and sophistication of adversaries. More than 60% of organizations report that their security department is understaffed. Within four years, we will have a shortfall of nearly 2 million qualified cybersecurity professionals.

We recently surveyed over 2,000 IT security decision-makers around the world, and when asked what it would take to overcome these security challenges, they split roughly in half into two very different groups:

One group favored a best-of-breed approach, believing that self-integration of disparate technologies with manual processes delivers the best security outcomes. This is the traditional “defense in depth” school of thought, assuming that technology diversity drives a better overall security posture using human capital to make the parts into a system.

The other group favored an integrated platform approach, believing that an open and integrated security framework enabling consolidation and automation yields better overall security results. This group sees efficiency as a key component to success.

When you run the numbers, it becomes clear that we cannot solve the growing complexity and risk equation by throwing more people at the problem. Not only is there not enough grey matter to go around, the speed and scale of the problem demands the combined advantages of human and machine processing. Automation and orchestration will be essential components of security in 2017, and Ralphie needs to rewrite his Christmas list. 


Posted by CEOinIRVINE
l

Ask just about anyone the question “What distinguishes an automated (bot) session from a human-driven session?” and you'll almost always get the same first answer: “Speed.” And no wonder - it's our first intuition. Computers are just faster.


If you focus the question on credential brute-forcing, then it's even more intuitive. After all, the whole purpose of a brute-force attack is to cover as many options as possible, in the shortest possible time. Working quickly is just elementary, right?

Well, it turns out that this is not always the case. Most defenders, if not all, are already looking at speed and have created volumetric detections that are nothing more than time-based signatures. And that works, most of the time. But the attackers are getting smarter every day, and changing their attack methods. Suddenly, checking speed is no longer enough.

On the first week of October, we detected a credentials brute-force attack on one of our customers that commenced around 03:30am UTC. The attack, which lasted a few minutes shy of 34 hours, spanned a whopping 366,000 login attempts. Sounds like an easy case - 366K over 34 hours is over 10,000 attempts per hour. 

But an easy catch? Not by existing volumetric detections, because the attack did not originate from one single IP address. In fact, we discovered that well over 1,000 different IP addresses participated in this attack. Let's look at the distribution of attempts:

Image Source: PerimeterX
Image Source: PerimeterX

Of all the participating IP addresses, the vast majority (over 77%) of them appeared up to 10 times only, during the entire attack. While the minority may trigger a volumetric detection, 77% percent of the attacking IP addresses would go unnoticed.

One can argue that counting failed login attempts would come in handy here. And it indeed could, except that many of the brute-force attacks don't actually enumerate on passwords tirelessly. Instead, they try username/password pairs that were likely obtained from leaked account databases, gathered from other vulnerable and hacked sites. Since many people use the same password in more than one place, there is a good chance that some, if not many, of the login attempts will actually be successful. 


How Motivated Attackers Adapt
On a different attack we observed, nearly 230,000 attempts at logging in over 20 minutes were performed from over 40,000 participating IP addresses. The vast majority of IP addresses were the origin point of 10 or fewer attempts. A volumetric detection would simply miss this attack.

In comparison, a common volumetric detector is usually set to between 5 and 30 as a minimum, depending on the site’s specific behavior. Our data suggest that motivated attackers will adapt and adjust their numbers to your threshold, no matter how low it is. We also observed that the attack was incredibly concentrated within a very short detection window of only about 20 or 25 seconds.

Fake User Creation Attack
Let's look at one last distributed attack, on yet another client. This time, the attack is not about credentials brute-forcing but rather fake user creation. In this example, the largest groups of IP addresses used per attempt count were those that committed only 1 or 2 attempts:

Image  Source: PerimeterX
Image Source: PerimeterX

The entire attack was conducted in less than six hours.

How do the attackers get so many IP addresses to attack from? The answer lies in analyzing the IP addresses themselves. Our research shows that 1% were proxies, anonymizers or cloud vendors, and the other 99% were private IP addresses of home networks, likely indicating that the attacks were performed by some botnet (or botnets) of hacked computers and connected devices. Furthermore, the residential IP addresses constantly change (as in any home) rendering IP blacklisting irrelevant, and even harmful for the real users' experience.

Suspicious Indicators
We included in this post just a few representative examples (out of many more we detected) of large-scale attacks originating from thousands of IP addresses over a short time span. In the majority of these cases, detection was achieved by examining how users interacted with the website. The suspicious indicators included users accessing only the login page, filling in the username and password too fast or not using the mouse.

The implication of these attacks vary. They include theft of user credentials as well as fake user account creation, which in turn leads to user fraud, spam, malware distribution and even layer-7 DDoS on the underlying web application.

In conclusion, volumetric detections are simple and useful, but they are not sufficient. The attackers continue to improve their techniques, bypassing old-fashioned defenses. The new frontier in defense is in distinguishing bot behavior from human behavior – and blocking the bots.



Inbar Raz has been teaching and lecturing about Internet security and reverse engineering for nearly as long as he’s been doing that himself: He started programming at the age of 9 and reverse engineering at the age of 14. Inbar specializes in outside-the-box approaches to analyzing security and finding vulnerabilities; the only reason he's not in jail right now is because he chose the right side of the law at an earlier age. These days, Inbar is the principal researcher at PerimeterX, researching and educating the public on automated attacks on websites.



'Hacking' 카테고리의 다른 글

Major Cyberattacks On Healthcare Grew 63% In 2016  (0) 2016.12.27
A Cybersecurity Christmas Story  (0) 2016.12.27
Russian Hackers Run Record-Breaking Online Ad-Fraud Operation  (0) 2016.12.27
How to tell if an email is forged  (0) 2016.09.09
Jessica  (0) 2016.03.11
Posted by CEOinIRVINE
l

Russian Hackers Run Record-Breaking Online Ad-Fraud Operation

'Methbot' is a sophisticated cybercrime scheme that has hit major US advertisers and publishing brands and pilfered millions of dollars per day.


Cybercriminals out of Russia are behind a newly discovered massive online advertising fraud operation hiding in plain site that steals up to $5 million per day from big-name US advertisers by posing as some 6,000 major US media sites including The Huffington Post, Fortune, ESPN, CBS Sports, and Fox News, and generating fake ad impressions.

Researchers at White Ops recently spotted the so-called "Methbot" operation pilfering anywhere from $3 million to $5 million per day in what they say is the largest and most profitable online ad fraud operation in history. Methbot has been operating for three years under cover by a Russian cybercrime group that White Ops has dubbed "AFK14," with a unique twist: its own internal botnet infrastructure runs and automates the click-fraud rather than the traditional ad fraud model of infecting unsuspecting consumers to do the dirty work.

Sponsor video, mouseover for sound

US advertisers in October alone lost a whopping $17.7 million to the criminal hackers, according to White Ops, and AFK13 made some $10.6 million.

AFK13, which is based in Russia, also employs data centers in Dallas and Amsterdam, to run its botnet via spoofed IP addresses that help them evade blacklists. The cybercrime gang created its own Web browser in order to better hide its tracks, as well as its own HTTP library.

"This is the largest operation ever discovered in digital ad fraud," says Eddie Schwartz, president and COO of White Ops, an ad fraud detection firm, which published its findings on AFK13 and its Methbot infrastructure today. "This one is unique in that they went to the trouble of writing their own browser code … They game everything across the entire value chain" of online advertising, he says.

The Methbot network basically drives video and other ad impressions that appear to be humans clicking on them. But video ad "watching" is actually via its botnet of automated Web browsers of more than a half-million Internet addresses using phony IP registrations posing as large ISPs such as Verizon, Comcast, AT&T, Cox, and CenturyLink.

The botnet generates phony impressions for up to 300 million of these ads daily and sends them via 6,111 Internet domains posing as actual ad inventory on brand-name websites, according to White Ops.  

"Ad companies are losing because they're paying the bill" for phony impressions, White Ops' Schwartz says.

Methbot until recently was able to operate under the radar because the Russian cybergang behind it has apparently studied how to avoid detection, including reverse-engineering and duping ad-fraud measures and spoofing fraud verification data so the advertiser sees Methbot's ad impressions as legit, even though they're phony.

AFK13's Methbot has tallied some 200 million to 300 million phony video-ad impressions daily, making an average of $13.04 per CPM, or around $4 million in phony ad inventory revenue each day.

The Russian hackers even have built the bots to imitate mouse movements and social media login information so they appear to be human-generated activity. "They're making the traffic look like residential humans," Schwartz says.

He says the forged and compromised domains made them appear legit to the advertising exchange services that broker ad space inventory for publishers. The exchanges were fooled into believing they were handing the subsequent ad impressions to the publishers, but that phony yet billable traffic instead went to Methbot.

'Hacking' 카테고리의 다른 글

A Cybersecurity Christmas Story  (0) 2016.12.27
Brute-Force Botnet Attacks Now Elude Volumetric Detection  (0) 2016.12.27
How to tell if an email is forged  (0) 2016.09.09
Jessica  (0) 2016.03.11
CSD ExecGuide  (0) 2016.01.13
Posted by CEOinIRVINE
l

itune back up D drive

Apple 2016. 9. 23. 14:35

How-To Geek

How to Change the Backup Location of iTunes (or Any Windows App)

2013-05-27_130100

The vast majority of Windows applications park their backups and bulky data directories right on the primary partition. This means the precious space on your SSD is chewed up by backups, a less than ideal situation. Read on as we show you how to move your backups to a data disk.

Back Up and Protect Your Computer the Easy Way

Windows includes a number of backup and recovery tools for free, but the reality is that they aren’t anywhere near as good as commercial solutions. Carbonite automatically backs up all of your files, photos, and documents and stores them encrypted in the cloud.

Not only do you get cheap unlimited cloud backup, but you can also use Carbonite to backup your PC to a local hard drive. And you get versioning, deleted file protection, mobile apps so you can access your files from any device, and a whole lot more.

And for a limited time, How-To Geek readers get 2 free bonus months.

Backup Your PC or Mac with Carbonite Today

Why Do I Want to Do This?

Many people have switched to using a speedy Solid State Disk as their primary drive. These drives are known for their snappy response time, not their expansive storage capabilities. There’s no sense in storing bulky and infrequently accessed data like your iPhone and iPad backup files on your SSD.

Furthermore, in many instances, application functions will outright fail because the primary disk isn’t large enough. The last time we went to do a complete backup of our iPad before installing a new version of iOS, for example, the backup failed because out small-but-speedy SSD simply couldn’t hold the entire contents of the iPad. Modern applications simply assume you have a modern hulking 300GB+ primary hard drive with space to spare.

In today’s tutorial we’re going to look at a quick and painless way for Windows users to easily move their backup and/or data directories for iTunes (or any other Windows application that doesn’t support in-app backup/data directory changes) to a secondary disk.

What Do I Need?

You need precious little for this tutorial. The tools for adjusting the location of the directories within Windows are built right into Windows.

Beyond that, the only thing you’ll need is a secondary drive to move the backup data to. For this tutorial, we’ll be moving our backup data to the G:\ drive, but any large disk that isn’t your operating system disk will do.

Finally, although we’ll be specifically moving the iTunes backup directory to our secondary disk, you can use this trick to move any bulky data or backup directory off your small primary disk onto a larger secondary disk–you’ll just need to locate the data directory on your primary disk and adjust the commands accordingly.

Moving the Backup Directory via Symbolic Links

The magic that drives this entire operation is the symbolic links system. A symbolic link is effectively a very advanced shortcut that is transparent to the requesting application. After we move the iTunes backup directory, iTunes will never be the wiser (but the iTunes data will end up on the secondary disk). If you would like to read more about symbolic links, check out our Complete Guide to Symbolic Links (symlinks) on Windows or Linux. Otherwise, let’s dig in.

Create a new backup directory. Before we point an application at a new backup directory, we need a new backup directory. As we noted above, we’re going to redirect iTunes to the G:\ drive. In light of that, we’ve created a new folder “iTunes Backup” on the G:\ drive. Create a new backup folder on your secondary drive now.

Locate and rename the current backup directory. We need to locate the current iTunes backup directory and rename it.

2013-05-27_114246

Press the Start button. In the shortcut box paste the following:

“%APPDATA%\Apple Computer\MobileSync”

This will take you to the backup folder used by iTunes. Within that folder you will see a folder simply titled “Backup”. Rename that folder “Backup-Old”.

Open a command prompt. Hold down the SHIFT key and right click inside the explorer pane of the current folder (/MobileSync/). Select “Open command window here” to conveniently open a command prompt already focused on the current directory. 2013-05-27_121111

Create the symbolic link. At the command prompt, again ensuring you’re in the MobileSync directory, enter the following command (adjust the G:\iTunes Backup entry to point at your chosen backup directory):

mklink /J “%APPDATA%\Apple Computer\MobileSync\Backup” “G:\iTunes Backup”

The “mklink” command is the Windows shell command for creating a symbolic link and the “/J” switch creates a special type of symbolic link known as a Directory Junction, which will seamlessly redirect any applications that query the original Backup directory to the iTunes Backup on the secondary disk.

2013-05-27_121737

At this point you should see a folder with a shortcut icon in the \Mobile Sync\ folder, labeled Backup. If you click on this folder it will appear to open like a normal folder (you will not appear to switch over to the secondary drive like you would with a regular shortcut) but anything placed in this drive will be physically stored on the secondary disk.

Test the junction. If you can click on the link without an error, everything should be good to go, but we’re going to double check it to be safe. While in the \MobileSync\Backup directory (accessed via the new symbolic link you just created) right click and create a new text document as a temporary file place holder. After creating it, navigate to the actual backup directory you created on the secondary disk (in our case, G:\iTunes Backup\). You should see the file sitting in the directory. Delete the place holder file once you’ve confirmed that it is in the secondary directory.

Initiate an iTunes backup. Whether you’re following along with this tutorial to transfer the iTunes backup directory or the backup directory of another Windows application, the real test is whether or not the application works as intended with the symbolic link in place. Let’s fire it up and see.

After initiating the backup process, visit the backup directory on the secondary disk:

2013-05-27_124534

There we can see a brand new collection of backup files created at the time of our new backup. Success!

Copy the original backup data. In the beginning of the tutorial we renamed the Backup directory to Backup-Old. That Backup-Old directory contains all your old iTunes backup files. Now that we’ve successfully tested the symbolic link and performed a successful backup operation, it’s time to move the backup data to its new home.

Unlike a regular same disk-to-same disk transfer, this transfer will take a little longer as Windows copies the data through the symbolic link to the secondary disk. Once it has completed the copy you can again confirm that the data is safe on the secondary disk.

2013-05-27_124933

As you can see in the screenshot above, after we copied the iTunes backup directory, we freed up around 5GB of data on our primary disk. The entire process took around 5 minutes from start to finish and our reward is extra space on our primary disk,  and backup data stored on a secondary disk, and we can finally do a full device backup because there’s enough room for everyone to get along.

Jason Fitzpatrick is a warranty-voiding DIYer who spends his days cracking opening cases and wrestling with code so you don't have to. If it can be modded, optimized, repurposed, or torn apart for fun he's interested (and probably already at the workbench taking it apart). You can follow him on if you'd like.

  • Published 05/28/13

The VR Game That Will Take You on a Thrilling Quest

Edge of Nowhere blends adventure gameplay with elements of horror where nothing is what it seems. Now available for Rift!

Sponsored by Oculus

More Articles You Might Like


'Apple' 카테고리의 다른 글

iPad Apps Round-Up: Best Coolest Top Free iPad Apps for Music (So Far)  (0) 2010.04.08
iMAC ma comp.  (1) 2008.09.18
iPhone 3G  (0) 2008.09.18
[MAC] Screen Capture  (0) 2008.09.16
Posted by CEOinIRVINE
l