抱歉,您的浏览器无法访问本站

本页面需要浏览器支持(启用)JavaScript


了解详情 >

byc_404's blog

Do not go gentle into that good night

寒假主要是先出完了之前心心念念的typescript 题目,之后主要是抽点时间学golang.同学推荐的仓库讲的还是很不错的

https://github.com/unknwon/the-way-to-go_ZH_CN

从简单的开发与学习过程中可以感觉到golang的确非常安全,很多问题由于作为强类型的静态语言,从编译过程就能防止不安全的操作。因此大部分漏洞产生还是归结于依赖库(通常已经发展为CVE或者issue)以及开发者自身的操作漏洞。这里就作为小结,简单谈一谈

interger overflow/truncation

golang 存在非常经典的整数反转/溢出问题

对无符号数的反转

1
2
3
4
5
6
7
8
9
func main() {
var a uint32 = 2147483648
var b uint32 = 2147483648
var sum = a + b
fmt.Println(reflect.TypeOf(sum))
fmt.Printf("Sum is : %d",sum)
}
//uint32
//Sum is : 0

想要直接声明一个大小已经溢出的数自然不会通过编译,因此出现反转的话,主要是在变量的相加这样的计算才会会导致标志CF位反转

有符号数的溢出

1
2
3
4
5
6
7
var a int8 = 127
var b int8 = 1
var sum int8 = a + b
fmt.Println(reflect.TypeOf(sum))
fmt.Printf("Sum is : %d",sum)
//int8
//-128

具体的值可以看到math包中的常量定义。

在类型转换中,也会出现较大整型向较小整型转换的截断问题

1
2
3
4
5
var a int16 = 256
var b = int8(a)
fmt.Println(b)
// 0
// high-order byte is truncated

我们可以看到整型安全的检查也出现在了gosec中,一个比较经典的例子就是:kubectl命令行中出现了一个strconv.Atoi导致的截断问题。当我们传入port参数的对应字符串后,容器启动的端口这一参数会将经Atoi处理后的字符串进行int32的类型转换。由于64位系统的int是int64类型。转int32的话会出现明显截断
可以简化成以下代码:

1
2
3
4
v , _ := strconv.Atoi("4294967377")
s := int32(v)
fmt.Println(s)
// 81

这样就有可能导致81端口的服务启动,或者被停止。所以使用ParseInt ,ParseUInt会比较好。或者对端口号进行限制。

CTF中出现整数溢出的scenario 一般都是 xx shop之类的。通过重复的加数进行溢出然后鉴权。

pseudo-rand

golang 的math/rand 包中,我们可以看到随机数生成的函数形式

跟进一下函数与结构体

1
2
3
4
5
6
7
8
9
var globalRand = New(&lockedSource{src: NewSource(1).(*rngSource)})

......

func NewSource(seed int64) Source {
var rng rngSource
rng.Seed(seed)
return &rng
}

可以看到,这些随机数函数的seed默认为1.也就是说如果不使用rand.Seed()确认种子的话,生成的只是所谓的伪随机数。

这种问题可能会出现在开发者直接用rand生成的字符串作为密钥的场景,比如gin的cookie的key.从而导致本地复现,直接鉴权。

go net/http

net/http < 1.11 CRLF

低版本的http库会导致CRLF.比如http.NewRequest()。貌似是原本没有问题,但是在一次升级中疏忽了导致重新出现

现在会看到存在限制,我们无法传入\r\n的字符

WMCTF中的gogogo出现过这一漏洞,利用自然是通过CRLF发送POST请求进行绕过与上传。

weird stuff

在之前的justCTF中,出现了一道go题。题目原本的漏洞是由出题人发现的一个issuehttps://github.com/golang/go/issues/40940 加上其对fileServer一些代码的魔改组合的。

简单陈述下的话,题目提供了一个go http起的FileServer

1
http.Handle("/", http.FileServer(http.Dir("/tmp")))

flag就在其提供文件服务的文件夹下,但是,出题人加上了web服务的flag路由,从而使得我们没法通过直接访问/flag来获取文件。而是得到/flag路由的回显。

出题人的意图是利用其挖掘到的这个漏洞,造成错误的文件读取范围。通过访问其他文件越界读到flag.(http的Fileserver在我们访问时,会先根据我们访问的url进行一系列处理,杜绝路径穿越的url,之后进行文件读取返回给用户)

但是比较有意思的时,比赛中出现了一个非预期读flag的方式
curl --path-as-is -X CONNECT http://gofs.web.jctf.pro/../flag

简单说就是用CONNECT请求+路径穿越的url读取到了文件。我们看看源码是怎么处理的

