Author Archives: J.S Tomar

GPS Security: How vulnerable GPS is & what’s the alternative?

Abstract

Coordinated Universal Time, or U.T.C., the global reference for timekeeping, is beamed down to us from extremely precise atomic clocks aboard Global Positioning System (GPS) satellites. The time it takes for GPS signals to reach receivers is also used to calculate location for air, land and sea navigation……

The problem is that GPS signals are incredibly weak, due to the distance they have to travel from space, making them subject to interference and vulnerable to jamming and what is known as spoofing, in which another signal is passed off as the original. And the satellites themselves could easily be taken out by hurtling space junk or the sun coughing up a fireball. As intentional and unintentional GPS disruptions are on the rise, experts warn that our overreliance on the technology is courting disaster, but they are divided on what to do about it.

Impact of GPS Security

More than 10,000 incidents of GPS interference have been linked to China and Russia in the past five years. Ship captains have reported GPS errors showing them 20-120 miles inland when they were actually sailing off the coast of Russia in the Black Sea. well documented are ships suddenly disappearing from navigation screens while maneuvering in the Port of Shanghai. 

Alternative of GPS

“China, Russia, Iran, South Korea and Saudi Arabia all have eLoran systems because they don’t want to be as vulnerable as we are to disruptions of signals from space,” said Dana Goward, the president of the Resilient Navigation and Timing Foundation, a nonprofit that advocates for the implementation of an eLoran backup for GPS.

Read full story here

Must Read for developers: Thirteen rules for developing secure Java applications

The following ground rules offer a good foundation for building more secure Java applications.

Java security rule #1: Write clean, strong Java code

Vulnerabilities love to hide in complexity, so keep your code as simple as possible without sacrificing functionality. Using proven design principles like DRY (don’t repeat yourself) will help you write code that is easier to review for problems.  

Java security rule #2: Avoid serialization

This is another coding tip, but it’s important enough to be a rule of its own. Serialization takes a remote input and transforms it into a fully endowed object.

Java security rule #3: Never expose unencrypted credentials or PII

You must encrypt the password via a one-way cypher before persisting it to the database, and then do it again whenever comparing against that value.

Java security rule #4: Use known and tested libraries

For instance, if you are looking at using JSON Web Tokens to manage authentication and authorization, look at the Java library that encapsulates JWT, and then learn how to integrate that into Spring Security. Even using a reliable tool, it is fairly easy to bungle authorization and authentication. Be sure to move slowly and double check everything you do.

Java security rule #5: Be paranoid about external input

Whether it comes from a user typing into a form, a datastore, or a remote API, never trust external input.

SQL injection and cross-site scripting (XSS) are just the most commonly known attacks that can result from mishandling external input.

Java security rule #6: Always use prepared statements to handle SQL parameters

Anytime you build up an SQL statement, you risk interpolating a fragment of executable code. Knowing this, it’s a good practice to always use the java.sql.PreparedStatement class to create SQL

Java security rule #7: Don’t reveal implementation via error messages

Error messages in production can be a fertile source of information for attackers. Stack traces, especially, can reveal information about the technology you are using and how you’re using it. Avoid revealing stack traces to end users.

Java security rule #8: Keep security releases up to date

As of 2019, Oracle has implemented a new licensing scheme and release schedule for Java. Unfortunately for developers, the new release cadence does not make things easier. Nonetheless, you are responsible for frequently checking for security updates and applying them to your JRE and JDK.

Java security rule #9: Look for dependency vulnerabilities

There are many tools available to automatically scan your codebase and dependencies for vulnerabilities. All you have to do is use them.

Java security rule #10: Monitor and log user activity

Even a simple brute-force attack can be successful if you aren’t actively monitoring your application. Use monitoring and logging tools to keep an eye on app health.

Java security rule #11: Watch out for Denial of Service (DoS) attacks

Anytime you are processing potentially expensive resources or undertaking potentially expensive operations, you should guard against runaway resource usage.

Java security rule #12: Consider using the Java security manager

Java has a security manager that can be used to restrict the resources a running process has access to. It can isolate the program with respect to disk, memory, network, and JVM access.

Java security rule #13: Consider using an external cloud authentication service

Some applications simply must own their user data; for the rest, a cloud service provider could make sense.

