[2021-05-15] webgoat 직렬화, OSS

Insecure login

• 3계층의 data를 패킷이라고 하지만, 넓은 의미에서 트래픽을 패킷이라고도 부르는데, 이 트래픽을 수집하는 프로그램이 패킷 스니퍼이다.
• F12에 http history와 비슷한 network 기능을 사용한다

 

실습

직렬화한 객체를 token에 넣고 submit하면 역직렬화한다.

 

이렇게 트래픽 상에서 password와 id를 캡쳐할 수 있으니 암호화의 중요성을 알 수 있다.

Insecure Deserialization(역직렬화)

직렬화는 객체를 형식에 맞춰 데이터로 전송하기 쉬운 형태로 만드는 것이다.

역직렬화는 데이터를 객체로 만드는 것이다.

XML,JSON 등이 있다.

직렬화: 객체를 나중에 복원할 수 있도록 데이터 형식으로 변환시키는 과정 객체를 저장하거나 전송하기 위해 직렬화를 수행한다

역직렬화: 직렬화의 반대로, 직렬화된 객체를 원래의 객체로 재구성하는 과정을 의미한다

오늘날 직렬화를 위해 가장 많이 사용되는 데이터 형식은 JSON

자체 직렬화 많은 프로그램 언어는 자체 직렬화 기능을 제공한다. 이러한 자체 기능은 신뢰할 수 없는 데이터로부터 악영향을 받을 수 있다.

 

데이터만이 직렬화의 대상이며, program code는 대상이 아니다.(=코드까지 모두 알 수는 없고 데이터만을 복원)

직렬화해서 보낸 것을 역직렬화 할 수 있다.

Known Affected Programming Languages

• PHP
• Python
• Ruby
• Java
• C
• C++

The Simplest Exploit

Vulnerable code

The following is a well-known example for a Java Deserialization vulnerability.

InputStream is = request.getInputStream(); ObjectInputStream ois = new ObjectInputStream(is); 객체 생성 AcmeObject acme = (AcmeObject)ois.readObject();

It is expecting an AcmeObject object, but it will execute readObject() before the casting ocurs. If an attacker finds the proper class implementing dangerous operations in readObject(), he could serialize that object and force the vulnerable application to performe those actions.

Class included in ClassPath

Attackers need to find a class in the classpath that supports serialization and with dangerous implementations on readObject().

직렬화 인터페이스를 상속하는 class가 있는 java 코드

`public class GadgetObject implements Serializable { String cmd;

private void readObject( ObjectInputStream stream ) throws Exception {

    Runtime.getRuntime().exec(cmd);

}

 

}`

Exploit

If the java class shown above exists, attackers can serialize that object and obtain Remote Code Execution.

`GadgetObject go = new GadgetObject(); go.cmd = "touch /tmp/pwned.txt";

ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeObject(go); oos.flush(); byte[] exploit = bos.toByteArray();`

 

가젯 체인: 역직렬화 시점에 이런 특징을 통해 악성 행위를 유발하는 가젯들의 모음을 가젯 체인(gadget chain)이라고 함

가젯(gadget): 특정 기능을 수행하는 부속품. 사용되는 상황에 따라 일부를 이루는 작은 소프트웨어나 함수가 될 수도, 특정 데이터가 될 수도, 소스코드가 될 수도 있다. 여기서의 가젯은 "공격용으로 악용 가능한 취약한 소스코드" 정도가 된다.

 

Gadgets Chain : 첫번째 가젯이 두번째 가젯의 어떤 행위를 유발하고 두번째 가젯이 세번째 가젯의 행위를 유발하는 가젯의 모음.

실습

직렬화한 객체를 token에 넣고 submit하면 역직렬화한다.

직렬화한 객체를 token에 넣고 submit하면 역직렬화하면 된다는 내용인데, 아무런 반응이 오지 않는다

따라서 웹고트의 코드를 분석하여 이를 해결해야 된다고 예상된다.

웹고트 파일의 압축을 해제하여 다음과 같이 코드를 찾는다.

 

웹고트 코드를 본다

성공이 되는 조건은 바로 delay가 7초 이하, 3초 이상일 때라고 볼 수 있다.

https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads/util

의 링크에 들어가서

의 java 파일을 확인하고 다운 받은뒤, 위와 같은 경로로 들어간다

이렇게 다운받고 위 처럼 들어가서 gadgets를 살펴본다

이 부분을 유의해서 본다

저 역슬래쉬 부분에 새로운 코드를 입력한다.

string cmd 변수에 java.lang.Thread.sleep(5000) 함수를 넣어준다.

이를 컴파일 해야하는데 ysoserial 사이트에서도 maven으로 컴파일하라고 권고가 되어있으니 아파치 maven 으로 컴파일을 하도록한다.

다음과 같이 입력

컴파일이 완료되면 target 폴더가 생긴다.

이제

target 을 들어가서 shell 명령창을 켜서

 java -Dhibernate5 -jar .\target\ysoserial-0.0.6-SNAPSHOT-all.jar Hibernate1 "12345" > result.txt

을 입력하고

certutil -encode .\result.txt .\text.txt 로 인코딩 명령을 수행한 txt파일을 새로 생성하면 된다.

이렇게 된 file의 줄 바꿈을 모두 지우고 submit하면 성공.

해당 명령은 5초의 delay가 나오도록 되었기 때문에 약간 기다려야한다.

 

Vulnerable Components

오픈소스 관리, 관련 위험 결정 시 BoM 작성에 관련된 내용

vulnerable components(재사용 목적의 부품개념의 소프트 웨어)

아티팩트 : 소프트웨어 개발 시 생성되는 다양한 산출물. 실행파일, 설계 문서, 소스코드, 개발자 문서