如果是CONNECT方式请求,就不会处理url中的特殊字符。导致直接读取flag.其他的请求方法都会在cleanPath中被处理url

算是一个很有意思的问题。不过golang1.16似乎已经处理了。但是包括我在内的大部分应该还是使用的go1.15及以下版本,所以还是值得注意的

feature of slice

之前在做buu上的roarCTF时遇到一道go题,其中一个利用点来自Confidence CTF,其中用到了golang slice的一个feature

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
a := make([]uint64, 0)
a = append(a, 1)
a = append(a, 2)
a = append(a, 3)
b := append(a, 4)
c := append(a, 5)

fmt.Println(a)
fmt.Println(b)
fmt.Println(c)

//result:
//[1 2 3]
//[1 2 3 5]
//[1 2 3 5]

按照直觉来说,b这里应该是[1,2,3,4],但实际上却是[1,2,3,5]
这就与golang的slice也就是切片的结构相关了

1
2
3
4
5
type slice struct {
array unsafe.Pointer // ptr
len int
cap int
}

slice结构中的cap是按2的倍数扩容的。所以说当我们append(3)时会发生第一次扩容,此时len为3,cap为2*2=4.
执行b := append(a, 4)时,我们的4会被放在指针ptr的第四个位置。然后返回ptr len=4 cap=4给b。不过这并没有改变a的结构(slice只是指向内存的指针)之后进行c := append(a, 5)时,由于a没变,新元素只会覆盖之前b那放上的4.

那一道题目就是利用这点,可以通过先beg三次构造出len=3,cap=4的切片,通过题目中一个append超大随机数的机会,在下一次beg时达成元素覆盖。

这个可以算是slice的feature,还是很有意思的。

reDOS

原本是以为golang不存在reDOS的问题的。当初阅读lmt-swallow的文章时也看到他提到golang有linear time matching。 不过后来发现还是有途径的。

当然,reDOS主要还是在js里影响比较大,因为其事件队列阻塞对于web服务的影响是巨大的。相比之下其他的DOS影响可能就较小。用nginx做个处理基本就没有影响。不过,如果是以Blind regex injection为目的考虑reDOS的话,就另当别论了。

回到golang上。golang使用的正则引擎是re2。但是用的是无回溯机制(DFA)。
所以之前的payload如^(?=(PAYLOAD))((.*)*)*salt$就无效了

但是,通过其他方法制造延时仍然是可行的。比如re2对于{n}这样的正则,n存在有上限1000,且对于DFA状态数没有限制.我们可以通过不断重复(.?){1000}来制造足够的DFA状态进行一定程度上的延时

reDOS其实一直是一个很有意思的点,除了喜闻乐见的nodejs,前端中xss也可以导致这个问题,从而xsleak ,ruby中也有类似问题。当然,如果是从reDOS引申到正则盲注的话,sql注入中倒也有类似的情况。总之就是利用差异性进行数据提取。可惜因为太容易坏环境了,所以很难出道题到比赛中 :(

SSTI

最后一个就简单提一下ssti.要说golang这种静态编译还会出ssti还是挺难的( 除非源码中用sprintf 或者说拼接来构建template的参数

1
var tmpl = fmt.Sprintf(`<h2>No search results for %s</h2>`, xxx)

golang的template跟很多模板引擎的语法差不多,比如双花括号指定可解析的对象。.xxx表示一个对象的xxx属性。.就是当前作用域的当前对象,基本就跟handlebars里的this差不多。

假如我们传入的参数是可解析的,就有可能泄露template在执行过程中引入的对象内容(执行的本质就是合并替换)

简单的demo可以参考这里 https://blog.takemyhand.xyz/2020/05/ssti-breaking-gos-template-engine-to.html

如果传入的struct属性含有指针的话(非常常见,因为用指针可以节省很很多空间),我们ssti的回显就只是一个地址。需要我们手动去访问属性才会解引

Summary && Reference

简单的梳理下自己见过的golang安全问题(CTF-based web go)。其实像之前dasCTF中也有golang的题目,用gob序列化存内容到cookie,不过利用点与go的关系为0,所以不谈。

自己golang的开发还有很多值得去学的,这门语言确实有其优越之处以及一些可能存在并被挖掘的安全问题

https://github.com/tsg-ut/tsgctf2020
https://annevi.cn/2020/08/14/wmctf2020-gogogo-writeup/
https://github.com/golang/go/issues/30794
https://github.com/golang/go/issues/40940
https://github.com/mwarzynski/confidence2019_teaser_lottery

评论