Read more in

https://www.infoworld.com/article/2076837/twelve-rules-for-developing-more-secure-java-code.html

Glimpse of CyberWar: Hacker Tried to Poison Florida City’s Water Supply, Police Say

Here is the glimpse of a cyberwar where hackers are not leaving any chance to take human lives. All Industrial systems has serious security flaws and all of them impose life threatening situation if they are hacked. For instance, water supply, electric grid or nuclear plant etc. Read about this hack..

“The hacker changed the sodium hydroxide from about one hundred parts per million, to 11,100 parts per million,” Gualtieri said, adding that these were “dangerous” levels. When asked if this should be considered an attempt at bioterrorism, Gualtieri said, “What it is is someone hacked into the system not just once but twice … opened the program and changed the levels from 100 to 11,100 parts per million with a caustic substance. So, you label it however you want, those are the facts.”

Impacts of this hack

In smaller quantities, sodium hydroxide can cause severe skin burns and eye damage. Small amounts of sodium hydroxide are put in some cities’ drinking water supplies to prevent corrosion to pipes and to bring the pH up (it is a strong base).

The news highlights what could be a serious cyber and physical security breach, and raises questions about how secure access to such a sensitive system really was.

Read more:

https://www.vice.com/en/article/88ab33/hacker-poison-florida-water-pinellas-county

Web Solutions: How to enable newrelic monitoring in SpringBoot Application?

NewRelic is a very powerful tool to enable engineers, techops and devops to get insights about their application running in production. NewRelic can give you so many data points and you can resolve many modern enterprise problems. One of the need is to have enterprise application autoscale. And newrelic gives you many data points to automate server auto scaling.

How newrelic works?

Newrelic works with JavaAgent. With New Relic’s Java agent, you can track everything from performance issues to tiny errors within your code. New Relic’s Java agent monitors your Java app and provides visibility into the behavior of your JVM. After installing, you will be able to quickly monitor transactions, dive deep into errors, and more.

So let’s understand how to enable NEWRELIC in your spring boot application?

  • Download newrelic-java.zip using below commands. it does not require any authentication.
curl -O https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic-java.zip
  • Unzip “newrelic-java.zip” and goto newrelize-java folder.
  • Find newrelic.yml and open in editor.
  • Update license-key and app_name.
  • last step is to run application with javaagent newrelic.

If Springboot runs as a standalone jar file:

java -javaagent:/<Your Directory Path>/newrelic-java/newrelic.jar -jar SpringBootApp.jar

If Springboot is deployed in TOMCAT Container

First step is to deploy above newrelic-java.zip file in server where tomcat is running and make sure it is deployed outside of tomcat directory.

let's say.. tomcat is in /opt/tomcat and newrelic directory is /opt/newrelic-java/

To pass the -javaagent argument on Tomcat: You need to pass newrelic as javaagent into environment variables.

export JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/newrelic-java/newrelic.jar"

After setting JAVA_OPTS as environment variables, Restart the tomcat server and start exploring websites. After a few mins you should be able to see metrics in newrelic console.

References

https://docs.newrelic.com/docs/agents/java-agent/installation/include-java-agent-jvm-argument#Installing_on_Tomcat

Good Read: Domain Generating Algorithm (DGA)

Abstract

A Domain Generating Algorithm (DGA) is a program or subroutine that provides malware with new domains on demand or on the fly.

History

Kraken was the first malware family to use a DGA (in 2008) that we could find. Later that year, Conficker made DGA a lot more famous.

What’s the use?

The DGA technique is in use because malware that depends on a fixed domain or IP address is quickly blocked, which then hinders operations. So, rather than bringing out a new version of the malware or setting everything up again at a new server, the malware switches to a new domain at regular intervals.

An example of DGA in practice is C&C servers for botnets and ransomware. If we were able to block these or take them down, we would cut the link between the victims and the threat actor. Bots would no longer be able to fetch new instructions and machines infected with ransomware would be unable to request encryption keys and send user data.

The constant changing of the domain for the C&C server is also sometimes called “Domain Fluxing” or “Fast Fluxing”, which actually is a reference to an older technique based on abusing the DNS load balancing system.

Read more in

https://blog.malwarebytes.com/security-world/2016/12/explained-domain-generating-algorithm/