component : 다른 프로그램에서의 재사용을 목적으로 개발된 부품 개념의 소프트웨어이다.

모듈 Module : 기능을 구분하기 위한 목적으로 개발된 부품 개념의 소프트웨어. 일부 수정을 통해 재사용 가능하다.

BoM(Bill of Materials) : 부품표. 제품을 구성하는 부품의 명칭과 규격 등이 기록된 리스트 소프트웨어 관점으로 본다면 해당 소프트웨어에 사용된 오픈소스 소프트웨어(라이브러리, 프레임워크, 컴포넌트 등)의 리스트라고 볼 수 있다

오픈소스 goals

오픈소스 중요

오픈소스 관리 부족

오픈소스 컴포넌트 관련 위험 결정 BOM 중요성

 

1.깃허브

2.sourceforge

3.public binary repositories(라이센스 준수)

 

같은 버전에 대해 다른 유형 파일 재배포 가능

 

OWASP

웹고트가 owasp top 10을 기준으로 만들어졌다.

 

component are everywhere

동일 소스코드를 사용하더라도 버전 업데이트시 취약점이 없어질 수 있다

 

knowing the oss bill of material is the starting point

BoM:제품을 구성하은 부품의 명칭과 규격 리스트

Knowing the OSS "Bill of Materials" is the starting point

Modern applications are comprised of custom code and many pieces of open source. The developer is normally very knowledgeable about their custom code but less familiar with the potential risk of the libraries/components they use. Think of the bill of materials as the list of ingredients in a recipe.

Questions we should know the answer to:

• How do we know what open source components are in our applications?
  
  
  
• How do we define the risk of open source components?
  
  
• How do we discover the risk of open source components?
  
  
  
• How do we know when a component releases a new version?
  
  
• How do we know if a new vulnerability is found on what was previously a "good" component?
  
  
• How do we know if we are using the authentic version of an open source component?
  
  

How do I generate a Bill of Materials

There are several open source and paid-for solutions that will identify risk in components. However, there are not many tools that will deliver a complete list of "ingredients" used within an application. OWASP Dependency Check provides the ability to generate a bill of materials and identify potential security risk.

Dependency check uses several pieces of evidence to determine the library names. Below is a snippet of a report:

 

Security Information Overload

What’s important?

• Is my component exploitable?
  
  
• Is my component an authentic copy?
  
  
  

Security information is scattered everywhere

• Multiple sources of security advisories
  
  
  
• 600,000 GitHub events generated daily
  
  
  

Summary

• It is not reasonable to expect a developer to continually research each component.
  
  
• Developers are not security experts; they already have a day job.
  
  

License Information Overload

What’s important?

• Can I use this component within the context of distribution of my software?
  
  
• Are there license incompatibilities?
  
  
• If using a modified component, did I addressed additional license obligations?
  
  

License information is scattered everywhere

• Projects declare a license:
  
  
  
• Projects include licenses as headers in the source code.
  
  

Summary

• It is difficult to determine the scope of a license.
  
  
• A project often has license discrepancies.
  
  
• Developers are not lawyers .

Security Information Overload

What’s important?

• Is my component exploitable?
  
  
• Is my component an authentic copy?
  
  
  

Security information is scattered everywhere

• Multiple sources of security advisories
  
  
  
• 600,000 GitHub events generated daily
  
  
  

Summary

• It is not reasonable to expect a developer to continually research each component.
  
  
• Developers are not security experts; they already have a day job.
  
  

•  

요약 옛날 버전을 오래 사용할수록 위험하다.

Architecture Information

What’s important?

• Is my component old or is it stable
  
  
• Is my component unpopular
  
  
• Was my lack of upgrade a deliberate choice or a lack of knowledge
  
  

Summary

• It’s really difficult to keep components up to date
  
  

For the components analyzed in 25,000 applications it was found that:

• 8% of 2 year old components did not have a newer version
  
  
• 23% of 11 year old components did not have a newer version
  
  
• Older components make up the majority of the risk
  
  

Some Examples of OSS Risk

Commons Collections

In November of 2015, the Apache Commons Collections component latest release was 8 years old. Commons Collections was considered a reliable and stable component. A researcher found a way to exploit a deserialization issue in Commons Collections resulting in a remote code execution. The next day…​ everyone using Commons Collections was in a panic.

Ref: Thousands of Java applications vulnerable to nine-month-old remote code execution exploit

Dinis Cruz and Alvaro Munoz exploit of XStream

XStream, a relatively common XML and JSON parsing library, has a nasty little remote code execution.

Ref: Dinis Cruz Blog

pwntester/XStreamPOC

You may want to read the article(s) before trying this lesson. Let’s see if you can figure out how to exploit this in WebGoat.

 

OSS 위험 관련 예시

-Commons Collections

-XStream 원격코드 실행 취약점

-CVE-2013-7285 취약점 공격

 

Xstream 공격

 

실습

CVE-2013-7285(2013년에 7285번으로 입력된 취약점, XSTREAM)

직렬화 한 코드 :

복붙

 

이 취약점은 해결할 수 없는 것이

Xstream, 웹고트 서버의 라이브러리 XStream 버전이 맞지않아서 클리어할 수 없다.

.

Summary

• Open source consumption in modern day applications has increased.
  
  
• Open source is obtained from many different repositories with different quality standards.
  
  
• Security information on vulnerabilities is scattered everywhere.
  
  
• License information is often difficult to validate.
  
  
• Most teams don’t have a component upgrade strategy.
  
  
• Open source components are the new attack vector.
  
  

What to do

• Generate an OSS Bill of Materials.
  
  
  
• Baseline open source consumption in your organization.
  
  
• Develop an open source component risk management strategy to mitigate current risk and reduce future risk.